[rfc-i] Why? (was Re: For v3: draft-hoffman-xml2rfc-02.txt)

Paul Hoffman paul.hoffman at vpnc.org
Sat Feb 15 08:03:04 PST 2014


On Feb 14, 2014, at 11:46 PM, Julian Reschke <julian.reschke at gmx.de> wrote:

> On 2014-02-15 00:41, Dave Crocker wrote:
>> On 2/14/2014 3:36 PM, Paul Hoffman wrote:
>>> Greetings again. I made a handful of more changes to the proposed v3
>>> spec.
>>> 
>>> To discuss the new proposed features, please be sure to start a new
>>> thread Thanks!
>> 
>> 
>> I suggest that the portion of the document that cites what is changed
>> also explain why it is deemed worthy.  Why make the change?
>> 
>> The goal is to facilitate review of the underlying rationale, not just
>> the technical details.
>> 
>> Changes have costs.  Let's explain they they are being incurred.

The "cost" of a change from v2 to v3 is almost always incurred in the conversion tool. If you don't want to convert from v2 to v3, don't.

However, in the case Julian brings up, the change does indeed requires change in user behavior when <vspace> is used outside of a list.

> In particular, when changes have not been discussed at all. For instance:
> 
>>   o  Removed the <vspace> element because it is no longer needed for
>>      lists.
> 
> It may be true that it's not needed in lists anymore (hopefully), but it was allowed and used in other places before.

I was going by the text in the latest version of the v2 document:

   Note that this is a purely presentational element and thus its use
   ought to be avoided.

If it "ought to be avoided", maybe it ought not to be allowed. Allowing something that ought to be avoided forces the RFC Editor to manually make changes during the editing process. This costs money and time. Leaving in such a "feature" is in no one's best interest.

> I agree with the goal to address all cases where people currently fall back to <vspace>, but (a) we're not there yet,

How can we know when we're there yet? We have no way of polling every Internet Draft author of their use of <vspace>. For the v3 definition process, putting in steps that have no measurable ending does not seem productive.

> and (b) it doesn't necessarily mean that the element needs to be removed.

Correct. We can in fact leave in features that will force the RFC Editor to make hand corrections (as compared to automated converter corrections) during the edit phase of production. I claim that is not a good idea, but would like to hear from others why this might be a good way forward.

--Paul Hoffman


More information about the rfc-interest mailing list