I have several issues with what is described below, the first and foremost being that it only really describes central authority extensions. Certainly, this is one use case, but it is not the only one. For example the exclusive country clubs of southern America may decide to put wifi APs around their golf courses and write an iPhone application to provide information to players about a particular hole, so they need to define a series of local civic elements that include amongst other things the definition of a hole element. The scheme in the document allows this to occur without any impact to anyone else, why should the exclusive country clubs of southern America have to register an XML namespace with the IETF? No reason at all.
I think I agree that having a single central authority in a country to define what elements may be required to define a jurisdictional address is a good idea. If this is the case, then a single extension schema that needs to be recognized within a country is quite possible. Again I don't think that this needs to registered within the IETF. What is probably more useful, if a registry is of any use at all, is to have them register a link that points to the current national schema. This would make writing your web application below a snack.
"Our protocols don't have mechanisms that would allow the receiver to tell the sender what namespaces it understands. That makes this whole thing more than a little difficult to get interoperability, and indeed may doom the whole effort, but I personally think there is value in it, with registries."
This statement to me points out that we are not on the same page of understanding at all.
I don't see any cases where this is required. The only requirement is that if a node receives XML elements from a namespace it doesn't understand that it ignores them and passes it on as required and doesn't drop them on the floor. This is standard XML behaviour, so absolutely no change is required.
For example, a LIS in Albania must provide a series of elements that the Albania regulator has decided are required to define an address in Albania. The device with the HELD client in it comes from New Zealand, but the device discovers the local LoST server. The LIS provides the full address to the HELD client including the Albanian extensions. The HELD client doesn't understand these, so it ignores them, but passes the whole PIDF-LO, Albania extensions and all to the emergency application. This application extract the civic address, Albanian extensions and all, and passes it LoST. The LoST server is local in Albania and understands these extensions so the correct route is returned to the device.
Where in this example does any client require the server to tell it what namespaces it needs? If it is a jurisdictional requirement to provide these elements, then nodes in the jurisdiction will need to support them. If the LoSt server requires specific elements that are not specified, then it reports these back as qualified names according to the schema in 5222, and a qualified name includes the namespace, so even your assertion above is incorrect, the mechanisms do exist in the most critical of cases.
I disagree with the cleanliness statement below also, since the scope of what these elements are is local, and the code simplification really doesn't enter into it, if you are using an XML parser as this will be largely the same regardless of the namespace.
Cheers
James
________________________________________
From: Brian Rosen [br@brianrosen.net]
Sent: Wednesday, September 08, 2010 8:58 AM
To: Thomson, Martin
Cc: James M. Polk; Winterbottom, James; geopriv@ietf.org
Subject: Re: [Geopriv] New Version Notification for draft-winterbottom-geopriv-local-civic-00
We have some awareness that if there is to be precision, addressing is a national matter. Having one reference work per country is probably needed; indeed we agree that there needs to be one. We have experience with working on something that is formal and one per country (public ENUM), and the experience is bad. We need some informal way to have about one per country. The easy way is registry with expert review. NENA is a reasonable source of US addressing information, although URISA would be better, but if the expert looks into it even a little, NENA is appropriate. Joe Blow is not.
Having more than one per country, except when you have dueling experts, which is possible (disputed territories or internecine rivals) is bad.
My nightmare is being given the assignment to write a website form that accepts an address from anywhere in the world and create a PIDF that would be accepted anywhere in the world. Having to manage one namespace per country is bad enough. Possibly hundreds, or thousands, because there is no registry is mind-boggling. It's actually impossible - without a registry, you don't even know what namepaces are available.
Our protocols don't have mechanisms that would allow the receiver to tell the sender what namespaces it understands. That makes this whole thing more than a little difficult to get interoperability, and indeed may doom the whole effort, but I personally think there is value in it, with registries.
Within namespaces, we really do want the same kind of element to have the same element name. It's more than just cleanliness - it simplifies code if a milepost is a milepost, and not a mile-post. It's also easy.
On Sep 7, 2010, at 7:25 PM, Thomson, Martin wrote:
> This is doing nothing more than formalizing the extensibility scheme that is already provided for XML in such a way that it can be translated into RFC 4776. And this goes right to the heart of the extensibility philosophy of the work we do here.
>
> <rant>
> I find the idea that the IETF should maintain a monopoly on the definition of civic addresses offensive. The same goes for much of the work we do. It's an insult to the community that uses our stuff. Familiar as I am with the well-worn stories about the standard that was poisoned by proprietary extension, I simply don't buy into that ethos.
>
> We build protocols with extension in mind not only for the benefit of the IETF, but also to allow others to benefit.
>
> The cost is in occasional duplications of effort and interoperability problems. By the same measure that these sorts of genuine problems arise from the provided extension capability, they are also mitigated. If this capability was not provided, I propose that our standard would not be used at all, or it would be used in some altered state that would entirely prevent interoperability of the most basic functions. This doesn't prevent real problems from occurring, but we were never going to stop them in any case.
>
> Of course, I recognise and appreciate that others will have a different opinion. There are good reasons for tighter control in some cases. But not for civic addresses.
> </rant>
>
> --Martin
>
>> -----Original Message-----
>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
>> Behalf Of James M. Polk
>> Sent: Wednesday, 8 September 2010 8:14 AM
>> To: Winterbottom, James; Brian Rosen
>> Cc: geopriv@ietf.org
>> Subject: Re: [Geopriv] New Version Notification for draft-winterbottom-
>> geopriv-local-civic-00
> ...
>> see, this to me is a real problem - as I see "no one has to come to
>> the IETF to define new things" as creating something RIPE for
>> collisions, i.e., incompatible elements or descriptions that mean one
>> thing to one (group) and an entirely different thing to the other
>> (group).
>>
>> This, to me, breeds incompatibility - only to get worse over time.
>>
>> IANA is there to prevent this - and what you're suggesting is to
>> circumvent that registration (with associated document defining the
>> means/usage of such a/each new element.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
