[rfc-i] EOL in draft-flanagan-plaintext-04

Joe Hildebrand (jhildebr) jhildebr at cisco.com
Tue Oct 28 12:08:28 PDT 2014

+1.  Pick a line ending and stick to it.  To start painting the bike shed, 
I like simple "\n"s.

Modern transports such as HTTP will transmit the file with a length and 
encoding information.  FTP can be used in a similar manner if set to 
"binary".  Telnet isn't really about transferring files, without escapes 
to [xyz]modem land.  SMTP can deal with base64-encoded binary just fine.  
My point here: the protocol used to transmit the file has almost nothing 
to do with the format we pick.  If you use a protocol that mangles the 
file in transit, or configure a protocol to do so, then you shouldn't be 
surprised if the signature doesn't match.

On 10/28/14, 6:44 PM, "Robert Sparks" <rjsparks at nostrum.com> wrote:

>Section 4.3 of -04 spends a couple of paragraphs talking about having 
>different EOL markers on different OSes, and what some transports might 
>want to see. I think this is confusing what the RFC Editor will produce 
>and publish with what people might find lying around after it's been 
>moved off the RFC Editor's website.
>I think this document should specify exactly what the plaintext 
>publication format will contain (and what will be signable).
>I _don't_ think the plan is to publish versions with the various line 
>ending styles. Unless that's wrong, please pick one and say what it is.
>It's ok to warn people that their own tools might change the line 
>endings for them, but don't make it look like the variants are part of 
>what's published.
>rfc-interest mailing list
>rfc-interest at rfc-editor.org

Joe Hildebrand

More information about the rfc-interest mailing list