Subject: RFC 4288

From: Alfred Hönes <[email-masked]>
Date: Sun, 18 Dec 2005 23:44:30 +0100 (MEZ)

Hello,
I just read the recently published RFC 4288 == BCP 13.1
(and RFC 4289 == BCP 13.2 as well, of cause) authored by you
and would like to submit a few comments.

(1)

First of all, I welcome the clarifications and the separation
of RFC 2048 into two distinct memos.

Nevertheless, the official naming of both RFCs as BCP 13 is
perhaps a bit unfortunate, and -- being the first appearance of
such a "double BCP" -- it obviously overcharges the existing
capabilities of certain RFC Editor tools, e.g. to produce
"rfcxx00.txt".  Future development and management of IETF
publications would certainly be made easier if such numeration
practice would have been avoided.

[Begin of Note]:

I personally have introduced a 'dot' notation like the one used
above for better references to 'multivalued' STDs many years ago,
e.g., I refer to RFC 3414 as "STD62.4" in our internal "meta-RFC"
data base.  This notation might be convenient for reference to
IETF STD RFCs in general. It would allow similarly named symbolic
links from the "in-notes/std/" subdirectory to the proper RFCs
without pasting these RFCs together into huge aggregate "stdxx.txt"
documents, and thus alleviate the change management in case of an
update to one ore more STD 'component(s)' (as it has happend, e.g.,
to STD 10) without a need to modify "never changing documents".
And its use would avoid silly and unlogical wording, e.g., such as
in the current "MIB Boilerplate" text,

  "... STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579],
   and STD 58, RFC 2580 [RFC2580] ..."

that linguistically correct (but apparently not accepted) should
better read:

  "... STD 58: RFC 2578 [RFC2578], RFC 2579 [RFC2579], and
   RFC 2580 [RFC2580] ..." ,

turning the original phrase into a logically consistent form:

  "... STD 58.1, RFC 2578 [RFC2578], STD 58.2, RFC 2579 [RFC2579],
   and STD 58.3, RFC 2580 [RFC2580] ..."

[End of Note]

(2)

I miss a discussion of the "model" primary media type (originating
from RFC 2077 -- which is on the Standards Track as well) in Section
4.2. of RFC 4288.
Perhaps, an up-to-date "statement of direction from the gurus"
would have been appropriate to give guidance and marking off the
"model" and "application" primary media types.

(3)

Finally, two small editorial issues:

- Perhaps as an artifact of the conversion of text from an existing
  RFC to a revised memo in I-D format and finally back to RFC format,
  along with repeated re-pagination, it can be observed from time to
  time that there appear unexpected blank lines in RFC text which
  visually break sentences aparts.  This recurring arifact has hit
  RFC 4288 near the top of its pages #8 and #10.

  [
    Future revisions of RFC-Ed tools might be able to recognize
    potential occurrances of this artifact, e.g. by applying the
    following (proposed) criteria:
    - an end-of-line in text without a trailing period,
    - followed by one [or more] blank line[s],
    - followed by another text line of the same indentation level
      as before, starting with a lowercase initial character;
    'telegram style' enumerations -- without complete sentences and
    without punctuation marks -- might be recognizable exceptions.
  ]

- On page 8, apparently a significant word has been lost;
  Section 4.2.2 says:
                                                                v
    A Media type of "image" indicates that the content specifies or more
    separate images that require appropriate hardware to display. ...

  It obviously should say:
                                                                vvvvv
    A Media type of "image" indicates that the content specifies one or
    more separate images that require appropriate hardware to display.
    ...

  This issue might be considered for submission as an Errata Note.
  Please comment/decide.

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Ned Freed <[email-masked]>
Date: Sun, 18 Dec 2005 18:06:37 -0800 (PST)

> of RFC 2048 into two distinct memos.

Frankly, I do not. In retrospect and considering recent events the split
appears to have been a collosal waste of my and everyone else's time. What's
done is done, of course, but if I had it to do over I would not have agreed to
it or done it.

This is the second time I've been burned - this time pretty badly - by agreeing
to a document split. (The first one was MIME itself.) You may rest assured it
will not happen again with any document I edit.

> practice would have been avoided.

The assignment of BCP, STD, and FYI numbers is an RFC Editor task; it is not
something authors have any control over. That said, the existing example of STD
numbers being able to refer to multiple documents argues strongly IMO for what
was done here, for consistency if nothing else.

> [End of Note]

Well, all I can say is that appears to me to be a solution in search of a
problem. The ability of the meta-sequence numbers to refer to multiple
documents hasn't been a source of confusion or other issues in my experience.

This is not to say the currrent procedures doesn't have problems that need to
be solved. IMO they do - but this just isn't one of them.

A real problem is the state of affairs that arises when a proposed standard
obsoletes a full standard. As a specific example, RFC 822 being declared
obsolete by the publication of RFC 2822 is a source of significant ongoing
confusion in the community. (And no, I don't have any suggestion as to how to
solve this one, but perhaps some sort of numbering convetion would make sense
in this case.)

> "model" and "application" primary media types.

I considered adding additional information about model to this revision but
ultimately rejected it in the interests of time. As it was the publication of
these revised procedures took far too long. Adding model to the mix would
almost certainly reopened additional old debates and stretched out the process
even longer.

I hope this can be dealt with in a subsequent revision because I agree it would
be best to have model in there.

>   visually break sentences aparts.

Simply put, it isn't, because that's not what happened. RFC 2048 was formatted
using nroff. The nroff sources where hand-converted to xml2rfc format by me.
The RFC Editor had both the XML source and of course the Internet Draft to work
with.

As an aside, as part of the author 48 process I took the opportunity to update
the xml2rfc source to match the published RFC.

  This recurring arifact has hit
>   RFC 4288 near the top of its pages #8 and #10.

I assume you're referring to the break between "linear" and "sequence". I agree
it should not have been there. However, it appears that it was introduced as
part of whatever process the RFC Editor uses. The XML source file for this
reads as follows:

<t>
Plain text does not
provide for or allow formatting commands, font attribute specifications,
processing instructions, interpretation directives, or content markup.  Plain
text is seen simply as a linear sequence of characters, possibly interrupted by
line breaks or page breaks.  Plain text MAY allow the stacking of several
characters in the same position in the text.  Plain text in scripts like Arabic
and Hebrew may also include facilities that allow the arbitrary mixing of text
segments with opposite writing directions.
</t>

I further note that this break corresponds to a page break in the I-D.

The poor break on page 10 appears to have a similar genesis. And both of
these went unnoticed because the differences tool used to compare the final
RFC with the Internet Draft cannot tell the difference between a page break
in the middle of a paragraph in the I-D and a paragraph break in the RFC.

>     without punctuation marks -- might be recognizable exceptions.

IMO a better way to correct this as well as numerous other problems would be
for the RFC Editor to make better use of the XML source and xml2rfc. The fact
that these errors crept in makes me think that the XML sources were not used,
and that the nroff was generated from the I-D text. Unless there's something
deeply broken in xml2rfc's nroff output, the nroff should not have contained an
explicit page break in either of these cases.

Better use of XML source and xml2rfc would also make it far easier for authors
to resync their XML sources to the published RFC. The amount of time it takes
to do this manually is considerable.

But again, this is something only the RFC Editor can fix - authors clearly
cannot specify the tools the RFC Editor uses.

>   This issue might be considered for submission as an Errata Note.

Yep, that's a typo. I've corrected it in my XML source and IMO an errata note
would be appropriate.

				Ned