>Hi Brian,
>
>Comments in line.
>________________________________________
>From: Brian Rosen [br@brianrosen.net]
>Sent: Tuesday, September 07, 2010 8:41 AM
>To: Winterbottom, James
>Cc: geopriv@ietf.org
>Subject: Re: [Geopriv] New Version Notification for
>draft-winterbottom-geopriv-local-civic-00
>
>While I am in favor of the basic idea this puts forth, I am opposed
>to the mechanisms described in this draft.
>
>[AJW] Excellent. This is a good place to start from.
>
>Let's take an example - Robins George and my "lamp-post"
>draft. This would mean we wouldn't proceed with that draft, and
>NENA would just create a namespace with milepost in it.
>
>[AJW] Absolutely right, only applications that need to understand
>"lamp-post" would do so. Better still, organization don't need to
>come the IETF everytime they want to define a new element specific
>to their application. This is a win for everyone.
see, this to me is a real problem - as I see "no one has to come to
the IETF to define new things" as creating something RIPE for
collisions, i.e., incompatible elements or descriptions that mean one
thing to one (group) and an entirely different thing to the other (group).
This, to me, breeds incompatibility - only to get worse over time.
IANA is there to prevent this - and what you're suggesting is to
circumvent that registration (with associated document defining the
means/usage of such a/each new element.
>There is no review and no registry for these namespaces - anyone can
>make one, and create a PIDF that conforms to it and recipients would
>be up the creek without the paddle if they didn't know this variant
>= no interoperability.
>
>[AJW] Herein lies a great misconception. First of all this can and
>is done today already, XML allows this, and to a large extent
>encourages it. That is the XML examples in the document are
>perfectly legal civic examples today, and any device processing the
>civic schema needs to be able to handle this today. Absolutely
>nothing new, the current behaviour is to ignore the additional
>elements it doesn't understand.
but if you do not understand that I am using the same element to mean
something entirely different, there is no ignoring rule applicable,
just incompatibility because how you fill your element and how I fill
my element - where they both look like the same XML element. This
cannot work unless you have a means to prevent collisions.
>Requiring the registrations of namespaces into the IETF by external
>organizations so that they can extend an XML schema that has been
>defined with extensions points is cumbersome, unnecessary and I
>would argue ultimately unmanageable.
I think it is quite necessary, and has to be manageable - even if
some may think it takes too long or they do not wish to "go through
the process".
James
>No interaoperability is patently not true. The local extension
>schemas have clearly defined scope. This is defined by the
>namespace, and is applicable to the local application in mind.
>Fields cannot be misinterpreted by something outside of the context
>within which the element was specified. This is good design. You are
>talking variants, and I am talking contexts, and there is a world of
>difference, and the namespace provides this very clear clarification.
>
>If Canada makes a namespace, and calls it mile-post when the U.S.
>one calls it milepost, tough, it's different (different name
>spaces). This is not INT where I explicitly proposed to follow
>local signage and plans; it's the basic civic location.
>
>[AJW] You are right. The Canadian mile-post has significance in
>Canada only. But here is where I think you are misunderstanding
>something. The different namespace means that it is a completely
>different thing, their mile-post might represents the number of
>standard-begets from the Eiffel-tower. It isn't just a US mile-post
>in a different namespace. It is very difficult to misinterpret
>anything when it is defined in this fashion.
>
>My very significant issues with INT, is that it is exactly the
>opposite! It is totally open to misinterpretation and arbitrary
>assignment. It has no definition of context, even within the domain
>that assigns it. So if it forms a basic part of the must implement
>everywhere there is no way to enforce usage or understanding leading
>to complete chaos.
>
>Further to this, you cannot define INT in the fashion that your
>current draft does, without up versioning the civic schema. This
>requires a NEW representation of the civic schema. The impact of
>this is very large. People have implemented and are starting to
>deploy product that represents civic addresses using the schema
>defined in RFC5139. Further to this there are several national
>profiles of the 5139 schema that people have invested a lot of time
>producing. Up versioning the schema will require pretty much all
>implementations to require support for both. This is a very BAD idea.
>
>The DHCP option stuff is truly ugly. With a registry of namespaces,
>and some reasonable rules, we could get the triplet (namespace,
>element name, and value) into a single CAtype.
>
>[AJW] Yes, you could. This would however have significant impacts on
>how long your namespace is allowed to be, and how long the value can
>be. The method as defined means that the namespace only need to be
>sent once, and a number of local elements defined within that
>namespace can be sent following it. The method defined also
>eliminates the need to have artificial separators between the
>namespace, element and value. But if the group things that slamming
>these together into a single value is a good idea, it probably isn;t
>a show-stopped on my part.
>
>Instead, I would propose that we have registries for the namespaces
>with at least expert review, and elements within the namespace, and
>a more compact DHCP option.
>
>[AJW] Requiring organizations to register their namespaces with the
>IETF is a very bad idea and for the reasons stated earlier is
>totally unnecessary.
>
>Brian
>
>On Sep 5, 2010, at 8:41 PM, Winterbottom, James wrote:
>
> > Hi All,
> >
> > There have been a number of discussions on this list, and a
> number of drafts that attempt to introduce new civic address types.
> The problem is that all of these drafts, as written, would require
> an update of the schema defined in RFC5139, and would likely
> require a new namespace. This issue with this is that it breaks
> backward compatibility for other specifications, such as LoST. It
> also has impact on equipment vendors that have implement the 5139
> schema, and national organizations that have profiled their civic
> addresses to fit within the 5139 schema.
> >
> > This draft describes a way that allows easy tension of the civic
> schema, without breaking backwards compatibility, and allows local
> authorities to define their own local address elements in such a
> way that they can have local significance without being open to
> misinterpretation by general applications.
> >
> > Cheers
> > James
> >
> >
> > A new version of I-D,
> draft-winterbottom-geopriv-local-civic-00.txt has been successfully
> submitted by James Winterbottom and posted to the IETF repository.
> >
> > Filename: draft-winterbottom-geopriv-local-civic
> > Revision: 00
> > Title: Specifying Local Civic Address Fields in PIDF-LO
> > Creation_date: 2010-09-06
> > WG ID: Independent Submission
> > Number_of_pages: 7
> >
> > Abstract:
> > This document describes how to specify local civic elements in
> the Geopriv civic schema maintaining backward compatibility with
> existing specifications and implementations. Support for providing
> local civic elements over DHCP is also described.
> >
> >
> >
> > <image002.jpg>
> > James Winterbottom
> > Global Product Manager
> > Andrew GeoLENs
> > IP Location Product Portfolio
> > Email: james.winterbottom@andrew.com
> > Phone: +61-2-42-212938
> > Mobile: +61-447-773-560
> >
> >
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > https://www.ietf.org/mailman/listinfo/geopriv
>
>_______________________________________________
>Geopriv mailing list
>Geopriv@ietf.org
>https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
