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
