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
