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
