Re: Working Group Last Call for HTTP Random Access and Live Content

I wonder whether what is being proposed to be handled by this is a 
philosophical change for what is meant by a representation.

I guess in the end, my only concerns are that

1. We don't create unsolvable problems for proxies, or require them to 
change behaviour around byte-ranges (e.g. when it comes to caching or 
framing etc.).
2. We have a clear picture of what we are even doing here.  It seems 
like over-loading byte ranges is a hack (large value????).  There should 
be no room for hacks in http.
3. It's not clear to me why byte ranges are needed to be used for this 
at all.

In the case of the appended content, I'm not convinced the argument in 
the introduction isn't a straw man.  2 options are given

1. Read the whole thing from the beginning.
2. multiple byte-range requests.  A latency problem is identified.

what about a 3rd option

3. Ask the server to send you from a certain timestamp, or "now" not 
using byte ranges, but with some other specific attribute of the request 
that is deterministic.  Does it even need to be a new header, or could 
it just be a part of a querystring?  Definitely never use Range in any 
other dimension than bytes.

So I guess I'm overall not convinced there's a need to alter range 
request handling.  The whole spec seems to be built on an assumption 
that Range requests are needed to solve this problem.  I would question 
that.  Given that Range, C-L etc are framing headers, and breaking 
framing is something that should not even be considered, due to all the 
intermediaries out there that will make this problematic.


------ Original Message ------
From: "Mark Nottingham" <>
To: "HTTP Working Group" <>
Cc: "Patrick McManus" <>
Sent: 9/02/2018 3:38:24 PM
Subject: Re: Working Group Last Call for HTTP Random Access and Live 

>Hi Folks,
>We didn't receive any feedback during the WGLC period, which is causing 
>your chairs a bit of concern.
>If you have read this document and believe it should progress as 
>Experimental, please say so on-list (or privately to us, if necessary).
>>On 22 Nov 2017, at 6:21 pm, Mark Nottingham <> wrote:
>>We discussed this document at the Singapore meeting, where we agreed 
>>that it's ready to progress. There are no outstanding design issues on 
>>Please have a look at:
>>and bring up any issues either on the mailing list or in the issues 
>>list. Statements of support to the list would also be helpful.
>>As discussed, we'd like to have a longer-than-typical WGLC for this 
>>document, to allow some experimentation to take place, account for the 
>>holiday period, and to assure that there aren't bad interactions with 
>>deployed code.  So, WGLC will end on 2018-01-20.
>Mark Nottingham

Received on Friday, 16 February 2018 20:44:42 UTC