HTTP Random Access and Live Content
draft-ietf-httpbis-rand-access-live-04

Received changes through RFC Editor sync (created alias RFC 8673, changed abstract to 'To accommodate byte-range requests for content that has data appended over time, this document defines semantics that allow an HTTP client and a server to perform byte-range GET and HEAD requests that start at an arbitrary byte offset within the representation and end at an indeterminate offset.', changed pages to 10, changed standardization level to Experimental, changed state to RFC, added RFC published event at 2019-11-27, changed IESG state to RFC Published)

[Ballot discuss]
This document is still in IETF last call until tomorrow. So it seems just slightly premature for us to approve it with the consensus bit set to Yes. I looked around but did not see any email indicating why this popped up on a telechat before the LC ended.

[Ballot comment]
I echo Adam's comments, but I have some of my own this time:

What is the nature of the experiment? It would be nice to have some sort of statement of why this is experimental, even if that just means we need to get implementation experience.

The security considerations don't seem security specific. That is, they talk about what can go wrong, but do not describe the consequences from a security perspective. I suggest either describing those consequences, or perhaps moving the content to an "implementation" or "interop" considerations section.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-httpbis-rand-access-live-03, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Amanda Baber
Lead IANA Services Specialist

[Ballot comment]
Thanks for the well-written document!

In line with Adam and Ekr's comments, it is perhaps plausible to RECOMMEND a
concrete Very Large Value (of 2**53-1 or such) while discussing the cases in which
other values would be needed.  I agree with Ekr that discussing what happens if
you guess wrong and use a too-small value is important, but it also seems that
understanding how likely that is to happen can be considered part of the Experiment.

[Ballot comment]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3189


I can't tell whether this document is intended to have normative
content or not. I note that you cite RFC 2119 not RFC 8174, and have
some lower-case should-type language....

COMMENTS
S 5.
>      seek request or content-range response.  Also, some implementations
>      (e.g.  JavaScript-based clients and servers) are not able to
>      represent all values beyond 2^^53.  So similarly, if there's no
>      expectation that a representation will ever exceed 2^^53 bytes,
>      values smaller than this limit should be used for the last-byte-pos
>      in byte-range requests.

What happens if you are wrong about this?

[Ballot comment]

Thanks to everyone who worked on this document. I have two rather small
comments.

---------------------------------------------------------------------------

I am quite uncomfortable with the nebulous definition of the term "Very Large
Value" in this document. Given that "Very Large Values" are intended to serve as
a negotiation mechanism, I would strongly suggest that a more formal definition
of that term be added to this document (e.g., a client should send "a value of
at least 2^^39 or twice the value of the end of the randomly accessible byte
range, whichever is larger")

---------------------------------------------------------------------------

§1.1:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in RFC 2119 [RFC2119].

This document does not use these words in capitalized form. Especially in light
of RFC 8174, this is likely to cause confusion. If the intention is to assign
RFC 2119 definitions to the non-uppercased "must", "should", and "may" usage
in this document, please capitalize those terms and update the boilerplate to
that in RFC 8174. Otherwise, please remove this section.

The following Last Call announcement was sent out (ends 2018-10-12):

From: The IESG
To: IETF-Announce
CC: httpbis-chairs@ietf.org, draft-ietf-httpbis-rand-access-live@ietf.org, mcmanus@ducksong.com, ietf-http-wg@w3.org, alexey.melnikov@isode.com, Patrick McManus
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (HTTP Random Access and Live Content) to Experimental RFC


The IESG has received a request from the Hypertext Transfer Protocol WG
(httpbis) to consider the following document: - 'HTTP Random Access and Live
Content'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-10-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

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 file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-rand-access-live/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-rand-access-live/ballot/


No IPR declarations have been submitted directly on this I-D.

Expected status: Experimental

Technical Summary

Traditional HTTP range semantics allow the request of ranges with
fixed starting points but undefined ending points. However, responses
must not be open ended in this way - they can indicate that the full
representation is open ended but the range response itself must be
finitely defined. The draft discusses this in section 2.2

This document defines a backwards compatible mechanism for streaming
open ended response ranges (i.e. ranges that start at a fixed point
but are appended to and transferred after the response headers have
been generated).

It is applicable to all versions of HTTP.

Working Group Summary

There was consistent, but low level, interest from the working group
in this document. It was discussed in several dozen email messages and
at least 3 times in face to face sessions with concrete discussion
each time. The initial mechanism was agreed to quickly and much of the
discussion focused around use cases, examples, and whether or not
Experimental is the right status for the document.

There is no controversy around this document within the working group.

Document Quality

Participation in the document's review and development was
acceptable: involving about 10 individuals representing browsers,
servers, and intermediaries. The Working Group Last Call reassured the
chairs that there was sufficient broad based interest to move the
document forward.

There is at least one implementation of this on a large content
provider currently deployed.

Personnel

Patrick McManus is the document shepherd; Alexey Melnikov is the
responsible Area Director.