Nevertheless, as I said, I would like a better way.
I agree that people will extend. I am not advocating eliminating the possibility of a "private" namespace. However, I believe it is appropriate that IETF control "official" extensions that have broad applicability. Prefix is one such extension. "relative-location" is another. Adding new "official" CAtypes should be possible, with appropriate review.
I understand that to correctly parse an address into fields, or to render fields into human readable text, requires a per-country document, which means per-country code. It's unavoidable. However, we saw value in creating a list of common elements that many countries used in their addresses. I believe that remains a value, and it would be most unfortunate to have "Street Prefix" in one and "ThoroughfareType-Pre" in another that was exactly the same thing, used the same way as "STS" but before the street name. That is the value in having a formal extension path for CAtypes.
If we agree on that, then we need a way to create the XML. I really dislike 3 ways to do the same thing. Having a generic extension gives us one way to have an extended CAtype, rather than 3. It avoids adding a slew of namespaces. It continues the use of the CAtype registry, with its current policy for adding CAtypes. Given the example in 5774, that's really all we need.
Private extensions can use their own namespace, as they can now.
Brian
On Oct 25, 2010, at 7:10 PM, Thomson, Martin wrote:
> Hi Brian,
>
> I agree with Hannes. Backwards compatibility is more important than you seem to think.
>
> On 2010-10-26 at 01:46:17, Brian Rosen wrote:
>> Is there really a good reason why 5139 can create a new namespace that
>> effectively obsoletes the one in 4119, but -prefix cannot?
>
> Yes, there are two very good reasons.
>
> Use: Actual use of 4119 was rare to non-existent. 5139 is in use.
>
> Language: There was no allowance for language tags in 4119 - something that I'm sure you'll agree is handy. Adding language tags in any other way would have been extremely difficult.
>
>> It has always been possible to add a namespace and add elements to a
>> PIDF. The obvious problem is that anyone could declare such a
>> namespace, and then expect the rest of the world to generate PIDFs with
>> their namespace. This leads to non-interoperability, a point made in
>> the comments on earlier versions of -local-civic.
>
> There's a definite parallel on the apps-discuss list regarding extensions in the discussions on X-. The basic rule is that people will extend. When they do so, they don't necessarily seek interoperability. That comes later as the extension is seen to be useful.
>
> We need to provide a path toward interoperability. -local-civic describes how that works. "Interoperability or bust" is not a sentiment that I would like to have conveyed.
>
>> The current accepted IETF practice in this kind of
>> situation is to in fact issue a new namespace, which we all agree is
>> not very good.
>
> [citation required]
>
> Extensions go in new namespaces: yes. Extensions replace the original namespace: not from what I've seen.
>
> I'm not sure if I think this is very good or not. It's just how things are: a trade-off between competing considerations.
>
>> I think we will discover, from time to time, that new CAtypes, which
>> have relatively broad applicability, are needed. What we're searching
>> for is a way to add them without breaking backwards compatibility.
>
> Precisely. This is why my mind boggles when you recommend that we break backward compatibility.
>
> --Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
