Subject: Re: [MMUSIC] WGLC on RTSP 2.0 - draft-ietf-mmusic-rfc2326bis-23.txt

From: "Martin Stiemerling" <[email-masked]>
Date: Mon, 17 May 2010 15:17:35 +0200

Wolfgang, all,

Here is are replies, all marked with [MS] (see below).

Thanks a lot for the detailed review!!

  Martin

General:
Proxies and Via : really necessary? Via is not secure

[MS] waiting for a reply from the WG.

Timer handling looks underspecified.
[MS] can you hint what part you're referring to?

Appendix E, RTSP Use Cases
Several of the described use cases require RTSP functionalities not specified in the draft.
How is this useful to implementors?

[MS] This section intends to give guidance for the implementers how RTSP
interworks with other protocols or functionality. 

GET/SET_PARAMETER
shouldn't there be a list of supported parameters which an agent understands?

There is a list for GET_PARAMETER. However, this GET/SET_PARAMETER list is left open, as the usage of this seems to be very implementation specific. However, I'm happy to add text here, if the WG can come up with a list.

Page 10 
"RTSP 2.0 is an replacement"
should read
"RTSP 2.0 is a replacement"

[MS] Fixed.

"Then comes the actual protocol specification"
klingt sehr deutsch, besser vielleicht
"It is followed by the actual protocol specification."

[MS] Fixed.

(Page 24)
"..maintains an explicit state machine (see Appendix A) "
should read
"..maintains an explicit state machine (see Appendix B) "

[MS] Fixed.

Page 25 
Use case for rtspu? What is an implementation supposed to do with it?

[MS] there is actually no use case, other than "is defined here to register and reserve the URI scheme that is defined in RTSP 1.0". However, the second questions hits the point. I have added text to Section 4.2. "RTSP IRI and URI", saying that the server must repsonse with a "501 Not Implemented":
" A RTSP server MUST response with with an error code indicating the "rtspu" scheme is not implemented (501) to a request that carries a "rtspu" URI scheme"

Page 26
host identity - is this the DNS name or one of the IP addresses associated with a DNS host name?

[MS] can be both. do we need to clarify this?

Page 31 looks ok, uses different terms than 16.45 RAP/CoRAP 

[MS]linked  both sections, as they are too far apart from each other, i.e., hard to figure out that they are linked.

Page 37 
"General headers are headers that may be used in both request and responses."
should read
"General headers are headers that may be used in both requests and responses."

[MS] Fixed.

Page 49 
10.1
"When RTSP messages are transmitted using reliable transport protocols.."
doesn't the previous section state that RTSP must use reliable transport?

[MS] seems to be a left-over from RTSP 1.0. I discussed this text with Magnus some time ago and we agreed to keep this text - just for the case somebody in the future (not me or Magnus) will extend RTSP 2.0 with unreliable transport.

Page 52 
10.3 Closing Connections
Maybe this section should define a timeout for incomplete RTSP
messages. An attacker could try to keep the sesion open by sending an
incomplete message.

[MS] added text at the end of this section:
"The server MAY close a connection if he receives an incomplete message and if the message is not completed within a reasonable amount of time.  It is RECOMMENDED that the server waits at least 1 second for the completion of a message or for the next part of the message to arrive (which is an indication that the transport and the client are still alive)."

Page 53
Behaviour described in 10.4 is missing from state machine, appendix B

[MS] Added a link to 10.4 in appendix B.4, 2nd para, with text:
"For any request message that cannot be responded to within the time defined in Section 10.4  (Timing Out Connections and RTSP Messages), a 100 response must be sent. "

Page 62
"Using SETUP to add media to an existing sessionn when the session is in PLAY state, is unspecified."
What is the implementation supposed to do?

[MS] This has also been left open for future extensions. We do not have yet any use case for this, but there seem to be some implementations that can do that. However, there is nobody yet that has written up the semantics for this.

Page 70
 C->S line User-Agent?

[MS] Fixed.

Page 87 
"..method to use in request sent for .."
should read
"..method to use in a request sent for .."
or should read
"..method to use in requests sent for .."

[MS] Fixed w/ 1st option.

Page 93 
Is '100 Continue' really useful with reliable transport?

[MS] is used to notify the client that the server is acting on the request message. the text itself is an adapted copy from the http1.1 status codes.

15.5.4
Response 503 has caused some headache in SIP. Some implementors tried the next IP address as returned in the DNS answer, some just gave up. 

[MS] Does SIP also use this mechanism (described in 15.5.4):
"If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response. "

15.5.5
If a proxy keeps state, why do we have Via-headers?

[MS] Posted again to the list, as separated thread, w/o response - yet. I'm also in favour of dropping via, but let's see what others say.

Page 121 
The example seems to suggests that DER Certs need to start at 32 bit
boundaries. If this is not the case, the example should be changed in
a way that the first certificate starts at some odd position.

[MS] IMHO no need for 32bits boundary, but I personally may be wrong.

Page 127 
16.23
"The If-Match request-header field is especially useful for ensuring the
integrity of the presentation description, in both the case where it is
fetched via means external to RTSP (such as HTTP), or in the case where
the server implementation is guaranteeing the integrity of the description
between the time of the DESCRIBE message and the SETUP message."

Convoluted and confusing. Maybe there should be a separate description
of the precondition mechanism, which could be referenced from here and from other header descriptions.

[MS1] I have rewritten the text a bit:
"The If-Match request-header field is especially useful for ensuring the integrity of the presentation description, independent of how the presentation description was received. The presentation description can be fetched via means external to RTSP (such as HTTP) or via the DESCRIBE message and the SETUP message. In the case of retrieving the presentation description via RTSP, the server implementation is guaranteeing the integrity of the description between the time of the DESCRIBE message and the SETUP message. By including the MTag given in or with the session description in a If-Match header part of the SETUP request, the client ensures that resources set up are matching the description. A SETUP request with the If-Match header for which the MTag validation check fails, MUST response using 412 (Precondition Failed)."

[MS2] Is the text in 15.4.12 sufficient to understand (also for referring to it)?

Page 140 
compare with RfC 5390; what is the implementation supposed to do if Retry-After is missing?

[MS1] RFC 5390 vs. RTSP (in my understanding): RFC 5390 seems to argue for all service at the particular network element. while Retry-After in RTSP refers to the current session and not the whole RTSP server.
[MS2]If header is missing: see 15.5.4. 

Page 144 Check Capitalization of Server and Client
A Server that .. A Client receiving

[MS] Fixed.

Page 147 
Speed .. overlap with Scale header?

[MS] see this Section for a clarification of the issue:
2.5.1.  Media Delivery Manipulations

Page 149
16.51 Timestamp

[..] It also resolves retransmission ambiguities for unreliable transport of RTSP
compare with
2. Protocol Overview
[..] RTSP messages are sent over a reliable transport protocol

[MS] left-over with a bet to the future that somebody will come up with unreliable transport ;)

16.52 Transport

Media transport or signalling transport?
If media, isn't this covered by SDP?

[MS] It's the media transport. RTSP is made for deployments that are not using SDP for the presentation description, thus there is the need that RTSP can carry basic media transport information. The text hints to this and also SDP:  "It sets those values not already determined by a presentation description. "

Page 152
"Responses to request including.."
should read
"Responses to requests including.."

[MS] Fixed.

"src_addr .. Protocol/Profile/Lower Transport "
capitalization?

[MS] Fixed.

Page 153 
"..both end-parties.." -> "..both parties.."

[MS] end-parties seems to be right, as it is between client and server, and not involving a proxy.

Page 160 
"This proxy type can also accept unknown methods as it doesn't interfere
with the clients requests."

should read

"This proxy type can also accept unknown methods as it doesn't interfere
with the clients' requests."

[MS] Fixed.

"However, that trust model may not be suitable for all type of deployment,
and instead secured sessions do by-pass of the proxies."

should read

"However, that trust model may not be suitable for all types of deployment.
In those cases, secured sessions by-pass the proxies."

[MS] Fixed.

"Thus resulting in blocking further development of RTSP and its usage."

sounds strange. How about

"This would impede RTSP's future development."

[MS] Fixed.

17.1

"Most type of proxies will need to implement any new method to operate
correct in the presence of that extension."

should read

"Most types of proxies will need to implement any new method to operate
correctly in the presence of that extension."

[MS] Fixed.

"New headers will be possible to introduce without being blocked by
proxies not yet updated."

sounds strange, how about

"New headers can be introduced and will not be blocked by older proxies."

[MS] Fixed.

"The transport header and its parameters also shows that headers that
are extensible and requires correct interpretation in the proxy also
requires handling rules."

should read

"The transport header and its parameters also show that headers that
are extensible and require correct interpretation in the proxy also
require handling rules."

[MS] Fixed.

"When defining a new RTSP header it needs to be considered if RTSP
proxies are required to understand them to achieve correct functionality."

repetitive, this was mentioned in the previous paragraph. I'd remove this sentence and
change the next to:
"Whether a proxy needs to understand a header is not easy to determine,
as they serve a broad variety of functions."

[MS] Fixed.

Page 175 
"An complete extra message exchange between the proxy connecting to the
next hop and the client results because of the process for approval for
each hop."
should read
"A complete extra message exchange between the proxy connecting to the
next hop and the client results because of the process for approval for
each hop."

[MS] Fixed.

"However, after the first message exchange the remaining message should
not be delayed, if each message contains the chain of proxies that the
requester accepts.
maybe
"However, if each message contains the chain of proxies that the requester
accepts, the remaining message exchange should not be delayed."

[MS] Fixed.

Page 181 looks ok, but needs implementation attempt to really verify it

[MS] Yes, as many parts, i.e., there is a need for implementation feedback for quite a number of parts...

Page 194 
via-branch?? Purpose??

[MS] good question...I will need to check this again.

Page 195
Could not find [H15]. Are the bibliographical references missing from the document?

[MS] [HX] denotes a reference to HTTP1.1, Section 15, RFC 2616(RTSP internal notation, see Section 3, right at the beginning)

Page 201 
"The reason is that new methods may radically change the protocols behavior and purpose."
should read
"The reason is that new methods may radically change the protocol's behavior and purpose."

[MS] Fixed.

"A clear specification on what action and response a request with the method will result in."
Not clear to me what that sentence says.
Maybe
"A clear specification what a request using the method does and what responses are expected."

[MS] Fixed. Text was really confusing...

Maybe the enumeration should use complete sentences instead of fragments.

Page 235 

HTTP example looks wrong (<href "Streamed Live Music ..), isn't href an attribute, not an element?

[MS] broken indeed. Fixed:
"        <a href "rtsp://live.example.com/concert/audio"> 
           Streamed Live Music performance </a>           "

Page 238 
"For each state there exist a table which shows which requests and events
that are allowed and if they will result in a state change."

should read

"For each state there exists a table which shows which requests and events
are allowed and whether they will result in a state change."

[MS] Fixed.

"Init: Initial state no session exist."

should read

"Init: Initial state no session exists."

[MS] Fixed.

Page 244 
"The Play state table is the largest." Why is this relevant?

[MS] removed. Fixed.

"The table contains an number of requests that has presentation URI as a
prerequisite on the Request-URI, this is due to the exclusion of
non-aggregated stream control in sessions with more than one media stream."

I don't understand this grammatically dubious sentence.
The term 'presentation URI' is mentioned several times, but never really explained in the document.

[MS] me neither. presentation URI is discribed under Aggregate URI in the terminology.
Here is the changed text:
"The Play state table, see Table 16  (State: Play), contains a number of requests that needs a presentation URI (labeled as Prs URI) to work on (i.e., the presentation URI has to be used as the Request-URI). This is due to the exclusion of non-aggregated stream control in sessions with more than one media stream. "

"It may appear that there exist an automatic transitions in "RedP reached"
and "PP reached", however, they are requested and acknowledge before they take place."

should read

"It may appear that there exist automatic transitions in "RedP reached"
and "PP reached". However, they are requested and acknowledged before they take place."

[MS] Fixed.

"If the client sends request close in time to these transitions it needs
to be prepared for getting error message as the state may or may not have changed."

should read

"If the client sends a request close in time to these transitions it needs
to be prepared for getting error message, as the state may or may not have changed."

[MS] Fixed.

Page 246 
how many ways to express the media ip address do we really need? SDP m-line? Transport header?

Both ways are needed, as RTSP may or may not be used with SDP.

Page 279 
"request for pipelinig .."
should read
"request for pipelining .."

[email-masked]

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Wolfgang Beck
> Sent: Saturday, March 27, 2010 3:36 PM
> To: [email-masked]
> Subject: Re: [MMUSIC] WGLC on RTSP 2.0 - draft-ietf-mmusic-rfc2326bis-
> 23.txt
> 
> Here's my first batch of remarks:

---

From: Tom Taylor <[email-masked]>
Date: Mon, 17 May 2010 21:42:26 -0400

A couple of remarks below, dealing with unreliable transport and the 503 response.

> Here is are replies, all marked with [MS] (see below).
...
> 
> Page 49 10.1 "When RTSP messages are transmitted using reliable transport
> protocols.." doesn't the previous section state that RTSP must use reliable
> transport?
> 
> [MS] seems to be a left-over from RTSP 1.0. I discussed this text with Magnus
> some time ago and we agreed to keep this text - just for the case somebody in
> the future (not me or Magnus) will extend RTSP 2.0 with unreliable transport.
> 
> [PTT] I wonder if we could simply change that "When" to a "Since"? I would hope 
that would provide a warning to someone who wishes to specify an unreliable 
transport, that application-level acknowledgements may be required.

...
> 
> 15.5.4 Response 503 has caused some headache in SIP. Some implementors tried
> the next IP address as returned in the DNS answer, some just gave up.
> 
> [MS] Does SIP also use this mechanism (described in 15.5.4): "If known, the
> length of the delay MAY be indicated in a Retry-After header. If no
> Retry-After is given, the client SHOULD handle the response as it would for a
> 500 response. "
> 
[PTT] SIP uses exactly this mechanism. RFC 5390 documents the problems they have 
with it. A SIP overload control WG (SOC) was finally chartered earlier this 
month to specify alternative controls.

It's possible that RTSP is different from SIP in terms of the RTSP network's 
reaction to 503, but once you get proxies into the picture I wouldn't bet on it.

> ... Page 149 16.51 Timestamp
> 
> [..] It also resolves retransmission ambiguities for unreliable transport of
> RTSP compare with 2. Protocol Overview [..] RTSP messages are sent over a
> reliable transport protocol
> 
[PTT] I suppose you could add the following note to this paragraph:

"Note that the present specification provides only for reliable transport of 
RTSP messages. The Timestamp general-header is specified in case the protocol is 
extended in the future to use unreliable transport."

...

---

From: "Martin Stiemerling" <[email-masked]>
Date: Wed, 19 May 2010 15:20:38 +0200

Hi Christian,

Thanks for your review and my replies are below:

> Behalf Of Christian Haas
> Sent: Saturday, April 03, 2010 7:16 PM
> To: mmusic (E-mail)
> Hello!
> This time I reviewed the syntax and examples first, with only quick
> references to the text whenever I wasn't sure about the meaning of the
> syntax.
> I'm planning another go at the full text some other time.
> 
> 
> I) Simple findings in syntax
> 
> 1. quoted-string
>  > quoted-string   =  ( DQ *qdtext DQ )

Good question, but seems to be in line with RFC 5234, Section 3.5, at the end:
"The sequence group notation is also used within free text to set off an element sequence from the prose."
the brackets is denoting the sequence group.

> 
> Why the extra parentheses?
> 
> 
> 2. FLOAT
>  > FLOAT            = ["-"] 1*12DIGIT ["." 1*9DIGIT]
>  > POS-FLOAT        = 1*12DIGIT ["." 1*9DIGIT]
> 
> A float is a positive float with a prefix; How about
> FLOAT            = ["-"] POS-FLOAT

True. Fixed. 

> 
> 
> 3. fraction
>  > fraction         =  1*9DIGIT
> 
> is used only once for utc-clock, whereas npt-sec and npt-hhmmss write
> its value explicitly. Suggestions:
> a) (remove fraction)
> utc-clock        =  6DIGIT [ "." 1*9DIGIT ]
> b) (exclusive use of fraction)
> npt-sec          =  1*19DIGIT [ "." fraction ]
> npt-hhmmss       =  npt-hh ":" npt-mm ":" npt-ss [ "." fraction ]

I would prefer a). Changed to this in the draft.

> 
> 
> 4. Connection and connection-token
> According to 16.11., the connection-token "close" is defined for RTSP
> 2.0, but this string isn't included in syntax. Suggestion:
> connection-token = "close" / token

Yes, that is indeed missing. fixed.

> 
> (Note: The connection-tokens are not listed in chapter 22, IANA
> considerations, though I don't know the rule when some extensible
> tokens
> shall be listed)
> 
> 
> 5. Timestamp:
> The LWS should be part of the optional delay; Suggestion:
> Timestamp        =  "Timestamp" HCOLON timestamp-value [LWS delay]

Fixed.

> 
> 
> 6. mode-spec
>  > mode-spec           = ( DQ mode *(COMMA mode) DQ )
> 
> Similar as above, why the extra parentheses?

see above, your very first point.

> 
> 
> 7. SDP, control-attribute
> CRLF is missing at the end, suggestion:
> control-attribute   =  "a=control:" *SP RTSP-REQ-Ref CRLF

Fixed.

> 
> (Question: Why is SP explicitly permitted - or /not/ for the other two
> attributes?)

You can have multiple RTSP-REQ-Ref and they need to be separated by SP.

> 
> 
> II) Other findings:
> 
> 1. Terminate-Reason
> See 16.50.:
>  > [...] the server when sending a REDIRECT or TERMINATE request [...]
> I believe it should be written TEARDOWN, not TERMINATE.

Yep – fixed.

> 
> 
> 2. Header syntax:
> User-Agent is still only a request-header and Server only a
> response-header. What may the respective agents send for the
> PLAY_NOTIFY
> and REDIRECT exchanges? I don't think the server should send User-Agent
> and the client Server.
> I would even go as far as to drop the ABNF separation of request-header
> and response-header and put them all into general-header. Tables 10-12
> already list in detail which header may appear in which message.
> Note: All the examples with PLAY_NOTIFY and REDIRECT have the client
> send User-Agent in the response, violating the current classification
> of
> response-header - a pedantic parser would treat them as extension-
> header
> now.
> 
> (One step even further would be too drastic I guess and not desired:
> unify User-Agent and Server and simply call the header "Agent")

I've just sent an extra email to discuss this with the WG.

> 
> 
> 3. Accept-Language
> The syntax still allows this header to be empty; We had the mail
> exchange about that last year, resulting in agreement to disallow the
> empty header.
> (http://www.ietf.org/mail-archive/web/mmusic/current/msg07799.html)

Fixed.
Accept-Language   =  "Accept-Language" HCOLON
                     language *(COMMA language)

> 
> 
> 4. CSeq
> 16.19.:
>  > [...] however, it is RECOMMENDED to start at 0.
> J.2.:
>  > CSeq header [...] A Recommendation to start at 1 has also been
> added.
> 
> Quite contradicting :) Or will the final detailed list of changes be
> finalized at the very last minute?

Fixed in J.2, as this is the informative part and not 16.19.

> 
> 
> III) Examples:
> 
> 13.4.1.
> The request CSeq 836 misses a CRLF between Range and User-Agent.

Fixed, as of Wolfgang's email.

> 
> 19.3.2.:
> - The second request case the same CSeq number (or is it a valid
> retransmission according to 16.19.?)

Nope, 2nd request should carry a new CSeq.

Fixed.

> - Also, the second line of the Transport header is not properly SWS
> delimited from its previous line - both in the request and the
> response.

Fixed.

> 
> C.2.2.:
> The response to CSeq 2 has some malformed Address/Port string in the
> second src_addr field.

Fixed.

> 
> *:
> Many responses have the Server header specify the supposed version as
> product, not product-version (it should be PhonyServer/x.y - '/' is
> often missing)

Fixed.

> 
> 
> IV) Possible Nit-Picking (can be ignored if not relevant - or I didn't
> understand it)
> 
> 16.50. Terminate-Reason (user-msg)
> If I understand correctly, in case of Server-Admin reason, user-msg is
> something the server administrator wants to to tell the current clients
> why the session will be dropped. Such as "I really need to change that
> memory now, sorry!". How does this work in relation to Accept-Language,
> where 16.4. specifies it being relevant for reason phrases?
> Or, is it expected that the admin chooses from a list of reason codes,
> behind which the server has a lookup table for the respective languages
> it supports?

It's true that Accept-Language applies to the reason phrases, but how this is implemented is outside the RTSP2.0 protocol specification.

  Martin

---

From: "Martin Stiemerling" <[email-masked]>
Date: Thu, 27 May 2010 10:24:05 +0200

Hi Tom, all,

> Behalf Of Tom Taylor
> Sent: Tuesday, May 18, 2010 3:42 AM
> To: Martin Stiemerling
> Cc: [email-masked]
[...]

> transport, that application-level acknowledgements may be required.

Changed to "Since". 

> reaction to 503, but once you get proxies into the picture I wouldn't

OK, I have added this to the issue tracker and will come back with a separate email about this.
(3007825, https://sourceforge.net/tracker/?func=detail&aid=3007825&group_id=23194&atid=377744)

> > [MS] left-over with a bet to the future that somebody will come up
> with
> > unreliable transport ;)
> >

Yes, that is indeed a good text proposal. Added.

Thanks a lot!

  Martin