W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: END_SEGMENT and END_STREAM redundant

From: David Krauss <potswa@gmail.com>
Date: Sun, 20 Apr 2014 10:23:27 +0800
Cc: Adrian Cole <adrian.f.cole@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <06DA6EF1-1977-4712-A755-FBFD25BB05CC@gmail.com>
To: Roberto Peon <grmocg@gmail.com>

On 2014Ė04Ė20, at 9:14 AM, Roberto Peon <grmocg@gmail.com> wrote:

> The implementation and API on top of that allows or disallows the expression of such things to the application.
> It is the duty of the protocol to make it possible to express these things, not to mandate how it is used,

Itís probably just an editorial issue, but the spec wording currently doesnít clarify the intent or motivating semantics of segmentation, as shown by K Morganís recent thread.

If there were a nice diagram of a segment-message or some BNF like you wrote in your earlier reply to me, then applications might be more likely to assign bits to their intended meanings and less likely to put excessive demands on the API.

> unless it is necessary for interop.
> 
> The spec defines the minimum for interop: each bit has its own meaning. Interpretation is up to the application.

Thereís some circular reasoning here. Interoperability refers to what intermediaries may change, or to a lesser extent what synonymous bit-codings portable APIs (e.g. Javascript XHR) may merge. If an underlying representation may be changed according to the semantics it expresses, then relying on bits is not interoperable.

A different programmer sensibility is often applied to binary coding than to text, but itís best to use the same approach either way. A format defines the expression of a variety of messages, and those messages comprise the only defined meaning.
Received on Sunday, 20 April 2014 02:24:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC