[rfc-i] On backwards compatibility for v2

Henrik Levkowetz henrik at levkowetz.com
Wed Mar 5 03:02:04 PST 2014


I'm reviewing draft-hoffman-xml2rfc-02 at the moment, and also reading
through the rfc-interest archives for the last month.  Sorry if some of
my comments are late, and possibly have already been covered, but in
case they help, I'll be responding to some of the last month's postings
as I come to them:

On 2014-02-10 21:39 Nico Williams said the following:
> On Mon, Feb 10, 2014 at 1:35 PM, Dave Crocker <dhc at dcrocker.net> wrote:
>> On 2/10/2014 10:29 AM, Julian Reschke wrote:
>>> I still believe that we can get to a reasonable v3 without having to
>>> break existing (valid) documents.
>> It is very easy to neglect installed base.  (Take a look at IPv6 as a
>> particularly unfortunate example; it could have been done as a
>> largely-compatible upgrade to v4, rather than forcing an independent stack.)
> The universal deployment of IPv6 continues a[slow]pace for reasons
> nothing like what are being discussed here.  The analogy is simply not
> appropriate.  I won't go on a tangent as to IPv6 here, so I'll stop
> there.
> I see nothing wrong with: "use the v2 tool for formatting docs in the
> v2 schema, use the v3 tool for formatting docs in the v3 schema, use
> the v3 schema for all new docs".  The users here can handle that.
>> So I suggest declaring backward compatibility an explcit requirement, just
>> so no one else gets confused.
> I'd rather have a wart-less, clean v3.  But more than that, I think
> the people writing xml2rfc's v3 support should really be the ones to
> get the most say on this; if it's easy, then fine, if not, not.

Speaking as one of the current maintainers of the xml2rfc command-line

I think supporting two different tools over any length of time is going to
be much more painful than extending one tool to support v3 without taking
out v2 support.  That will also allow us to gradually deperecate elements
of v2.

What's more, I think it's a substantial benefit to the users of the tools
to have one tool to process both v2 and v3, rather than 2 different ones.

>> Might even want to say that the conversion tool is for those who happen to
>> want to upgrade, but that it isn't required.
> If you have an explicit backwards-compat requirement why should there
> be a conversion tool?  If there's a conversion tool that users need to
> be aware of (when they want the new features), why should there be a
> backwards-compat requirement?

I'd prefer to go the route of backwards compatibility rather than having to
design and code a conversion tool.

Best regards,


More information about the rfc-interest mailing list