Re: [Geopriv] Other civic-related stuff

From: Brian Rosen ^lt;>
Date: Wed Dec 01 2010 - 19:45:35 EST

Progress, and yet perhaps a bigger misunderstanding of positions.


On Dec 1, 2010, at 6:44 PM, Thomson, Martin wrote:

> Brian,
> In response to the other bits of this response...
> On 2010-12-02 at 10:19:38, Brian Rosen wrote:
>> 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.
> See my other response, and my explanation below for why I think we're not actually making progress.
>> 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.
> 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.
>> LoST validation is also not in play - we understand how to do that with
>> any of the proposals on the table.
> At least we agree on that. There might be hacks, but that's OK.
>> I had the suggestion to have two generic parameters in the one or two
>> 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?
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)
>> I'm pretty lost, no pun intended, on why the service boundary is any
>> 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>.
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. Add multiple extensions and you have an exponential problem.
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 <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.
Yes, but the response could always be in the same form, although I want to eliminate the problem.
> 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
>> 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

Geopriv mailing list
Received on Wed, 1 Dec 2010 19:45:35 -0500

This archive was generated by hypermail 2.1.8 : Wed Dec 01 2010 - 19:46:08 EST