[rfc-i] On backwards compatibility for v2

Julian Reschke julian.reschke at gmx.de
Tue Feb 11 00:01:10 PST 2014


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

> 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