[rfc-i] Deprecated pieces and PIs [was: Re: Input Syntax vs Canonical Form/rfcedstyle vs Output Formats]

Dave Crocker dhc at dcrocker.net
Fri May 2 09:29:09 PDT 2014


On 5/2/2014 11:08 AM, Elwyn Davies wrote:
>> > pps.  The long list of deprecated features is distressing.  Given the
>> > earlier discussions, it never occurred to me that there would be so
>> > little concern for staying compatible with the installed base.  But
>> > then, the IETF seems to have largely lost its appreciation for the role
>> > of operational stability...
>> > 
> As I understand the specification, the pieces that are labeled as
> 'deprecated' MUST be implemented in v3 processors and the syntax and
> semantics will be as defined in the v2 specification.  Consequently
> existing v1 and v2 documents ought to be able to be processed by a v3
> processor (see para 6 of s1.1).  This seems to have an adequate eye to
> operational stability; unfortunately I think the eye was slightly
> blinkered...


So I had missed:

   1.1.  Design Criteria for the Changes in v3

   "The canonical RFCs will not have any markup that uses a deprecated
   feature.  The processor described in Appendix B will have a "convert
   with warnings" mode that will convert a v2 document to a v3 document
   that converts deprecated features wherever possible, issuing warnings
   for where it cannot convert.  The processor will also have a "strict"
   mode that will issue errors if any deprecated features are in the
   input."

The concept of deprecate, here, is a bit challenging.  I don't think the
model here is bad or wrong, but it's also not overly clean.

Given the 1.1 text, I think I suggest moving all 'deprecated' stuff into
its own section, but in the main document, not just an Appendix.
Perhaps immediately after "2. Elements" have "3. Deprecated Elements"
with some sort of introduction as a variant of what's in 1.1.

Perhaps:


     The Elements described in this section remain legal for use in
xml2rfc documents, but will be converted by the RFC Editor into
alternative elements.



Then for each element, don't merely say "Deprecated" but also include
the explanation of what element(s) work as the alternative.  This make
use of deprecated constructs easier in an author process of referring to
this document.  Having a the deprecated elements in the main set but
only saying Deprecated means that the author has to bounce around (to
section 1.2.3, I guess) to figure out what they are supposed to use to
get rid of warnings.


d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


More information about the rfc-interest mailing list