Re: WGLC issue: ambiguity in part 1 example

On Feb 26, 2013, at 7:20 PM, Amos Jeffries wrote:

> On 27/02/2013 12:27 p.m., Roy T. Fielding wrote:
>> On Feb 16, 2013, at 5:27 PM, Amos Jeffries wrote:
>> 
>>> Part 1 section 2.1 example server response contains an entity body and a Content-Length header.
>>> 
>>> The Content-Length header is 2 bytes larger than the visible/printable bytes in the entity and it is not made clear that there are invisible trailer bytes being included in the in the displayed entity size.
>>> 
>>> I think at this early stage of the texts it would be best to keep things simple and only have the Content-Length equal to the visible bytes - "Hello world!" being 12 bytes long.
>> Note that the extra two bytes (for CR LF) is intentional and produced
>> automatically by the xslt example body processor.  I believe it is
>> useful to show the real protocol and let the reader figure out why
>> all the bytes aren't visible.
>> 
>> ....Roy
> 
> That is exactly the wrong thing to do at this point in the spec IMHO. This is the readers first exposure to the protocol - with dozens of pages ahead. They are not going to be bothered stopping to figure out something that fundamental. Probably they write their own sender/receiver to test with both "working perfectly" despite assumption flaws .

No, assuming that all bytes are visible is naive.  I simply don't
care to support the notion that a protocol developer who is concerned
enough to actually count out the printed bytes in the example won't be
able to figure out that not all bytes are visible, because it isn't
a scenario based on reality (as you demonstrated yourself).
A text/plain document is supposed to always end in a CRLF in
order to be interoperable across multiple operating systems,
which is why the example does so.

I have zero interest whatsoever in supporting developers who
implement according to one and only one example, without reading
the many sections in the same document on how to parse.  That
is not the audience of an IETF spec.

And now I have to go fix the two grammatical errors added in

  (Note that the content length includes the trailing CR/LF
   sequence of the body text)

just because of an unnecessary last-minute addition.

....Roy

Received on Wednesday, 27 February 2013 08:11:00 UTC