- From: David Krauss <potswa@gmail.com>
- Date: Sun, 20 Apr 2014 10:23:27 +0800
- To: Roberto Peon <grmocg@gmail.com>
- Cc: Adrian Cole <adrian.f.cole@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
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