Re: [Geopriv] Other civic-related stuff

From: Thomson, Martin ^lt;>
Date: Wed Dec 01 2010 - 22:43:55 EST

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

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

> Brian
Geopriv mailing list
Received on Thu, 2 Dec 2010 11:43:55 +0800

This archive was generated by hypermail 2.1.8 : Thu Dec 02 2010 - 00:53:03 EST