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

AFAICT, the existing ABNF for byte ranges *does* already support what you are looking for, without having to introduce a new unit type:

    byte-range-spec = first-byte-pos "-" [ last-byte-pos ]

Simply omit the * and leave the second value empty:
    Range: bytes=1234567-

RFC 2616 Section 14.35.1 says:

"If the last-byte-pos value is absent, or if the value is greater than or equal to the current length of the entity-body, last-byte-pos is taken to be equal to one less than the current length of the entity- body in bytes."

<bhs> Yes the client can make an open-ended request. The problem is the server has no means of providing an open-ended response.

RFC 7233 Section 2.1 says:

"If the last-byte-pos value is absent, or if the value is greater than or equal to the current length of the representation data, the byte range is interpreted as the remainder of the representation (i.e., the server replaces the value of last-byte-pos with a value that is one less than the current length of the selected representation)."

<bhs> Correct. The server is required to provide an actual value for last-byte-pos. And that value is based on the current length. If the server is recording the content from a live stream, whatever value the server provides will no longer be the last byte almost as soon as the value is sent. The actual endpoint is constantly increasing.

Since the media is being recorded while streaming, the client can randomly jump around within the recorded portion of the media all it wants. Once jumped, it would simply be receiving media from the recording, not the live feed.  To jump back to the live feed, simply omit the "Range" header.

<bhs> The use case is not one of the client recording the stream. It is of the server recording the stream. Let me see if I can explain the use case better.
The user is watching content on a client that is being streamed from a server. The server is recording the content from a live stream. The client has limited memory and can only buffer about 15 seconds worth of content.
The user pauses watching the content and comes back after 1 minute to resume. The client sends the server a request to provide content from the paused byte position to “-“.
The server is required to provide a response that has an actual last byte value. The only last byte value the server has is the one for the precise moment of the request. After a minute, the server has a minute more of content but has provided the client with the content up to that responded last byte. Shouldn’t the server stop sending bytes once it gets to the value of its responded last-byte-pos? Even though it has now a whole lot more bytes and we know that the user just wants to keep watching? Should the client be expected to make continual requests to keep up with the ever-increasing endpoint?
The purpose of this proposal is to allow the server to provide an open-ended response, so the server can send bytes that it didn’t have at the time of the original request.

Barbara