Discussion:
Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34
(too old to reply)
Magnus Westerlund
2013-06-07 09:35:23 UTC
Permalink
Hi Elwyn,

Many thanks for the detailed review. We will address the nits you have
raised, but I cut them out of this reply to focus on the more
substantial issues you have brought up.

See inline below.
I am an additional Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-mmusic-rfc2326bis
Reviewer: Elwyn Davies
Review Date: 5 June 2013
IETF LC End Date: 5 JUne 2013
IESG Telechat date: (if known) -
Almost ready. Generally this is an excellent and well written document,
particularly given its size. There are a few minor issues to sort out
mainly at the nit level and some consistency issues to fix up. The two
issues that I have brought out below are really at what the IESG would
call 'DISCUSS-DISCUSS' level. The issue of URI scheme redefinition may
well have already been cleared by the URI expert - the draft does not do
itself any favours here by failing to explain what the syntax changes
are in s4.2; this raises immediate red flags that only start to fade a
couple of hundred pages later. The rudimentary nature of the pipeline
mechanism is carried over from RTSP 1.0. I'd like to be sure that this
has been properly discussed in the WG as it looks pretty flaky to an
outsider. There are several inconsistencies between various lists of
headers that need sorting out and there is no definition of
Proxy-Authorization in the ABNF.
There are also a fairly large number of editorial nits but these are all
localized and trivial to fix. Finally I have't had time to review the
appendices (maybe there will be a follow up).
Robert Sparks is the main gen-art reviewer for the document; he asked
for additional eyes on the document given the size and his RAI
background. Having (just) seen his review, I think we have both picked
up on the URI scheme and pipeline issues. I am not sure that I concur
with his view that there is significant normative material in the
appendices - AFAICS the main protocol definition *is* in the main body
of the document and the bits especiially in Appendices B and C are not
the core of the protocol. However this is based on a very cursory
glance through something like 75 pages of the document. However, I do
concur with Robert's view that it needs a security expert to check the
security stories.
s4.2: This section (re-)defines the URI schemes "rtsp" and "rtsps". The
last sentence of para 1 states that the 'details of the syntax' of the
URIs 'have been changed'. Is this a reasonable thing to do? Has this
been cleared with the URI expert reviewer? I am not entirely clear what
the change involves and the draft doesn't explain exactly how the syntax
has been altered and its consequences (if any) in s4.2. Some details
are finally given in s22.14.
These syntax changes where discussed in the reviews I got on the URI
list. That resulted in the explicitness in the template, but I forgot
about adding anything into Section 4.2. I see no issue with adding the
following clarification to Section 4.2:

The details of the syntax of "rtsp" and "rtsps" URIs has been changed
from RTSP 1.0. These changes are:

o Support for IPV6 literal in host part and future IP literals
through RFC 3986 defined mechanism.

o A new relative format to use in the RTSP protocol elements that is
not required to start with "/".

Neither should have any significant impact on interoperability. If
one is required to use IPv6 literals to reach an RTSP server, then
that RTSP server must be IPv6 capable, and RTSP 1.0 is not a fully
IPv6 capable protocol. Thus, RTSP 2.0 support will be needed anyway.
The second change will only occur in RTSP messages, that are
explicitly identified as being RTSP 2.0 messages, thus a RTSP 1.0
only agent will not be required to parse this variant.

I hope this makes it clear that these syntax changes is unlikely to hurt
the interoperability.
s11, para 3: I guess that the WG decided that sticking with the RTSP 1.0
model of sending requests and worrying about success of prior prior
pipelined requests was the right answer. I would have thought that it
might have been helpful to provide qualifiers on the Pipelined-Requests
header that allowed subsequent requests to be suppressed unless the
previous command resulted in one of a given set of status codes with a
'reset' option to 'restart' the pipeline. It strikes me that this would
avoid some irritating need to work out how to recover from arbitrary
failures in a command chain in a client.
I assume you mean this Section 12 paragraph:

If a pipelined request builds on the successful completion of one or
more prior requests the requester must verify that all requests were
executed as expected. A common example will be two SETUP requests
and a PLAY request. In case one of the SETUP fails unexpectedly, the
PLAY request can still be successfully executed. However, the
resulting presentation will not be as expected by the requesting
client, as only a single media instead of two will be played. In
this case the client can send a PAUSE request, correct the failing
SETUP request and then request it to be played.

I think I agree with your assessment, that it would have been nice.
However, we should have thought of that when we introduced this type of
pipelining 7 years ago. Making any changes to this at this stage is
counter productive. The reality is that all the "nice" features and
necessary clarifications has been retrofitted into RTSP 1.0 by the ones
that have been using RTSP 1.0. So changing anything will separate the
RTSP 1.0 and RTSP 2.0 implementations. The good thing is that I can't
remember any substantial complaints about this issue.

I hope this resolves your comments.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB | Phone +46 10 7148287
Färögatan 6 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: ***@ericsson.com
----------------------------------------------------------------------
Elwyn Davies
2013-06-07 12:26:00 UTC
Permalink
Post by Magnus Westerlund
Hi Elwyn,
Many thanks for the detailed review. We will address the nits you have
raised, but I cut them out of this reply to focus on the more
substantial issues you have brought up.
.. and thanks for the quick response.
Post by Magnus Westerlund
See inline below.
OK. I think the responses clear those issues.

I have done a little bit more on the Appendices and liaised a bit with
Robert Sparks. 'Highlights':

Appendix F: I missed that the text/parameter format appeared in the
examples for GET_PARAMETER and SET_PARAMETER. It isn't stated in the
definitions of these methods what encodings are acceptable for the
message bodies that may go with these methods and their responses.
Clearly the new text/parameter MIME format is one. Is it the only one?
I guess you could use a application/json or an XML format but I guess
these would also either have to be called out explicitly in the method
descriptions or put in as feature extensions. This needs to be
clarified in the method descriptions (s13). The upshot of all this is
that I think Appendix F needs to be pulled back into Section 20 as
currently it is the only way to encode the message bodies.

Appendix B: I appreciate that the state machine is illustrative and to
an extent 'abstract'. However, the tables are really written to
describe the state machine in the server: the action column mostly
describes the events that come into the server (apart from the notify
actions) - sending these 'events' are actions in the client. The 'real'
state machine in the both the server and the client has a somewhat more
complex form: I'd think that there was a STOPPED state in the server
when the media has reached an end point and not been explictly paused
and STARTING/PAUSING states in the client while the client waits for
response to PLAY/PAUSE respectively. I think a little bit more
explanation about the dual nature of the columns would solve the
problem.

Appendix C: Pending.

Regards,
Elwyn
Post by Magnus Westerlund
I am an additional Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-mmusic-rfc2326bis
Reviewer: Elwyn Davies
Review Date: 5 June 2013
IETF LC End Date: 5 JUne 2013
IESG Telechat date: (if known) -
Almost ready. Generally this is an excellent and well written document,
particularly given its size. There are a few minor issues to sort out
mainly at the nit level and some consistency issues to fix up. The two
issues that I have brought out below are really at what the IESG would
call 'DISCUSS-DISCUSS' level. The issue of URI scheme redefinition may
well have already been cleared by the URI expert - the draft does not do
itself any favours here by failing to explain what the syntax changes
are in s4.2; this raises immediate red flags that only start to fade a
couple of hundred pages later. The rudimentary nature of the pipeline
mechanism is carried over from RTSP 1.0. I'd like to be sure that this
has been properly discussed in the WG as it looks pretty flaky to an
outsider. There are several inconsistencies between various lists of
headers that need sorting out and there is no definition of
Proxy-Authorization in the ABNF.
There are also a fairly large number of editorial nits but these are all
localized and trivial to fix. Finally I have't had time to review the
appendices (maybe there will be a follow up).
Robert Sparks is the main gen-art reviewer for the document; he asked
for additional eyes on the document given the size and his RAI
background. Having (just) seen his review, I think we have both picked
up on the URI scheme and pipeline issues. I am not sure that I concur
with his view that there is significant normative material in the
appendices - AFAICS the main protocol definition *is* in the main body
of the document and the bits especiially in Appendices B and C are not
the core of the protocol. However this is based on a very cursory
glance through something like 75 pages of the document. However, I do
concur with Robert's view that it needs a security expert to check the
security stories.
s4.2: This section (re-)defines the URI schemes "rtsp" and "rtsps". The
last sentence of para 1 states that the 'details of the syntax' of the
URIs 'have been changed'. Is this a reasonable thing to do? Has this
been cleared with the URI expert reviewer? I am not entirely clear what
the change involves and the draft doesn't explain exactly how the syntax
has been altered and its consequences (if any) in s4.2. Some details
are finally given in s22.14.
These syntax changes where discussed in the reviews I got on the URI
list. That resulted in the explicitness in the template, but I forgot
about adding anything into Section 4.2. I see no issue with adding the
The details of the syntax of "rtsp" and "rtsps" URIs has been changed
o Support for IPV6 literal in host part and future IP literals
through RFC 3986 defined mechanism.
o A new relative format to use in the RTSP protocol elements that is
not required to start with "/".
Neither should have any significant impact on interoperability. If
one is required to use IPv6 literals to reach an RTSP server, then
that RTSP server must be IPv6 capable, and RTSP 1.0 is not a fully
IPv6 capable protocol. Thus, RTSP 2.0 support will be needed anyway.
The second change will only occur in RTSP messages, that are
explicitly identified as being RTSP 2.0 messages, thus a RTSP 1.0
only agent will not be required to parse this variant.
I hope this makes it clear that these syntax changes is unlikely to hurt
the interoperability.
s11, para 3: I guess that the WG decided that sticking with the RTSP 1.0
model of sending requests and worrying about success of prior prior
pipelined requests was the right answer. I would have thought that it
might have been helpful to provide qualifiers on the Pipelined-Requests
header that allowed subsequent requests to be suppressed unless the
previous command resulted in one of a given set of status codes with a
'reset' option to 'restart' the pipeline. It strikes me that this would
avoid some irritating need to work out how to recover from arbitrary
failures in a command chain in a client.
If a pipelined request builds on the successful completion of one or
more prior requests the requester must verify that all requests were
executed as expected. A common example will be two SETUP requests
and a PLAY request. In case one of the SETUP fails unexpectedly, the
PLAY request can still be successfully executed. However, the
resulting presentation will not be as expected by the requesting
client, as only a single media instead of two will be played. In
this case the client can send a PAUSE request, correct the failing
SETUP request and then request it to be played.
I think I agree with your assessment, that it would have been nice.
However, we should have thought of that when we introduced this type of
pipelining 7 years ago. Making any changes to this at this stage is
counter productive. The reality is that all the "nice" features and
necessary clarifications has been retrofitted into RTSP 1.0 by the ones
that have been using RTSP 1.0. So changing anything will separate the
RTSP 1.0 and RTSP 2.0 implementations. The good thing is that I can't
remember any substantial complaints about this issue.
I hope this resolves your comments.
Cheers
Magnus Westerlund
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB | Phone +46 10 7148287
Färögatan 6 | Mobile +46 73 0949079
----------------------------------------------------------------------
_______________________________________________
Gen-art mailing list
https://www.ietf.org/mailman/listinfo/gen-art
Magnus Westerlund
2013-06-07 14:05:49 UTC
Permalink
Hi Elwyn,
Post by Elwyn Davies
Post by Magnus Westerlund
Hi Elwyn,
Many thanks for the detailed review. We will address the nits you have
raised, but I cut them out of this reply to focus on the more
substantial issues you have brought up.
.. and thanks for the quick response.
Post by Magnus Westerlund
See inline below.
OK. I think the responses clear those issues.
I have done a little bit more on the Appendices and liaised a bit with
Appendix F: I missed that the text/parameter format appeared in the
examples for GET_PARAMETER and SET_PARAMETER. It isn't stated in the
definitions of these methods what encodings are acceptable for the
message bodies that may go with these methods and their responses.
Exactly, that is intentional. These methods can use anything that has a
MIME type. Also it has HTTP's mechanisms for determining what formats
one supports.
Post by Elwyn Davies
Clearly the new text/parameter MIME format is one. Is it the only one?
It is the only one defined by IETF for this purpose. That is why it is
in the appendix so that RTSP users shall have something to define the
parameters they want in. However, they have to accept the limitations of
a basic text format.
Post by Elwyn Davies
I guess you could use a application/json or an XML format but I guess
these would also either have to be called out explicitly in the method
descriptions or put in as feature extensions. This needs to be
clarified in the method descriptions (s13). The upshot of all this is
that I think Appendix F needs to be pulled back into Section 20 as
currently it is the only way to encode the message bodies.
I can agree that the format negotiation for the bodies of
GET/SET_PARAMETER is not clear. I will look at proposing some
improvements of the text related to the handling of method bodies and
their format negotiation.

However, I am not pulling in Appendix F. It is an optional to use format
for parameter value pairs that can be used in these methods, it is not
required. Nor, does the specification define any parameters that are
transferred using this interface. The things that are in the appendix
are not core protocol, they represent either informational things, like
the examples and the state machine. The other appendices are normative
definitions of particular choices for things that can be combined or
used with RTSP, like RTP as media transport.
Post by Elwyn Davies
Appendix B: I appreciate that the state machine is illustrative and to
an extent 'abstract'. However, the tables are really written to
describe the state machine in the server: the action column mostly
describes the events that come into the server (apart from the notify
actions) - sending these 'events' are actions in the client. The 'real'
state machine in the both the server and the client has a somewhat more
complex form: I'd think that there was a STOPPED state in the server
when the media has reached an end point and not been explictly paused
and STARTING/PAUSING states in the client while the client waits for
response to PLAY/PAUSE respectively. I think a little bit more
explanation about the dual nature of the columns would solve the
problem.
There shouldn't be an issue to clarify this nature.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB | Phone +46 10 7148287
Färögatan 6 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: ***@ericsson.com
----------------------------------------------------------------------
Elwyn Davies
2013-06-07 15:40:02 UTC
Permalink
Post by Magnus Westerlund
Post by Elwyn Davies
Appendix F: I missed that the text/parameter format appeared in the
examples for GET_PARAMETER and SET_PARAMETER. It isn't stated in the
definitions of these methods what encodings are acceptable for the
message bodies that may go with these methods and their responses.
Exactly, that is intentional. These methods can use anything that has a
MIME type. Also it has HTTP's mechanisms for determining what formats
one supports.
Post by Elwyn Davies
Clearly the new text/parameter MIME format is one. Is it the only one?
It is the only one defined by IETF for this purpose. That is why it is
in the appendix so that RTSP users shall have something to define the
parameters they want in. However, they have to accept the limitations of
a basic text format.
Post by Elwyn Davies
I guess you could use a application/json or an XML format but I guess
these would also either have to be called out explicitly in the method
descriptions or put in as feature extensions. This needs to be
clarified in the method descriptions (s13). The upshot of all this is
that I think Appendix F needs to be pulled back into Section 20 as
currently it is the only way to encode the message bodies.
I can agree that the format negotiation for the bodies of
GET/SET_PARAMETER is not clear. I will look at proposing some
improvements of the text related to the handling of method bodies and
their format negotiation.
Good. I don't see where the server tells what formats it accepts for
either GET_PARAMETER or SET_PARAMETER. Also the Accept spec doesn't say
anything about SET_PARAMETER. AFAICS the client could tell the server
what formats it accepts as a side-effect of DESCRIBE but that's a bit
arcane - and it is not clear how you would separate the formats for
DESCRIBE from those for GET_PARAM and SET_PARAM.
Post by Magnus Westerlund
However, I am not pulling in Appendix F. It is an optional to use format
for parameter value pairs that can be used in these methods, it is not
required. Nor, does the specification define any parameters that are
transferred using this interface. The things that are in the appendix
are not core protocol, they represent either informational things, like
the examples and the state machine. The other appendices are normative
definitions of particular choices for things that can be combined or
used with RTSP, like RTP as media transport.
OK, it is possible to use GET_PARAM for basic requirements without using
message bodies, so you can get away without defining a lowest common
denominator format. However, the use of message bodies for SET_PARAM is
RECOMMENDED so it seems a little odd not to ensure that server and
client will have at least one format in common. (And its not as if we
are dealing with a hugely complicated bit of spec for
text/parameters! :-) ). Then, given the example in GET_PARAMETER it
seems sensible to advise implementing text/parameters as the default for
GET_PARAM also.

/Elwyn
Magnus Westerlund
2013-06-10 07:52:07 UTC
Permalink
Post by Elwyn Davies
Post by Magnus Westerlund
Post by Elwyn Davies
Appendix F: I missed that the text/parameter format appeared in the
examples for GET_PARAMETER and SET_PARAMETER. It isn't stated in the
definitions of these methods what encodings are acceptable for the
message bodies that may go with these methods and their responses.
Exactly, that is intentional. These methods can use anything that has a
MIME type. Also it has HTTP's mechanisms for determining what formats
one supports.
Post by Elwyn Davies
Clearly the new text/parameter MIME format is one. Is it the only one?
It is the only one defined by IETF for this purpose. That is why it is
in the appendix so that RTSP users shall have something to define the
parameters they want in. However, they have to accept the limitations of
a basic text format.
Post by Elwyn Davies
I guess you could use a application/json or an XML format but I guess
these would also either have to be called out explicitly in the method
descriptions or put in as feature extensions. This needs to be
clarified in the method descriptions (s13). The upshot of all this is
that I think Appendix F needs to be pulled back into Section 20 as
currently it is the only way to encode the message bodies.
I can agree that the format negotiation for the bodies of
GET/SET_PARAMETER is not clear. I will look at proposing some
improvements of the text related to the handling of method bodies and
their format negotiation.
Good. I don't see where the server tells what formats it accepts for
either GET_PARAMETER or SET_PARAMETER. Also the Accept spec doesn't say
anything about SET_PARAMETER. AFAICS the client could tell the server
what formats it accepts as a side-effect of DESCRIBE but that's a bit
arcane - and it is not clear how you would separate the formats for
DESCRIBE from those for GET_PARAM and SET_PARAM.
Yes, I think this negotiation should happen on per methods basis.
Post by Elwyn Davies
Post by Magnus Westerlund
However, I am not pulling in Appendix F. It is an optional to use format
for parameter value pairs that can be used in these methods, it is not
required. Nor, does the specification define any parameters that are
transferred using this interface. The things that are in the appendix
are not core protocol, they represent either informational things, like
the examples and the state machine. The other appendices are normative
definitions of particular choices for things that can be combined or
used with RTSP, like RTP as media transport.
OK, it is possible to use GET_PARAM for basic requirements without using
message bodies, so you can get away without defining a lowest common
denominator format. However, the use of message bodies for SET_PARAM is
RECOMMENDED so it seems a little odd not to ensure that server and
client will have at least one format in common. (And its not as if we
are dealing with a hugely complicated bit of spec for
text/parameters! :-) ). Then, given the example in GET_PARAMETER it
seems sensible to advise implementing text/parameters as the default for
GET_PARAM also.
Sure, I personally don't have any issue with making it at least SHOULD
implement text/parameters. But from my horizon a forward pointer with
the normative requirements is sufficient to accomplish that.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB | Phone +46 10 7148287
Färögatan 6 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: ***@ericsson.com
----------------------------------------------------------------------
Magnus Westerlund
2013-08-28 09:45:25 UTC
Permalink
WG,

As a result of the below quoted discussion I have created a proposed
text change to make the format negotiation more explicit and clear and
linked to the RTSP methods that have need for it.

The changes I have done in an attempt to address this can be summarized as:
- Create a general negotiation description in a sub-section to the
Message Body section
- Updated GET_PARAMETER and SET_PARAMETER methods to reference this and
be more explicit about handling request formats and returning the same
format.
- Mandate that anyone capable of responding to a GET_PARAMETER and
SET_PARAMETER request MUST support text/parameters
- Updating the Accept header to actually contain description of how you
use it. Missed import from HTTP spec when removing reference.

Please review these changes and provide comments.

Actual text proposal below including whole sections:

9.3. Message Body Format Negotiation

The content format of the message body is provided using the Content-
Type header (Section 18.18). To enable the responder of a request to
determine which media type it should use, the requestor may include
the Accept header (Section 18.1) in a request to identify supported
media types or media type ranges suitable to the response. In cases
the responder is not supporting any of the specified formats, then
the request response will be a 406 (Not Acceptable) error code.

The media types that may be used on requests with message bodies
needs to be determined through the use of feature-tags, specification
requirement or trial and error. Trial and error works in the regards
that in case the responder is not supporting the media type of the
message body it will respond with a 415 (Unsupported Media Type).

The formats supported and their negotiation is done individually on a
per method and direction (request or response body) direction.
Requirements on supporting particular media types for use as message
bodies in requests and response SHALL also be specified on per method
and direction basis.


13.8. GET_PARAMETER

The GET_PARAMETER request retrieves the value of any specified
parameter or parameters for a presentation or stream specified in the
URI. If the Session header is present in a request, the value of a
parameter MUST be retrieved in the specified session context. There
are two ways of specifying the parameters to be retrieved.

The first is by including headers which have been defined such that
you can use them for this purpose. Headers for this purpose should
allow empty, or stripped value parts to avoid having to specify bogus
data when indicating the desire to retrieve a value. The successful
completion of the request should also be evident from any filled out
values in the response. The headers in this specification that MAY
be used for retrieving their current value using GET_PARAMETER below.
Additional headers MAY be specified in the future:

o Accept-Ranges

o Media-Range

o Media-Properties

o Range

o RTP-Info

The other way is to specify a message body that lists the
parameter(s) that are desired to be retrieved. The Content-Type
header (Section 18.18) is used to specify which format the message
body has. If the receiver of the request is not supporting the media
type used for the message body, it SHALL respond using the error code
415 (Unsupported Media Type). The responder to a GET_PARAMETER
request MUST use the media type of the request for the response. For
additional considerations regarding message body negotiation see
Section 9.3.

RTSP Agents implementing support for responding to GET_PARAMETER
requests SHALL implement the text/parameters format (Appendix F).
This to ensure that at least one known format for parameter are
implemented and thus prevent parameter format negotiation failure.

Parameters specified within the body of the message must all be
understood by the request receiving agent. If one or more parameters
are not understood a 451 (Parameter Not Understood) MUST be sent
including a body listing these parameters that weren't understood.
If all parameters are understood their values are filled in and
returned in the response message body.

The method MAY also be used without a message body or any header that
requests parameters for keep-alive purpose. The keep-alive timer has
been updated for any request that is successful, i.e., a 200 OK
response is received. Any non-required header present in such a
request may or may not have been processed. Normally the presence of
filled out values in the header will be indication that the header
has been processed. However, for cases when this is difficult to
determine, it is recommended to use a feature-tag and the Require
header. For this reason it is usually easier if any parameters to be
retrieved are sent in the body, rather than using any header.

Example:

S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 431
User-Agent: PhonyClient/1.2
Session: 12345678
Content-Length: 26
Content-Type: text/parameters

packets_received
jitter

C->S: RTSP/2.0 200 OK
CSeq: 431
Session: 12345678
Server: PhonyServer/1.1
Date: Mon, 08 Mar 2010 13:43:23 GMT
Content-Length: 38
Content-Type: text/parameters

packets_received: 10
jitter: 0.3838


13.9. SET_PARAMETER

This method requests to set the value of a parameter or a set of
parameters for a presentation or stream specified by the URI. The
method MAY also be used without a message body. It is the
RECOMMENDED method to be used in a request sent for the sole purpose
of updating the keep-alive timer. If this request is successful,
i.e., a 200 OK response is received, then the keep-alive timer has
been updated. Any non-required header present in such a request may
or may not have been processed. To allow a client to determine if
any such header has been processed, it is necessary to use a feature
tag and the Require header. Due to this reason it is RECOMMENDED
that any parameters are sent in the body, rather than using any
header.

When using a message body to list the parameter(s) that are desired
to be set the Content-Type header (Section 18.18) is used to specify
which format the message body has. If the receiver of the request is
not supporting the media type used for the message body, it SHALL
respond using the error code 415 (Unsupported Media Type). For
additional considerations regarding message body negotiation see
Section 9.3.

RTSP Agents implementing support for responding to SET_PARAMETER
requests SHALL implement the text/parameters format (Appendix F).
This to ensure that at least one known format for parameters are
implemented and thus prevent parameter format negotiation failure.

A request is RECOMMENDED to only contain a single parameter to allow
the client to determine why a particular request failed. If the
request contains several parameters, the server MUST only act on the
request if all of the parameters can be set successfully. A server
MUST allow a parameter to be set repeatedly to the same value, but it
MAY disallow changing parameter values. If the receiver of the
request does not understand or cannot locate a parameter, error 451
(Parameter Not Understood) MUST be used. When a parameter is not
allowed to change, the error code is 458 (Parameter Is Read-Only).
The response body MUST contain only the parameters that have errors.
Otherwise no body MUST be returned. The response body MUST use the
media type of the request for the response.

Note: transport parameters for the media stream MUST only be set with
the SETUP command.

Restricting setting transport parameters to SETUP is for the
benefit of firewalls.

The parameters are split in a fine-grained fashion so that there
can be more meaningful error indications. However, it may make
sense to allow the setting of several parameters if an atomic
setting is desirable. Imagine device control where the client
does not want the camera to pan unless it can also tilt to the
right angle at the same time.

Example:

C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 421
User-Agent: PhonyClient/1.2
Session: iixT43KLc
Date: Mon, 08 Mar 2010 14:45:04 GMT
Content-length: 20
Content-type: text/parameters

barparam: barstuff

S->C: RTSP/2.0 451 Parameter Not Understood
CSeq: 421
Session: iixT43KLc
Server: PhonyServer/1.0
Date: Mon, 08 Mar 2010 14:44:56 GMT
Content-length: 20
Content-type: text/parameters

barparam: barstuff



18.1. Accept

The Accept request-header field can be used to specify certain
presentation description and parameter media types [RFC6838] which
are acceptable for the response to DESCRIBE and GET_PARAMETER
requests.

See Section 20.2.3 for the syntax.

The asterisk "*" character is used to group media types into ranges,
with "*/*" indicating all media types and "type/*" indicating all
subtypes of that type. The media-range MAY include media type
parameters that are applicable to that range.

Each media-range MAY be followed by one or more accept-params,
beginning with the "q" parameter for indicating a relative quality
factor. The first "q" parameter (if any) separates the media-range
parameter(s) from the accept-params. Quality factors allow the user
or user agent to indicate the relative degree of preference for that
media-range, using the qvalue scale from 0 to 1 (section 3.9). The
default value is q=1.

Example of use:

Accept: application/example ;q=0.7, application/sdp

Indicates that the requesting agent prefers the media type
application/sdp through the default 1.0 rating but also accepts
the application/example media type with 0.7 quality rating.

If no Accept header field is present, then it is assumed that the
client accepts all media types. If an Accept header field is
present, and if the server cannot send a response which is acceptable
according to the combined Accept field value, then the server SHOULD
send a 406 (not acceptable) response.
Post by Magnus Westerlund
Post by Elwyn Davies
Post by Magnus Westerlund
Post by Elwyn Davies
Appendix F: I missed that the text/parameter format appeared in the
examples for GET_PARAMETER and SET_PARAMETER. It isn't stated in the
definitions of these methods what encodings are acceptable for the
message bodies that may go with these methods and their responses.
Exactly, that is intentional. These methods can use anything that has a
MIME type. Also it has HTTP's mechanisms for determining what formats
one supports.
Post by Elwyn Davies
Clearly the new text/parameter MIME format is one. Is it the only one?
It is the only one defined by IETF for this purpose. That is why it is
in the appendix so that RTSP users shall have something to define the
parameters they want in. However, they have to accept the limitations of
a basic text format.
Post by Elwyn Davies
I guess you could use a application/json or an XML format but I guess
these would also either have to be called out explicitly in the method
descriptions or put in as feature extensions. This needs to be
clarified in the method descriptions (s13). The upshot of all this is
that I think Appendix F needs to be pulled back into Section 20 as
currently it is the only way to encode the message bodies.
I can agree that the format negotiation for the bodies of
GET/SET_PARAMETER is not clear. I will look at proposing some
improvements of the text related to the handling of method bodies and
their format negotiation.
Good. I don't see where the server tells what formats it accepts for
either GET_PARAMETER or SET_PARAMETER. Also the Accept spec doesn't say
anything about SET_PARAMETER. AFAICS the client could tell the server
what formats it accepts as a side-effect of DESCRIBE but that's a bit
arcane - and it is not clear how you would separate the formats for
DESCRIBE from those for GET_PARAM and SET_PARAM.
Yes, I think this negotiation should happen on per methods basis.
Post by Elwyn Davies
Post by Magnus Westerlund
However, I am not pulling in Appendix F. It is an optional to use format
for parameter value pairs that can be used in these methods, it is not
required. Nor, does the specification define any parameters that are
transferred using this interface. The things that are in the appendix
are not core protocol, they represent either informational things, like
the examples and the state machine. The other appendices are normative
definitions of particular choices for things that can be combined or
used with RTSP, like RTP as media transport.
OK, it is possible to use GET_PARAM for basic requirements without using
message bodies, so you can get away without defining a lowest common
denominator format. However, the use of message bodies for SET_PARAM is
RECOMMENDED so it seems a little odd not to ensure that server and
client will have at least one format in common. (And its not as if we
are dealing with a hugely complicated bit of spec for
text/parameters! :-) ). Then, given the example in GET_PARAMETER it
seems sensible to advise implementing text/parameters as the default for
GET_PARAM also.
Sure, I personally don't have any issue with making it at least SHOULD
implement text/parameters. But from my horizon a forward pointer with
the normative requirements is sufficient to accomplish that.
Cheers
Magnus Westerlund
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB | Phone +46 10 7148287
Färögatan 6 | Mobile +46 73 0949079
----------------------------------------------------------------------
--
Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB | Phone +46 10 7148287
Färögatan 6 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: ***@ericsson.com
----------------------------------------------------------------------
Magnus Westerlund
2013-06-24 14:51:46 UTC
Permalink
Elwyn,

Follow up on some of the nits that is not simply to implement or where I
disagree or want to provide feedback.

This email covers all issues up to and including Section 11. That is as
far as I have managed to process them yet. I will now handle over the
rest of this list to my co-authors.
The server should also regularly send every 5
minutes the current media range in a PLAY_NOTIFY request.
Shouldn't this be configurable?
As discussed in Section 13.5.2 the reasons for the picked time is the
following:

The recommendation for sending updates every 5 minutes is due to
any clock skew issues. In 5 minutes the clock skew should not
become too significant as this is not used for media playback and
synchronization, only for determining which content is available
to the user.

Yes, it can be configurable, and in fact 5 min is only the recommended
interval. So, if an implementation that have a good reason for something
else can do that. Do you have a reason why you think this should be
configurable?

But, if it should be rewritten, I think the acceptable range for within
to adjust it should be specified, like between 1 min and 2 hours.
If the client waits too long
before resuming the pause point, the content may no longer be
available. In this case the pause point will be adjusted to the end
of the available media.
I know this is a subjective choice, but I would have thought adjusting
to the beginning of the available media would be what the user expects.
Later: Having read s13.4.1, I think this conflicts with (or is unclear)
compared with s13.4.1, para 2 which states that the pause point will be
the oldest retained time - that is what I would have expected.
Yes, "end" in the above sentence is not quite right. My proposal is the
following:

In this case the pause point will be adjusted to the closest point in
the available media.
s3.1, para 3: Clearly there won't be any smaller type paras in the
ASCII version.. is there a PDF version that actually has smaller type?
The one I get from the repository doesn't seem to have any smaller type
paras.
I removed the "small type" as this is a remains from when the draft was
produced using LaTex and a PDF version was produced.
s4.4: An external reference to the relevant Society of Motion Picture
and Television Engineers standard (probably SMPTE 12M) ought to be
included to define things like "SMPTE 30 drop". [Aside: 29.97 frames
per second?? Must be something to do with Never Twice the Same Color.
Oh, well, a little research job for whan I am really bored.]
Yes, it is ST 12M-1 2008 that appears to be the relevant reference. Yes,
SMPTE 30 drop is a NTSC thing.
s4.9.1: There seems to be some confusion in this section between the
values from the Seek-Style header and the values from the
Media-Properties random access property. The section says the values
are from Seek-Style but they are actually from the random access
property. Presumably there was some intention to interelate the media
capabilities and the play event policies? Further this section has
Random Access, Conditional Random Access, Return to Start and No
Seeking. This doesn't match exactly with either Seek-Style (RAP, CoRAP,
First-Prior and Next) or Media-Properties (Random-Access, Beginning-Only
and No-Seeking).
Yes, this was confused. Actual the Media-Properties headers values are a
distinct set. Then if doing random access then the Seek-Style policies
applies. This I propose to clarify by writing Section 4.9.1 as:

4.9.1. Random Access and Seeking

Random Access is the ability to specify and get media delivered from
any point inside the content, an operation called seeking. The
Media-Properties header will indicate the general capability for a
media resource to perform random access. If random access is
possible the actual behavior policy when seeking can be controlled
using the Seek-Style header (Section 18.45).

Random-Access: The media is seekable to any out of a large number of
points within the media. Due to media encoding limitations, a
particular point may not be reachable, but seeking to a point
close by is enabled. A floating point number of seconds may be
provided to express the worst case distance between random access
points.

Beginning-Only: Seeking is only possible to the beginning of the
content.

No-seeking: Seeking is not possible at all.
s4.9.x: It would be desirable to use the parameter names in the same
form as they appear in s18 (e.g., Random-Access instead of Random
Access, No-Seeking instead of No seeking) both in the definitions
(s4.9.1 - s4.9.4) and the mapping (s4.9.5).
Yes, that is has been addressed.
ss4.4/4.5/4.6: If I read the ABNF in s20.2.1 correctly, the unqualified
values "smpte", "npt" and "clock" are valid in the Range parameter.
What is the meaning of such an unqualified value?
You are correct about that the basic definition in ABNF allows for
empty. The reason for this is the following stated in Section 18.38:

It MAY be
included in GET_PARAMETER requests from the client to the server with
only a Range format and no value to request the current media
position, whether the session is in Play or Ready state in the
included format.
s5: It would be sensible to note that the ABNF fragments in s5 and the
following sections match with the full syntax productions in s20.
I have added a note, but they are in fact equivalent, but not identical.
Thus I make it clear that that this is for information and the formal is
in section 20.2.2.
Table 3: Proxy-Authorization (Section 18.34) doesn't appear in any of
the various header categorization tables [I must have better things to
do than checking they were all there :-( ]. I think it belongs here.
Sorry, for not having found this myself before. You noticing it missing,
was actually a larger inconsistency issue. It was missing in the ABNF also.

I have spent quite some time now to ensure that the ABNF, the tables in
Section 6-8 and the header description now align as they should
regarding category.
s8.1.1, code 505: HTTP code 505 is explicitly '*HTTP* version not
supported' - should there really be a separate code for 'RTSP version
not supported'?
Yes, but the import of HTTP response codes are their meaning not there
exact definition. Thus 505 is RTSP version not supported as listed in
table. That is also what section 17.5.6 defines it as.
s9: Is it deliberately left vague as to whether other message types
might have message bodies?
This is unnecessary vague. In attempt to clarify this I have proposed
the following rewrite of that paragraph:

The SET_PARAMETER and GET_PARAMETER request and response, and DESCRIBE
response is by this specification defined that they MAY have a message
body and its purpose. All 4xx and 5xx responses MAY also have a message
body to carry additional response information. A message body MAY occur
on any RTSP 2.0 request or response, but the content of the message body
MAY be ignored. Extensions to this specification can specify the purpose
and content of message bodies, including requireing their inclusion.
s10.2, para 6 and following note: I can't see that the note following
para 6 can be justified: since the restriction on multiple connections
from a client to a server is only a SHOULD, an interoperable server MUST
be capable of handling multiple connections from a client unless the
server can explicitly send back a TOO MANY CONNECTIONS status.
See separate email
s10.6: RFC 3986 has capability for dealing with IP versions beyond 6...
should these be carried over into RTSP? The IANA registry says they are.
I am uncertain what you want here? Yes, the URI format allows for future
definitions of literal IP address versions. However, RTSP does contain
explicit IPv4 and IPv6 address fields that aren't URIs. Thus, future IP
versions will require some extension definition to function.
s10.7, para 3: Anti-synchronization measures such as are RECOMMENDED
here are usually MANDATORY. (Also applies to wait timer in last para of
this section).
Yes, I agree that they usually are. I personally have no issues making
them required. I think the Recommended formulation is really one of
these cases, do this or something even better or you will hang yourself
to be a bit blunt.

But, if I understand you, you think this paragraph should read:

An RTSP server or proxy in an overload situation must select the value
of the Retry-After header carefully and bearing in mind its current load
situation. It is REQUIRED to increase the timeout period in proportion
to the current load on the server, i.e., an increasing workload should
result in an increased length of the indicated unavailability. It is
REQUIRED to not send the same value in the Retry-After header to all
requesting proxies and clients, but to add a variation to the mean value
of the Retry-After header.

Objections to this?
s10.7, last para: Should the doubling of the wait timer have an upper limit?
Yes, I added an upper limit of 30 minutes. This is way beyond what any
human will accept, only robots will keep on going at this timeout value.
And I think that is large enough to avoid any issues.

I also propose to clarify the range for the variations and added the
classical 0.5 to 1.5 times the deterministic value.

Text proposal.

That timer MUST be doubled for each additional failure to connect or
receive response until the value exceeds 30 minutes when the timers
deterministic value may be set to 30 minutes. It is RECOMMENDED to not
set the same value in the timer for each scheduling, but instead to add
a variation to the mean value, resulting in picking a random value
within the range of 0.5 to 1.5 of the mean value.
s11, para 4: According to s22.1.3, play.basic, play.scale and play.speed
are 'defined' in this draft. The nearest thing to a definition of
play.basic that I can find is the last sentence of para 4 in this
section. I am not convinced that I could produce an interoperable
implementation of a server with this feature-tag with the one sentence
'definition'. References to where play.xxx are defined would be useful
(play.scale in s18.44, play.speed in s18.48).
Hmmm, the other feature-tags than play.basic are pretty straightforward
and well contained. play-basic is really a minimal RTSP server
implementation according to the whole spec for media playback.

This can probably be more clearly expressed somewhere, but it can't
really be enumerated. Then we are back to the issue we had with RFC 2326
minimal implementation list that was incomplete and lacked a lot of
things really necessary.

This issue still haven't resulted in any changes to our source.
This results in the
receiver is learning the requester's feature support.
This results in the
receiver learning the requester's feature support
relevant to the specified resource.
[Note: I added 'specified resource' here and then thought about whether
this made any sense. It probably needs to be clearer what set of
features are included in the Supported list for both requester and
responder. Are they restricted to those relevant to the specified
resource that might of course be the whole server, proxy - or client?? -
in which case there isn't an issue, but it might be a specific
presentation - what happens then? Affects s13.1, para 3 also.]
Actually, I don't think it is specific to the media resource. The issue
with making it specific to a media resource is that a RTSP client needs
to be able to look into the future and supply an answer for a media
resource it may not yet know sufficient to provide a tailored response
for. I think it is simpler and better to provide general capabilities in
the supported header and then later determine how well they apply for
the media resource itself.

We do have Media-Properties header to provide more details for what
specific media transformations a server can do when the support play.scale.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB | Phone +46 10 7148287
Färögatan 6 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: ***@ericsson.com
----------------------------------------------------------------------
Elwyn Davies
2013-06-25 12:47:46 UTC
Permalink
Hi, Magnus.

Thanks for the (continuing) responses.

Some comments in line.

I look forward to the updated document!

/Elwyn
Post by Magnus Westerlund
Elwyn,
Follow up on some of the nits that is not simply to implement or where I
disagree or want to provide feedback.
This email covers all issues up to and including Section 11. That is as
far as I have managed to process them yet. I will now handle over the
rest of this list to my co-authors.
The server should also regularly send every 5
minutes the current media range in a PLAY_NOTIFY request.
Shouldn't this be configurable?
As discussed in Section 13.5.2 the reasons for the picked time is the
The recommendation for sending updates every 5 minutes is due to
any clock skew issues. In 5 minutes the clock skew should not
become too significant as this is not used for media playback and
synchronization, only for determining which content is available
to the user.
Yes, it can be configurable, and in fact 5 min is only the recommended
interval. So, if an implementation that have a good reason for something
else can do that. Do you have a reason why you think this should be
configurable?
Standard review reaction to an apparently sensible but arbitrary fixed
parameter!
Post by Magnus Westerlund
But, if it should be rewritten, I think the acceptable range for within
to adjust it should be specified, like between 1 min and 2 hours.
Suggest:
- adding 'approximately' ('send approximately every') and a ref to
s13.5.2 to s2.3.
- change s13.5.2:
OLD:
In addition it is
RECOMMENDED that the server sends these notifications every 5 minutes
for time-progressing content to ensure the long-term stability of the
client estimation and allowing for clock skew detection by the
client.
NEW:
In addition it is
RECOMMENDED that the server sends these notifications approximately
every 5 minutes
for time-progressing content to ensure the long-term stability of the
client estimation and allowing for clock skew detection by the
client. The time between notifications should be greater than 1 minute
and less than 2 hours.
Post by Magnus Westerlund
If the client waits too long
before resuming the pause point, the content may no longer be
available. In this case the pause point will be adjusted to the end
of the available media.
I know this is a subjective choice, but I would have thought adjusting
to the beginning of the available media would be what the user expects.
Later: Having read s13.4.1, I think this conflicts with (or is unclear)
compared with s13.4.1, para 2 which states that the pause point will be
the oldest retained time - that is what I would have expected.
Yes, "end" in the above sentence is not quite right. My proposal is the
In this case the pause point will be adjusted to the closest point in
the available media.
Seems like a good choice.
Post by Magnus Westerlund
s3.1, para 3: Clearly there won't be any smaller type paras in the
ASCII version.. is there a PDF version that actually has smaller type?
The one I get from the repository doesn't seem to have any smaller type
paras.
I removed the "small type" as this is a remains from when the draft was
produced using LaTex and a PDF version was produced.
Fine.
Post by Magnus Westerlund
s4.4: An external reference to the relevant Society of Motion Picture
and Television Engineers standard (probably SMPTE 12M) ought to be
included to define things like "SMPTE 30 drop". [Aside: 29.97 frames
per second?? Must be something to do with Never Twice the Same Color.
Oh, well, a little research job for whan I am really bored.]
Yes, it is ST 12M-1 2008 that appears to be the relevant reference. Yes,
SMPTE 30 drop is a NTSC thing.
:-)
Post by Magnus Westerlund
s4.9.1: There seems to be some confusion in this section between the
values from the Seek-Style header and the values from the
Media-Properties random access property. The section says the values
are from Seek-Style but they are actually from the random access
property. Presumably there was some intention to interelate the media
capabilities and the play event policies? Further this section has
Random Access, Conditional Random Access, Return to Start and No
Seeking. This doesn't match exactly with either Seek-Style (RAP, CoRAP,
First-Prior and Next) or Media-Properties (Random-Access, Beginning-Only
and No-Seeking).
Yes, this was confused. Actual the Media-Properties headers values are a
distinct set. Then if doing random access then the Seek-Style policies
4.9.1. Random Access and Seeking
Random Access is the ability to specify and get media delivered
from any point inside the content, an operation called seeking. The
^^^^^^^^^^^^^^^^^^^^^
Try: starting from any time instant within
Post by Magnus Westerlund
Media-Properties header will indicate the general capability for a
media resource to perform random access. If random access is
possible the actual behavior policy when seeking can be controlled
using the Seek-Style header (Section 18.45).
Random-Access: The media is seekable to any out of a large number of
points within the media. Due to media encoding limitations, a
particular point may not be reachable, but seeking to a point
close by is enabled. A floating point number of seconds may be
provided to express the worst case distance between random access
points.
Beginning-Only: Seeking is only possible to the beginning of the
content.
No-seeking: Seeking is not possible at all.
Generally fine - small suggestion above.
Post by Magnus Westerlund
s4.9.x: It would be desirable to use the parameter names in the same
form as they appear in s18 (e.g., Random-Access instead of Random
Access, No-Seeking instead of No seeking) both in the definitions
(s4.9.1 - s4.9.4) and the mapping (s4.9.5).
Yes, that is has been addressed.
OK
Post by Magnus Westerlund
ss4.4/4.5/4.6: If I read the ABNF in s20.2.1 correctly, the unqualified
values "smpte", "npt" and "clock" are valid in the Range parameter.
What is the meaning of such an unqualified value?
You are correct about that the basic definition in ABNF allows for
It MAY be
included in GET_PARAMETER requests from the client to the server with
only a Range format and no value to request the current media
position, whether the session is in Play or Ready state in the
included format.
Two points:
- A suggestion: Make ss4.4/4.5/4.6 into subsections of a new s4.4. Add
a bit of text in the new s4.4 saying that the range specifiers are used
in the RANGE header and pointing to s18.38 for the unqualified use.
(consistent with s2.7 which gives usage).
- An issue I hadn't spotted: I haven't checked but are the unqualified
values allowed in the SDP extension case (s20.3)?
Post by Magnus Westerlund
s5: It would be sensible to note that the ABNF fragments in s5 and the
following sections match with the full syntax productions in s20.
I have added a note, but they are in fact equivalent, but not identical.
Thus I make it clear that that this is for information and the formal is
in section 20.2.2.
OK
Post by Magnus Westerlund
Table 3: Proxy-Authorization (Section 18.34) doesn't appear in any of
the various header categorization tables [I must have better things to
do than checking they were all there :-( ]. I think it belongs here.
Sorry, for not having found this myself before. You noticing it missing,
was actually a larger inconsistency issue. It was missing in the ABNF also.
(I think I noted that later).
Post by Magnus Westerlund
I have spent quite some time now to ensure that the ABNF, the tables in
Section 6-8 and the header description now align as they should
regarding category.
Yes.. tedious job as I found out! Good!
Post by Magnus Westerlund
s8.1.1, code 505: HTTP code 505 is explicitly '*HTTP* version not
supported' - should there really be a separate code for 'RTSP version
not supported'?
Yes, but the import of HTTP response codes are their meaning not there
exact definition. Thus 505 is RTSP version not supported as listed in
table. That is also what section 17.5.6 defines it as.
I won't push this one.
Post by Magnus Westerlund
s9: Is it deliberately left vague as to whether other message types
might have message bodies?
This is unnecessary vague. In attempt to clarify this I have proposed
The SET_PARAMETER and GET_PARAMETER request and response, and DESCRIBE
response is by this specification defined that they MAY have a message
body and its purpose. All 4xx and 5xx responses MAY also have a message
body to carry additional response information. A message body MAY occur
on any RTSP 2.0 request or response, but the content of the message body
MAY be ignored. Extensions to this specification can specify the purpose
and content of message bodies, including requireing their inclusion.
Seems sensible. Editorial update:
The SET_PARAMETER and GET_PARAMETER requests and responses, and the
DESCRIBE response as defined by this specification MAY have a message
body; the purpose of the message body is defined in each case. All 4xx
and 5xx responses MAY also have a message body to carry additional
response information. Generally a message body MAY be attached to any
RTSP 2.0 request or response, but the content of the message body
MAY be ignored by the receiver. Extensions to this specification can
specify the purpose and content of message bodies, including requiring
their inclusion.
Post by Magnus Westerlund
s10.2, para 6 and following note: I can't see that the note following
para 6 can be justified: since the restriction on multiple connections
from a client to a server is only a SHOULD, an interoperable server MUST
be capable of handling multiple connections from a client unless the
server can explicitly send back a TOO MANY CONNECTIONS status.
See separate email
Should I have had this already?
Post by Magnus Westerlund
s10.6: RFC 3986 has capability for dealing with IP versions beyond 6...
should these be carried over into RTSP? The IANA registry says they are.
I am uncertain what you want here? Yes, the URI format allows for future
definitions of literal IP address versions. However, RTSP does contain
explicit IPv4 and IPv6 address fields that aren't URIs. Thus, future IP
versions will require some extension definition to function.
Perhaps an excess of zeal on my behalf. Perhaps a (non-normative) note
saying what you just wrote: 'Although the general URI format envisages
potential future new versions of the literal IP address, usage of any
such new version would require other modifications to the RTSP
specofication (e.g., ...[any relevant section(s)]).'
Post by Magnus Westerlund
s10.7, para 3: Anti-synchronization measures such as are RECOMMENDED
here are usually MANDATORY. (Also applies to wait timer in last para of
this section).
Yes, I agree that they usually are. I personally have no issues making
them required. I think the Recommended formulation is really one of
these cases, do this or something even better or you will hang yourself
to be a bit blunt.
An RTSP server or proxy in an overload situation must select the value
of the Retry-After header carefully and bearing in mind its current load
situation. It is REQUIRED to increase the timeout period in proportion
to the current load on the server, i.e., an increasing workload should
result in an increased length of the indicated unavailability. It is
REQUIRED to not send the same value in the Retry-After header to all
requesting proxies and clients, but to add a variation to the mean value
of the Retry-After header.
Objections to this?
I was only really concerned about the variation. I would leave the 'how
much to increase' as a RECOMMENDED, but say there MUST be variation in
the retry values sent to different clients if theye are sent at all.
Post by Magnus Westerlund
s10.7, last para: Should the doubling of the wait timer have an upper limit?
Yes, I added an upper limit of 30 minutes. This is way beyond what any
human will accept, only robots will keep on going at this timeout value.
And I think that is large enough to avoid any issues.
Agreed
Post by Magnus Westerlund
I also propose to clarify the range for the variations and added the
classical 0.5 to 1.5 times the deterministic value.
Text proposal.
That timer MUST be doubled for each additional failure to connect or
receive response until the value exceeds 30 minutes when the timers
deterministic value may be set to 30 minutes. It is RECOMMENDED to not
^^^^^^^^^^^^^
base?
Post by Magnus Westerlund
set the same value in the timer for each scheduling, but instead to add
a variation to the mean value, resulting in picking a random value
within the range of 0.5 to 1.5 of the mean value.
s11, para 4: According to s22.1.3, play.basic, play.scale and play.speed
are 'defined' in this draft. The nearest thing to a definition of
play.basic that I can find is the last sentence of para 4 in this
section. I am not convinced that I could produce an interoperable
implementation of a server with this feature-tag with the one sentence
'definition'. References to where play.xxx are defined would be useful
(play.scale in s18.44, play.speed in s18.48).
Hmmm, the other feature-tags than play.basic are pretty straightforward
and well contained. play-basic is really a minimal RTSP server
implementation according to the whole spec for media playback.
This can probably be more clearly expressed somewhere, but it can't
really be enumerated. Then we are back to the issue we had with RFC 2326
minimal implementation list that was incomplete and lacked a lot of
things really necessary.
This issue still haven't resulted in any changes to our source.
Ah! I see I have (re-)opened a can of worms! One thought for providing
the proverbial larger can into which the worms can be stuffed back:

Define 'play.basic' as the default that you get back if none of the
others apply. How's that for weasel words!
Post by Magnus Westerlund
This results in the
receiver is learning the requester's feature support.
This results in the
receiver learning the requester's feature support
relevant to the specified resource.
[Note: I added 'specified resource' here and then thought about whether
this made any sense. It probably needs to be clearer what set of
features are included in the Supported list for both requester and
responder. Are they restricted to those relevant to the specified
resource that might of course be the whole server, proxy - or client?? -
in which case there isn't an issue, but it might be a specific
presentation - what happens then? Affects s13.1, para 3 also.]
Actually, I don't think it is specific to the media resource. The issue
with making it specific to a media resource is that a RTSP client needs
to be able to look into the future and supply an answer for a media
resource it may not yet know sufficient to provide a tailored response
for. I think it is simpler and better to provide general capabilities in
the supported header and then later determine how well they apply for
the media resource itself.
So maybe make it clear that feature support returned is just what the
responder can do generally and is not specific to the URI provided.

Either that or make the request valid only for non-specific URIs (i.e.
at the server/client level) if that is possible (not sure how that would
work for server asking client if that is allowed).
Post by Magnus Westerlund
We do have Media-Properties header to provide more details for what
specific media transformations a server can do when the support play.scale.
Right.


/Elwyn
Post by Magnus Westerlund
Cheers
Magnus Westerlund
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB | Phone +46 10 7148287
Färögatan 6 | Mobile +46 73 0949079
----------------------------------------------------------------------
_______________________________________________
Gen-art mailing list
https://www.ietf.org/mailman/listinfo/gen-art
Magnus Westerlund
2013-08-23 13:54:32 UTC
Permalink
Hi,

Now getting to implement your response in our source.

Some few additional comments or notes below.
Post by Elwyn Davies
Post by Magnus Westerlund
Elwyn,
Follow up on some of the nits that is not simply to implement or where I
disagree or want to provide feedback.
This email covers all issues up to and including Section 11. That is as
far as I have managed to process them yet. I will now handle over the
rest of this list to my co-authors.
ss4.4/4.5/4.6: If I read the ABNF in s20.2.1 correctly, the unqualified
values "smpte", "npt" and "clock" are valid in the Range parameter.
What is the meaning of such an unqualified value?
You are correct about that the basic definition in ABNF allows for
It MAY be
included in GET_PARAMETER requests from the client to the server with
only a Range format and no value to request the current media
position, whether the session is in Play or Ready state in the
included format.
- A suggestion: Make ss4.4/4.5/4.6 into subsections of a new s4.4. Add
a bit of text in the new s4.4 saying that the range specifiers are used
in the RANGE header and pointing to s18.38 for the unqualified use.
(consistent with s2.7 which gives usage).
- An issue I hadn't spotted: I haven't checked but are the unqualified
values allowed in the SDP extension case (s20.3)?
I think your suggestion is a good one and I have written such a section,
initial proposal below:

4.4. Media Time Formats

RTSP currently supports three different media time formats defined
below. Additional time formats may be specified in the future.
These time formats can be used with the Range header (Section 18.38)
to request playback and specify at which media position protocol
requests actually will or has taken place. They are also used in
description of the media's properties using the Media-Range header
(Section 18.29). The format identifier only are used in Accept-
Ranges header (Section 18.5) to declare supported time formats and
also in the Range header (Section 18.38) to request the time format
used in the response.

4.4.1. SMPTE Relative Timestamps


Regarding the SDP a=range attribute. The ABNF allows the unqualified
usage. The textual specification of a=range attribute in D.1.6 is silent
on unqualified usage.

The only usage of unqualified usage in a=range would be to indicate that
although this media has unknown or time-progressing properties it does
support the time formats for the a=range with unqualified values that
has been included.
Post by Elwyn Davies
Post by Magnus Westerlund
s10.2, para 6 and following note: I can't see that the note following
para 6 can be justified: since the restriction on multiple connections
from a client to a server is only a SHOULD, an interoperable server MUST
be capable of handling multiple connections from a client unless the
server can explicitly send back a TOO MANY CONNECTIONS status.
See separate email
Should I have had this already?
It was sent to the MMUSIC WG mailing list on the 24th of June. I have
forwarded if to you personally.
Post by Elwyn Davies
Post by Magnus Westerlund
s10.6: RFC 3986 has capability for dealing with IP versions beyond 6...
should these be carried over into RTSP? The IANA registry says they are.
I am uncertain what you want here? Yes, the URI format allows for future
definitions of literal IP address versions. However, RTSP does contain
explicit IPv4 and IPv6 address fields that aren't URIs. Thus, future IP
versions will require some extension definition to function.
Perhaps an excess of zeal on my behalf. Perhaps a (non-normative) note
saying what you just wrote: 'Although the general URI format envisages
potential future new versions of the literal IP address, usage of any
such new version would require other modifications to the RTSP
specofication (e.g., ...[any relevant section(s)]).'
Yes, I added such text.
Post by Elwyn Davies
Post by Magnus Westerlund
s10.7, last para: Should the doubling of the wait timer have an upper limit?
Yes, I added an upper limit of 30 minutes. This is way beyond what any
human will accept, only robots will keep on going at this timeout value.
And I think that is large enough to avoid any issues.
Agreed
Post by Magnus Westerlund
I also propose to clarify the range for the variations and added the
classical 0.5 to 1.5 times the deterministic value.
Text proposal.
That timer MUST be doubled for each additional failure to connect or
receive response until the value exceeds 30 minutes when the timers
deterministic value may be set to 30 minutes. It is RECOMMENDED to not
^^^^^^^^^^^^^
base?
Post by Magnus Westerlund
set the same value in the timer for each scheduling, but instead to add
a variation to the mean value, resulting in picking a random value
within the range of 0.5 to 1.5 of the mean value.
This has gotten changed a bit more and currently reads:

A more complex case may arise when a load balancing RTSP proxy is in
use, i.e., where an RTSP proxy is used to select amongst a set of RTSP
servers to handle the requests, or when multiple server addresses are
available for a given server name. The proxy or client may receive a 503
(Service Unavailable) or 553 (Proxy Unavailable) from one of its RTSP
servers or proxies, or a TCP timeout (if the server is even unable to
handle the request message). The proxy or client simply retries the
other addresses or configured proxies, but may also receive a 503
(Service Unavailable) or 553 (Proxy Unavailable) response or TCP
timeouts from those addresses. In such a situation, where none of the
RTSP servers/proxies/addresses can handle the request, the RTSP agent
has to wait before it can send any new requests to the RTSP server. Any
additional request to a specific address MUST be delayed according to
the Retry-After headers received. For addresses where no response was
received or TCP timeout occurred, an initial wait timer SHOULD be set to
5 seconds. That timer MUST be doubled for each additional failure to
connect or receive response until the value exceeds 30 minutes when the
timers mean value may be set to 30 minutes. It is REQUIRED to not set
the same value in the timer for each scheduling, but instead to add a
variation to the mean value, resulting in picking a random value within
the range of 0.5 to 1.5 of the mean value.
Post by Elwyn Davies
Post by Magnus Westerlund
s11, para 4: According to s22.1.3, play.basic, play.scale and play.speed
are 'defined' in this draft. The nearest thing to a definition of
play.basic that I can find is the last sentence of para 4 in this
section. I am not convinced that I could produce an interoperable
implementation of a server with this feature-tag with the one sentence
'definition'. References to where play.xxx are defined would be useful
(play.scale in s18.44, play.speed in s18.48).
Hmmm, the other feature-tags than play.basic are pretty straightforward
and well contained. play-basic is really a minimal RTSP server
implementation according to the whole spec for media playback.
This can probably be more clearly expressed somewhere, but it can't
really be enumerated. Then we are back to the issue we had with RFC 2326
minimal implementation list that was incomplete and lacked a lot of
things really necessary.
This issue still haven't resulted in any changes to our source.
Ah! I see I have (re-)opened a can of worms! One thought for providing
Define 'play.basic' as the default that you get back if none of the
others apply. How's that for weasel words!
After my leave I have written a bit of definition for play.basic:

11.1. Feature Tag: play.basic

The play.basic feature tag represents an RTSP implementation
according to all normative RTSP protocol features specified in this
specification. This specification is both a RTSP core specification
as well intended to enable setup and control of playback of media.
Thus following all normative parts in the main sections (the ones
with numbers), not the appendices (starting with letters), unless
explicitly specified in a main section for being a required appendix.

Note: This feature tag does not mandate any media delivery
protocol, such as RTP.

In RTSP 1.0 there was a minimal implementation section. However,
that was not consistent with the rest of the specification. So
rather than making an attempt to explicitly enumerate the features
for play.basic this specification have to be read in completeness
and the necessary features normatively defined as being required
are included.
Post by Elwyn Davies
Post by Magnus Westerlund
This results in the
receiver is learning the requester's feature support.
This results in the
receiver learning the requester's feature support
relevant to the specified resource.
[Note: I added 'specified resource' here and then thought about whether
this made any sense. It probably needs to be clearer what set of
features are included in the Supported list for both requester and
responder. Are they restricted to those relevant to the specified
resource that might of course be the whole server, proxy - or client?? -
in which case there isn't an issue, but it might be a specific
presentation - what happens then? Affects s13.1, para 3 also.]
Actually, I don't think it is specific to the media resource. The issue
with making it specific to a media resource is that a RTSP client needs
to be able to look into the future and supply an answer for a media
resource it may not yet know sufficient to provide a tailored response
for. I think it is simpler and better to provide general capabilities in
the supported header and then later determine how well they apply for
the media resource itself.
So maybe make it clear that feature support returned is just what the
responder can do generally and is not specific to the URI provided.
Yes, I have tried to make it clear that it is not resource specific.

Supported: This header is used to determine the complete set of
functionality that both client and server have in general and
is not dependent on specific resource. The intended usage is
to determine before one needs to use a functionality that it is
supported. It can be used in any method, but OPTIONS is the
most suitable one as it at the same time determines all methods
that are implemented. When sending a request the requester
declares all its capabilities by including all supported
feature-tags. This results in the receiver is learning the
requester's feature support. The receiver then includes its
set of features in the response.

Proxy-Supported: This header is used similarly to the Supported
header, but instead of giving the supported functionality of
the client or server it provides both the requester and the
responder a view of the common functionality supported in
general by all members of the proxy chain between the two
supports and not dependent on the resource. Proxies are
required to add this header whenever the Supported header is
present, but proxies may also add it independently of the
requester.

I also added variations of this sentence to the Supported and
Proxy-Supported headers description:

These feature tags are the ones the server or client support in general,
and is not specific to the request resource.
Post by Elwyn Davies
Either that or make the request valid only for non-specific URIs (i.e.
at the server/client level) if that is possible (not sure how that would
work for server asking client if that is allowed).
Doesn't really work as supported is intended to be possible to add to
any request to determine the functionality supported by the replying agent.

cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB | Phone +46 10 7148287
Färögatan 6 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: ***@ericsson.com
----------------------------------------------------------------------
Magnus Westerlund
2013-08-23 08:52:15 UTC
Permalink
Hi,

Continuing with the issues after Section 11.

Once more a big thanks for the work you have put into this. It is really
helpful, both from clarity point of view and finding some actual
protocol issues.
Upon receipt of the PLAY request, the server MUST position the normal
play time to the beginning of the range specified in the received
Range header
Should this mention the caveat that (if I understood earlier statements
correctly) the server may not be able to deliver exactly on this MUST
and then sets it the nearest it can manage? This is borne out by the
example later in this section where the server sets the start point back
10ms (and says so), etc. Seek-Style affects the interpreation of MUST!
Yes, I have added that this needs to happen ".. within the limits of the
media resource and in accordance with the Seek-Style header (Section
X.Y) ..".
s13.4.4/.5/.7/.8: In these sections the Media-Property random access
property is stated as being required to be Random-Access. Is
Conditional Random Access a possible value for this property? The
confusion in s4.9.1 does not allow me to conclude that this shouldn't be
a value for the property (sorry for the double negative but this looks a
bit confused).
These section lists the Media-Properties for the media resource one
request delivery for. Thus from a PLAY request perspective using a
Seek-Style: CoRAP header is fine for the ones that has Random Access
property as Random-Access in these section.
s13.5.1: Apologies if this question is stupid - I am not a media stream
wxpert. Suppose we have an aggregated stream with (say) a number of
recorded media items making up the aggregate. The client sets it on to
play to the end. What happens if not all the streams end at the same
time? Do we get PLAY_NOTIFY End-of-Stream notifications for each
individual stream as it ends or just one when the complete aggregate
ends?
Not at all a stupid question. This should have been clearly specified
for all usages of PLAY_NOTIFY in regards to aggregated sessions. Thus I
have added both a general requirement on PLAY_NOTIFY level:

PLAY_NOTIFY requests MAY use both aggregate control URI and individual
media resource URIs depending on scope of the notification. This scope
may have important distinctions for aggregated sessions, and each reason
for a PLAY_NOTIFY request needs to specify the interpretation and if
aggregated control URIs or individual URIs may be used in requests.

And specified the following for end-of-stream:

For RTSP Session where media resources under aggregated control the
media resources will normally end at approximately the same time,
although some small differences may exist, on the scale of a few
hundred of milliseconds. In those cases a RTSP session under aggregated
control SHOULD send only a single PLAY_NOTIFY request. By using the
aggregate control URI in the PLAY_NOTIFY request the RTSP server
indicates that this applies to all media resources within the session.
In cases RTP is used for media delivery corresponding RTP-Info needs to
be included for all media resources. In cases where one or more media
resource has significantly shorter duration than some other resources in
the aggregated session the server MAY send end-of-stream notifications
using individual media resource URIs to indicate to agents that there
will be no more media for this particular media resource related to the
current active PLAY request. In such cases when the remaining media
resources comes to end-of-stream they MUST send a PLAY_NOTIFY request
using the aggregate control URI to indicate that no more resources remains.

And the following for Media-Properties-Update

The Media-Properties header has session scope, thus for aggregated
sessions the PLAY_NOTIFY request MUST be using the aggregated control URI.

And for Scale-Change

PLAY_NOTIFY requests for aggregated sessions MUST use the aggregated
control URI in the request. The scale change for any aggregated session
do apply to all media streams part of the aggregate.
that changes the basis for making
estimates on how the media range progress.
I can't parse the last part of this and I am not sure what it should be.
I hope this is better

This notification MUST be sent for media that are Time-Progressing every
time an event happens that changes the basis for making estimates on how
the available for play-back media range will progress with wall clock time.
s14: What happens if the upper layer PDU is longer than (2^16 - 1)?
I have added this note:

Note that this mechanism does not support larger PDUs than 65535 bytes,
which is the same that regular IPv4 and IPv6 is capable. If the media
delivery protocol intended to be used has larger PDUs than that, the
definition of such mechanisms usage of this mechanism will require the
definition of a PDU fragmentation mechanism.
s18.10, private para: Is there any way in RTSP for the cache to know
whether this is a private cache for the user that should cache this
content?
To my understanding this is something the cache itself knows through its
behavior and deployment.
s18.10, last para: I am not absolutely certain, but I think this para
is specific to the max-age cache type rather than being generic as
implied by the indentation. [If so use the <vspace blankLines=1/> trick
to provide a pseudo-paragraph break]
Yes, you are correct. I did the equally easy choice for hanging lists to
simply make a new paragraph without any paragraph text.
s18.14: Consider adding the 'identity' value explicitly to the ABNF.
If I understand you correctly what you are requesting is that "identity"
is listed as an construct in the content-coding ABNF construction that
are used by Accept-Encoding and Content-Encoding headers.

Accept-Encoding = "Accept-Encoding" HCOLON
[ encoding *(COMMA encoding) ]
encoding = codings [SEMI accept-params]
codings = content-coding / "*"
content-coding = "identity" / token
Content-Encoding = "Content-Encoding" HCOLON
content-coding *(COMMA content-coding)
s18.29, para 2: Are (or should there be) constraints on the ordering of
media ranges for a non-continuous media stream? It would probably make
the client's job easier if they were in incresing order.
This is a interesting question. If one simply expresses what pieces of
media that are currently available then using a requirement that the
first ranges end-time must be prior any of the subsequent ranges start
times would work. However, my head gets stuck on considering when
desired playback is non linear. But that is probably a higher function
question.

So a possible addition after this existing sentence:

The server MAY include more than one range specification of any given
time format to indicate media that has non-continuous range.

would be:
The range specifications shall be ordered with the range with the lowest
value or earliest start time first, followed by ranges with increasingly
higher values or later start time.

Comments on this?
s18.41: It appears from a literal interpretation (the third sentence is
an unqualified MUST) that the responder has to respond with error code
551 and an (empty?) list of Unsupported features if it actually does
support all the features. I suspect this is not what is wanted.
Correct, reformulated proposal is:

In case any of the feature-tags listed by the Require header are not
supported by the server or client receiving the request, it MUST respond
to the request using the error code 551 (Option Not Supported) and
include the Unsupported header listing those feature-tags which are NOT
supported.
s18.45, para 4: Harummph! Political Correctness strikes again. Every
protocol should (and probably does) have a CRAP policy. ;-)
Yes, the lower case o is silent here ;-).
s18.52, 'setup' section: There seems to be some inconsistency in the
spcification of the 'active/passive/actpass' values. a) Is there some
reason for specifying them in square brackets?
Not, that I can remember. Removing both brackets and quotes.

b) should they say
["active:"] or ["active":] - both formats are used? The ABNF has the
plain words with no brackets or quotes.
The later would be correct, but now it will only say
active: <description>

The ABNF is clear that it will be
RTP/SAVPF/TCP;unicast;setup=active;connection=new
s/Clients use the setup parameter/Clients use the connection parameter/
(I assume).
Had to tweak that sentence a bit more:

Clients use the connection parameter in a transport specification part
of the Transport header in a SETUP request, to indicate the client's
preference for either reusing an existing connection between client and
server (in which case the client sets the "connection" parameter to
"existing"), or requesting the creation of a new connection between
client and server (in which cast the client sets the "connection"
parameter to "new").
s21.1, transfer of sensitive info: Is there an equivalent of the Referer
header in RTSP? Not sure there is but it would be good to explain one
way or the other (either there isn't one so it's less of a problem or
this is the equivalent...)
Yes, the Referer header is retained also in RTSP.
s21.1, DNS Spoofing: Presumably RTSP will interact significantly with
content delivery networks. Some of these work by DNS 'spoofing' that
was in its infancy when RFC 2616 was published. Are there any other
issues that come out of the greater prevalence of CDNs since 1999?
I have no experience with large scale deployment of RTSP. To my
knowledge there hasn't been the same development with CDNs for RTSP as
HTTP. This I think is dependent on several factors. One has been the
issues with deploying RTSP on global scale due to NAT traversal etc,
instead progressive download and HTTP adaptive streaming has mostly
taken this market. Thus most large scale deployments has been in
contexts within single operators providing Video On Demand services etc.

Thus, I don't really know of any additional issues around this.
s21.1, Session Hijacking: The last part of this is written so that it
appears to mandate authentication in all cases. As far as I understand
it is up to the client to decide if it needs authentication etc and some
content will be offered on unsecured URIs. I think this needs to be
clearer that authentication will mitigate the problem but whether it is
done is up to the client if the server doesn't care.
Is this better?

Another choice for preventing session hijacking is to use client
authentication and only allow the authenticated client creating the
session to access that session.
s21.1, Persistently suspicious behaviour: There seems to be a mismatch
between the title (persistently..) and the first sentence (a single
instance). Do we have examples of the sort of security risk which is
supposed to be met with a 403 response the first time?
Yes, it is a bit inconsistent. I propose:

Suspicious behavior: RTSP servers upon detecting intances of behavior
which is deemed a security risk SHOULD return error code 403
(Forbidden). RTSP servers SHOULD also be aware of attempts to probe the
server for weaknesses and entry points and MAY arbitrarily disconnect
and ignore further requests from clients which are deemed to be in
violation of local security policy.
Some of the above threats are such that
the implementation of the RTSP functionality itself needs to consider
which policy and strategy it uses to mitigate them.
It strikes me that this is not very helpful to a prospective
implementer. The point of this section is at least in part to provide
that policy and strategy. I am not quite sure how to rewrite this (or
if indeed other people think it does need rewriting).
No, it is not helpful in other ways then, you need to think about this
and consider what mitigations you think should be implemented and how
that affects your implementation design.

For now I am leaving this as it is.
s22.3: The rules about allocating in the sections above x50 should be
explained here (see s8.1.1). The numbers below x50 in each section
should be marked as a special category of reserved so they are only
allocated to HTTP analogues. Is an experimental/private segment in each
category desirable?
Yes I think adding something like the below to at least make clear the
intention that RTSP specific status codes should first be registered in
the x50-x99 range.

New RTSP functionality requiring Status Codes should first be registered
in the range x50-x99. Only when the range is full should registrations
be done in the x00-x49 range, unless it is to adopt an HTTP extension
also to RTSP. The reason is to enable any HTTP extension to be adopted
to RTSP without needing to renumber any related status codes.


Regarding experimental and private I am very torn about such range.
Unless someone else in the WG thinks this is worth the work I will leave
it out.
s22.9: Being allowed to register new Range header formats will currently
be restricted to times specified by NPT, SMPTE or UTC because no
registry is defined for Accept-Ranges. Is this what is intended?
No, the intention is that Range header format registry is shared between
Range and Accept-Ranges. However, I see the description is not clear on
this and needs to be amended.

I have sent a separate email on this.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB | Phone +46 10 7148287
Färögatan 6 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: ***@ericsson.com
----------------------------------------------------------------------
Loading...