In the development of -prefix, I asked our AD to ask around to see if there is some mechanism we could use to do this. There doesn't appear to be. The basic way any XML schema is updated is to create a new namespace. 5139 did this. It is not backwards compatible with the namespace in 4119, except that the extension point in 4119 would cover the additional elements 5139 introduced. A PIDF created by a 5139 compatible source would not be recognized by a 4119 compatible recipient - the namespace would not be recognized.
The authors of -local-civic wish to say that 5139 is the last such update, and there should be no more. Any additional elements should be added by adding new namespaces in addition to the one created by 5139.
-prefix fixes an obvious problem with both 4119 and 5139. Where "A Avenue" can be coded, "Avenue A" cannot be correctly coded. Similarly, where 123A Main St can be coded, A123 Main St cannot. This is clearly an issue, especially for Spanish, French and other languages where the thoroughfare type commonly precedes the street name. Is there really a defensible argument for why STP is not equal in every regard to STS? Is there really a good reason why 5139 can create a new namespace that effectively obsoletes the one in 4119, but -prefix cannot?
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.
This seems to be to be two extreme ends of the spectrum - if we follow current practice, we get a new namespace, break backwards compatibility, but have completely interoperable implementations. If we follow earlier versions of local-civic, we get chaos - new namespaces declared at the whim of the recipient and no interoperability.
-03 of -local-civic gets closer to a more rational world, but I think falls far short of a reasonable way to move forward. It does have a couple of ideas I find interesting, and perhaps we can come to some reasonable compromise on a way forward.
I don't think anyone is disagreeing with the notion that we would like a better way to extend PIDF-LO without breaking backwards compatibility. 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.
I believe that we need to maintain considerable control on how new elements are introduced to PIDF-LO. I agree that elements that really are only used in one or two countries probably ought not to have the same level of standardization as elements used in many countries. The level of review ought to reflect the generality. We have a registry for CAtypes, which gives us the basis for controlling new ones.
I really don't want to see a lot of local extensions to PIDF. It's ALWAYS possible to add a new namespace for a local extension, and I'm not at all proposing to change that. However, I think that should be a very rare occurrence where both ends know what is happening.
On the other hand, there are details to every country's addressing that need to be dealt with. 5774 recognizes this. I think that we should have one document per country that defines, precisely, how addresses are encoded for that country. I think the registry defined by 5774 allows implementations to know what is needed for any given country, and as the example in 5774 points out, adding new "fields" by encoding them in existing fields is relatively straightforward. It's not clear to me that we need anything for adding such fields other than the technique described in 5774.
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. I think the basic idea introduced in local-civic-03 of a CAtype that has a numeric CAtype embedded within it may be the way forward - which means getting out of adding CAtypes by introducing them as first class elements in a schema, in favor of having a generic extension extensionCAtype that references the CAtype index as a parameter, and is restricted to the values in the existing registry.
I think that would mean that we do in fact, reissue the base PIDF-LO schema one more time. We add the extensionCAtype, possibly including one or more of the proposed additional CAtypes (-prefix, -lamp-post, INT), either as defined XML elements or initial values that use the extensionCAtype. We do an update to the DHCP encoding that uses this extensionCAtype appropriately.
And, of course, we continue the practice defined in 5774 of documenting specific encoding for a country with a document listed in a registry.
Brian
On Oct 25, 2010, at 2:42 AM, Hannes Tschofenig wrote:
> Hi all,
>
> I just read through these two documents. For me a specification that extends the existing civic XML elements has to fulfill two requirements:
>
> 1) With any new extension there is the chance that the recipient does not understand it. Hence, the added element must be safe to ignored. [We ran into a similar issue with PIDF-LO dynamic and this requirement constraint our solution space.]
>
> 2) While the civic location can be copied from one protocol to the other without having the need to understand the semantic of each element in many cases (e.g. from HELD to LoST, from HELD to SIP Location Conveyance) there are cases where this is not true, such as DHCP to LoST. For this case the specification has to provide a description.
>
> draft-ietf-geopriv-prefix-00 focuses on a use case that appears quite narrow but there is obviously the question how to deal with the endless number of civic address extensions. I am missing the introduction of XML elements and how the two requirements above are reflected.
>
> I understand that draft-ietf-geopriv-prefix-00 is already quite far in the process but it nevertheless might we worthwhile to have a discussion about this topic.
>
> Ciao
> Hannes
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
