Re: Issue with "bytes" Range Unit and live streaming

["Adrien de Croy" <[e-mail]>]

unless we allow Content-Length to also use the new unit (which I'd be 
dead against), I'd suggest we steer clear of minting any new range 
units.

All the proposed use cases for new range units that I've seen are 
application specific, and could arguably better be dealt with using 
another header.

Adrien


------ Original Message ------
From: "Mark Nottingham" <[e-mail]>
To: "Darshak Thakore" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Sent: 12/05/2016 12:59:25 p.m.
Subject: Re: Issue with "bytes" Range Unit and live streaming

>Hi Darshak,
>
>I don't think that's where we're at. Based on the discussion so far, it 
>seems like there are two possible paths forward:
>
>1. Changing the 'bytes' range-unit to allow this use case
>2. Minting a new range-unit
>
>As discussed, both have downsides. What we need is data about how 
>current implementations -- especially caching intermediaries -- behave 
>when faced with a) 'bytes' used in the desired way, and b) a new 
>range-unit.
>
>Cheers,
>
>
>>  On 11 May 2016, at 5:57 AM, Darshak Thakore <[e-mail]> 
>>wrote:
>>
>>  Hi all,
>>
>>  Based on feedback on this thread, it seems like the need for being 
>>able to send an open ended (read as unknown-last-byte-pos) Range 
>>response has been discussed a couple of times (with different use 
>>cases). Also there seems to be somewhat general agreement that the 
>>Content-Range ABNF in RFC 7233 is deficient in providing this. The 
>>initial argument has been, “is there a compelling enough need” and i 
>>think with different use cases popping up (log files, media streaming, 
>>gzip… others ??) there seems to be some value in defining a 
>>non-application specific Range unit that plugs this gap. Clearly 
>>fixing RFC 7233 is invasive and will result in thing breaking in 
>>unknown ways so that’s a no-go. With that, we can:
>>   • Ensure that the scope of this work item is narrow and restricted 
>>only to fixing the gap in RFC 7233
>>   • Define a new range unit (anything with “bytes” in it seems like a 
>>bad idea, so maybe call it “live-octets”, “blive”, “b-add" - 
>>suggestions welcome….)
>>   • Decide if there is enough interest/reason to do this as a WG item
>>  Any objects/suggestions to any of the above ?
>>
>>  Regards,
>>  Darshak
>>
>>
>>  From: "[e-mail]" <[e-mail]>
>>  Date: Thursday, April 21, 2016 at 4:25 AM
>>  To: 'Craig Pratt' <[e-mail]>, "[e-mail]" 
>><[e-mail]>
>>  Cc: "[e-mail]" <[e-mail]>
>>  Subject: RE: Issue with "bytes" Range Unit and live streaming
>>  Resent-From: <[e-mail]>
>>  Resent-Date: Thursday, April 21, 2016 at 4:25 AM
>>
>>  On Thursday,21 April 2016 05:18 [e-mail] wrote:
>>  >
>>  > Re: Representation caching
>>  >
>>  > Whether a representation is considered cacheable in this use case 
>>is at
>>  > the discretion of the origin server and specific to the use
>>  > case/application - as it should be (imho). There's no *necessity* 
>>in
>>  > having a periodically-appended resource marked non-cachable, 
>>correct? If
>>  > the resource mutates, it's not cacheable. If it's just being 
>>appended
>>  > to, it is cacheable. And if an appended resource stops being 
>>appended
>>  > to, it doesn't invalidate the cached representation.
>>  >
>>
>>  I couldn't agree more. However, it seemed the prevailing sentiment 
>>when we tried to resolve the related issue of ranges before content 
>>codings, with a new bbcc unit (bytes-before-content-coding), was that 
>>the use cases for append-only growth represent an insignificant 
>>portion of HTTP traffic. “We live by app-specific protocols to handle 
>>these cases. What is so special ... that it must be addressed by http 
>>(in a very ugly way)?” [1]
>>
>>  [1] 
>>https://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/1383.html
>>
>>
>>
>>  This email message is intended only for the use of the named 
>>recipient. Information contained in this email message and its 
>>attachments may be privileged, confidential and protected from 
>>disclosure. If you are not the intended recipient, please do not read, 
>>copy, use or disclose this communication to others. Also please notify 
>>the sender by replying to this message and then delete it from your 
>>system.
>
>--
>Mark Nottingham   https://www.mnot.net/
>
>