[rfc-i] Alternatives to 'deprecated' in xml2rfc v3
Heather Flanagan (RFC Series Editor)
rse at rfc-editor.org
Wed May 7 09:35:11 PDT 2014
On 5/6/14, 10:33 AM, Dave Crocker wrote:
> On 5/6/2014 9:25 AM, Julian Reschke wrote:
>> On 2014-05-06 18:14, Dave Crocker wrote:
>>>> Exactly. It means "you can still use it, but it might be gone in the
>>>> next revision".
>>> Well, that certainly makes clear the issue here.
>>> Basically, some of you are indulging in a desire by some others (maybe
>>> more than just me, but maybe not, I can't tell) for backward
>>> compatibility, but really don't want to indulge it and are threatening
>>> to remove it in the future.
>> The idea is to remove certain constructs only after a better replacement
>> has been available for some time.
> That's certainly the usual model for 'improving' an architecture or
> language. It's effort at better system cleanliness would seem
> unassailable. So it's a classic model when there is very good control
> of the product and user base.
I definitely agree with your first and second sentence above, but the
third sentence is where I start to question. Declaring something as
"deprecated" is an understood model. It is a bridge between something
that exists and something different, helping people clearly see where
evolution is happening in the system.
> However it works poorly in less controlled environments that have a
> variety of independent tools and an unruly user population. Transitions
> are much uglier and users and use are less predictable.
If you introduce users into a system, especially one as open as ours
where we encourage separate implementations to test the validity of the
idea, of course there's going to be some divergence in use and
confusion. Both of which will, hopefully, inform a better system in the
> When I said 'compelling' what I meant was the the pain or damage of
> retention was sufficiently problematic. This is quite a different
> threshold from "we've found a better way to do it."
I think your threshold is higher than is useful in this situation.
>>> Over the course of Internet development, specs that make predictions
>>> about the future are almost always wrong. So avoid the temptation, even
>>> in underlying philosophy.
>>> The point behind backward compatibility is to retain functionality, not
>>> merely to tolerate it temporarily. If there is a compelling reason to
>>> break it, then make that case. Don't threaten it for the future. When
>>> the arguments are compelling, invoke them and apply them. Until then,
>>> embrace backward compatibility.
>> Again, see above. Removing features right now means that there is no
>> transition period. Is this really what you want?
> Of course not. My point really is that there do not seem to be
> compelling reasons now.
> The existing constructs are used and useful. They are not causing
> (significant?) damage.
> So reasons for removal look more like aesthetics than problems.
I think we're looking at a reasonable evolution of the xml2rfc
vocabulary, with rough consensus on what would make the lives of most
authors and the RFC Editor easier. Using clear words like "deprecated"
should lessen the confusion of what we are trying to do and the changes
More information about the rfc-interest