[rfc-i] EOL in draft-flanagan-plaintext-04
Brian E Carpenter
brian.e.carpenter at gmail.com
Tue Oct 28 12:44:37 PDT 2014
Well, since it was me who asked for the old EOL text to be kept,
I would like to know why you think the inconsistent EOL problem has gone
away. As far as I know, it's still alive and kicking when files are copied
between any Unix-like system and Windows, and can be seen trivially by
any user of NotePad on Windows when the file has LF alone to signal a
Maybe the old text goes too far, but I think the problem does need to
be flagged somehow.
On 29/10/2014 08:08, Joe Hildebrand (jhildebr) wrote:
> +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
More information about the rfc-interest