[rfc-i] Line ending conventions in drafts and RFCs
"Martin J. Dürst"
duerst at it.aoyama.ac.jp
Mon Oct 15 00:57:47 PDT 2012
On 2012/10/15 15:53, Brian E Carpenter wrote:
> On 15/10/2012 02:42, Martin J. Dürst wrote:
>> Probably this question has come up before:
>> What's the line ending convention for drafts and RFCs, if there's any?
>> The IETF convention, in particular for mail, is CRLF. On the other hand,
>> and RFC I just checked (http://www.rfc-editor.org/rfc/rfc3987.txt) was
>> just LF.
> http://www.rfc-editor.org/rfc-editor/instructions2authors.txt says
> Note: A plain-text RFC is expected to be stored on a
> disk file using the EOL sequence of that system. For
> example, MS DOS-based systems use the two-character
> sequence: CR LF (Carriage Return followed by Line Feed),
> Unix systems use the single character LF for EOL, and
> EBCDIC systems use the single character NL (New Line).
> Whenever an RFC is transmitted across the Internet,
> Internet protocol convention requires that each line of
> text be followed by the two-character EOL sequence CR LF
> (Carriage Return followed by Line Feed). A user level
> protocol (e.g., FTP, Telnet, HTTP, SMTP, ...) must make
> the appropriate EOL transformation at each line end.
> Note that binary transmission of plain-text RFC files
> can cause the sender's EOL convention to "leak" into the
> receiver, causing confusion.
That's all well and good, except for the fact that HTTP never lived up
to that promise (or to be more specific, never even gave that promise),
neither at the senders' nor at the receivers' end.
If the paragraph above is supposed to apply, then at least the RFC
Editor itself should try to live up to it, by either getting a 'better'
HTTP server or by making sure that the files that are served over HTTP
contain CRLF on their end, even if otherwise, they use Unix.
Otherwise, the text should be rewritten to match more closely with
reality (and IETF specs such as RFC 2616).
More information about the rfc-interest