- From: Anne van Kesteren <annevk@opera.com>
- Date: Tue, 22 Sep 2009 13:25:15 +0200
- To: "Per-Erik Brodin" <per-erik.brodin@ericsson.com>
- Cc: "Michael A. Puls II" <shadow2531@gmail.com>, public-webapps@w3.org
On Tue, 22 Sep 2009 11:05:26 +0200, Per-Erik Brodin <per-erik.brodin@ericsson.com> wrote: > Anne van Kesteren wrote: >> On Mon, 21 Sep 2009 17:39:14 +0200, Per-Erik Brodin wrote: >>> So what you are saying is that "\r\n" will always be a Windows line >>> ending and never a Mac line ending followed by a Unix line ending? >> That's what should happen as that would be consistent with other text >> formats, e.g. text/html. I guess this should be stated below the ABNF >> or the ABNF should be rewritten to a more parser/state-like thingy. > > I'm envisioning a scenario where event stream data is aggregated from > various sources, and done so improperly so that multiple different line > endings end up in the stream. For example, appending a carriage return > to a string that is already ending with carriage return produces a > different result than appending a line feed to the same string. Since > it's a new format being defined, why not make it clean and simple? > > Consider the following example: > print "data: hello\r"; > print "data: world\r"; > print "\n"; # dispatch! I'm not very opposed, but given that this is a text/* media type and that this is how most text/* media types work (in practice, per some old specification only CRLF is a new line) it makes sense to me to keep it that way. We could strongly encourage authors to just use \n for the reasons you mention or indeed deviate from the standard format. -- Anne van Kesteren http://annevankesteren.nl/
Received on Tuesday, 22 September 2009 11:40:25 UTC