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
