[rfc-i] Alternatives to 'deprecated' in xml2rfc v3

Dave Crocker dhc at dcrocker.net
Tue May 6 10:33:13 PDT 2014


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.

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.

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."


>> 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.


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


More information about the rfc-interest mailing list