[rfc-i] On backwards compatibility for v2

Paul Kyzivat pkyzivat at alum.mit.edu
Tue Feb 11 08:18:23 PST 2014

On 2/11/14 3:01 AM, Julian Reschke wrote:
> On 2014-02-11 01:02, Paul Kyzivat wrote:
>> On 2/10/14 3:50 PM, Julian Reschke wrote:
>>> On 2014-02-10 20:16, Heather Flanagan (RFC Series Editor) wrote:
>>>> On 2/10/14 9:03 AM, Dave Crocker wrote:
>>>>> On 2/10/2014 8:11 AM, Paul Hoffman wrote:
>>>>>> - There will be good v2-to-v3 conversion tools for when an author
>>>>>> wants to change versions.
>>>>> So all of the existing corpus of xml2rfc files would have to be
>>>>> converted, and all of the existing base of user environments would
>>>>> have
>>>>> to be upgraded?
>>>>> Really?
>>>> If an RFC has an XML file, and if that RFC is going to go through a
>>>> -bis
>>>> process, then they could run through a converter tool to use v3
>>>> vocabulary.  But wholesale updates to everything, given they aren't
>>>> canonical files and generally don't include the final updates made
>>>> immediately prior to publication?  Why would we do that?
>>>> ...
>>> For instance, because, at some point, we may want to publish even older
>>> XMLs in the new format.
>>> Reminder: whether the XML source that we have on archive is an accurate
>>> representation of the published RFC can be determined programatically
>>> (by rerunning xml2rfc, and diffing with the published plain text).
>> Remember - there will probably be many more xml formatted for v1 than v2.
> Right now we have a collection of > 1000 RFCs that have been edited in
> XML at some point during AUTH48.
>> Are you planning a v1 to v3 translator?
> No, I'm trying to define v3 so that it is a superset of v1.
>> If you want to use this to republish existing RFCs then the v3
>> processor, applied to the converted XML, had better be bug compatible
>> with a v1 xml2rfc, and produce output that is consistent down to every
>> space and line break.
> Hm, no. Whitespace and line breaks (except when in artwork) are things
> the new canonical format doesn't prescribe (because these are pagination
> artefacts).

I didn't expect that you would or could. But not doing so puts 
constraints on when/how it makes sense to migrate to the new versions.

For instance, for one document that is still in draft state, I upgraded 
the xml so that it would work with the v2 tool. But when I generated my 
new version with the new tool, and did a diff to the prior version, it 
showed many more differences than just the intended ones, due to 
formatting differences. That was distracting, so I chose to keep using 
the old tool for the time being.

Probably at some point I will issue a new version, where the *only* 
changes are the version number, date, and use of the new tool. It will 
show numerous changes from the prior version, but those will all be 
superficial and won't confuse anyone.

There could be similar issues if one wanted to publish an old RFC in a 
different format. Because it is a different format, one won't expect it 
to be identical to the old txt version. But one would not want to 
*replace* the xml with upgraded xml that is only used for new formats. 
Perhaps both xml versions could be stored, but I doubt we have a way to 
do that.


>> The compatibility requirements are less severe if only used to work on
>> the "next" version of the document.
> v1 is a subset of v2. So, by definition, what processes v2 will process
> v1, assuming the v1 input isn't broken in the first place.
> Best regards, Julian

More information about the rfc-interest mailing list