Subject: Re: [httpwg/http-extensions] Incorporated comments from MartinT and some of my own edits to draft-ietf-httpbis-rand-access-live (#414)

From: HTTP issue updates <[email-masked]>
Date: Thu, 09 Nov 2017 21:11:28 +0000 (UTC)

martinthomson approved this pull request.

> @@ -166,16 +166,22 @@
     
     <section anchor="introduction" title="Introduction">
         <t>
-             Some Hypertext Transfer Protocol (HTTP) Clients use byte-range requests (Range requests using the "bytes" Range Unit) to transfer select portions of large representations. And in some cases large representations require content to be continuously or periodically appended - such as representations consisting of live audio or video sources, blockchain databases, and log files. Clients cannot access the appended/live content using a Range request with the bytes range unit using the currently defined byte-range semantics without accepting performance or behavior sacrifices which are not acceptable for many applications.
+             Some Hypertext Transfer Protocol (HTTP) clients use byte-range requests (Range requests using the "bytes" Range Unit) to transfer select portions of large representations. And in some cases large representations require content to be continuously or periodically appended - such as representations consisting of live audio or video sources, blockchain databases, and log files. clients cannot access the appended/live content using a Range request with the bytes range unit using the currently defined byte-range semantics without accepting performance or behavior sacrifices which are not acceptable for many applications.

"client" needs to be capitalized at the start of a sentence :)

>          </t>
         <t>
-			To accommodate byte-range requests on large representations which have data appended over time efficiently and with low latency, this recommendation defines semantics whereby the HTTP Client performs byte-range requests using a combination of open-ended byte-range HEAD requests and GET requests using "Large Value" last-byte-pos values.
+            This document describes a usage model for range requests which enables
+            efficient retrieval of representations that are appended to over time
+            by utilizing large values and associated semantics for communicating

https://grammarpartyblog.com/2012/01/17/use-versus-utilize/

> -       </list>
+            This document recommends a two-step process for accessing resources
+            that have indeterminate length representations.
+            
+            Two steps are necessary because of limitations with the Range request
+            header and the Content-Range response header fields. A server cannot
+            know from a range request that a client wishes to receive a response
+            that does not have a definite end. More critically, the header fields
+            do not allow the server to signal that a resource has indeterminate
+            length without also providing a fixed portion of the resource.
+
+            A client first learns that the resource has a representation of
+            indeterminate length by requesting a range of the resource. The server
+            responds with the range that is available, but indicates that the
+            length of the representation is unknown using the existing
+            Content-Range syntax. See Section 2.1 for details and examples.

<xref target="establishing-range"/> for the section reference.

> +
+            A client first learns that the resource has a representation of
+            indeterminate length by requesting a range of the resource. The server
+            responds with the range that is available, but indicates that the
+            length of the representation is unknown using the existing
+            Content-Range syntax. See Section 2.1 for details and examples.
+
+            Once the client knows the resource has indeterminate length, it can
+            request a range with a very large end position from the resource. The
+            client chooses an explicit end value larger than can be transferred in
+            the foreseeable term. A server which supports range requests of
+            indeterminate length signals its understanding of the client's
+            indeterminate range request by indicating that the range it is
+            providing has a range end that exactly matches the client's requested
+            range end rather than a range that is bounded by what is currently
+            available. See Sections 2.2 and 2.3 for details.

xrefs

>  </artwork></figure>
       <t>
-        could return
+        will return

maybe "will return a range covering only those bytes that are currently available:"

> @@ -390,7 +423,9 @@
 
     <section anchor="Security" title="Security Considerations">
         <t>
-      One potential issue with this recommendation is related to the use of very-large last-byte-pos values. Some Client and Server implementations may not be prepared to deal with byte position values of 2^^63 and beyond. So in applications where there's no expectation that the representation will ever exceed 2^^63, a value smaller than this value should be used as the Very Large last-byte-pos in a byte-seek request or content-range response.
+      One potential issue with this recommendation is related to the use of very-large last-byte-pos values. Some client and server implementations may not be prepared to deal with byte position values of 2^^63 and beyond. So in applications where there's no expectation that the representation will ever exceed 2^^63, a value smaller than this value should be used as the Very Large last-byte-pos in a byte-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^^63 bytes, values smaller than this limit should be used for the last-byte-pos in byte-range requests.

it's less about representation for this, but about ease of parsing

I think that the second value here could be 2^53 instead of 2^63.

> @@ -210,24 +232,26 @@
    byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
 </artwork></figure>
       <t>
-      which allows a Client to send a HEAD request with a first-byte-pos and leave last-byte-pos absent. A Server that receives a satisfiable byte-range request (with first-byte-pos smaller than the current representation length) must respond with a 206 status code (Partial Content) with a Content-Range header indicating the currently satisfiable byte range. For example, a Client-issued HEAD request performed against a continuously aggregating representation hosted on a Server could contain a byte-range header of the form:
+      which allows a client to send a HEAD request with a first-byte-pos and leave last-byte-pos absent. A server that receives a satisfiable byte-range request (with first-byte-pos smaller than the current representation length) must respond with a 206 status code (Partial Content) with a Content-Range header indicating the currently satisfiable byte range. For example, a client-issued HEAD request performed against a continuously aggregating representation hosted on a server could contain a byte-range header of the form:

The "must" here is incorrect.  It can provide the entire representation (for instance, if it didn't support range requests).  Maybe "might".

> @@ -210,24 +232,26 @@
    byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
 </artwork></figure>
       <t>
-      which allows a Client to send a HEAD request with a first-byte-pos and leave last-byte-pos absent. A Server that receives a satisfiable byte-range request (with first-byte-pos smaller than the current representation length) must respond with a 206 status code (Partial Content) with a Content-Range header indicating the currently satisfiable byte range. For example, a Client-issued HEAD request performed against a continuously aggregating representation hosted on a Server could contain a byte-range header of the form:
+      which allows a client to send a HEAD request with a first-byte-pos and leave last-byte-pos absent. A server that receives a satisfiable byte-range request (with first-byte-pos smaller than the current representation length) must respond with a 206 status code (Partial Content) with a Content-Range header indicating the currently satisfiable byte range. For example, a client-issued HEAD request performed against a continuously aggregating representation hosted on a server could contain a byte-range header of the form:

Finally, the client doesn't necessarily know that the resource is continuously aggregating.  Maybe just say "For example, a client issues a request for an indefinite range of bytes as follows:"

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/414#pullrequestreview-75585363

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 10 Nov 2017 10:27:30 +0000 (UTC)

craigpratt commented on this pull request.

Yeah - I think I recall hearing that rule in an English class once...

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/414#discussion_r150200610

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 10 Nov 2017 10:29:08 +0000 (UTC)

<t>

Guess I never really thought about it that much. No problem with changing it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/414#discussion_r150200934

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 10 Nov 2017 10:31:02 +0000 (UTC)

ok - simplified the setup...

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/414#discussion_r150201306

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 10 Nov 2017 10:31:02 +0000 (UTC)

<t>
-        could return
+        will return

fixed

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/414#discussion_r150201314

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 10 Nov 2017 10:31:59 +0000 (UTC)

fixed

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/414#discussion_r150201622

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 10 Nov 2017 10:49:18 +0000 (UTC)

@craigpratt pushed 1 commit.

28aebf0  Incorporated a few more suggested edits and fixed some xrefs

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/httpwg/http-extensions/pull/414/files/21b611b6ad20334af2ac2cc855c0c7a2c3c267c3..28aebf005b5060c2260ce90c6af9765289850a1d

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 10 Nov 2017 10:57:02 +0000 (UTC)

Merged #414.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/414#event-1335835766