Subject: [Geopriv] New Version Notification for draft-winterbottom-geopriv-local-civic-00

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 6 Sep 2010 08:41:09 +0800

Hi All,

There have been a number of discussions on this list, and a number of drafts that attempt to introduce new civic address types. The problem is that all of these drafts, as written, would require an update of the schema defined in RFC5139, and would likely require a new namespace. This issue with this is that it breaks backward compatibility for other specifications, such as LoST. It also has impact on equipment vendors that have implement the 5139 schema, and national organizations that have profiled their civic addresses to fit within the 5139 schema.

This draft describes a way that allows easy tension of the civic schema, without breaking backwards compatibility, and allows local authorities to define their own local address elements in such a way that they can have local significance without being open to misinterpretation by general applications.

Cheers
James

A new version of I-D, draft-winterbottom-geopriv-local-civic-00.txt has been successfully submitted by James Winterbottom and posted to the IETF repository.

Filename:   draft-winterbottom-geopriv-local-civic
Revision:   00
Title:            Specifying Local Civic Address Fields in PIDF-LO
Creation_date:    2010-09-06
WG ID:            Independent Submission
Number_of_pages: 7

Abstract:
This document describes how to specify local civic elements in the Geopriv civic schema maintaining backward compatibility with existing specifications and implementations.  Support for providing local civic elements over DHCP is also described.

James Winterbottom
Global Product Manager
Andrew GeoLENs
IP Location Product Portfolio
Email: [email-masked]<mailto:[email-masked]>
Phone: +61-2-42-212938
Mobile: +61-447-773-560

---

From: Brian Rosen <[email-masked]>
Date: Tue, 7 Sep 2010 09:41:01 -0400

While I am in favor of the basic idea this puts forth, I am opposed to the mechanisms described in this draft.

Let's take an example - Robins George and my "lamp-post" draft.  This would mean we wouldn't proceed with that draft, and NENA would just create a namespace with milepost in it.

There is no review and no registry for these namespaces - anyone can make one, and create a PIDF that conforms to it and recipients would be up the creek without the paddle if they didn't know this variant = no interoperability.

If Canada makes a namespace, and calls it mile-post when the U.S. one calls it milepost, tough, it's different (different name spaces).  This is not INT where I explicitly proposed to follow local signage and plans; it's the basic civic location.

The DHCP option stuff is truly ugly.  With a registry of namespaces, and some reasonable rules, we could get the triplet (namespace, element name, and value) into a single CAtype.

Instead, I would propose that we have registries for the namespaces with at least expert review, and elements within the namespace, and a more compact DHCP option.

Brian

On Sep 5, 2010, at 8:41 PM, Winterbottom, James wrote:

> Email: [email-masked]
> Phone: +61-2-42-212938
> Mobile: +61-447-773-560
>  
>  
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 8 Sep 2010 05:36:08 +0800

Hi Brian,

Comments in line.
________________________________________
From: Brian Rosen [[email-masked]]
Sent: Tuesday, September 07, 2010 8:41 AM
To: Winterbottom, James
Cc: [email-masked]
Subject: Re: [Geopriv] New Version Notification for draft-winterbottom-geopriv-local-civic-00

[AJW] Excellent. This is a good place to start from.

[AJW] Absolutely right, only applications that need to understand "lamp-post" would do so. Better still, organization don't need to come the IETF everytime they want to define a new element specific to their application. This is a win for everyone.

[AJW] Herein lies a great misconception. First of all this can and is done today already, XML allows this, and to a large extent encourages it. That is the XML examples in the document are perfectly legal civic examples today, and any device processing the civic schema needs to be able to handle this today. Absolutely nothing new,  the current behaviour is to ignore the additional elements it doesn't understand. Requiring the registrations of namespaces into the IETF by external organizations so that they can extend an XML schema that has been defined with extensions points is cumbersome, unnecessary and I would argue ultimately unmanageable.

No interaoperability is patently not true. The local extension schemas have clearly defined scope. This is defined by the namespace, and is applicable to the local application in mind. Fields cannot be misinterpreted by something outside of the context within which the element was specified. This is good design. You are talking variants, and I am talking contexts, and there is a world of difference, and the namespace provides this very clear clarification.

[AJW] You are right. The Canadian mile-post has significance in Canada only. But here is where I think you are misunderstanding something. The different namespace means that it is a completely different thing, their mile-post might represents the number of standard-begets from the Eiffel-tower. It isn't just a US mile-post in a different namespace. It is very difficult to misinterpret anything when it is defined in this fashion.

My very significant issues with INT, is that it is exactly the opposite! It is totally open to misinterpretation and arbitrary assignment. It has no definition of context, even within the domain that assigns it. So if it forms a basic part of the must implement everywhere there is no way to enforce usage or understanding leading to complete chaos.

Further to this, you cannot define INT in the fashion that your current draft does, without up versioning the civic schema. This requires a NEW representation of the civic schema. The impact of this is very large. People have implemented and are starting to deploy product that represents civic addresses using the schema defined in RFC5139. Further to this there are several national profiles of the 5139 schema that people have invested a lot of time producing. Up versioning the schema will require pretty much all implementations to require support for both. This is a very BAD idea.

[AJW] Yes, you could. This would however have significant impacts on how long your namespace is allowed to be, and how long the value can be. The method as defined means that the namespace only need to be sent once, and a number of local elements defined within that namespace can be sent following it. The method defined also eliminates the need to have artificial separators between the namespace, element and value. But if the group things that slamming these together into a single value is a good idea, it probably isn;t a show-stopped on my part.

[AJW] Requiring organizations to register their namespaces with the IETF is a very bad idea and for the reasons stated earlier is totally unnecessary.

Brian

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 07 Sep 2010 17:13:37 -0500

At 04:36 PM 9/7/2010, Winterbottom, James wrote:
>Subject: Re: [Geopriv] New Version Notification for 
>draft-winterbottom-geopriv-local-civic-00
>
>While I am in favor of the basic idea this puts forth, I am opposed 
>to the mechanisms described in this draft.
>
>Let's take an example - Robins George and my "lamp-post" 
>draft.  This would mean we wouldn't proceed with that draft, and 
>NENA would just create a namespace with milepost in it.
>
>[AJW] Absolutely right, only applications that need to understand 
>"lamp-post" would do so. Better still, organization don't need to 
>come the IETF everytime they want to define a new element specific 
>to their application. This is a win for everyone.

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.

>There is no review and no registry for these namespaces - anyone can 
>make one, and create a PIDF that conforms to it and recipients would 
>be up the creek without the paddle if they didn't know this variant 
>= no interoperability.
>
>[AJW] Herein lies a great misconception. First of all this can and 
>is done today already, XML allows this, and to a large extent 
>encourages it. That is the XML examples in the document are 
>perfectly legal civic examples today, and any device processing the 
>civic schema needs to be able to handle this today. Absolutely 
>nothing new,  the current behaviour is to ignore the additional 
>elements it doesn't understand.

but if you do not understand that I am using the same element to mean 
something entirely different, there is no ignoring rule applicable, 
just incompatibility because how you fill your element and how I fill 
my element - where they both look like the same XML element. This 
cannot work unless you have a means to prevent collisions.

>Requiring the registrations of namespaces into the IETF by external 
>organizations so that they can extend an XML schema that has been 
>defined with extensions points is cumbersome, unnecessary and I 
>would argue ultimately unmanageable.

I think it is quite necessary, and has to be manageable - even if 
some may think it takes too long or they do not wish to "go through 
the process".

James

>No interaoperability is patently not true. The local extension 
>schemas have clearly defined scope. This is defined by the 
>namespace, and is applicable to the local application in mind. 
>Fields cannot be misinterpreted by something outside of the context 
>within which the element was specified. This is good design. You are 
>talking variants, and I am talking contexts, and there is a world of 
>difference, and the namespace provides this very clear clarification.
>
>If Canada makes a namespace, and calls it mile-post when the U.S. 
>one calls it milepost, tough, it's different (different name 
>spaces).  This is not INT where I explicitly proposed to follow 
>local signage and plans; it's the basic civic location.
>
>[AJW] You are right. The Canadian mile-post has significance in 
>Canada only. But here is where I think you are misunderstanding 
>something. The different namespace means that it is a completely 
>different thing, their mile-post might represents the number of 
>standard-begets from the Eiffel-tower. It isn't just a US mile-post 
>in a different namespace. It is very difficult to misinterpret 
>anything when it is defined in this fashion.
>
>My very significant issues with INT, is that it is exactly the 
>opposite! It is totally open to misinterpretation and arbitrary 
>assignment. It has no definition of context, even within the domain 
>that assigns it. So if it forms a basic part of the must implement 
>everywhere there is no way to enforce usage or understanding leading 
>to complete chaos.
>
>Further to this, you cannot define INT in the fashion that your 
>current draft does, without up versioning the civic schema. This 
>requires a NEW representation of the civic schema. The impact of 
>this is very large. People have implemented and are starting to 
>deploy product that represents civic addresses using the schema 
>defined in RFC5139. Further to this there are several national 
>profiles of the 5139 schema that people have invested a lot of time 
>producing. Up versioning the schema will require pretty much all 
>implementations to require support for both. This is a very BAD idea.
>
>The DHCP option stuff is truly ugly.  With a registry of namespaces, 
>and some reasonable rules, we could get the triplet (namespace, 
>element name, and value) into a single CAtype.
>
>[AJW] Yes, you could. This would however have significant impacts on 
>how long your namespace is allowed to be, and how long the value can 
>be. The method as defined means that the namespace only need to be 
>sent once, and a number of local elements defined within that 
>namespace can be sent following it. The method defined also 
>eliminates the need to have artificial separators between the 
>namespace, element and value. But if the group things that slamming 
>these together into a single value is a good idea, it probably isn;t 
>a show-stopped on my part.
>
>Instead, I would propose that we have registries for the namespaces 
>with at least expert review, and elements within the namespace, and 
>a more compact DHCP option.
>
>[AJW] Requiring organizations to register their namespaces with the 
>IETF is a very bad idea and for the reasons stated earlier is 
>totally unnecessary.
>
>Brian
>
> > There have been a number of discussions on this list, and a 
> number of drafts that attempt to introduce new civic address types. 
> The problem is that all of these drafts, as written, would require 
> an update of the schema defined in RFC5139, and would likely 
> require a new namespace. This issue with this is that it breaks 
> backward compatibility for other specifications, such as LoST. It 
> also has impact on equipment vendors that have implement the 5139 
> schema, and national organizations that have profiled their civic 
> addresses to fit within the 5139 schema.
> >
> > This draft describes a way that allows easy tension of the civic 
> schema, without breaking backwards compatibility, and allows local 
> authorities to define their own local address elements in such a 
> way that they can have local significance without being open to 
> misinterpretation by general applications.
> >
> > Cheers
> > James
> >
> >
> > A new version of I-D, 
> draft-winterbottom-geopriv-local-civic-00.txt has been successfully 
> submitted by James Winterbottom and posted to the IETF repository.
> >
> > This document describes how to specify local civic elements in 
> the Geopriv civic schema maintaining backward compatibility with 
> existing specifications and implementations.  Support for providing 
> local civic elements over DHCP is also described.
> >
> >
> >
> > James Winterbottom
> > Global Product Manager
> > Andrew GeoLENs

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 8 Sep 2010 07:25:44 +0800

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: [email-masked] [mailto:[email-masked]] On
> Behalf Of James M. Polk
> Sent: Wednesday, 8 September 2010 8:14 AM
> To: Winterbottom, James; Brian Rosen
> Cc: [email-masked]
...

---

From: Brian Rosen <[email-masked]>
Date: Wed, 8 Sep 2010 09:58:14 -0400

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.

---

From: "Carl Reed" <[email-masked]>
Date: Wed, 8 Sep 2010 08:13:19 -0600

ISO TC 211(geomatics) has a relatively new Address Modeling activity 
(19160). They are collecting information on the existing addressing 
standards. Their goal is determine gaps and how better to craft the sharing 
of address content on an international basis. They are not inventing any new 
standards. They are aware of the work of OASIS and the IETF in this space (I 
briefed them).

I believe there are some slides I can share but I need to check first.

Regards

Carl

----- Original Message ----- 
From: "Brian Rosen" <[email-masked]>
To: "Thomson, Martin" <[email-masked]>
Cc: <[email-masked]>; "James M. Polk" <[email-masked]>
Sent: Wednesday, September 08, 2010 7:58 AM
Subject: Re: [Geopriv] New Version Notification 
fordraft-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.
>
>
>
>
>> 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
>>

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 08 Sep 2010 14:32:12 -0500

At 06:25 PM 9/7/2010, 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.

<my rant>
this rant is probably the least intelligent thing I've ever heard/read you say.
</my rant>

Now the facts:
The IETF created and "OWNS" the civic datum. They have every right to 
claim to be the ultimate source for its definitions, extensions and 
registrations - that is, until they collectively choose to give that 
right up (which they haven't).

you don't like it? Get the IETF to give up its rights to the datum -- 
but until then, deal with it!

James

>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
>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 8 Sep 2010 16:06:38 -0400

James,

I believe Martin's point is this: RFC 4119, 4776, and 5139 don't place  
any restriction on what can be done with the "##other" extension point  
in the schema.  So it is perfectly legal for any entity to put any XML  
entity in a civic address that it wants, as long as it's not from the  
namespace "urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr".

--Richard

On Sep 8, 2010, at 3:32 PM, James M. Polk 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.
>
> <my rant>
> The IETF created and "OWNS" the civic datum. They have every right  
> to claim to be the ultimate source for its definitions, extensions  
> and registrations - that is, until they collectively choose to give  
> that right up (which they haven't).
>
> you don't like it? Get the IETF to give up its rights to the datum  
> -- but until then, deal with it!
>
> James
>
>
>> <rant>
>> > Subject: Re: [Geopriv] New Version Notification for draft- 
>> winterbottom-
>> > geopriv-local-civic-00
>> ...

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 08 Sep 2010 16:13:53 -0500

>namespace "urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr".

Thanks for clarifying that point. I agree with what you say, but 
that's not how I read Martin's note about how offensive it is to him.

Brian and I (at least) are stating that registries prevent collisions 
and increase interoperability by understanding what a given element 
means. If some random other SDO or group of guys in a garage decide 
to define a <cl:HMO> element that isn't in line with RFC 4119, 4776, 
5139 *and* IANA -- they are increasing the likelihood of miscommunications.

Similarly if some random other SDO or group of guys in a garage 
decide to define it's a race condition to see who can define which 
new element -- believing that first come, first to defacto ownership 
of the name of the element.

James

>>> > Subject: Re: [Geopriv] New Version Notification for draft- winterbottom-
>>> > geopriv-local-civic-00
>>>...

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 9 Sep 2010 05:35:44 +0800

Hi James,

There is still a part I think that you are misunderstanding from both Martin and I are saying, and what the draft tries to state, though not clearly enough.

I would go as far as to propose that we do not define any further IETF civic address types that extend the existing civic schema. Any further extensions would be local and go into the namespace of the organization that required the extensions. In your example below cl:HMO cannot possibly have a clash using this scheme, the garage boys would define their HMO element in their namespace, and it could be a complex element if they want, and it ONLY has significance in their  context. If the civic object already has the following line xlms:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" then they can't even get the namespace prefix cl to prefix their elements with. Absolutely no possibility of a clash, because namespaces define scope, and I think that this is a point that is not perhaps being articulated by us very well.

Hopefully this clears things up a bit.

Cheers
James

________________________________________
From: James M. Polk [[email-masked]]
Sent: Wednesday, September 08, 2010 4:13 PM
To: Richard L. Barnes; James M. Polk
Cc: Thomson, Martin; Winterbottom, James; Brian Rosen; [email-masked]
Subject: Re: [Geopriv] New Version Notification for  draft-winterbottom-geopriv-local-civic-00

James

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 9 Sep 2010 06:01:20 +0800

Brian,

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 [[email-masked]]
Sent: Wednesday, September 08, 2010 8:58 AM
To: Thomson, Martin
Cc: James M. Polk; Winterbottom, James; [email-masked]
Subject: Re: [Geopriv] New Version Notification for draft-winterbottom-geopriv-local-civic-00

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 9 Sep 2010 07:50:33 +0800

All of that is moot when you consider that it is already possible for any entity to define their own namespace and civic address elements.  You can't take that ability back, so why waste time on it.

The registry exists when folks want to come and get some interoperability.

This draft shouldn't need to exist.  Mileposts (or mile-posts) are a foreign concept to most of the world [1], so a US authority is free to define them.  If they want to register a CAtype, there is nothing preventing this, and there is no need for an IETF publication.

If they want to define their own private extension instead, well, this was intended to enable that.

--Martin

p.s. I observe that the same arguments apply equally well to INT.  It's just that our positions are reversed.  The only significant difference is that there are (probably) pre-arranged semantics associated with these sorts of extensions, whereas INT is proudly semantic-free.

[1] http://www.allvoices.com/contributed-news/1098610-google-street/image/16214621

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Wednesday, 8 September 2010 11:58 PM
> To: Thomson, Martin
> We have some awareness that if there is to be precision, addressing is
> a national matter.  Having one reference work per country is probably
> 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.
> 
> 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.
> 
> 
> 
> 
> > We build protocols with extension in mind not only for the benefit of
> the IETF, but also to allow others to benefit.
> >
> 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.
> >
> different opinion.  There are good reasons for tighter control in some
> cases.  But not for civic addresses.
> > </rant>
> >
> > --Martin
> >

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 9 Sep 2010 07:52:19 +0800

James,

Namespaces in XML have inherent protection against collision.  The only viable concern is the interoperability one.  If you want that; we have a registry.

--Martin

---

From: Brian Rosen <[email-masked]>
Date: Thu, 9 Sep 2010 18:22:55 -0400

Nearly every IETF defined namespace has some kind of extension point to which some newer element can be attached.  There are no protocol police, so anyone can create anything using those extension points.  This is of course true with PIDF, it has always been true, and no one is suggesting changing it.

However, we nearly always require, in an IETF document sense, that extensions be defined in document and/or a registry, and that they have at least a modicum of IETF review before adding them to a registry.   We do this to foster interoperability and to prevent dumb things from happening.

A lot of protocol mechanisms work the same way - for example, we often have ABNF that is more permissive than the document actually defines.

In this case, some of use are saying that even though anyone can already add anything they want to a PIDF, and get a validated XML document, don't do that.

Brian

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 10 Sep 2010 09:04:12 +0800

I am saying that no rational argument has been provided for mandating the implementation of the registry machinery in terms of benefit to anyone including the IETF.

The one technical argument concerning protocols not providing support to indicate what namespaces they understand has been shown to be incorrect. All other arguments have boiled down to a lack of understanding of element scoping within XML.

Interoperability within jurisdictions is assured for any device if it follows basic XML rules, which it should already be following given the current specifications anyway.

All that I see in the arguments provided is a desire to have the IETF control what other organizations can do, and as Martin indicated previously, this borders on being offensive and is totally unnecessary. It wastes IETF and other organization resources and delays implementation and deployment creating a lose-lose environment for everybody.

Regards
James

> Sent: Friday, 10 September 2010 8:23 AM
> To: Thomson, Martin
> Cc: James M. Polk; Richard L. Barnes; Winterbottom, James;
> [email-masked]
> Nearly every IETF defined namespace has some kind of extension point to
> which some newer element can be attached.  There are no protocol police,
> so anyone can create anything using those extension points.  This is of
> course true with PIDF, it has always been true, and no one is suggesting
> changing it.
> 
> However, we nearly always require, in an IETF document sense, that
> extensions be defined in document and/or a registry, and that they have at
> least a modicum of IETF review before adding them to a registry.   We do
> this to foster interoperability and to prevent dumb things from happening.
> 
> A lot of protocol mechanisms work the same way - for example, we often
> have ABNF that is more permissive than the document actually defines.
> 
> In this case, some of use are saying that even though anyone can already
> add anything they want to a PIDF, and get a validated XML document, don't
> do that.
> 
> Brian
> 
> > Namespaces in XML have inherent protection against collision.  The only
> viable concern is the interoperability one.  If you want that; we have a
> registry.
> >
> > --Martin

---

From: Ted Hardie <[email-masked]>
Date: Fri, 10 Sep 2010 13:27:15 -0700

On Thu, Sep 9, 2010 at 6:04 PM, Winterbottom, James
<[email-masked]> wrote:
> All that I see in the arguments provided is a desire to have the IETF control what other organizations can do,
>

For what it is worth, that's not something I see in the discussion to
date at all.  The interoperability you achieve
with the xml namespace-based proposal without a registry is whatever
was initially standardized.  Each subsequent
jurisdiction that wants to add functionality does so independently.  I
agree with Brian that this is likely to mean that
un-reviewed later additions will overlap (but likely not perfectly).
Since the sender doesn't know what the
receiver supports, the sender can't fix it by mapping to namespaces
that the receiver *does* understand.  That means
the end device that doesn't understand "mile-post" but would have
understood "milepost" can send it along,
but can't actually use the data.

I think having a registry here helps by identifying what has already
been covered and fosters interoperability.
Having a reviewer helps further, but making a first-come first-served
registry to help folks identify what
has already been done.  I really don't seen how that level of support
from the IETF could be considered
control.

My two cents,

Ted Hardie

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 11 Sep 2010 06:12:39 +0800

Hi Ted,

[AJW] I want to make really sure that I understand what you are saying here.
Are you suggesting that different jurisdictions are defining different CATypes, e.g. Jurisdiction A defines CAType[100]=lamp-post and jurisdiction B defines CAType[101]=lamppost?
This is the only kind of real overlap that I can see, and the draft indicates why continuing to extend CATypes has significant ramifications and should not be done.
This really only leaves the option of adding new elements into a new XML namespace.
Can we agree on this to start with?
Otherwise we are not starting from the same premise. 

Other comments inline...

jurisdiction that wants to add functionality does so independently. 

[AJW] Do you agree that it does it within the jurisdiction though, and that the jurisdiction likely has the ability to require conformance?

 I agree with Brian that this is likely to mean that

[AJW] Okay, I see what you are saying, but I think that there are a couple of over simplifications in your example.
The first is that if I have two namespaces urn:orga:civicextension and urn:orgb:civicextension, and both define milepost,
<milepost xlmns:urn:orga:civicextension/> is not the same as <milepost xlmns:urn:orgb:civicextension/>, one cane define it as an integer, the other a complex element, and someone else a token. This is a very local thing and it should be.
So what I am trying to say is that the base-part, that everyone needs to understand, is defined in the 5139 schema. Extensions are local, and that not everything will understand them, but they must not discard them. This will ensure that the information is used by things that can use it, even if intermediaries can't. This will mean that local applications will work, but that a foreign application may not get everything it wants. Emergency services as per ECRIT will work fine using the above method. Personally I think this is okay.

[AJW] Because registry that Brian was proposing was a namespace registry, I didn't see a suggestion of also requiring them to register their schema extensions with the IETF. Even if they did, if the first come one had defined a lampost as a token within their namespace, and a second organization wanted to define a lamp-post as a token, for the second organization to pickup the first lamppost into their schema would result in a lot of unnecessary inclusions.

So this leads back to my initial question of whether people understand the concern raise din the document about the continuing addition of more and more CATypes, and how this impacts things already specified and implemented.

Cheers
James

---

From: Brian Rosen <[email-masked]>
Date: Fri, 10 Sep 2010 18:35:38 -0400

I proposed two registries:

One registered namespaces with (approximately) one per country.

One registered element tags with expert review to avoid duplication and consistent naming that can be as big as it needs to be.

I believe we all understand that an element in one namespace is distinct from an element in another in a syntactic/XML sense.  However, it is very useful to avoid mile-post vs milepost even if the XML tools are clear that they are not the "same" thing.  The point we are making is that they ARE the same thing and we should call them, and use them, the same way in any namespace that needs that kind of element.  XML is actually getting in the way here, but no one is proposing to actually do anything other than have some expert look at a new element name to see if it is already in the registry and the same element name can be re-used to avoid complexity and confusion.

Brian

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 11 Sep 2010 08:54:54 +0800

What you have said is clear, and I do understand it.
My concern is that this falsely lulls a node receiving an element named fred in one namesapce into believing that it is interchangeable  with fred in another namespace, and I think that this is a very dangerous precedent to set. If this is not the precedent that is trying to be set then I think that the second registry is redundant.

Cheers
James
________________________________________
From: Brian Rosen [[email-masked]]
Sent: Friday, September 10, 2010 5:35 PM
To: Winterbottom, James
Cc: Ted Hardie; Thomson, Martin; [email-masked]; James M. Polk
Subject: Re: [Geopriv] New Version Notification for draft-winterbottom-geopriv-local-civic-00

Brian

---

From: Ted Hardie <[email-masked]>
Date: Mon, 13 Sep 2010 09:51:33 -0700

> My concern is that this falsely lulls a node receiving an element named fred in one namesapce into believing that it is interchangeable  with fred in another namespace, and I think that this is a v…

I think the second registry actually shows tuples of (namespace,
element) so that someone considering
naming something ("newnamespace", "matched name") can consider whether
they 1) need to create
that element at all (instead re-using the existing one) or 2) whether
disambiguation might be useful
(e.g. using "track mile marker" instead of "milepost" for train track
mile markers, when "milepost" has
already been used to mean road mile markers).

regards,

Ted

---

From: Brian Rosen <[email-masked]>
Date: Mon, 13 Sep 2010 13:39:04 -0400

I suppose it depends on how fragmented you want these things to be. 

I was thinking that we would try to keep the number of namespaces down to (about) one per country.

If the U.S., say, was first to define "milepost", but the UK used milepost, would you want the UK to import the US namespace just to get the milepost definition?  It would clearly work, but I was thinking that the element registry didn't have the namespace, but that we encouraged reuse of the same entry in the registry for the same thing.

I'm okay either way.

Brian

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 14 Sep 2010 03:18:07 +0800

I would not support your approach Ted as I think it becomes horribly convoluted  very quickly.
I also don't think that we can limit the registry to one per country, this extension scheme is not proposed just for jurisdictional extensions, it is proposed for all extensions, including enterprise application extensions. So any assertion as to only a few number of namespaces is well grounded unless we are also saying that people don't have to register them. If we say the latter then we shouldn't expect anyone to register them.

Cheers
James

________________________________________
From: Brian Rosen [[email-masked]]
Sent: Monday, September 13, 2010 12:39 PM
To: Ted Hardie
Cc: Winterbottom, James; Thomson, Martin; [email-masked]; James M. Polk
Subject: Re: [Geopriv] New Version Notification for draft-winterbottom-geopriv-local-civic-00

I'm okay either way.

Brian

---

From: Brian Rosen <[email-masked]>
Date: Mon, 13 Sep 2010 16:13:46 -0400

If any enterprise can add anything it wants to a PIDF, then we have no interoperability unless all the apps knew about all of the enterprises.  This is impossible.

We can't stop any enterprise from doing this of course, and I don't want to.  However, I want to be able to write apps that can parse addresses all over the world.  With a finite number of namespaces listed in a registry, I have a reasonable chance to do that.

Brian

---

From: Ted Hardie <[email-masked]>
Date: Mon, 13 Sep 2010 13:19:47 -0700

> I would not support your approach Ted as I think it becomes horribly convoluted  very quickly.

Why?  Because of the multiple namespaces needed to parse the XML?

It's an interoperability trade-off.  If anyone can mint a namespace
and elements within it with no
registration (pace review for a minute), then you'll very quickly get
fragmentation in the extensions.
For extensions which are highly likely to overlap, that fragmentation
isn't needed, is bad for the
end-user, and could be avoided.  For those that don't, the key
questions are whether the barrier to
creating a registered extension is so high that it's a problem and
whether the number of interesting,
useful extensions coming from multiple namespaces gets out of hand.

For the second one, I would suggest that if this is likely to be a
problem, then the fragmentation
issue is equally serious.  Your mileage may vary.

regards,

Ted