Skip to main content

HTTP Random Access and Live Content
RFC 8673

Revision differences

Document history

Date Rev. By Action
2019-11-27
04 (System)
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 …
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)
2019-11-27
04 (System) RFC published
2019-11-23
04 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2019-10-28
04 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2019-09-26
04 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2019-08-26
04 Gunter Van de Velde Assignment of request for Telechat review by OPSDIR to Carlos Martínez was marked no-response
2019-08-26
04 (System) RFC Editor state changed to EDIT
2019-08-26
04 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2019-08-26
04 (System) Announcement was received by RFC Editor
2019-08-26
04 (System) IANA Action state changed to No IANA Actions from In Progress
2019-08-26
04 (System) IANA Action state changed to In Progress
2019-08-26
04 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2019-08-26
04 Amy Vezza IESG has approved the document
2019-08-26
04 Amy Vezza Closed "Approve" ballot
2019-08-26
04 Amy Vezza Ballot approval text was generated
2019-08-23
04 Alexey Melnikov IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed
2019-03-07
04 Craig Pratt New version available: draft-ietf-httpbis-rand-access-live-04.txt
2019-03-07
04 (System) Forced post of submission
2019-03-06
04 (System) Request for posting confirmation emailed to previous authors: Craig Pratt , Barbara Stark , Darshak Thakore
2019-03-06
04 Craig Pratt Uploaded new revision
2018-12-13
03 Tero Kivinen Closed request for Telechat review by SECDIR with state 'No Response'
2018-10-19
03 Amy Vezza IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation
2018-10-18
03 Alissa Cooper [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss
2018-10-12
03 Alexey Melnikov IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2018-10-12
03 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2018-10-11
03 Jean Mahoney Request for Telechat review by GENART Completed: Ready. Reviewer: Meral Shirazipour.
2018-10-11
03 Ignas Bagdonas [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas
2018-10-11
03 Alissa Cooper [Ballot comment]
Please address the Gen-ART review nits.
2018-10-11
03 Alissa Cooper Ballot comment text updated for Alissa Cooper
2018-10-11
03 Alissa Cooper
[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 …
[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.
2018-10-11
03 Alissa Cooper [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper
2018-10-10
03 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2018-10-10
03 Ben Campbell
[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 …
[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.
2018-10-10
03 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2018-10-10
03 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2018-10-10
03 Amanda Baber
(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 …
(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
2018-10-10
03 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2018-10-10
03 Benjamin Kaduk
[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 …
[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.
2018-10-10
03 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2018-10-10
03 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2018-10-10
03 Mirja Kühlewind [Ballot comment]
Inline with Ekr question it seems to me that the text in the security consideration section rather discusses what this experiement is about.
2018-10-10
03 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2018-10-10
03 Mirja Kühlewind [Ballot comment]
Inline with Ekr question it seems to me that the text in the security consideration section rather discussion what this experiement is about.
2018-10-10
03 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2018-10-09
03 Eric Rescorla
[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 …
[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?
2018-10-09
03 Eric Rescorla [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla
2018-10-09
03 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2018-10-08
03 Adam Roach
[Ballot comment]

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

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

I am quite uncomfortable with the nebulous definition …
[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.
2018-10-08
03 Adam Roach [Ballot Position Update] New position, Yes, has been recorded for Adam Roach
2018-10-04
03 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Carlos Martínez
2018-10-04
03 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Carlos Martínez
2018-10-04
03 Tero Kivinen Request for Telechat review by SECDIR is assigned to Matthew Miller
2018-10-04
03 Tero Kivinen Request for Telechat review by SECDIR is assigned to Matthew Miller
2018-10-03
03 Jean Mahoney Request for Telechat review by GENART is assigned to Meral Shirazipour
2018-10-03
03 Jean Mahoney Request for Telechat review by GENART is assigned to Meral Shirazipour
2018-09-28
03 Amy Vezza Placed on agenda for telechat - 2018-10-11
2018-09-28
03 Amy Vezza IANA Review state changed to IANA - Review Needed
2018-09-28
03 Amy Vezza
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 …
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.




2018-09-28
03 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2018-09-28
03 Alexey Melnikov Ballot has been issued
2018-09-28
03 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov
2018-09-28
03 Alexey Melnikov Created "Approve" ballot
2018-09-28
03 Alexey Melnikov Ballot writeup was changed
2018-09-28
03 Alexey Melnikov Last call was requested
2018-09-28
03 Alexey Melnikov Last call announcement was generated
2018-09-28
03 Alexey Melnikov Ballot approval text was generated
2018-09-28
03 Alexey Melnikov Ballot writeup was generated
2018-09-28
03 Alexey Melnikov IESG state changed to Last Call Requested from AD Evaluation
2018-09-28
03 Alexey Melnikov IESG state changed to AD Evaluation from Publication Requested
2018-09-14
03 Patrick McManus
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 …
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.
 
2018-09-14
03 Patrick McManus Responsible AD changed to Alexey Melnikov
2018-09-14
03 Patrick McManus IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2018-09-14
03 Patrick McManus IESG state changed to Publication Requested
2018-09-14
03 Patrick McManus IESG process started in state Publication Requested
2018-09-14
03 Patrick McManus Changed document writeup
2018-09-14
03 Patrick McManus Changed document writeup
2018-09-14
03 Patrick McManus Notification list changed to Patrick McManus <mcmanus@ducksong.com>
2018-09-14
03 Patrick McManus Document shepherd changed to Patrick McManus
2018-09-14
03 Patrick McManus IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2018-05-30
03 Mark Nottingham Intended Status changed to Experimental from None
2018-05-30
03 Mark Nottingham Changed consensus to Yes from Unknown
2018-03-20
03 Darshak Thakore New version available: draft-ietf-httpbis-rand-access-live-03.txt
2018-03-20
03 (System) New version approved
2018-03-20
03 (System) Request for posting confirmation emailed to previous authors: Craig Pratt , Barbara Stark , Darshak Thakore
2018-03-20
03 Darshak Thakore Uploaded new revision
2017-11-21
02 Mark Nottingham ends 2018-01-20
2017-11-21
02 Mark Nottingham IETF WG state changed to In WG Last Call from WG Document
2017-11-15
02 Patrick McManus Added to session: IETF-100: httpbis  Fri-0930
2017-11-14
02 Craig Pratt New version available: draft-ietf-httpbis-rand-access-live-02.txt
2017-11-14
02 (System) New version approved
2017-11-14
02 (System) Request for posting confirmation emailed to previous authors: Craig Pratt , Barbara Stark , Darshak Thakore
2017-11-14
02 Craig Pratt Uploaded new revision
2017-09-04
01 Craig Pratt New version available: draft-ietf-httpbis-rand-access-live-01.txt
2017-09-04
01 (System) New version approved
2017-09-04
01 (System) Request for posting confirmation emailed to previous authors: Craig Pratt , Barbara Stark , Darshak Thakore
2017-09-04
01 Craig Pratt Uploaded new revision
2017-03-21
00 Patrick McManus Added to session: IETF-98: httpbis  Fri-0900
2017-03-07
00 Darshak Thakore New version available: draft-ietf-httpbis-rand-access-live-00.txt
2017-03-07
00 (System) WG -00 approved
2017-03-07
00 Darshak Thakore Set submitter to "Darshak Thakore ", replaces to (none) and sent approval email to group chairs: httpbis-chairs@ietf.org
2017-03-07
00 Darshak Thakore Uploaded new revision