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
