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
