Subject: Re: [Geopriv] On civic extensions

From: Brian Rosen <[email-masked]>
Date: Wed, 1 Dec 2010 08:07:49 -0500

My notion is that you have two registries, the existing one, and one that only attempts to avoid duplication. With registries come two things: a label and a number.

The label is what you use with LoST.  The number is what you use with DHCP.  If you are worried about running out of DHCP number space, create one new number that has the label as it's first parameter.

For the new namespace, LoST works already.  Create one new DHCP option with the namespace as the first parameter and the label (tag) as the second.

Brian

On Nov 30, 2010, at 8:01 PM, Thomson, Martin wrote:

> Robert asked a question about how the various extension scheme affect
> LoST service boundaries (as opposed to the validation we've already
> discussed).  I think that this is another consideration we need to deal
> with in designing a solution.
> 
> Ultimately, questions of the effect of our decisions on other protocols
> and users of the civic address format are the most important.
> Discussions on registries and associated concerns is - at this stage -
> an wasteful distraction.
> 
> Service boundary evaluation is a simple process that treats each address
> label as opaque (see draft-thomson-ecrit-civic-boundary for a more
> thorough discussion).  This would make things easy if there were only
> one possible way an extension could find its way into the system.
> 	
> Here are my collected thoughts on the real problem.
> 
> --
> 
> There are two formats that can be used to introduce an extension: DHCP
> and XML.
> 
> Those two entry points could lead to an increased number of
> representations for extensions.
> 
> Most of the problems occur at the point where conversions occur between
> formats.  If an originator (LG) and ultimate recipient both understand
> the extension, conversions between different formats are the only
> serious cause of problems.
> 
> If all intermediaries understood all extensions, we have no problem.
> That's not a reasonable precondition though.  We have to deal with
> certain intermediaries who are ignorant of extensions.
> 
> An extension that finds its way into the system by way of DHCP (or
> DHCP-based formats) is going to appear as a new, unknown CAtype to
> recipients.  This can be translated to an XML format in two ways: when
> the translator understands the DHCP form and the equivalent XML form;
> and when the translator does not.  We need to deal with both cases.
> 
> An extension that finds its way into the system by way of an XML format
> has a similar problem.  The specific qualified name that identifies the
> type of the extension can't be carried by DHCP.  The same concerns apply
> to this sort of conversion.
> 
>   Though a specific piece of location information might not need to be
>   converted to DHCP format, it's genesis in XML might ultimately
>   dictate that DHCP clients be able to convey this to clients for it to
>   be represented in XML.  The idea being that data is forced to go XML
>   -> DHCP -> XML and the goal is not to lose the extension.
> 
> This leads to the following truth table for converting intermediaries:
> 
>              | Intermediary | Intermediary
>              | Understands  |   Ignorant
>  ------------+--------------+--------------
>  DHCP -> XML |      A       |      B
>  XML -> DHCP |      C       |      D
> 
>   Note: Existing software is forced to discard extensions when
>   translating in either direction.  Thus, it's safe to ignore that in
>   this analysis.  I assume that software is compliant with whatever
>   specification we produce.
> 
> -local-civic allows for two expressions of the same data in either basic
> format to deal with the problem cases "B" and "D".  This does add two
> different representations of the same information in both XML and DHCP;
> one representation for each of the four cases.
> 
> This could cause a problem for LoST service boundaries (or any other
> application that uses civic addresses).  If a particular extension can
> be represented in different ways, the LoST server that relies on an
> extension for its boundaries has to produce 2^n different service
> boundaries if it wants to be understood (where 2 = the number of
> different representations for each extension, and n = the number of
> extensions).
> 
>   In practice, I expect that such reliance on extensions will be rare
>   for LoST.  This problem is rendered moot if the extensions are safely
>   ignored, but it's something we need to consider for the general case.
> 
> If we want to solve the problem of multiple representations - and we
> should really evaluate the impact if we do not - then we need to
> legislate to remove one of the options.  Since we can do nothing to
> rectify the ignorance (or not) of translators, the only real option is
> to restrict where extensions are defined.
> 
> Removing the XML extension point would force all civic address
> extensions to acquire a CAtype from the registry.  Extensions are only
> ever natively defined as one octet CAtypes.  To carry extensions in XML,
> we'd define an element that can carry unknown CAtypes.  <ext:EXT
> CAtype="192">Value</ext:EXT> as suggested in -local-civic would be
> a representative implementation of this option.
> 
> Removing the DHCP extension point was actually something suggested in a
> previous version of -local-civic.  That got some fairly strong
> objections, but it should be tabled again.  In this option extensions
> are natively defined in XML and we define a way to convey an XML-based
> extension in DHCP.  The two new CAtypes in -local-civic are
> representative implementations of this option.
> 
> Thus we have the solution matrix:
> 
>                            Extend DHCP?
>               |      Yes        |      No
>         ------+-----------------+-----------------
>  Extend   Yes | -local-civic-03 | -local-civic-02
>   XML?    No  |       *C        |      *D
> 
> *C is what (I think) Brian is advocating (Brian: correct me if I am
> wrong, I've heard you support this).
> 
> I don't think that anyone is advocating *D, though it's effectively
> where we are at the moment.
> 
> Keith is partly right about a do-over always being a final failsafe
> option: we do always have the option of a complete do-over.  However,
> the main problem will just carry over into the new format if we don't
> resolve it.  A do-over is just a decision we might make in the course of
> implementing one of these four options.
> 
> We should resolve this issue before we get into discussions on
> registration policies and so forth.  Those discussions are wasteful as
> long as we each have different fundamental solutions in mind.  I hope
> that we can agree that each of these works with wild west, fcfs, expert
> review or standards action with similar efficacy, though different 
> levels of accessibility and interoperability.
> 
> --Martin
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: Marc Linsner <[email-masked]>
Date: Wed, 01 Dec 2010 08:28:40 -0500

Brian,

>
>For the new namespace, LoST works already.  Create one new DHCP option
>with the namespace as the first parameter and the label (tag) as the
>second.
>

What if someone wants to build a location with more than 2
namespaces....maybe 3, 4, 5, 6.....??  Define DHCP to carry multiple
namespaces concatenated into one CAtype?

-Marc-

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 1 Dec 2010 09:03:57 -0500

No, I think Brian has it right, except that he says "label" where he actually means "namespace + localName".  You make a single suboption that encodes the (namespace, localName, value triple).  Using the TLS specification language:

struct {
    uint8 CAtype = PRIVATE_EXTENSION;
    uint8 CAlength;
    opaque ns<>;
    opaque localName<>;
    opaque value<>
} ExtCAType

So the following XML values:

<A8 xmlns="ns1">value1</A8>
<A9 xmlns="ns2">value2</A9>

... would serialize to the following CAtypes

XX 0E 03 6E7331 02 4138 06 76616C756531
XX 0E 03 6E7332 02 4139 06 76616C756532

(where XX is the CAtype value)  

The only problem you really run into here is length, which is what the namespace prefix bits in local-civic are intended to address.

I think it's also worth noting that this extension scheme works best if the extension schema has the same basic structure as the base civic address schema, i.e., if it's just a flat list of types.  If you try to add complex types, this scheme doesn't really work.  (I'm thinking of someone getting the idea to do something like xAL [1])

--Richard

[1] <http://www.oasis-open.org/committees/ciq/ciq.html#6>

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 1 Dec 2010 22:21:32 +0800

The disadvantage to this approach is that if you have multiple elements for the new namespace, then you must same the whole namespace multiple times. This is not the case if you have a separate CAtype that specifies the namespace and prefix elements.

Cheers
James

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Richard L. Barnes
> Sent: Thursday, 2 December 2010 1:04 AM
> To: Marc Linsner
> Cc: [email-masked]
> Subject: Re: [Geopriv] On civic extensions
> 
> No, I think Brian has it right, except that he says "label" where he
> actually means "namespace + localName".  You make a single suboption that
> encodes the (namespace, localName, value triple).  Using the TLS
> specification language:
> 
> struct {
> The only problem you really run into here is length, which is what the
> namespace prefix bits in local-civic are intended to address.
> 
> I think it's also worth noting that this extension scheme works best if
> the extension schema has the same basic structure as the base civic
> address schema, i.e., if it's just a flat list of types.  If you try to
> add complex types, this scheme doesn't really work.  (I'm thinking of
> someone getting the idea to do something like xAL [1])
> 
> --Richard
>

---

From: Brian Rosen <[email-masked]>
Date: Wed, 1 Dec 2010 09:47:48 -0500

With the two registries, the incidence of the local namespace is small, and I think this is a simple solution that is obvious, works, and is easy to implement.

Brian

---

From: Brian Rosen <[email-masked]>
Date: Wed, 1 Dec 2010 09:57:25 -0500

One more thing: I think the extension CAtype and the DHCP option ought to have two generic parameters.

Brian

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 1 Dec 2010 10:15:01 -0500

Could you explain a little more?  I'm assuming you're thinking of INT when you say that; are there other use cases?

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 2 Dec 2010 05:50:54 +0800

Of course, you wouldn't encode it that way because an existing client should still be able to decode it, and what you have could produce invalid UTF-8.

On 2010-12-02 at 01:03:57, Richard L. Barnes wrote:
> actually means "namespace + localName".  You make a single suboption
> that encodes the (namespace, localName, value triple).  Using the TLS
> specification language:
> 
> struct {

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 2 Dec 2010 05:52:06 +0800

Thank you Brian for doing exactly what I predicted and de-railing the conversation onto registries again.

If you didn't read the email, "tl;dr" is an acceptable response, I wont be offended.

On 2010-12-02 at 00:07:49, Brian Rosen wrote:
> My notion is that you have two registries, the existing one, and one
> that only attempts to avoid duplication. With registries come two
> things: a label and a number.
> 
> The label is what you use with LoST.  The number is what you use with
> DHCP.  If you are worried about running out of DHCP number space,
> create one new number that has the label as it's first parameter.
>

---

From: Brian Rosen <[email-masked]>
Date: Wed, 1 Dec 2010 18:19:38 -0500

While I consider it part of my life's mission to always do what you expect me to do, I don't expect to be recognized for doing it.

I did read the email, and didn't see where "tl;dr" was mentioned, whatever "tl" and "dr" mean.

I think we're very close to agreement.  We have an open issue on how to represent the namespace in DHCP for a local extension, and we have two proposals: two DHCP options or one.  

If you are okay with the second registry, with it's accompanying CAtype and DHCP option, then we should be able to close the one or two DHCP options issues with a couple of other people expressing their opinions; I certainly don't feel very strongly about that, since the result is the same: any local extension can be passed through DHCP.

Since we have mechanisms to pass two new CAtypes with the associated registries through DHCP, there is no problem there, and I think we have no disagreement (save the one or two registry issue).

LoST validation is also not in play - we understand how to do that with any of the proposals on the table.

I had the suggestion to have two generic parameters in the one or two CAtypes.  You could weigh in on that.

I'm pretty lost, no pun intended, on why the service boundary is any issue at all.   There are 3 entities, and some can either pass data without understanding it, or drop it.  If the LoST server gets some LI it doesn't understand, it ignores it, which means it doesn't appear in a service boundary.  If the LoST client got LI elements it didn't understand, and passes them through to LoST, it may get that element back in the service boundary if the LoST server does understand the extension.  If the server sends something back, it would have to be the value it got sent in.  Take bridge: if getting off the bridge is out of the service area, then bridge id is part of the service boundary -- the client can compare the bridge id it gets from a location update even if it doesn't know anything about bridge and requery LoST if it changed.   If bridge ID is not part of the service boundary, it's not in the return and the LoST client won't miss it.  I am missing the problem.  It appears to me to work, and not be dependent on representation.

Brian

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 2 Dec 2010 07:23:32 +0800

Extend DHCP?
              |      Yes        |      No

Is this a variation on -local-civic-03 we're discussing?

On 2010-12-02 at 10:19:38, Brian Rosen wrote:
> While I consider it part of my life's mission to always do what you
> expect me to do, I don't expect to be recognized for doing it.
> 
> I think we're very close to agreement.  We have an open issue on how to
> represent the namespace in DHCP for a local extension, and we have two
> proposals: two DHCP options or one.
> 
> If you are okay with the second registry, with it's accompanying CAtype
> and DHCP option, then we should be able to close the one or two DHCP
> options issues with a couple of other people expressing their opinions;
> I certainly don't feel very strongly about that, since the result is
> the same: any local extension can be passed through DHCP.
> 
> Since we have mechanisms to pass two new CAtypes with the associated
> registries through DHCP, there is no problem there, and I think we have
> no disagreement (save the one or two registry issue).
> 
> I'm pretty lost, no pun intended, on why the service boundary is any
> issue at all.   There are 3 entities, and some can either pass data
> without understanding it, or drop it.  If the LoST server gets some LI
> it doesn't understand, it ignores it, which means it doesn't appear in
> a service boundary.  If the LoST client got LI elements it didn't
> understand, and passes them through to LoST, it may get that element
> back in the service boundary if the LoST server does understand the
> extension.  If the server sends something back, it would have to be the
> value it got sent in.  Take bridge: if getting off the bridge is out of
> the service area, then bridge id is part of the service boundary -- the
> client can compare the bridge id it gets from a location update even if
> it doesn't know anything about bridge and requery LoST if it changed.
> If bridge ID is not part of the service boundary, it's not in the
> return and the LoST client won't miss it.  I am missing the problem.
> It appears to me to work, and not be dependent on representation.
> 
> Brian
> 
> >>> Discussions on registries and associated concerns is - at this
> stage
> >> -
> >>> an wasteful distraction.
> >>>
> >>> Removing the DHCP extension point was actually something suggested
> in
> >> a
> >>> resolve it.  A do-over is just a decision we might make in the
> course
> >> of

---

From: Brian Rosen <[email-masked]>
Date: Wed, 1 Dec 2010 18:37:24 -0500

Uh, yeah.  local-civic-03 defines two DHCP options for use with local namespaces, and I think only one is needed.

Otherwise, the basic idea is the same.  

Having two registries instead of one is also a "variation of -local-civic-03".  I have some syntactic objections to how -03 defines the extCA, but they are minor.  I would use the element name, not the number. 

Neither has much to do with the issue of LoST service boundary handling, which is just whether the element that comes in (in XML, always) does or does not appear in the service boundary output.

Brian

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 2 Dec 2010 07:42:19 +0800

OK, that's definitely progress :)

Syntactic disagreements I can deal with.  We should address the service boundary concern though.  (Ignoring it might be reasonable, but we should first all understand the implications.)  I've another email half done on that.

The element name isn't known to the thing taking the unknown DHCP extension...

On 2010-12-02 at 10:37:24, Brian Rosen wrote:
> Uh, yeah.  local-civic-03 defines two DHCP options for use with local
> namespaces, and I think only one is needed.
> 
> Having two registries instead of one is also a "variation of -local-
> civic-03".  I have some syntactic objections to how -03 defines the
> extCA, but they are minor.  I would use the element name, not the
> number.
> 
> Neither has much to do with the issue of LoST service boundary
> handling, which is just whether the element that comes in (in XML,
> always) does or does not appear in the service boundary output.
> 
> Brian
> 
> >> LoST validation is also not in play - we understand how to do that
> with
> >> any of the proposals on the table.
> >>
> >> I had the suggestion to have two generic parameters in the one or
> two
> >> CAtypes.  You could weigh in on that.
> >>
> >>> Thank you Brian for doing exactly what I predicted and de-railing
> the
> >> conversation onto registries again.
> >>>
> >>>>> discussed).  I think that this is another consideration we need
> to
> >>>> deal
> >>>>> has a similar problem.  The specific qualified name that
> identifies
> >>>> the
> >>>>> type of the extension can't be carried by DHCP.  The same
> concerns
> >>>> apply
> >>>>> dictate that DHCP clients be able to convey this to clients for
> it
> >>>> to
> >>>>> -local-civic allows for two expressions of the same data in
> either
> >>>> basic
> >>>>> application that uses civic addresses).  If a particular
> extension
> >>>> can
> >>>>> rectify the ignorance (or not) of translators, the only real
> option
> >>>> is
> >>>>> ever natively defined as one octet CAtypes.  To carry extensions
> in
> >>>> XML,
> >>>>> registration policies and so forth.  Those discussions are
> wasteful
> >>>> as

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 2 Dec 2010 07:44:25 +0800

Brian,

In response to the other bits of this response...

> proposals: two DHCP options or one.

See my other response, and my explanation below for why I think we're not actually making progress.
 
> the same: any local extension can be passed through DHCP.

I don't want to talk about one registry or two.  That's like discussing what colour to paint the baby's room before you've made the fundamental procreation decision.
 
> any of the proposals on the table.

At least we agree on that.  There might be hacks, but that's OK.
 
> CAtypes.  You could weigh in on that.

I think that it's a terrible idea.  But then, I don't know what a generic parameter is or what it gains me, so I could be convinced otherwise.  What semantics did you want to attach to these parameters?

> issue at all. 

This is the fundamental technical issue in question.  This is not about the LIS or DHCP server and the LoST server having a conversation in full awareness of all the extensions, it's about what the guy in the middle does with those extensions.

If an extension only ever has a single representation, then there is no problem.  However, imagine that you define a CAtype (192) and a corresponding XML element <pfx:STP>.  A generic client that gets the CAtype translates that to an extension element in XML: <ext:EXT CAtype="192">; and a client that knows about the extension produces <pfx:STP>.

That's two different representations for the same logical element.  A service boundary needs to identify _either_ form in order to guarantee that a client can match their address to the boundary.  Add multiple extensions and you have an exponential problem.

Now, in LoST at least the server can tailor responses based on what elements it sees (maybe), so that a client that produces one form gets service boundaries in the same form.  If a client produces <pfx:STP>, then that's what is in the boundary.  However, LoST has the advantage of seeing the client's location first.  And that all assumes that the client is the one doing the conversion - if it's getting the extension from another entity, that entity could change and start producing the other form.

Other uses of addresses don't necessarily have that luxury.  We can decide that we don't care about that, but that decision needs to be made in full cognizance of the consequences.

>  There are 3 entities, and some can either pass data

---

From: Brian Rosen <[email-masked]>
Date: Wed, 1 Dec 2010 19:45:35 -0500

Progress, and yet perhaps a bigger misunderstanding of positions.

Inline...

> I think that it's a terrible idea.  But then, I don't know what a generic parameter is or what it gains me, so I could be convinced otherwise.  What semantics did you want to attach to these parame…
The CAtypes that use the extensions are free to use them, and define what they mean.  If we decided, just for example, to use one new CAtype for "post", then one parameter could say what kind of a post it was.  The purpose of defining them is obviously to have the syntax for them in all of the appropriate XML (and DHCP)
> If an extension only ever has a single representation, then there is no problem.  However, imagine that you define a CAtype (192) and a corresponding XML element <pfx:STP>.  A generic client that g…
Perhaps we have a bigger problem.

I want to define two new CAtypes, put them in the registry, with one new namespace.   If the process defined to add new CAtypes is followed, no new namespace is created.  There is only an entry in the registry.  The encoding for that new CAtype is always <ext:EXT CAtype="STP"> (or <ext:localEXT CAtype="foo">) and there is no pfx.   The names (and numbers) in the registries are unique.

If you create a local extension, then there is a namespace, and there is only one representation <pfx:STP> and there is no registry entry, no CAtype name or number.  One or the other, not both.  If you add an entry to the registry, you don't need a new namespace.  EXT is the namespace.  If you don't add an entry to the registry, then you do need a new namespace, and you don't have a CAtype name or number in the registry.  

DHCP also only has one way - two DHCP options (ext and localExt), plus one (or two) for local namespaces based extensions.   Since there is only one way, conversion between DHCP and XML is straightforward, transparent and reversible.

> That's two different representations for the same logical element.  A service boundary needs to identify _either_ form in order to guarantee that a client can match their address to the boundary.…
Well, even if this was a problem, all you need to do to solve it is require that the LoST server use the same representation as the LI passed up and then it isn't a problem.  As in my description, if the LoST server doesn't understand the extension, then it never appears in the service boundary.  If it does understand the extension, it's not in the input LI, and the location is valid, then I think it doesn't send it back in the service boundary.  If it does understand the LI and it's in the LI, then it may appear in the service boundary.  If it appears in the service boundary (which means it appeared in the LI), and the LoST client doesn't understand it, it can still use it, because all it has to do is compare.  If the LIS did something really stupid and switched representations mid stream, the client would have to requery.  So what?

By eliminating two ways to do the same thing (as I propose above), you don't ever have a problem of the LI having it one way and the service boundary having it the other way.  
> Now, in LoST at least the server can tailor responses based on what elements it sees (maybe), so that a client that produces one form gets service boundaries in the same form.  If a client produces…
Yes, but the response could always be in the same form, although I want to eliminate the problem.

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 2 Dec 2010 09:11:15 +0800

> Progress, and yet perhaps a bigger misunderstanding of positions.

Ditto.

> > I think that it's a terrible idea.  But then, I don't know what a
> >generic parameter is or what it gains me, so I could be convinced
> > otherwise.  What semantics did you want to attach to these parameters?
>
> The CAtypes that use the extensions are free to use them, and define
> what they mean.  If we decided, just for example, to use one new CAtype
> for "post", then one parameter could say what kind of a post it was.
> The purpose of defining them is obviously to have the syntax for them
> in all of the appropriate XML (and DHCP)

In otherwords: no semantics, just a limited space for sub-typing.  If you need to split things further, split them further and use more CAtypes.

> > If an extension only ever has a single representation, then there is
> > no problem.  However, imagine that you define a CAtype (192) and a
> > corresponding XML element <pfx:STP>.  A generic client that gets the
> > CAtype translates that to an extension element in XML: <ext:EXT
> > CAtype="192">; and a client that knows about the extension produces
> > <pfx:STP>.
>
> I want to define two new CAtypes, put them in the registry, with one
> new namespace.   If the process defined to add new CAtypes is followed,
> no new namespace is created.  There is only an entry in the registry.
> The encoding for that new CAtype is always <ext:EXT CAtype="STP"> (or
> <ext:localEXT CAtype="foo">) and there is no pfx.   The names (and
> numbers) in the registries are unique.
> 
> If you create a local extension, then there is a namespace, and there
> is only one representation <pfx:STP> and there is no registry entry, no
> CAtype name or number.  One or the other, not both.  If you add an
> entry to the registry, you don't need a new namespace.  EXT is the
> namespace.  If you don't add an entry to the registry, then you do need
> a new namespace, and you don't have a CAtype name or number in the
> registry.
> 
> DHCP also only has one way - two DHCP options (ext and localExt), plus
> one (or two) for local namespaces based extensions.   Since there is
> only one way, conversion between DHCP and XML is straightforward,
> transparent and reversible.

And now I think I've got a better handle on your proposal.  What you are suggesting is the third option I didn't think of.  A third, new, extension mechanism.  

The XML extension option exists, but rather than using CAtypes, you want to define a new mechanism for the "standardized" extensions.

The reason I didn't think of it is that it's expensive.  You have to close the CAtype registry for further business and create a new registry with two levels of registration.

Incidentally, why not cut off extension for other namespaces too?  You could use localExt with an unregistered name happily.

Or go even further an just have a single ext element.  Lump the local and standardized names in the same naming scope.  The registry can prevent collisions for those who care to use the registry (and those who don't use the registry get all they pay for anyhow).

A good reason is that namespace URIs are a handy, available, proven mechanism for ensuring global uniqueness with no management overhead.  You might save a few bits by using IANA to maintain a separate global namespace, but who counts bits in this modern age?

> > That's two different representations for the same logical element. [...]
>
> Well, even if this was a problem, all you need to do to solve it is
> require that the LoST server use the same representation as the LI
> passed up and then it isn't a problem.  [...] 
> If the LIS did something really stupid and
> switched representations mid stream, the client would have to requery.
> So what?

That's the conclusion that I was coming to.  Multiple representations isn't a big problem for LoST.  A little bit of tweaking on the server sets everything right.

Good thing that LoST is the only possible use we have for a civic address.

---

From: Brian Rosen <[email-masked]>
Date: Wed, 1 Dec 2010 21:18:18 -0500

> In otherwords: no semantics, just a limited space for sub-typing.  If you need to split things further, split them further and use more CAtypes.
In that particular example, perhaps, but others, maybe not.  Think about the floor discussion we're having.  Suppose you wanted something that had both that starts at zero always goes up or down by one, and you wanted the local signage version.  You could have two CAtypes with the different versions, but having the two representations in one is better.  That's basically the INT thing also.   In the end, you can probably add enough CAtypes to make them all work, but then you really would have a big registry.  Much cleaner to just allow parameters.  If you don't need them, don't use them.  I'm trying to think ahead.

> The reason I didn't think of it is that it's expensive.  You have to close the CAtype registry for further business and create a new registry with two levels of registration.
No, we keep the existing registry.  All of the details remain the same, no need to change it.  IANA won't know the difference.  Update 5139 to change how the encoding works.  No redefinition of the 5139 namespace, just a change in how the registry entry encodes in PIDF.

We add a new one.  It's like the existing one, but has a much easier management policy.  Either FCFS, or a lightweight expert review where the only thing the reviewer is doing is preventing duplicate entries with slightly different names.

You could expand the existing registry to have two policies and add a field that was what kind it was, but I don't think anyone benefits from that.

> Incidentally, why not cut off extension for other namespaces too?  You could use localExt with an unregistered name happily.
While I agree you could do that, I don't want to remove the existing namespace extension although I hope it's roughly never used except in a situation where there is only one app that uses it and therefore there is no interoperability issue.  I don't want to have two ways to encode the same thing, and that adds more mechanism with no benefit.

The benefit of the registry is interoperability - there is a place to go to find out what extensions are available, what they mean, and how they are encoded.  There is maximum re-use, and a modicum of review.  That has benefits.

Using the registry to have global uniqueness is just convenient.  I want the registry for the interoperability.  With it, I don't need a explosion of namespaces that add no value.  The number bits in the IANA registry aren't significant.  The bits that define all the namespaces in the PIDF are annoying but not fatal.  I'm pushing for interoperability, the other stuff comes with it for free.

> Good thing that LoST is the only possible use we have for a civic address.
I've avoided the problem you worried about by not allowing more than one way to encode.  All other uses for location will have the same advantage.  Be happy.

Brian

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 2 Dec 2010 11:43:55 +0800

Hi Brian,

Without a concrete proposal, I'm just trying to get a coherent view of what you are proposing.  I get the feeling that this is a moving target.  I'm not yet at the stage where I'm asking for an I-D proposal, but close.

I think that you want a data model that has a two parallel collections of "elements".  Each element containing a registered label, a value and two further optional values.  The label determines the semantics.  Labels in the first collection are "standardized", the second is more loosely controlled.

I get the impression that you still want to chuck the existing XML format.  But it could be that you want to just use this new data model for extensions.  I'm still not clear on that part.

Apparently you don't want to touch the basic DHCP format, but I could be wrong about that too.

All of this is based on some flimsy justification.  Registration policies are obviously orthogonal, but they seem to feature in your arguments quite a bit.  Beyond that we have "namespaces are ugly".  

The two extra optional labels are a discussion we should defer.  We're having enough trouble with a simple label+value data model.

On 2010-12-02 at 13:18:18, Brian Rosen wrote:
> > In otherwords: no semantics, just a limited space for sub-typing.  If
> you need to split things further, split them further and use more
> CAtypes.
> In that particular example, perhaps, but others, maybe not.  Think
> about the floor discussion we're having.  Suppose you wanted something
> that had both that starts at zero always goes up or down by one, and
> you wanted the local signage version.  You could have two CAtypes with
> the different versions, but having the two representations in one is
> better.  That's basically the INT thing also.   In the end, you can
> probably add enough CAtypes to make them all work, but then you really
> would have a big registry.  Much cleaner to just allow parameters.  If
> you don't need them, don't use them.  I'm trying to think ahead.

The same argument works for allowing for arbitrary structured content.  The conscious decision in the early stages of this process (before I got involved) was toward a simplified structure.  If you want to throw that out, bring better justification along, because "better" without qualification doesn't cut it.

If we were going to throw out what we already have in favour of something with more structure, why not use something like xAL?

> > The reason I didn't think of it is that it's expensive.  You have to
> close the CAtype registry for further business and create a new
> registry with two levels of registration.
>
> No, we keep the existing registry.  All of the details remain the same,
> no need to change it.  IANA won't know the difference.  Update 5139 to
> change how the encoding works.  No redefinition of the 5139 namespace,
> just a change in how the registry entry encodes in PIDF.

4776 asks IANA to manage 256 different numbers.  You are asking them to manage a textual name.  That's a pretty big change.

And you still haven't justified any change to 5139 in any of that.

> We add a new one.  It's like the existing one, but has a much easier
> management policy.  Either FCFS, or a lightweight expert review where
> the only thing the reviewer is doing is preventing duplicate entries
> with slightly different names.

I think that you've overestimated the difficulty of getting a registration.  Have you ever tried to register a new CAtype?  I've never seen a single request, so unless IANA are playing gatekeeper, no attempts have been made.  Writing a specification isn't that hard* (*if you don't care about the quality of the spec).

> You could expand the existing registry to have two policies and add a
> field that was what kind it was, but I don't think anyone benefits from
> that.

Updating the procedure to something akin to RFC 3864 isn't impossible and preferable to what you suggest.  Two registries and two separate namespaces leads to variations on the theme of the "x-" protocol slum.  But that actually involves _raising_ the bar on the strictest level.

Part of the story that you haven't elaborated on is the journey an extension makes from private use to full standardized interoperability.  RFC 3864 does a reasonable job of that and there are variations that work equally well with different trade-offs (for instance, see http://www.ietf.org/mail-archive/web/geopriv/current/msg08866.html).
 
> > Incidentally, why not cut off extension for other namespaces too?
> > You could use localExt with an unregistered name happily.
>
> While I agree you could do that, I don't want to remove the existing
> namespace extension although I hope it's roughly never used except in a
> situation where there is only one app that uses it and therefore there
> is no interoperability issue.  I don't want to have two ways to encode
> the same thing, and that adds more mechanism with no benefit.

If you only want one way, then you have to cut something out.  You can't have it both ways.  If you were serious about your proposal, you'd cut off both new CAtypes and XML extensions.  Neither actually prevents someone from trying those extension methods, but it does stop well-meaning people from using those dead-ends.

> Using the registry to have global uniqueness is just convenient.  I
> want the registry for the interoperability.  With it, I don't need a
> explosion of namespaces that add no value.  

That's just false.  It's just a trade-off.  You are allowed to think that namespaces are ugly and wasteful if you like.  They do work.

> The number bits in the IANA
> registry aren't significant.  The bits that define all the namespaces
> in the PIDF are annoying but not fatal.  I'm pushing for
> interoperability, the other stuff comes with it for free.
> 
> I've avoided the problem you worried about by not allowing more than
> one way to encode.  All other uses for location will have the same
> advantage.  Be happy.

I am.  Apparently, it's a form of psychosis.

---

From: Brian Rosen <[email-masked]>
Date: Thu, 2 Dec 2010 17:32:40 -0500

I'll write an I-D if I need to.

The essence is:
1) A CAtype that is generally useful is defined and entered into the existing registry as currently documented.  To use it, the XML is:
<ext:EXT CAtype="STP">Avenue</ext:EXT>

The DHCP is
<extCAoption><STP><Avenue>

The LoST validation is:
ext:STP

The LoST Service Boundary can contain <ext:EXT CAtype=STP>Avenue</ext:EXT>

2) A CAtype that is not generally useful can be entered into a new registry with expert review that simply avoids duplication.  This registry can't contain element names that conflict with those in the existing registry (and vice versa).  To use it, the XML is
<ext:localEXT CAtype="Foo">Baz</ext:localEXT>

The DHCP is
<extlocalCAoption><Foo><Baz>

The LoST validation is:
ext:Baz

The LoST Service Boundary can contain <ext:localEXT CAtype="Foo">Baz</ext:EXT>

3) It's possible, as it is now, to create a new namespace and elements within it.   To do so requires no registry entry.  The XML is
<my:Food>Tomato</my:Food>

The DHCP is
<extNameSpaceOption><http://foodsoftheworld.net/ns/food><Food><Tomato>

The LoST validation is:
my:Food

The LoST Service Boundary can contain <my:Food>Tomato</my:food>

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 6 Dec 2010 12:58:03 +0800

(Apologies for taking my time responding here.)

That's three parallel extension mechanisms.  

You get to choose from three wonderful options.  I'll admit that each is effectively partitioned from the other, so there is no need for multiple encodings for each.

You'd better pick the right option from the outset.  What happens when you pick option 3 and it turns out that Option 2 or Option 1 was a better choice (maybe it was a good enough idea to standardize)?  

After all, if it didn't matter, why would there even be three options?

The other big problem I have with this discussion is the subtext.  That subtext is that the existing extension mechanism doesn't work and /can't be made to work/.  You would have us throw it all in for a replacement scheme.  The numbers don't have enough code points; the namespaces are too ugly.  To-mah-toes, to-may-toes.

-local-civic acknowledges that it doesn't work due to the interaction between the different formats, but proposes an approach that is far less disruptive.  

Changing backwards compatibility schemes has its own backward compatibility problems, after all.

I had a small concern about there being multiple forms, but now that I've had time to mull it over, it's not going to cause significant damage.  We can handle it.  The way we agreed works.  For the types of things we're being asked to add, we can handle it 100 times over.

--Martin

On 2010-12-03 at 09:32:40, Brian Rosen wrote:
> 1) A CAtype that is generally useful is defined and entered into the
> existing registry as currently documented.  To use it, the XML is:
> 2) A CAtype that is not generally useful can be entered into a new
> registry with expert review that simply avoids duplication.  This
> registry can't contain element names that conflict with those in the
> existing registry (and vice versa).  To use it, the XML is
> 3) It's possible, as it is now, to create a new namespace and elements
> within it.   To do so requires no registry entry.  The XML is

---

From: Brian Rosen <[email-masked]>
Date: Tue, 7 Dec 2010 17:24:49 -0500

There is currently two mechanisms.  This adds 1/2 of one.  Semantics, to be sure, but the point is that the only difference between two of them is the registry they go in and the actual element name/DHCP option.

We can't avoid the new namespace thing, but it has so many interoperability problems, all we can do is discourage it.  Backwards compatibility is going to be an issue.  Yet another reason not to use it.  Your proposal has the same problem.

A problem occurs when you start with the local registry, and subsequently decide it deserves to be more general purpose.  It occurred to me to use the same name/number in both, and ask implementations to treat one as the other if they encounter it.  Anyone that really wanted to could actually check the IANA registry.  All of the implementations we're concerned about are on-line anyway.

The namespace mechanism can be made to "work", but it encourages anarchy.  No interoperability, no common use.  You have to just "know" that some namespace is out there or roll your own.  The registry is the advertisement for what others have done.  Namespaces are squeaks in the wind.  You could have a million of them and have no way whatsoever to build a general purpose LIS, or LoST server, or anything else.

I don't want to get rid of namespaces.  Don't think we really could even if we were even more against them than I am.   However, they are a bad idea for all but a very, very constrained environment.  Registries work.  Once you have the registry, then you look for the simplest way to implement the functionality.  That's what I proposed (one extension namespace, three DHCP options, and you are done for all new extensions).  If you really want to, you could have only two DHCP options if you have non-intersecting numbers in the two registries.

Brian

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 8 Dec 2010 08:12:13 +0800

Brian,

I have asked on numerous occasions for you to justify the "interoperability problems". I maintain that this is simply not true and have provided examples of why it is not true. The fact that the XML we are already using in protocols and in the PIDF itself all have multiple namespaces goes a long way towards bunking the interoperability argument. Quite simply, I don't want to discourage this, I think it is desirable flexibility to have. It has no impact on backwards compatibility, basic XML rules already allow for this. Local-civic explains this in quite a succinct way.

I am opposed to using a registry as you suggest below. We already have clear guidelines on what is required to register a new CAtype, I don't think these should be relaxed. Further, I think that anybody looking to define new elements will think about their general applicability as part of the definition phase and will, if they are good citizens, submit a specification to have them accepted to the common set of CAtypes. Where elements have local applicability I am all for them staying local, and I think that we need a way to allow people to define these without imposing unnecessary IETF process on them. I simply don't buy the FUD on interoperability that is being pushed using arguments that misrepresent scoping using XML namespaces. 

The reality is that the namespace mechanism doesn't need to be "made" to work, because it already works and I don't see the prediction of doom and chaos around us now, or even blooming on the horizon. Local-civic simply makes DHCP compatible with what can be provided via HELD already. Personally I am okay with a disparity, but previous decisions made by this work group have wanted, as much as possible, to maintain a parity in functionality between these LCPs. So, it is my opinion that this horse has already to a large extent bolted in that we already have one LCP capable of supporting 5139 civic extensions through namespace extension, the greater question is do we leave DHCP behind?

Your assertion that registries just work seems to be somewhat at odds with the email that Richard forwarded from Julian Reschke on the 14th of November.
"Many people take it as a given that once you have an extension point, you need a new registry. Not so." He then goes on to cite exactly what they did in WebDav which has very close parallels to what we are discussing here. The reality, quite to the converse to your assertion, is that local namespaces work really well when defining local content!

I assert that the proposed registry is an imposition on organizations that want to define their own extensions. It is an administrative overhead for the IETF. And, it undermines the due process required when defining new CAtypes by providing a relaxed means of registering globally visible civic address elements without requiring the scrutiny for general applicability provided through the writing and approval of a formal specification. This really will lead to the anarchy and chaos predicted below.

Cheers
James

> Of Brian Rosen
> Sent: Wednesday, 8 December 2010 9:25 AM
> To: Thomson, Martin
> Cc: [email-masked]
> Subject: Re: [Geopriv] Other civic-related stuff
> 
> There is currently two mechanisms.  This adds 1/2 of one.  Semantics, to
> be sure, but the point is that the only difference between two of them is
> the registry they go in and the actual element name/DHCP option.
> 
> We can't avoid the new namespace thing, but it has so many
> interoperability problems, all we can do is discourage it.  Backwards
> compatibility is going to be an issue.  Yet another reason not to use it.
> Your proposal has the same problem.
> 
> A problem occurs when you start with the local registry, and subsequently
> decide it deserves to be more general purpose.  It occurred to me to use
> the same name/number in both, and ask implementations to treat one as the
> other if they encounter it.  Anyone that really wanted to could actually
> check the IANA registry.  All of the implementations we're concerned about
> are on-line anyway.
> 
> The namespace mechanism can be made to "work", but it encourages anarchy.
> No interoperability, no common use.  You have to just "know" that some
> namespace is out there or roll your own.  The registry is the
> advertisement for what others have done.  Namespaces are squeaks in the
> wind.  You could have a million of them and have no way whatsoever to
> build a general purpose LIS, or LoST server, or anything else.
> 
> I don't want to get rid of namespaces.  Don't think we really could even
> if we were even more against them than I am.   However, they are a bad
> idea for all but a very, very constrained environment.  Registries work.
> Once you have the registry, then you look for the simplest way to
> implement the functionality.  That's what I proposed (one extension
> namespace, three DHCP options, and you are done for all new extensions).
> If you really want to, you could have only two DHCP options if you have
> non-intersecting numbers in the two registries.
> 
> Brian
> 
> 
> > You get to choose from three wonderful options.  I'll admit that each is
> effectively partitioned from the other, so there is no need for multiple
> encodings for each.
> >
> > You'd better pick the right option from the outset.  What happens when
> you pick option 3 and it turns out that Option 2 or Option 1 was a better
> choice (maybe it was a good enough idea to standardize)?
> >
> > The other big problem I have with this discussion is the subtext.  That
> subtext is that the existing extension mechanism doesn't work and /can't
> be made to work/.  You would have us throw it all in for a replacement
> scheme.  The numbers don't have enough code points; the namespaces are too
> ugly.  To-mah-toes, to-may-toes.
> >
> > -local-civic acknowledges that it doesn't work due to the interaction
> between the different formats, but proposes an approach that is far less
> disruptive.
> >
> > I had a small concern about there being multiple forms, but now that
> I've had time to mull it over, it's not going to cause significant damage.
> We can handle it.  The way we agreed works.  For the types of things we're
> being asked to add, we can handle it 100 times over.
> >
> >
> > --Martin
> >

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 8 Dec 2010 08:42:15 +0800

On 2010-12-08 at 09:24:49, Brian Rosen wrote:
> interoperability problems, all we can do is discourage it.  

Don't overdramatize it.  The only problem that you seem to be concerned with here is how discoverable new extensions are.  That can be fixed by adding a registry.  No need for new extension mechanisms.

As always, it's only going to be as effective as participation allows it to be.

> Backwards
> compatibility is going to be an issue.  Yet another reason not to use
> it.  Your proposal has the same problem.

Nope, not a bit of a problem.  After all, -local-civic is just describing the mechanism(s) that already exist.  Backwards compatibility for a new extension mechanism is going to be worse.

--

A new proposal:

1. Continue using namespaces to extend the XML.

2. Define a way to carry namespace + localName + value in CAtypes.

3. End use of CAtype numbers.

4. Create a registry for the namespaces.  FCFS or Expert Review with a minimal template required only.  Expert Review would only exist to look for duplicates and to make sure the template is filled out.

That's ONE mechanism. Not two and a half.

It's also far less disruptive to existing implementations.

--Martin

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 7 Dec 2010 19:58:53 -0500

> 4. Create a registry for the namespaces.  FCFS or Expert Review with a minimal template required only.  Expert Review would only exist to look for duplicates and to make sure the template is filled…

Overall, this proposal was sounding pretty good to me.  But I don't see why ending CAtype numbers is necessary or a good idea.  There doesn't seem to be any harm in keeping the numerical designations in the standard-required registry (while adding a "namespace" column) and allowing new standard options to use them.  Given the efficiency gain, it could serve as an incentive to get a standard CAtype!

Note that you could also assign numbers to the FCFS extension schema registry as well, and get a little bit of efficiency.  That way, for (2) you could have the generic extension binary type be:
{
  uint8_t EXT_CA_TYPE
  uint16_t NS_ID
  octet_string localName
  octet_string value
}
As a bonus, it would encourage people to register their schemas!

--Richard

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 8 Dec 2010 09:13:01 +0800

I'm not wed to the idea - I actually still prefer what's in -local-civic, which doesn't end the use of CAtypes.  I'm also somewhat ambivalent on the registry, but I'm willing to add that for Brian's sake.

What you propose is a false optimization because you have to know that the registry contains a particular NS_ID (and what it is) to be able to take it from the DHCP form and get an XML form.  That's the essential problem with extensions - you have to assume that someone, sometime is going to get one that they don't know about.

If you have two representations for the same thing (in this case, namespace URI and the NS_ID), then you are back to having two representations.

Now, I've satisfied myself that the impact of that is small, but what you propose has the same weaknesses as -local-civic and it adds a new extension mechanism in the process.  It does save a few bytes in the process, but you can save more by registering a CAtype.

--Martin

On 2010-12-08 at 11:58:53, Richard L. Barnes wrote:
> > 4. Create a registry for the namespaces.  FCFS or Expert Review with
> a minimal template required only.  Expert Review would only exist to
> look for duplicates and to make sure the template is filled out.
> 
> Overall, this proposal was sounding pretty good to me.  But I don't see
> why ending CAtype numbers is necessary or a good idea.  There doesn't
> seem to be any harm in keeping the numerical designations in the
> standard-required registry (while adding a "namespace" column) and
> allowing new standard options to use them.  Given the efficiency gain,
> it could serve as an incentive to get a standard CAtype!
> 
> Note that you could also assign numbers to the FCFS extension schema
> registry as well, and get a little bit of efficiency.  That way, for
> (2) you could have the generic extension binary type be:
> {
>   uint8_t EXT_CA_TYPE
>   uint16_t NS_ID
>   octet_string localName
>   octet_string value
> }

---

From: Brian Rosen <[email-masked]>
Date: Wed, 8 Dec 2010 08:52:45 -0500

> 4. Create a registry for the namespaces.  FCFS or Expert Review with a minimal template required only.  Expert Review would only exist to look for duplicates and to make sure the template is filled…
I'm always willing to compromise, and decoration is one of the easiest ways to compromise.  All we need is uniqueness, and getting it by registered namespace+local name gets that.  I think it's unnecessary, but it's okay.

The downside to me is that there really is a difference between a generally useful CAtype, with a document that has significant consensus/review, and a CAtype that is not duplicative, but has a more narrow use, and we're really only concerned about re-use.  Retaining the present registry with its current management requirements seems important to me.  If consensus is that having two levels of review is not important, I won't make a fuss.

As long as the template has a solid definition of the elements (such that it's possible for anyone else to re-use it the same way, and the expert can determine that a new one is different or not), It's okay.  Think about the fact that the registry has to have the elements defined in it, not just the namespace, along with at least a minimal description, so the expert (and anyone else) can scan through to find out if something is there.  IANA has to keep the templates, or they have to be stored in some archive somewhere that is permanent.  That's simple enough.  There wouldn't be any requirement that the element names be unique (because the namespace is unique), but good practice probably would suggest that it should be.

By the time you get to that, your registry and mine don't look very different.

I'm assuming that along with "Define a way to carry namespace + localName + value in CAtypes", there is an equivalent DHCP option.  Qnames would continue to work for LoST validation and service boundaries.

Brian

---

From: Brian Rosen <[email-masked]>
Date: Wed, 8 Dec 2010 09:09:18 -0500

We may be heading for compromise, so this may be moot but:

The point of interoperability is that if YOU create a LIS and I create an app that uses location, it would be real nice if my app uses your location.

If I define some extension that you don't know about, I may reject your location.

The more we create these situations, the less the whole system will work.

99% of apps should be able to use the per country location that is discussed in 5774.  It is HIGHLY desirable that the total number of elements needed to cover all of the countries that (eventually) get listed in the registry that 5774 creates be as small as possible, and that elements are re-used as much as possible.  If I want my app to work world wide, I have to deal with each of those elements, and the fewer, the better.

I'll accept that there will be apps that need things beyond that.  However, the same considerations apply.  The smaller the variation, the easier it is to create locations and apps that interoperate.

Uniqueness, which is the only property you seem to care about, is necessary, but far, far from sufficient.

I don't really care all that much about decoration.  I'm an engineer and I like things to be efficient.  If you want to carry around a zillion namespaces in a detailed location object, okay.  I'd prefer just a unique name in a registry, but that isn't that important to me.  What is important is to encourage re-use and advertisement of location elements so that apps can be built that work well in a wide variety of situations.

Brian

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 9 Dec 2010 03:49:45 +0800

Responses inline.

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Thursday, 9 December 2010 1:09 AM
> To: Winterbottom, James
> Cc: Thomson, Martin; [email-masked]
> The point of interoperability is that if YOU create a LIS and I create an
> app that uses location, it would be real nice if my app uses your
> location.
> 
[AJW] Then this would be a very bad application. If I provide you something that the application doesn't understand, then the application should ignore it. If the application requires more information than the LIS provides to the device in order to work, then having a registry still doesn't help. Perhaps you can elaborate a bit on how you see the registry fixing this problem? 

> 99% of apps should be able to use the per country location that is
> discussed in 5774.  It is HIGHLY desirable that the total number of
> elements needed to cover all of the countries that (eventually) get listed
> in the registry that 5774 creates be as small as possible, and that
> elements are re-used as much as possible.  If I want my app to work world
> wide, I have to deal with each of those elements, and the fewer, the
> better.

[AJW] If you want your app to work world wide, then we have a registry already for these elements, we don't need another one. If I want my app to work only within a limited scope, then I should be allowed to define local elements and have them made available to end-points that need to use the application. We have a disparity today in the HELD can do this and DHCP can't.

> 
> I'll accept that there will be apps that need things beyond that.
> However, the same considerations apply.  The smaller the variation, the
> easier it is to create locations and apps that interoperate.
> 
[AJW]I am not seeing what additional properties you require, certainly the registry is not providing anything additional.

> I don't really care all that much about decoration.  I'm an engineer and I
> like things to be efficient.  If you want to carry around a zillion
> namespaces in a detailed location object, okay.  I'd prefer just a unique
> name in a registry, but that isn't that important to me.  What is
> important is to encourage re-use and advertisement of location elements so
> that apps can be built that work well in a wide variety of situations.
>
[AJW] I like things to be efficient too. We aren't talking about a zillion namespaces in a location object, we are talking about one or two localized namespaces for local applications in some environments. The world doesn't need to know this stuff, so why tell it?

> > I have asked on numerous occasions for you to justify the
> "interoperability problems". I maintain that this is simply not true and
> have provided examples of why it is not true. The fact that the XML we are
> already using in protocols and in the PIDF itself all have multiple
> namespaces goes a long way towards bunking the interoperability argument.
> Quite simply, I don't want to discourage this, I think it is desirable
> flexibility to have. It has no impact on backwards compatibility, basic
> XML rules already allow for this. Local-civic explains this in quite a
> succinct way.
> >
> > I am opposed to using a registry as you suggest below. We already have
> clear guidelines on what is required to register a new CAtype, I don't
> think these should be relaxed. Further, I think that anybody looking to
> define new elements will think about their general applicability as part
> of the definition phase and will, if they are good citizens, submit a
> specification to have them accepted to the common set of CAtypes. Where
> elements have local applicability I am all for them staying local, and I
> think that we need a way to allow people to define these without imposing
> unnecessary IETF process on them. I simply don't buy the FUD on
> interoperability that is being pushed using arguments that misrepresent
> scoping using XML namespaces.
> >
> > The reality is that the namespace mechanism doesn't need to be "made" to
> work, because it already works and I don't see the prediction of doom and
> chaos around us now, or even blooming on the horizon. Local-civic simply
> makes DHCP compatible with what can be provided via HELD already.
> Personally I am okay with a disparity, but previous decisions made by this
> work group have wanted, as much as possible, to maintain a parity in
> functionality between these LCPs. So, it is my opinion that this horse has
> already to a large extent bolted in that we already have one LCP capable
> of supporting 5139 civic extensions through namespace extension, the
> greater question is do we leave DHCP behind?
> >
> > Your assertion that registries just work seems to be somewhat at odds
> with the email that Richard forwarded from Julian Reschke on the 14th of
> November.
> > "Many people take it as a given that once you have an extension point,
> you need a new registry. Not so." He then goes on to cite exactly what
> they did in WebDav which has very close parallels to what we are
> discussing here. The reality, quite to the converse to your assertion, is
> that local namespaces work really well when defining local content!
> >
> > I assert that the proposed registry is an imposition on organizations
> that want to define their own extensions. It is an administrative overhead
> for the IETF. And, it undermines the due process required when defining
> new CAtypes by providing a relaxed means of registering globally visible
> civic address elements without requiring the scrutiny for general
> applicability provided through the writing and approval of a formal
> specification. This really will lead to the anarchy and chaos predicted
> below.
> >
> > Cheers
> > James
> >
> >
> >
> >
> >
> >
> >
> >
> >

---

From: Brian Rosen <[email-masked]>
Date: Wed, 8 Dec 2010 16:15:20 -0500

Let's take milepost.

Using your logic, the 300 or more countries that have some sort of numbered post which represents distance along a road/trail/whatever should each create a new namespace, and call that thing whatever fits their fancy.  In the U.S., it would be a "milepost".  It most certainly wouldn't in many other countries. 

If I write an app that is expected to use the milepost globally, I have to use 300 different names for the same thing.   I have to have 300 different snippets of code that do the same thing. 

It "works" in the sense I can create the PIDFs, but not in the sense that the job to make a globally useful app is much, much larger than it should be for no value.  The namespaces for all of these countries don't help me; they just make my code bigger and my PIDF bigger, and create more possibility for error.

Let's take "bridge".  A bridge isn't something you would find in a street address, but many countries have naming schemes for bridges, and you can imagine apps that make use of them.  I know of several.  Your idea is that every app create it's own namespace, define bridge and demand that every user of that app use its definition of bridge.   There isn't any reasonable way for an app designer to just know that someone else wrote an app that defined a bridge element unless you create a registry, so you would expect dozens of namespaces with a bridge element.  Any creator of PIDFs needs custom code for each app, just to make a:bridge and b:bridge and c:bridge work.  

To me, this is all stupid.  There are very few instances of truly unique items in a location.  Nearly every item is common across many applications.  What you want is a list of element definitions.  If someone has already defined it, use their definition.  If not, create a new one and let everyone else know about it so they can use it.  That is a registry.

I further observe that if you have such a registry, then namespaces are just baggage, but I said I would compromise on that point.

Brian

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 9 Dec 2010 13:47:40 +0800

I think that your examples fundamentally miss the point.
As an application developer, if you believe that these items have significant importance and a wide scope then you should write a specification and have them defined as formal CAtypes.
The use case you describe below again assumes that a milepost in one schema has the same fundamental meaning as bagettesFromEiffelTower in a different schema and as I continually point our this is like assuming a variable X in one function is the same variable X in a different function. They may be fundamentally different things, you can't assume that they are the same, scoping means that they are not the same. If you want them to be the same then write a specification and submit them for approval as a formal CAtype.

To be clear in what I am saying. I don't want a registry as you propose below, I don't want a namespace registry either, though I would compromise on this if that is the only way to proceed. My preference is one registry, the CAtype registry, if you aren't prepared to write a specification then keep it local with namespaces.

Cheers
James

> Sent: Thursday, 9 December 2010 8:15 AM
> To: Winterbottom, James
> Using your logic, the 300 or more countries that have some sort of
> numbered post which represents distance along a road/trail/whatever should
> each create a new namespace, and call that thing whatever fits their
> fancy.  In the U.S., it would be a "milepost".  It most certainly wouldn't
> in many other countries.
>
> If I write an app that is expected to use the milepost globally, I have to
> use 300 different names for the same thing.   I have to have 300 different
> snippets of code that do the same thing.
>
> It "works" in the sense I can create the PIDFs, but not in the sense that
> the job to make a globally useful app is much, much larger than it should
> be for no value.  The namespaces for all of these countries don't help me;
> they just make my code bigger and my PIDF bigger, and create more
> possibility for error.
>
> Let's take "bridge".  A bridge isn't something you would find in a street
> address, but many countries have naming schemes for bridges, and you can
> imagine apps that make use of them.  I know of several.  Your idea is that
> every app create it's own namespace, define bridge and demand that every
> user of that app use its definition of bridge.   There isn't any
> reasonable way for an app designer to just know that someone else wrote an
> app that defined a bridge element unless you create a registry, so you
> would expect dozens of namespaces with a bridge element.  Any creator of
> PIDFs needs custom code for each app, just to make a:bridge and b:bridge
> and c:bridge work.
>
> To me, this is all stupid.  There are very few instances of truly unique
> items in a location.  Nearly every item is common across many
> applications.  What you want is a list of element definitions.  If someone
> has already defined it, use their definition.  If not, create a new one
> and let everyone else know about it so they can use it.  That is a
> registry.
>
> I further observe that if you have such a registry, then namespaces are
> just baggage, but I said I would compromise on that point.
>
> Brian
>
>
>
>
> > [AJW] Then this would be a very bad application. If I provide you
> something that the application doesn't understand, then the application
> should ignore it. If the application requires more information than the
> LIS provides to the device in order to work, then having a registry still
> doesn't help. Perhaps you can elaborate a bit on how you see the registry
> fixing this problem?
> >
> >
> > [AJW] If you want your app to work world wide, then we have a registry
> already for these elements, we don't need another one. If I want my app to
> work only within a limited scope, then I should be allowed to define local
> elements and have them made available to end-points that need to use the
> application. We have a disparity today in the HELD can do this and DHCP
> can't.
> >
> >>
> > [AJW]I am not seeing what additional properties you require, certainly
> the registry is not providing anything additional.
> >
> > [AJW] I like things to be efficient too. We aren't talking about a
> zillion namespaces in a location object, we are talking about one or two
> localized namespaces for local applications in some environments. The
> world doesn't need to know this stuff, so why tell it?
> >
> >
> >> Brian
> >>>> be sure, but the point is that the only difference between two of
> them
> >> is
> >>>>> You get to choose from three wonderful options.  I'll admit that
> each
> >> is
> >>>> scheme.  The numbers don't have enough code points; the namespaces
> are
> >> too

---

From: Brian Rosen <[email-masked]>
Date: Thu, 9 Dec 2010 07:07:40 -0500

And I fundamentally disagree.

Brian

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 10 Dec 2010 06:41:23 +0800

On 2010-12-09 at 00:52:45, Brian Rosen wrote:
> I'm always willing to compromise, and decoration is one of the easiest
> ways to compromise.  All we need is uniqueness, and getting it by
> registered namespace+local name gets that.  I think it's unnecessary,
> but it's okay.
> 
> The downside to me is that there really is a difference between a
> generally useful CAtype, with a document that has significant
> consensus/review, and a CAtype that is not duplicative, but has a more
> narrow use, and we're really only concerned about re-use.  Retaining
> the present registry with its current management requirements seems
> important to me.  If consensus is that having two levels of review is
> not important, I won't make a fuss.

I can be persuaded to include two levels of review, but I am only really describing the current management requirements.  That is, the current requirements are equivalent to the weaker level you advocate.

Current requirements are 'Expert Review' and 'Specification Required'.  Specification Required is a subset of Expert Review [RFC5226], so that's just redundant.  Without guidance (and there is none) Expert Review amounts to a check that the a specification exists.

> As long as the template has a solid definition of the elements (such
> that it's possible for anyone else to re-use it the same way, and the
> expert can determine that a new one is different or not), It's okay.
> Think about the fact that the registry has to have the elements defined
> in it, not just the namespace, along with at least a minimal
> description, so the expert (and anyone else) can scan through to find
> out if something is there.  IANA has to keep the templates, or they
> have to be stored in some archive somewhere that is permanent.  That's
> simple enough.  There wouldn't be any requirement that the element
> names be unique (because the namespace is unique), but good practice
> probably would suggest that it should be.

Anything we do to specify a template or any other procedure only makes the process MORE difficult.  That's probably not a bad thing because they also make it easier by making it clearer what the expectations are.

> I'm assuming that along with "Define a way to carry namespace +
> localName + value in CAtypes", there is an equivalent DHCP option.
> Qnames would continue to work for LoST validation and service
> boundaries.

That's right.  The QName works by default.  LoST validation and service boundaries only have to deal with one representation.

--Martin

---

From: Brian Rosen <[email-masked]>
Date: Thu, 9 Dec 2010 17:53:24 -0500

This looks like consensus, at least between Martin and I.

Brian