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
