[rfc-i] On backwards compatibility for v2
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
>>>>> to be upgraded?
>>>> If an RFC has an XML file, and if that RFC is going to go through a
>>>> 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
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
>> 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