First of all, I agree that we need to do something. The current mechanisms we have for extending are not adequate. The fundamental problem is that to add a CAtype (or anything else), one needs to create a new namespace, which effectively wipes out backwards compatibility.
-local civic correctly points out that one can add a new namespace, and define any new element in that namespace. It proposes to do that without any constraint - anyone who wants to add an element would be free to define a new namespace and create a new element. The issue several of us have with that is that it will be very difficult to maintain interoperability. Since the threshold to add new namespaces with uncontrolled elements will be low, we would expect a great many such namespaces, with all kinds of elements that may have a local name which is very similar to another element in another namespace, but be different, or alternatively have two (local) names for the same thing. While this is not strictly speaking a problem, because of the uniqueness of the namespace, it seems very hard to do something like create a parser which could parse "Address Line 1" into a PIDF that would be likely to be acceptable to a server.
The basic idea that Martin and James want to push out is that 5139, which added CAtypes and fixed some problems with 4119 contains the LAST official IETF PIDF-LO namespace, and the schema is hereby considered inviolate. Now, that's probably an overstatement, but they really do want to lock down any further changes, and confine them to some new namespace, and never change the schema in 5139.
There is a compromise proposal on the table, which would work as follows:
We would create a new namespace in a new RFC. In that namespace, we would define two new CAtypes: extCAtype and localExtCAtype. These CAtypes would have a parameter "name". There would be two registries, the existing CAtype registry created by 5139 and a new one. New entries in the existing registry would be used with extCAtype as:
<newns:extCAtype name="STP">Avenue</newns:extCAtype>
The intention is that address elements with general use (like a street type prefix) would be defined in the existing registry with the existing management policy.
Entries in the new registry would be used with localExtCAtype. The management for the policy with localExtCAtype would be expert review, with the instructions to seek to avoid clear duplication or spelling but otherwise to be liberal in allowing new definitions. The registry ONLY intends to foster re-use, not become a barrier to actual new address elements. The option to define a new namespace would remain as is.
There is a problem with validation of location information using LoST. The proposal on the table is to extend the definition of the items in the <valid>, <invalid> and <unchecked> lists to allow a name like newns:extCAtype+STP (ie behave as if newns defined an element extCAtype+STP.
I am not thrilled with the LoST hack. I would prefer to actually fix the problem, but I recognize that means updating the schema, and thus the namespace for LoST, and we're back to the same issue. I can live with it if that is the consensus of the work group.
However, I am unhappy about promising that we will never update the schema for PIDF-LO or LoST. We are not that good. Mistakes have been made. New features will arise that won't be able to be done with new namespaces. For example, I would like to change the part of the schema that contains the CAtype elements from what is now SEQUENCE, because SEQUENCE implies a fixed order, and there have been suggestions for things where SEQUENCE is problematic (INT). Now, actually, if INT was done with extCAtype, SEQUENCE would work, because there is only repeated instances of extCAtype (and localExtCAtype), and they are in a different namespace from the 5139 namespace, so just consider this an example. I don't know what problems we will find, only that history suggests that will happen.
We should not make such promises. We may be able to avoid updating the schema this time, we might not the next time.
Brian
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
