Re: I-D Action: draft-ietf-httpbis-rand-access-live-03.txt

[Craig Pratt <[e-mail]>]

Thanks Thomas for the suggestion/questions.

My thoughts in-line...

cp

On 3/20/18 7:12 AM, Thomas Peterson wrote:

A question I have with this draft is the behaviour or expectations that may or
may not occur during failure modes, particularly when a "reset" or roll-over
happens on the server side. Consider the scenario when the server byte-offset is
effective reset, and thus it's "range" has shifted beyond the client's
expectations.

When a server encounters an error acquiring the live content it's incorporating into the representation (e.g. a discontinuity) there are a couple options that come to mind: (1) stop appending the content into the representation (and optionally start a new one), or (2) append the content in a content-type-specific way that the client can digest/comprehend.

Either way, the client wouldn't receive a non-success HTTP status code when transferring content on each side of the discontinuity. In the case of (1), the content would just no longer grow (effectively becoming a static representation). For (2) the only effect would be a momentary decrease in the transmitted bitrate during the period of discontinuity. (you could see this effect periodically in the results I presented at IETF 100) To the client, it looks like one contiguous sequence of data.

So at this point, you might be thinking "this explanation on discontinuities is what should be in the draft RFC". I don think it would be great if there was more guidance on live content. The issue there is that (a) dealing with discontinuities is fairly format-specific, (b) the guidance applies to non-random access cases equally, and (c) I'm not sure it has to do with with the "transfer" aspect of HTTP - since my argument above is that the server-side failure modes really affect the *constitution/construction* of the representation and not the *transfer* of it. (as I still consider myself a newb in the httpbis group, maybe someone can clarify my understanding)

If only (a) and (b) apply, there might be a case to be made for a format-agnostic "Live Content and Errors/Discontinuities" draft RFC. But my thinking has been that it's a bit too far out of scope for this draft.

I don't see any reference in this draft that explicitly call out when 416
responses should be sent. Should these things be called out?

Regards

I think this statement from RFC-7233 (section 4.4) describes the 416 cases pretty well:

The 416 (Range Not Satisfiable) status code indicates that none of
the ranges in the request’s Range header field (Section 3.1) overlap
the current extent of the selected resource

Unfortunately, section 4.4 trips over itself a bit when it tries to talk about byte-range-specific simplifications. But I don't think it's appropriate to clarify this in our draft. (Perhaps this can be cleaned up as part of HTTPter?)

And while it might be useful to provide examples in the draft, I've tried to provide examples of ways to interact with a live/aggregating server that should *avoid* 416 errors (and get 206 instead). But the cool thing about the way that 7233 is written is that a client can really respond to a 206 and 416 similarly - since they both include a Content-Range response header.

Anyway, hope this helps. And please let me know if I'm missing something (like the point of your question)...

On Tue, Mar 20, 2018 at 05:19:38AM -0700, [e-mail] wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Hypertext Transfer Protocol WG of the IETF.

        Title           : HTTP Random Access and Live Content
        Authors         : Craig Pratt
                          Darshak Thakore
                          Barbara Stark
	Filename        : draft-ietf-httpbis-rand-access-live-03.txt
	Pages           : 11
	Date            : 2018-03-20

Abstract:
   To accommodate byte range requests for content that has data appended
   over time, this document defines semantics that allow a HTTP client
   and server to perform byte-range GET and HEAD requests that start at
   an arbitrary byte offset within the representation and ends at an
   indeterminate offset.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-rand-access-live/" rel="nofollow">https://datatracker.ietf.org/doc/draft-ietf-httpbis-rand-access-live/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-httpbis-rand-access-live-03" rel="nofollow">https://tools.ietf.org/html/draft-ietf-httpbis-rand-access-live-03
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rand-access-live-03" rel="nofollow">https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rand-access-live-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-rand-access-live-03" rel="nofollow">https://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-rand-access-live-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/" rel="nofollow">ftp://ftp.ietf.org/internet-drafts/

--

craig pratt caspia consulting [e-mail] 503.706.2933