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

Dave Crocker dhc at dcrocker.net
Tue May 6 09:14:57 PDT 2014


On 5/6/2014 8:37 AM, Julian Reschke wrote:
> On 2014-05-06 16:27, Andrew Sullivan wrote:
>> On Tue, May 06, 2014 at 03:24:57PM +0100, Elwyn Davies wrote:
>>> historic items there for backwards compatibility only.  'Deprecated' is
>>> more along the advisory or SHOULD NOT axis.
>>
>> I don't care what you call this.  I will say that, where I come from,
>> "deprecated" means "don't use for new work", which is I think what's
>> wanted, but I really totally don't care.  Call it
>> warning-danger-will-robinson if that makes everyone happy.
>>
>> A
> 
> 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.

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.

As of now, there is a set of vocabulary that will be permitted in input
versions but will not be in the canonical version.  Use of the extra
vocabulary will be translated as part of submission, into forms that
conform to the stricter canonical version.

The additional input constructs are not deprecated, they are not
historic, they are not frowned on, and they are not threatened.

They are supported for document input.  Period.

A section title along the lines of "Additional vocabulary supported for
input" accurately and neutrally describes this set of vocabulary.

The text for the additional vocabulary probably should indicate what it
will get translated to for canonical mode.  Besides simple clarity, this
will provide the reader with useful guidance about how to produce a
'canonical' version, if they wish.

d/

ps. As for the added boilerplate, when going from input to canonical,
yes, of course.  But it's not part of vocabulary.


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


More information about the rfc-interest mailing list