It is an industry requirement at this point that the changes don't impact these. You might not like the mechanism in local-civic but it address what the industry requires and still allows the extensions necessary.
Cheers
James
> -----Original Message-----
> From: Brian Rosen [mailto:br@brianrosen.net]
> Sent: Wednesday, 27 October 2010 11:45 AM
> To: Winterbottom, James
> Cc: Richard L. Barnes; geopriv@ietf.org; Thomson, Martin
> Subject: Re: [Geopriv] draft-ietf-geopriv-prefix-00 & draft-winterbottom-
> geopriv-local-civic
>
> I understand this, but I'd rather fix it then use the mechanisms you
> invented. I think the FCFS registry is a good idea.
>
> It's not a deal breaker to me, but we're early enough that I think it's
> worth doing it cleanly.
>
> Brian
>
> On Oct 26, 2010, at 6:49 PM, Winterbottom, James wrote:
>
> > Perhaps I should have clarified, the problem is caused with LoST
> validation.
> > LoST validation elements are returned as qualified names,
> namespace+element or if you have a namespace+prefix defined in the same
> scope then prefix+element. When you introduce a common element name, with
> a "type" to distinguish between the actual elements as 2a is doing, there
> is no way to communicate to the thing requesting validation what actually
> validated and what didn't.
> >
> > This problem doesn't exist with 2b.
> > The appendix in the local-civic draft hacks its way around this problem
> because the CATypeExt namespace is known, I don't think that this hack
> works well/at-all for an arbitrary namespace.
> >
> > Cheers
> > James
> >
> >
> > James Winterbottom
> > Global Product Manager
> > Andrew GeoLENs
> > IP Location Product Portfolio
> > Email: james.winterbottom@andrew.com
> > Phone: +61-2-42-212938
> > Mobile: +61-447-773-560
> >
> >
> >> -----Original Message-----
> >> From: Richard L. Barnes [mailto:rbarnes@bbn.com]
> >> Sent: Wednesday, 27 October 2010 9:44 AM
> >> To: Winterbottom, James
> >> Cc: Brian Rosen; geopriv@ietf.org; Thomson, Martin
> >> Subject: Re: [Geopriv] draft-ietf-geopriv-prefix-00 & draft-
> winterbottom-
> >> geopriv-local-civic
> >>
> >> How does 2.a. cause a problem with LoST? Or, is it that 2.a. causes a
> >> problem with LoST while 2.b. doesn't? The only difference is the
> >> number of extension namespaces/schemas.
> >>
> >> --Richard
> >>
> >>
> >>
> >> On Oct 26, 2010, at 6:24 PM, Winterbottom, James wrote:
> >>
> >>> I am not really in favour of type 2a. My rationale being that I
> >>> think that this doesn't fit well with how one would validate it in
> >>> something like LoST in a consistent way. The proposal in the
> >>> appendix of the local-civic draft is a hack, but it works because
> >>> the namespace is known, and so this is blended into the element
> >>> name. 2b works fine, because elements in LoST validation are qnames
> >>> and so are qualified by the namespace or prefix.
> >>>
> >>> Anything you want to do with 2a can be done with 2b, and 2b plays
> >>> nicely with other things.
> >>>
> >>> I think that for 2a to be a serious contender as an option there
> >>> needs to be a strong case made for it and there needs to be a
> >>> consistent way to over come the LoST interaction problem I described.
> >>>
> >>> Cheers
> >>> James
> >>>
> >>>
> >>> James Winterbottom
> >>> Global Product Manager
> >>> Andrew GeoLENs
> >>> IP Location Product Portfolio
> >>> Email: james.winterbottom@andrew.com
> >>> Phone: +61-2-42-212938
> >>> Mobile: +61-447-773-560
> >>>
> >>>> -----Original Message-----
> >>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com]
> >>>> Sent: Wednesday, 27 October 2010 9:11 AM
> >>>> To: Brian Rosen
> >>>> Cc: Winterbottom, James; geopriv@ietf.org; Thomson, Martin
> >>>> Subject: Re: [Geopriv] draft-ietf-geopriv-prefix-00 & draft-
> >>>> winterbottom-
> >>>> geopriv-local-civic
> >>>>
> >>>> Ok, good, hope we're converging here. To tighten up the proposal a
> >>>> little:
> >>>>
> >>>> 1. An "official extension" namespace with a single element
> >>>> <ext:caElement type="thing">fnord</ext:caElement>
> >>>> Values for the 'type' attribute MUST be registered in the standard
> >>>> IANA registry. DHCP serialization via standard RFC 4776 use of
> >>>> CAtype
> >>>> numbers.
> >>>>
> >>>> 2.a. A "private extension" namespace with a single element
> >>>> <priv:caElement type="other-thing">fnord</priv:caElement>
> >>>> (This could actually be done in the same namespace as the "official"
> >>>> one). Values for the 'type' attribute SHOULD be registered in a new
> >>>> FCFS registry and MUST NOT be in the "official CAType" registry.
> >>>> DHCP serialization via a new civic address element
> >>>> +-------------+----------+--------+---------+
> >>>> | CAType=PRIV | CALength | CAName | CAValue |
> >>>> +-------------+----------+--------+---------+
> >>>>
> >>>> 2.b. A template for private extensions recommending that they have
> >>>> the
> >>>> same "list of elements" structure
> >>>> <priv:XYZ>fnord</priv:XYZ>
> >>>> (Type values == element names are unconstrained.) DHCP serialization
> >>>> via a new civic address element
> >>>> +-------------+----------+-------------+--------+---------+
> >>>> | CAType=PRIV | CALength | CANamespace | CAName | CAValue |
> >>>> +-------------+----------+-------------+--------+---------+
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Oct 26, 2010, at 5:55 PM, Brian Rosen wrote:
> >>>>
> >>>>> Agree on both points
> >>>>>
> >>>>> We could do something gross like have a FCFS registry for local
> >>>>> CAtypes whose only purpose really is to allow extCAtype to be used
> >>>>> in DHCP and other similar mechanisms, but I think a private
> >>>>> namespace is a cleaner approach.
> >>>>>
> >>>>> Brian
> >>>>> On Oct 26, 2010, at 5:36 PM, Richard L. Barnes wrote:
> >>>>>
> >>>>>> Another wrinkle, just to make sure there's common understanding:
> >>>>>> This approach does *not* prevent people from adding "private"
> >>>>>> extension elements from other namespaces. It just provides a more
> >>>>>> extensible way forward for "official" CAtypes.
> >>>>>>
> >>>>>> It also kind of disclaims any responsibility for what the private
> >>>>>> extensions should look like. I think it might be nice to at least
> >>>>>> make some recommendations about that, e.g., suggesting a CAtype-
> >>>>>> like type/value list or saying something about DHCP serialization.
> >>>>>> (Note, though, that this path kind of leads back toward the -local-
> >>>>>> civic DHCP concepts.)
> >>>>>>
> >>>>>> --Richard
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Oct 26, 2010, at 4:23 PM, Brian Rosen wrote:
> >>>>>>
> >>>>>>> The better part of valor would be to say that we define extCAtype
> >>>>>>> in a new namespace and preserve backwards compatibility.
> >>>>>>>
> >>>>>>> I actually think there are so few deployments that we could redo
> >>>>>>> the schema with a new namespace, which would make it much cleaner
> >>>>>>> for the 99.9999% of implementations that come after the handful
> >>>>>>> that are around now. You are forcing two namespaces where one
> >>>>>>> will do for a very small deployment upgrade.
> >>>>>>>
> >>>>>>> But I'll go with WG consensus on that. The important parts to me
> >>>>>>> are:
> >>>>>>> a) Controlled expansion of the CAtypes registry
> >>>>>>> b) Common use CAtypes are always named, defined, and used
> >>>>>>> consistently
> >>>>>>> c) Limited (1 or 2) namespaces for any global address, with
> >>>>>>> possible per country tweaks as in 5774
> >>>>>>> d) Only one way to encode an extension (from here on in) CAtype,
> >>>>>>> not 3.
> >>>>>>>
> >>>>>>> If I might add a bit of a wrinkle:
> >>>>>>> I'd like to add two generic parameters to extCAtype, so that a new
> >>>>>>> CAtype could be defined that used them.
> >>>>>>> One example of that would be the INT (which had parameters), but
> >>>>>>> there are others.
> >>>>>>>
> >>>>>>> Brian
> >>>>>>>
> >>>>>>> On Oct 26, 2010, at 3:40 PM, Richard L. Barnes wrote:
> >>>>>>>
> >>>>>>>> The appropriate question would seem to be in what namespace this
> >>>>>>>> <extCAtype> element lives. If it's in a new namespace, then
> >>>>>>>> there's no break in backward compatibility. Also, there would be
> >>>>>>>> no need to change LoST, since the LoST civic profile is defined
> >>>>>>>> by reference to RFC 5139, which accommodates additional
> >>>>>>>> namespaces.
> >>>>>>>>
> >>>>>>>> --Richard
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Oct 26, 2010, at 10:46 AM, Brian Rosen wrote:
> >>>>>>>>
> >>>>>>>>> If you would please concentrate on what I proposed, we could
> >>>>>>>>> perhaps make some more rapid progress.
> >>>>>>>>>
> >>>>>>>>> I proposed having ONE new element = extensionCAtype, which very
> >>>>>>>>> similar to one part of your proposal.
> >>>>>>>>> <extCAtype "CAname="STP">Avenue</extCAtype>
> >>>>>>>>>
> >>>>>>>>> Endpoints have one (or maybe two) namespaces. We don't have to
> >>>>>>>>> mint new ones for any new extensions.
> >>>>>>>>>
> >>>>>>>>> LoST does need to change, once, but not again, although it's
> >>>>>>>>> backwards compatible with the current extension point. The only
> >>>>>>>>> reason it needs to change is that there are parameters to
> >>>>>>>>> extCAtype. I think your proposal has the same issue.
> >>>>>>>>>
> >>>>>>>>> Endpoints support ONE (or maybe 2) schema(s). If they don't
> >>>>>>>>> understand any given CAtype, they can pass it, or ignore it.
> >>>>>>>>>
> >>>>>>>>> There is ONE way to express any new CA, extCAtype.
> >>>>>>>>>
> >>>>>>>>> Brian
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Oct 25, 2010, at 10:29 PM, Winterbottom, James wrote:
> >>>>>>>>>
> >>>>>>>>>> I am sorry, but I don't see any rational argument for not
> >>>>>>>>>> including just the new elements into a new namespace beyond "oh
> >>>>>>>>>> I don't want to have multiple namespace declarations".
> >>>>>>>>>>
> >>>>>>>>>> Brian, the impacts we are talking about if we continue with
> >>>>>>>>>> your approach are:
> >>>>>>>>>> 1)No end-point can be sure what namespace received CATypes
> >>>>>>>>>> should be put in to ensure they are understood.
> >>>>>>>>>> 2) LoST will need to change to support another Civic profile
> >>>>>>>>>> 3) All end-points will now need to support multiple civic
> >>>>>>>>>> schemas since they cannot be sure which one they will be given
> >>>>>>>>>>
> >>>>>>>>>> And these just what I can think of without spending any time on
> >>>>>>>>>> the problem, yet all this work will need to be done because
> >>>>>>>>>> somebody doesn't want to see extra namespace declarations. I am
> >>>>>>>>>> sorry but I don't think that this is reasonable, and it leaves
> >>>>>>>>>> problems that I don't believe can be solved, without
> >>>>>>>>>> significant work by vendors.
> >>>>>>>>>>
> >>>>>>>>>> Cheers
> >>>>>>>>>> James
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> James Winterbottom
> >>>>>>>>>> Global Product Manager
> >>>>>>>>>> Andrew GeoLENs
> >>>>>>>>>> IP Location Product Portfolio
> >>>>>>>>>> Email: james.winterbottom@andrew.com
> >>>>>>>>>> Phone: +61-2-42-212938
> >>>>>>>>>> Mobile: +61-447-773-560
> >>>>>>>>>>
> >>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>> From: geopriv-bounces@ietf.org [mailto:geopriv-
> >>>>>>>>>>> bounces@ietf.org] On Behalf
> >>>>>>>>>>> Of Brian Rosen
> >>>>>>>>>>> Sent: Tuesday, 26 October 2010 11:04 AM
> >>>>>>>>>>> To: Thomson, Martin
> >>>>>>>>>>> Cc: geopriv@ietf.org
> >>>>>>>>>>> Subject: Re: [Geopriv] draft-ietf-geopriv-prefix-00 & draft-
> >>>>>>>>>>> winterbottom-
> >>>>>>>>>>> geopriv-local-civic
> >>>>>>>>>>>
> >>>>>>>>>>> While I am happy to hear that deployments of 5139 exist, we
> >>>>>>>>>>> live in a
> >>>>>>>>>>> world were it's upgrade or die.
> >>>>>>>>>>>
> >>>>>>>>>>> Nevertheless, as I said, I would like a better way.
> >>>>>>>>>>>
> >>>>>>>>>>> I agree that people will extend. I am not advocating
> >>>>>>>>>>> eliminating the
> >>>>>>>>>>> possibility of a "private" namespace. However, I believe it
> >>>>>>>>>>> is
> >>>>>>>>>>> appropriate that IETF control "official" extensions that have
> >>>>>>>>>>> broad
> >>>>>>>>>>> applicability. Prefix is one such extension. "relative-
> >>>>>>>>>>> location" is
> >>>>>>>>>>> another. Adding new "official" CAtypes should be possible,
> >>>>>>>>>>> with
> >>>>>>>>>>> appropriate review.
> >>>>>>>>>>>
> >>>>>>>>>>> I understand that to correctly parse an address into fields,
> >>>>>>>>>>> or to render
> >>>>>>>>>>> fields into human readable text, requires a per-country
> >>>>>>>>>>> document, which
> >>>>>>>>>>> means per-country code. It's unavoidable. However, we saw
> >>>>>>>>>>> value in
> >>>>>>>>>>> creating a list of common elements that many countries used in
> >>>>>>>>>>> their
> >>>>>>>>>>> addresses. I believe that remains a value, and it would be
> >>>>>>>>>>> most
> >>>>>>>>>>> unfortunate to have "Street Prefix" in one and
> >>>>>>>>>>> "ThoroughfareType-Pre" in
> >>>>>>>>>>> another that was exactly the same thing, used the same way as
> >>>>>>>>>>> "STS" but
> >>>>>>>>>>> before the street name. That is the value in having a formal
> >>>>>>>>>>> extension
> >>>>>>>>>>> path for CAtypes.
> >>>>>>>>>>>
> >>>>>>>>>>> If we agree on that, then we need a way to create the XML. I
> >>>>>>>>>>> really
> >>>>>>>>>>> dislike 3 ways to do the same thing. Having a generic
> >>>>>>>>>>> extension gives us
> >>>>>>>>>>> one way to have an extended CAtype, rather than 3. It avoids
> >>>>>>>>>>> adding a
> >>>>>>>>>>> slew of namespaces. It continues the use of the CAtype
> >>>>>>>>>>> registry, with its
> >>>>>>>>>>> current policy for adding CAtypes. Given the example in 5774,
> >>>>>>>>>>> that's
> >>>>>>>>>>> really all we need.
> >>>>>>>>>>>
> >>>>>>>>>>> Private extensions can use their own namespace, as they can
> >>>>>>>>>>> now.
> >>>>>>>>>>>
> >>>>>>>>>>> Brian
> >>>>>>>>>>>
> >>>>>>>>>>> On Oct 25, 2010, at 7:10 PM, Thomson, Martin wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Hi Brian,
> >>>>>>>>>>>>
> >>>>>>>>>>>> I agree with Hannes. Backwards compatibility is more
> >>>>>>>>>>>> important than you
> >>>>>>>>>>> seem to think.
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 2010-10-26 at 01:46:17, Brian Rosen wrote:
> >>>>>>>>>>>>> Is there really a good reason why 5139 can create a new
> >>>>>>>>>>>>> namespace that
> >>>>>>>>>>>>> effectively obsoletes the one in 4119, but -prefix cannot?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Yes, there are two very good reasons.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Use: Actual use of 4119 was rare to non-existent. 5139 is in
> >>>>>>>>>>>> use.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Language: There was no allowance for language tags in 4119 -
> >>>>>>>>>>>> something
> >>>>>>>>>>> that I'm sure you'll agree is handy. Adding language tags in
> >>>>>>>>>>> any other
> >>>>>>>>>>> way would have been extremely difficult.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> It has always been possible to add a namespace and add
> >>>>>>>>>>>>> elements to a
> >>>>>>>>>>>>> PIDF. The obvious problem is that anyone could declare
> >>>>>>>>>>>>> such a
> >>>>>>>>>>>>> namespace, and then expect the rest of the world to generate
> >>>>>>>>>>>>> PIDFs with
> >>>>>>>>>>>>> their namespace. This leads to non-interoperability, a
> >>>>>>>>>>>>> point made in
> >>>>>>>>>>>>> the comments on earlier versions of -local-civic.
> >>>>>>>>>>>>
> >>>>>>>>>>>> There's a definite parallel on the apps-discuss list
> >>>>>>>>>>>> regarding
> >>>>>>>>>>> extensions in the discussions on X-. The basic rule is that
> >>>>>>>>>>> people will
> >>>>>>>>>>> extend. When they do so, they don't necessarily seek
> >>>>>>>>>>> interoperability.
> >>>>>>>>>>> That comes later as the extension is seen to be useful.
> >>>>>>>>>>>>
> >>>>>>>>>>>> We need to provide a path toward interoperability. -local-
> >>>>>>>>>>>> civic
> >>>>>>>>>>> describes how that works. "Interoperability or bust" is not a
> >>>>>>>>>>> sentiment
> >>>>>>>>>>> that I would like to have conveyed.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> The current accepted IETF practice in this kind of
> >>>>>>>>>>>>> situation is to in fact issue a new namespace, which we all
> >>>>>>>>>>>>> agree is
> >>>>>>>>>>>>> not very good.
> >>>>>>>>>>>>
> >>>>>>>>>>>> [citation required]
> >>>>>>>>>>>>
> >>>>>>>>>>>> Extensions go in new namespaces: yes. Extensions replace the
> >>>>>>>>>>>> original
> >>>>>>>>>>> namespace: not from what I've seen.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I'm not sure if I think this is very good or not. It's just
> >>>>>>>>>>>> how things
> >>>>>>>>>>> are: a trade-off between competing considerations.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> I think we will discover, from time to time, that new
> >>>>>>>>>>>>> CAtypes, which
> >>>>>>>>>>>>> have relatively broad applicability, are needed. What we're
> >>>>>>>>>>>>> searching
> >>>>>>>>>>>>> for is a way to add them without breaking backwards
> >>>>>>>>>>>>> compatibility.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Precisely. This is why my mind boggles when you recommend
> >>>>>>>>>>>> that we break
> >>>>>>>>>>> backward compatibility.
> >>>>>>>>>>>>
> >>>>>>>>>>>> --Martin
> >>>>>>>>>>>
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>>>> 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
