1. Maintain IETF control of a registry of things that are REQUIRED
2. Allow "private" extensions that are OPTIONAL
3. Don't break backward compatibility with 5139
Of these three requirements, it seems like the only one that has a
bearing on the *mechanism* for extensibility is the third, which
basically says that new civic elements MUST be in a new namespace.
That seems to me to be orthogonal to the question of how we manage
other extensions. It seems like at a high level, what we want is a
process something like what Martin mentioned with "X-" headers: Let
people create their own proprietary extensions, and as useful ones
emerge, move them toward a list of standard, mandatory extensions
(each in a new namespace).
Really, the only differences between that idea and re-issuing the
schema are (1) how many schemas a client has to recognize, and (2)
breaking backward-compatibility. We can help mitigate (1) even
further by constraining extension schemas to have the same basic
structure as the current schema, i.e., to be a flat list of types.
Then the only change would be that an address would change from being
a list of (name, value) tuples to a list of (namespace, name, value)
tuples, which it is implicitly anyway, and which can have a nice
serialization into DHCP.
(Having written some code that implements RFC 5139, this is how I
handle CAType elements *anyway*, by cosntructing a mapping between
full names (namespace + localName) and values.)
Assuming that mechanism, the only thing you need to do to manage the
extension process is add a field to the IANA CAType table for
"namespace". When you want to create an "official" extension, you
just add the relevant items to the table tagged with the extension
namespace.
Does that maybe sound closer to reasonable?
--Richard
On Oct 25, 2010, at 8:04 PM, Brian Rosen wrote:
> 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
