Subject: [Geopriv] draft-ietf-geopriv-prefix-00 & draft-winterbottom-geopriv-local-civic

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 25 Oct 2010 09:42:48 +0300

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

---

From: Brian Rosen <[email-masked]>
Date: Mon, 25 Oct 2010 10:46:17 -0400

The essence of the question is: how do we extend PIDF-LO in a way that is backwards compatible?

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:

> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 26 Oct 2010 07:10:58 +0800

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

---

From: Brian Rosen <[email-masked]>
Date: Mon, 25 Oct 2010 20:04:26 -0400

While I am happy to hear that deployments of 5139 exist, we live in a world were it's upgrade or die. 

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 26 Oct 2010 10:29:08 +0800

I am sorry, but I don't see any rational argument for not including just the new elements into a new namespace beyond "oh I don't want to have multiple namespace declarations".

Brian, the impacts we are talking about if we continue with your approach are:
1)No end-point can be sure what namespace received CATypes should be put in to ensure they are understood.
2) LoST will need to change to support another Civic profile
3) All end-points will now need to support multiple civic schemas since they cannot be sure which one they will be given

And these just what I can think of without spending any time on the problem, yet all this work will need to be done because somebody doesn't want to see extra namespace declarations. I am sorry but I don't think that this is reasonable, and it leaves problems that I don't believe can be solved, without significant work by vendors.

Cheers
James

James Winterbottom
Global Product Manager
Andrew GeoLENs
IP Location Product Portfolio
Email: [email-masked]
Phone: +61-2-42-212938
Mobile: +61-447-773-560
 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian Rosen
> Sent: Tuesday, 26 October 2010 11:04 AM
> To: Thomson, Martin
> Cc: [email-masked]
> Subject: Re: [Geopriv] draft-ietf-geopriv-prefix-00 & draft-winterbottom-
> geopriv-local-civic
> 
> 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.
> 
> > 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.
> >
> > 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.
> >
> > 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.
> >

---

From: Marc Berryman <[email-masked]>
Date: Tue, 26 Oct 2010 14:17:24 +0000

I must agree with James,
If we allow insertions into the existing civic namespace, we will have interoperability issues. Appending them to the end of an existing namespace is allowed, but reconstituting the existing order of the civic namespace elements seems to be breaking interoperability, for the exact reasons James listed.
Vendors have been following RFC 5139 and other approved RFC documents, to change to another (or additional) civic namespace will take significant work, agreement, and time. 
It will not happen soon. LoST will need to be re-worked, with the possibility of multiple civic namespaces supported for backwards compatibility, there must be a means to determine which civic namespace is being used - which needs to be developed, and re-engineering must take place.  These and other problems this bring forth significantly delays in adopting a "moving target".
Marc 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Winterbottom, James
Sent: Monday, October 25, 2010 10:29 PM
To: Brian Rosen; Thomson, Martin
Cc: [email-masked]
Subject: Re: [Geopriv] draft-ietf-geopriv-prefix-00 & draft-winterbottom-geopriv-local-civic

Cheers
James

James Winterbottom
Global Product Manager
Andrew GeoLENs

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 26 Oct 2010 10:17:31 -0400

Let's take a second to look at requirements here:
1. Maintain IETF control of a registry of things that are REQUIRED
2. Allow "private" extensions that are OPTIONAL
3. Don't break backward compatibility with 5139

Of these three requirements, it seems like the only one that has a  
bearing on the *mechanism* for extensibility is the third, which  
basically says that new civic elements MUST be in a new namespace.

That seems to me to be orthogonal to the question of how we manage  
other extensions.  It seems like at a high level, what we want is a  
process something like what Martin mentioned with "X-" headers: Let  
people create their own proprietary extensions, and as useful ones  
emerge, move them toward a list of standard, mandatory extensions  
(each in a new namespace).

Really, the only differences between that idea and re-issuing the  
schema are (1) how many schemas a client has to recognize, and (2)  
breaking backward-compatibility.  We can help mitigate (1) even  
further by constraining extension schemas to have the same basic  
structure as the current schema, i.e., to be a flat list of types.   
Then the only change would be that an address would change from being  
a list of (name, value) tuples to a list of (namespace, name, value)  
tuples, which it is implicitly anyway, and which can have a nice  
serialization into DHCP.

(Having written some code that implements RFC 5139, this is how I  
handle CAType elements *anyway*, by cosntructing a mapping between  
full names (namespace + localName) and values.)

Assuming that mechanism, the only thing you need to do to manage the  
extension process is add a field to the IANA CAType table for  
"namespace".  When you want to create an "official" extension, you  
just add the relevant items to the table tagged with the extension  
namespace.

Does that maybe sound closer to reasonable?

--Richard

On Oct 25, 2010, at 8:04 PM, Brian Rosen wrote:

> I agree that people will extend.  I am not advocating eliminating  
> the possibility of a "private" namespace.  However, I believe it is  
> 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.
>
> 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.
>
>> 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.
>>
>> 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.
>>
>> describes how that works.  "Interoperability or bust" is not a  
>> sentiment that I would like to have conveyed.
>>
>> 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.
>>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 26 Oct 2010 10:46:02 -0400

If you would please concentrate on what I proposed, we could perhaps make some more rapid progress.

I proposed having ONE new element = extensionCAtype, which very similar to one part of your proposal. 
<extCAtype "CAname="STP">Avenue</extCAtype>

Endpoints have one (or maybe two) namespaces.  We don't have to mint new ones for any new extensions.

LoST does need to change, once, but not again, although it's backwards compatible with the current extension point.  The only reason it needs to change is that there are parameters to extCAtype.  I think your proposal has the same issue.

Endpoints support  ONE (or maybe 2) schema(s).  If they don't understand any given CAtype, they can pass it, or ignore it.

There is ONE way to express any new CA, extCAtype.

Brian

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 26 Oct 2010 15:40:15 -0400

The appropriate question would seem to be in what namespace this  
<extCAtype> element lives. If it's in a new namespace, then there's no  
break in backward compatibility.  Also, there would be no need to  
change LoST, since the LoST civic profile is defined by reference to  
RFC 5139, which accommodates additional namespaces.

--Richard

On Oct 26, 2010, at 10:46 AM, Brian Rosen wrote:

> LoST does need to change, once, but not again, although it's  
> backwards compatible with the current extension point.  The only  
> reason it needs to change is that there are parameters to  
> extCAtype.  I think your proposal has the same issue.
>
> Endpoints support  ONE (or maybe 2) schema(s).  If they don't  
> understand any given CAtype, they can pass it, or ignore it.
>
>> I am sorry, but I don't see any rational argument for not including  
>> just the new elements into a new namespace beyond "oh I don't want  
>> to have multiple namespace declarations".
>>
>> 3) All end-points will now need to support multiple civic schemas  
>> since they cannot be sure which one they will be given
>>
>> And these just what I can think of without spending any time on the  
>> problem, yet all this work will need to be done because somebody  
>> doesn't want to see extra namespace declarations. I am sorry but I  
>> don't think that this is reasonable, and it leaves problems that I  
>> don't believe can be solved, without significant work by vendors.
>>
>> Cheers
>> James
>>
>>
>>
>> James Winterbottom
>> Global Product Manager
>> Andrew GeoLENs
>>> While I am happy to hear that deployments of 5139 exist, we live  
>>> in a
>>> world were it's upgrade or die.
>>>
>>> the
>>> is
>>> render
>>> gives us
>>>> I agree with Hannes.  Backwards compatibility is more important  
>>>> than you
>>> seem to think.
>>>>
>>>> something
>>>> things
>>>> Precisely.  This is why my mind boggles when you recommend that  
>>>> we break
>>> backward compatibility.
>>>>
>>>> --Martin
>>>

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 27 Oct 2010 03:46:49 +0800

Agreed Richard.
________________________________________
From: Richard L. Barnes [[email-masked]]
Sent: Tuesday, October 26, 2010 2:40 PM
To: Brian Rosen
Cc: Winterbottom, James; [email-masked]; Thomson, Martin
Subject: Re: [Geopriv] draft-ietf-geopriv-prefix-00 & draft-winterbottom-geopriv-local-civic

--Richard

---

From: Brian Rosen <[email-masked]>
Date: Tue, 26 Oct 2010 16:23:31 -0400

The better part of valor would be to say that we define extCAtype in a new namespace and preserve backwards compatibility.

I actually think there are so few deployments that we could redo the schema with a new namespace, which would make it much cleaner for the 99.9999% of implementations that come after the handful that are around now.  You are forcing two namespaces where one will do for a very small deployment upgrade.

But I'll go with WG consensus on that.  The important parts to me are:
a) Controlled expansion of the CAtypes registry
b) Common use CAtypes are always named, defined, and used consistently
c) Limited (1 or 2) namespaces for any global address, with possible per country tweaks as in 5774
d) Only one way to encode an extension (from here on in) CAtype, not 3.

If I might add a bit of a wrinkle:
I'd like to add two generic parameters to extCAtype, so that a new CAtype could be defined that used them.
One example of that would be the INT (which had parameters), but there are others.

Brian

On Oct 26, 2010, at 3:40 PM, Richard L. Barnes wrote:

> The appropriate question would seem to be in what namespace this <extCAtype> element lives. If it's in a new namespace, then there's no break in backward compatibility.  Also, there would be no need to change LoST, since the LoST civic profile is defined by reference to RFC 5139, which accommodates additional namespaces.
> 
> --Richard
> 
> 
> 
>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 26 Oct 2010 17:36:25 -0400

Another wrinkle, just to make sure there's common understanding: This  
approach does *not* prevent people from adding "private" extension  
elements from other namespaces.  It just provides a more extensible  
way forward for "official" CAtypes.

It also kind of disclaims any responsibility for what the private  
extensions should look like.  I think it might be nice to at least  
make some recommendations about that, e.g., suggesting a CAtype-like  
type/value list or saying something about DHCP serialization.  (Note,  
though, that this path kind of leads back toward the -local-civic DHCP  
concepts.)

--Richard

On Oct 26, 2010, at 4:23 PM, Brian Rosen wrote:

> The better part of valor would be to say that we define extCAtype in  
> a new namespace and preserve backwards compatibility.
>
> I actually think there are so few deployments that we could redo the  
> schema with a new namespace, which would make it much cleaner for  
> the 99.9999% of implementations that come after the handful that are  
> around now.  You are forcing two namespaces where one will do for a  
> very small deployment upgrade.
>
>> <extCAtype> element lives. If it's in a new namespace, then there's  
>> no break in backward compatibility.  Also, there would be no need  
>> to change LoST, since the LoST civic profile is defined by  
>> reference to RFC 5139, which accommodates additional namespaces.
>>
>> --Richard
>>
>>
>>
>>
>>>> I am sorry, but I don't see any rational argument for not  
>>>> including just the new elements into a new namespace beyond "oh I  
>>>> don't want to have multiple namespace declarations".
>>>>
>>>> And these just what I can think of without spending any time on  
>>>> the problem, yet all this work will need to be done because  
>>>> somebody doesn't want to see extra namespace declarations. I am  
>>>> sorry but I don't think that this is reasonable, and it leaves  
>>>> problems that I don't believe can be solved, without significant  
>>>> work by vendors.
>>>>
>>>> Cheers
>>>> James
>>>>
>>>>
>>>>
>>>> James Winterbottom
>>>> Global Product Manager
>>>> Andrew GeoLENs

---

From: Brian Rosen <[email-masked]>
Date: Tue, 26 Oct 2010 17:55:31 -0400

Agree on both points

We could do something gross like have a FCFS registry for local CAtypes whose only purpose really is to allow extCAtype to be used in DHCP and other similar mechanisms, but I think a private namespace is a cleaner approach.

Brian
On Oct 26, 2010, at 5:36 PM, Richard L. Barnes wrote:

> Another wrinkle, just to make sure there's common understanding: This approach does *not* prevent people from adding "private" extension elements from other namespaces.  It just provides a more extensible way forward for "official" CAtypes.
> 
> It also kind of disclaims any responsibility for what the private extensions should look like.  I think it might be nice to at least make some recommendations about that, e.g., suggesting a CAtype-like type/value list or saying something about DHCP serialization.  (Note, though, that this path kind of leads back toward the -local-civic DHCP concepts.)
> 
> --Richard
> 
> 
>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 26 Oct 2010 18:11:10 -0400

Ok, good, hope we're converging here.  To tighten up the proposal a  
little:

1. An "official extension" namespace with a single element
<ext:caElement type="thing">fnord</ext:caElement>
Values for the 'type' attribute MUST be registered in the standard  
IANA registry.  DHCP serialization via standard RFC 4776 use of CAtype  
numbers.

2.a. A "private extension" namespace with a single element
<priv:caElement type="other-thing">fnord</priv:caElement>
(This could actually be done in the same namespace as the "official"  
one).  Values for the 'type' attribute SHOULD be registered in a new  
FCFS registry and MUST NOT be in the "official CAType" registry.    
DHCP serialization via a new civic address element
+-------------+----------+--------+---------+
| CAType=PRIV | CALength | CAName | CAValue |
+-------------+----------+--------+---------+

2.b. A template for private extensions recommending that they have the  
same "list of elements" structure
<priv:XYZ>fnord</priv:XYZ>
(Type values == element names are unconstrained.)  DHCP serialization  
via a new civic address element
+-------------+----------+-------------+--------+---------+
| CAType=PRIV | CALength | CANamespace | CAName | CAValue |
+-------------+----------+-------------+--------+---------+

On Oct 26, 2010, at 5:55 PM, Brian Rosen wrote:

> Agree on both points
>
> We could do something gross like have a FCFS registry for local  
> CAtypes whose only purpose really is to allow extCAtype to be used  
> in DHCP and other similar mechanisms, but I think a private  
> namespace is a cleaner approach.
>
> Brian
>> Another wrinkle, just to make sure there's common understanding:  
>> This approach does *not* prevent people from adding "private"  
>> extension elements from other namespaces.  It just provides a more  
>> extensible way forward for "official" CAtypes.
>>
>> make some recommendations about that, e.g., suggesting a CAtype- 
>> like type/value list or saying something about DHCP serialization.   
>> (Note, though, that this path kind of leads back toward the -local- 
>> civic DHCP concepts.)
>>
>> --Richard
>>
>>
>>
>>> The better part of valor would be to say that we define extCAtype  
>>> in a new namespace and preserve backwards compatibility.
>>>
>>> I actually think there are so few deployments that we could redo  
>>> the schema with a new namespace, which would make it much cleaner  
>>> for the 99.9999% of implementations that come after the handful  
>>> that are around now.  You are forcing two namespaces where one  
>>> will do for a very small deployment upgrade.
>>>
>>>> <extCAtype> element lives. If it's in a new namespace, then  
>>>> there's no break in backward compatibility.  Also, there would be  
>>>> no need to change LoST, since the LoST civic profile is defined  
>>>> by reference to RFC 5139, which accommodates additional namespaces.
>>>>
>>>> --Richard
>>>>
>>>>
>>>>
>>>>
>>>>>> including just the new elements into a new namespace beyond "oh  
>>>>>> I don't want to have multiple namespace declarations".
>>>>>>
>>>>>> 1)No end-point can be sure what namespace received CATypes  
>>>>>> should be put in to ensure they are understood.
>>>>>> 3) All end-points will now need to support multiple civic  
>>>>>> schemas since they cannot be sure which one they will be given
>>>>>>
>>>>>> problems that I don't believe can be solved, without  
>>>>>> significant work by vendors.
>>>>>>
>>>>>> Cheers
>>>>>> James
>>>>>>
>>>>>>
>>>>>>
>>>>>> James Winterbottom
>>>>>> Global Product Manager
>>>>>> Andrew GeoLENs
>>>>>>> While I am happy to hear that deployments of 5139 exist, we  
>>>>>>> live in a
>>>>>>>> I agree with Hannes.  Backwards compatibility is more  
>>>>>>>> important than you
>>>>>>> seem to think.
>>>>>>>>
>>>>>>>> Precisely.  This is why my mind boggles when you recommend  
>>>>>>>> that we break
>>>>>>> backward compatibility.
>>>>>>>>
>>>>>>>> --Martin
>>>>>>>

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 27 Oct 2010 06:24:25 +0800

I am not really in favour of type 2a. My rationale being that I think that this doesn't fit well with how one would validate it in something like LoST in a consistent way. The proposal in the appendix of the local-civic draft is a hack, but it works because the namespace is known, and so this is blended into the element name. 2b works fine, because elements in LoST validation are qnames and so are qualified by the namespace or prefix.  

Anything you want to do with 2a can be done with 2b, and 2b plays nicely with other things.

I think that for 2a to be a serious contender as an option there needs to be a strong case made for it and there needs to be a consistent way to over come the LoST interaction problem I described.

Cheers
James

James Winterbottom
Global Product Manager
Andrew GeoLENs
 
> From: Richard L. Barnes [mailto:[email-masked]]
> Sent: Wednesday, 27 October 2010 9:11 AM
> To: Brian Rosen

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 26 Oct 2010 18:43:42 -0400

How does 2.a. cause a problem with LoST?  Or, is it that 2.a. causes a  
problem with LoST while 2.b. doesn't?  The only difference is the  
number of extension namespaces/schemas.

--Richard

On Oct 26, 2010, at 6:24 PM, Winterbottom, James wrote:

> I am not really in favour of type 2a. My rationale being that I  
> think that this doesn't fit well with how one would validate it in  
> something like LoST in a consistent way. The proposal in the  
> appendix of the local-civic draft is a hack, but it works because  
> the namespace is known, and so this is blended into the element  
> name. 2b works fine, because elements in LoST validation are qnames  
> and so are qualified by the namespace or prefix.
>
> I think that for 2a to be a serious contender as an option there  
> needs to be a strong case made for it and there needs to be a  
> consistent way to over come the LoST interaction problem I described.
>
> Cheers
> James
>
>
> James Winterbottom
> Global Product Manager
> Andrew GeoLENs

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 27 Oct 2010 06:49:14 +0800

Perhaps I should have clarified, the problem is caused with LoST validation.
LoST validation elements are returned as qualified names, namespace+element or if you have a namespace+prefix defined in the same scope then prefix+element. When you introduce a common element name, with a "type" to distinguish between the actual elements as 2a is doing, there is no way to communicate to the thing requesting validation what actually validated and what didn't.

This problem doesn't exist with 2b.
The appendix in the local-civic draft hacks its way around this problem because the CATypeExt namespace is known, I don't think that this hack works well/at-all for an arbitrary namespace.

Cheers
James

James Winterbottom
Global Product Manager
Andrew GeoLENs

> Sent: Wednesday, 27 October 2010 9:44 AM
> To: Winterbottom, James
> Cc: Brian Rosen; [email-masked]; Thomson, Martin

---

From: Brian Rosen <[email-masked]>
Date: Tue, 26 Oct 2010 20:44:59 -0400

I understand this, but I'd rather fix it then use the mechanisms you invented.   I think the FCFS registry is a good idea.

It's not a deal breaker to me, but we're early enough that I think it's worth doing it cleanly.

Brian

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 27 Oct 2010 08:50:40 +0800

Changing the protocols and namespaces of well defined things is a deal breaker for me at this point, and it is a deal breaker for many vendors and standards bodies that have already implemented or profiled against existing specifications.

It is an industry requirement at this point that the changes don't impact these. You might not like the mechanism in local-civic but it address what the industry requires and still allows the extensions necessary.

Cheers
James

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Wednesday, 27 October 2010 11:45 AM
> To: Winterbottom, James
> Cc: Richard L. Barnes; [email-masked]; Thomson, Martin
> I understand this, but I'd rather fix it then use the mechanisms you
> invented.   I think the FCFS registry is a good idea.
>
> > LoST validation elements are returned as qualified names,
> namespace+element or if you have a namespace+prefix defined in the same
> scope then prefix+element. When you introduce a common element name, with
> a "type" to distinguish between the actual elements as 2a is doing, there
> is no way to communicate to the thing requesting validation what actually
> validated and what didn't.
> >
> > The appendix in the local-civic draft hacks its way around this problem
> because the CATypeExt namespace is known, I don't think that this hack
> works well/at-all for an arbitrary namespace.
> >
> > Cheers
> > James
> >
> >
> > James Winterbottom
> > Global Product Manager
> > Andrew GeoLENs

---

From: Marc Berryman <[email-masked]>
Date: Wed, 27 Oct 2010 12:03:16 +0000

I agree with James, vendors and other standard bodies have already put in a lot of time and effort to make this work today within the existing specs.

Any deviation will delay implementation considerably.

Marc B.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Winterbottom, James
Sent: Tuesday, October 26, 2010 8:51 PM
To: Brian Rosen
Cc: [email-masked]; Thomson, Martin
Subject: Re: [Geopriv] draft-ietf-geopriv-prefix-00 & draft-winterbottom-geopriv-local-civic

Cheers
James

---

From: Brian Rosen <[email-masked]>
Date: Wed, 27 Oct 2010 10:56:52 -0400

I'm a bit lost here (no pun), but ISTM, if we used your draft, then you could code a new CAtype with the X and Y codes, and then validation wouldn't work.

If we extend LoST so that it would look at priv:caElement names in some reasonable manner, then an unupgraded LoST server would return "not checked", and an upgraded one would return the right thing.

Could we concentrate on consensus please, instead of doom and gloom?  We do seem to be making progress.

Brian

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 27 Oct 2010 11:26:51 -0400

I had a more thorough look at the LoST spec last night, and I think I  
might understand the confusion.  (Summary: The examples are wrong.)   
I've written a summary below in three acts, plus conclusion.  Let me  
know whether you think this makes sense.
--Richard

I. Mechanism recap

We've been discussing two mechanisms for extending the civic address  
specification without breaking backward compatibility.  In either  
case, the assumption is that there is a desire to extend the set of  
"types" allowed in a civic address.  Elements with these extended  
types will still logically have a single value associated with them;  
complex types are not allowed (except maybe using attributes).  Either  
case can be constrained with IANA registration requirements (either on  
type tokens or (namespace,token) pairs).  The question is then purely  
one of syntax:

A. Attribute-based extension
<ext:caElement type="ex1">value1</ext:caElement>
<ext:caElement type="ex2">value2</ext:caElement>
<ext:caElement type="ex3">value3</ext:caElement>

B. Namespace-based extension
<extA:ex1>value1</extA:ex1>
<extA:ex2>value2</extA:ex2>
<extB:ex3>value3</extB:ex3>

II. LoST Recap

The complexity here is all in terms of LoST location validation.  For  
the purposes of using the 'civic' profile, neither mechanism requires  
a change to LoST, since the LoST civic profile uses the RFC 5139  
schema, which allows for arbitrary extension elements at the end of an  
address.

Recall that LoST validation works in the following way.  The client  
sets a flag requesting validation, and the server returns a  
<locationValidation> element indicating which elements of the address  
are <valid>, <invalid>, or <unchecked>.  The question for extension  
elements is how a LoST server refers to them in these validation  
elements.

RFC 5222 specifies the <valid>, <invalid>, or <unchecked> elements as  
lists of "qualified names".  Recall that in XML, a qualified name is  
the combination of a namespace prefix and a local name.  This means  
that the location validation examples in RFC 5222 are incorrect.   
Instead of this...

<locationValidation>
   <valid>country A1 A3 A6</valid>
   <invalid>PC</invalid>
   <unchecked>HNO</unchecked>
</locationValidation>

... the correct version using qualified names would be this:

<locationValidation
   xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
   <valid>ca:country ca:A1 ca:A3 ca:A6</valid>
   <invalid>ca:PC</invalid>
   <unchecked>ca:HNO</unchecked>
</locationValidation>

So LoST is built to refer to XML elements by their full names, with  
namespace plus local name.

III. LoST deals better with namespace-based extension

The upshot of the above observation about LoST is that LoST can deal  
with namespace-based extensions to civic addresses with no  
modification at all.  If the civic address in the RFC 5222 example  
were extended with the following values...

<extA:ex1>value1</extA:ex1>
<extA:ex2>value2</extA:ex2>
<extB:ex3>value3</extB:ex3>

... then the server could indicate validation outcomes with the  
following response:

<locationValidation
   xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
   xmlns:extA="urn:external:nonexistent-A"
   xmlns:extB="urn:external:nonexistent-B">
   <valid>ca:country ca:A1 ca:A3 ca:A6 extA:ex1</valid>
   <invalid>ca:PC extA:ex2</invalid>
   <unchecked>ca:HNO extB:ex3</unchecked>
</locationValidation>

With attribute-based extension and the current LoST syntax, the LoST  
server would only be able to point to the general extension element,  
not to specific types of extension elements.  So LoST would need to be  
modified to have a mechanism to point to address elements based on  
attributes instead of qualified names.

CONCLUSION: Attribute-based extension and namespace-based extension  
present the same properties in terms of
-- their ability to represent address information, and 
-- the IETF's ability to manage extension via IANA registration
Attribute-based extension requires modification to the LoST address  
validation function, however, while namespace-based extension does not.

On Oct 27, 2010, at 10:56 AM, Brian Rosen wrote:

> I'm a bit lost here (no pun), but ISTM, if we used your draft, then  
> you could code a new CAtype with the X and Y codes, and then  
> validation wouldn't work.
>
> If we extend LoST so that it would look at priv:caElement names in  
> some reasonable manner, then an unupgraded LoST server would return  
> "not checked", and an upgraded one would return the right thing.
>
>> Changing the protocols and namespaces of well defined things is a  
>> deal breaker for me at this point, and it is a deal breaker for  
>> many vendors and standards bodies that have already implemented or  
>> profiled against existing specifications.
>>
>> It is an industry requirement at this point that the changes don't  
>> impact these. You might not like the mechanism in local-civic but  
>> it address what the industry requires and still allows the  
>> extensions necessary.
>>
>> Cheers
>> James
>>
>>
>>> It's not a deal breaker to me, but we're early enough that I think  
>>> it's
>>> worth doing it cleanly.
>>>
>>> Brian
>>>
>>>>>>> 2.b. A template for private extensions recommending that they  
>>>>>>> have
>>>>>>> the
>>>>>>>>>> But I'll go with WG consensus on that.  The important parts  
>>>>>>>>>> to me
>>>>>>>>>> are:
>>>>>>>>>> d) Only one way to encode an extension (from here on in)  
>>>>>>>>>> CAtype,
>>>>>>>>>> not 3.
>>>>>>>>>>
>>>>>>>>>> I'd like to add two generic parameters to extCAtype, so  
>>>>>>>>>> that a new
>>>>>>>>>> CAtype could be defined that used them.
>>>>>>>>>> One example of that would be the INT (which had  
>>>>>>>>>> parameters), but
>>>>>>>>>> there are others.
>>>>>>>>>>
>>>>>>>>>> Brian
>>>>>>>>>>
>>>>>>>>>>>> If you would please concentrate on what I proposed, we  
>>>>>>>>>>>> could
>>>>>>>>>>>> perhaps make some more rapid progress.
>>>>>>>>>>>>
>>>>>>>>>>>> I proposed having ONE new element = extensionCAtype,  
>>>>>>>>>>>> which very
>>>>>>>>>>>> similar to one part of your proposal.
>>>>>>>>>>>> Endpoints have one (or maybe two) namespaces.  We don't  
>>>>>>>>>>>> have to
>>>>>>>>>>>> mint new ones for any new extensions.
>>>>>>>>>>>>
>>>>>>>>>>>>> Brian, the impacts we are talking about if we continue  
>>>>>>>>>>>>> with
>>>>>>>>>>>>> your approach are:
>>>>>>>>>>>>>> Subject: Re: [Geopriv] draft-ietf-geopriv-prefix-00 &  
>>>>>>>>>>>>>> draft-
>>>>>>>>>>>>>> winterbottom-
>>>>>>>>>>>>>> geopriv-local-civic
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> possibility of a "private" namespace.  However, I  
>>>>>>>>>>>>>> believe it
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>> appropriate that IETF control "official" extensions  
>>>>>>>>>>>>>> that have
>>>>>>>>>>>>>> broad
>>>>>>>>>>>>>> another.   Adding new "official" CAtypes should be  
>>>>>>>>>>>>>> possible,
>>>>>>>>>>>>>> with
>>>>>>>>>>>>>> appropriate review.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I understand that to correctly parse an address into  
>>>>>>>>>>>>>> fields,
>>>>>>>>>>>>>> or to render
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>> one way to have an extended CAtype, rather than 3.  It  
>>>>>>>>>>>>>> avoids
>>>>>>>>>>>>>> adding a
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Use: Actual use of 4119 was rare to non-existent.   
>>>>>>>>>>>>>>> 5139 is in
>>>>>>>>>>>>>>> use.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> that I'm sure you'll agree is handy.  Adding language  
>>>>>>>>>>>>>> tags in
>>>>>>>>>>>>>> any other
>>>>>>>>>>>>>>>> namespace, and then expect the rest of the world to  
>>>>>>>>>>>>>>>> generate
>>>>>>>>>>>>>>>> PIDFs with
>>>>>>>>>>>>>> extensions in the discussions on X-.  The basic rule is  
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>> people will
>>>>>>>>>>>>>>> We need to provide a path toward interoperability.  - 
>>>>>>>>>>>>>>> local-
>>>>>>>>>>>>>>> civic
>>>>>>>>>>>>>>>> situation is to in fact issue a new namespace, which  
>>>>>>>>>>>>>>>> we all
>>>>>>>>>>>>>>>> agree is
>>>>>>>>>>>>>>>> not very good.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [citation required]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm not sure if I think this is very good or not.   
>>>>>>>>>>>>>>> It's just
>>>>>>>>>>>>>>> how things
>>>>>>>>>>>>>>>> have relatively broad applicability, are needed.   
>>>>>>>>>>>>>>>> What we're
>>>>>>>>>>>>>>>> searching

---

From: Brian Rosen <[email-masked]>
Date: Wed, 27 Oct 2010 14:32:29 -0400

I think you are correct.

I suspect nearly all LoST implementations are wrong.

I believe, as a practical matter, that a LoST server can't be upgraded to validate a new element without an actual implementation change.  If you accepted a new namespace, you have new code.  You can ignore it ("not checked"), but you can't validate it.

A LoST client can shovel any form of PIDF into a LoST query and report results.  Nothing we're doing here would really affect the LoST client itself, but see below.

So the issue is how to extend LoST in a backwards compatible way which would allow us to use the extCAtype and it's local variation.

I note the following:  no matter how you look at it you can't extend validation of LoST to cover anything that could occur more than once.  The limit on validation is a QName, and that is a simple element name and prefix.  That is a very serious limitation.  No CAtype that had a parameter and could appear more than once is allowed.  This is a limit I noted in 4119 carried over to 5139: the CAtype list is a sequence, and James would have that be inviolate, never able to be changed.

If we take it as an unbreakable rule that the namespace in RFC5222 is inviolate, and we can't replace it with a new one, we would have to create some extension namespace add some additional validation response.   Any change like this to LoST has the same problem.

It is untenable, in my opinion, to force us to stay inside this box.  This is the basic dilemma that started this discussion.  If you consider whatever you want (5139 or 5222) to be the last word, and you assume it can never be changed, only new namespaces can be added, you really get into a very small box.  We aren't that good at predicting the future.  That is why the current practice is to reissue the schema.  

It gets worse.

Suppose we used the existing extensionPoint in the validation response.  We could add extValid, extInvalid, extUnchecked to locationValidation.  Except we can't.  Since we can't issue a new Relax NG schema that replaces the existing one, we can't actually use the extensionPoint, because that would actually add some new element to a defined name in an existing namespace.  All the extensionPoints in the schema are useless.

What to do?

Reissue the schemas.  Just like the XML directorate advises.  They have been through this.

Brian

On Oct 27, 2010, at 11:26 AM, Richard L. Barnes wrote:

> I had a more thorough look at the LoST spec last night, and I think I might understand the confusion.  (Summary: The examples are wrong.)  I've written a summary below in three acts, plus conclusion.  Let me know whether you think this makes sense.
> --Richard
> 
> 
> I. Mechanism recap
> 
> We've been discussing two mechanisms for extending the civic address specification without breaking backward compatibility.  In either case, the assumption is that there is a desire to extend the set of "types" allowed in a civic address.  Elements with these extended types will still logically have a single value associated with them; complex types are not allowed (except maybe using attributes).  Either case can be constrained with IANA registration requirements (either on type tokens or (namespace,token) pairs).  The question is then purely one of syntax:
> 
> The complexity here is all in terms of LoST location validation.  For the purposes of using the 'civic' profile, neither mechanism requires a change to LoST, since the LoST civic profile uses the RFC 5139 schema, which allows for arbitrary extension elements at the end of an address.
> 
> Recall that LoST validation works in the following way.  The client sets a flag requesting validation, and the server returns a <locationValidation> element indicating which elements of the address are <valid>, <invalid>, or <unchecked>.  The question for extension elements is how a LoST server refers to them in these validation elements.
> 
> RFC 5222 specifies the <valid>, <invalid>, or <unchecked> elements as lists of "qualified names".  Recall that in XML, a qualified name is the combination of a namespace prefix and a local name.  This means that the location validation examples in RFC 5222 are incorrect.  Instead of this...
> 
> <locationValidation>
> So LoST is built to refer to XML elements by their full names, with namespace plus local name.
> 
> 
> The upshot of the above observation about LoST is that LoST can deal with namespace-based extensions to civic addresses with no modification at all.  If the civic address in the RFC 5222 example were extended with the following values...
> 
> ... then the server could indicate validation outcomes with the following response:
> 
> <locationValidation
> With attribute-based extension and the current LoST syntax, the LoST server would only be able to point to the general extension element, not to specific types of extension elements.  So LoST would need to be modified to have a mechanism to point to address elements based on attributes instead of qualified names.
> 
> 
> CONCLUSION: Attribute-based extension and namespace-based extension present the same properties in terms of
> -- their ability to represent address information, and-- the IETF's ability to manage extension via IANA registration
> Attribute-based extension requires modification to the LoST address validation function, however, while namespace-based extension does not.
> 
> 
> 
> 
> 
> 
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 29 Oct 2010 05:49:59 +0800

On 2010-10-28 at 05:32:29, Brian Rosen wrote:
[Lots of stuff]
> Reissue the schemas.

Because a disproportionate response to a small problem is always the best way forward.

Seriously, things just aren't that broken.  A little hack and we're home.  Read the appendix of the local-civic draft and you'll see that the LoST problem isn't intractable.

--Martin

---

From: Brian Rosen <[email-masked]>
Date: Fri, 29 Oct 2010 09:32:23 -0400

Yes,  I saw that hack.  It's not bad (although including ext:EXT is really ugly), and it would work.  

What it doesn't do that I want to get done is changing SEQUENCE, but really I'm trying to point out that trying to keep the original schema inviolate constrains us way too much - we don't know enough about what we are doing to get it right the first time, and limiting us only to things you can do with extension namespaces is not feasible.  Never being able to use the defined extensionPoints for example.  If we can't use the extensionPoints, why are they there?

I don't want us to make promises we can't keep, and I want to fix things that are broken as early as possible, even if some early implementations have to be modified.

Brian