Re: 14.36

    My objections are not strong enough to want to raise a big fuss over
    this--I think the current design risks semantic transparency in a
    small number of cases to reduce round trips in an equally small number
    of cases--but I would be interested in hearing any further arguments
    which the editorial group might have heard in favor of this language.

I'm not sure I understand your point about "risk[ing] semantic
transparency".  If the Range request is conditional, then the
entity-tags (or last-modified-dates) must match; that is what
preserves semantic transparency.

If you can come up with a specific concrete scenario where something
goes undetectably wrong, then I would be open to reconsidering this.

The utility of allowing what the current draft allows is that,
for example, a client with a restricted memory and/or network
bandwidth (think: wireless PDA) could do a request such as this:

	GET /foo.html HTTP/1.1
	Range: 0-10000

and be assured of not getting more than 10,000 bytes.  This is
far more efficient than having the client try to abort the
response because it cannot take any more data.  And I believe
that the specification is well-defined, in the sense that the
client can tell from the response headers exactly what it has
received.

-Jeff

Received on Friday, 31 May 1996 15:02:57 UTC