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

From: Christian Haas <[email-masked]>
Date: Sat, 03 Apr 2010 19:15:30 +0200

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 )

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

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 ]

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

(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]

6. mode-spec
 > mode-spec           = ( DQ mode *(COMMA mode) DQ )

Similar as above, why the extra parentheses?

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

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

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.

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")

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)

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?

III) Examples:

13.4.1.
The request CSeq 836 misses a CRLF between Range and User-Agent.

19.3.2.:
- The second request case the same CSeq number (or is it a valid 
retransmission according to 16.19.?)
- Also, the second line of the Transport header is not properly SWS 
delimited from its previous line - both in the request and the response.

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

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

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?

regards,
ch
____________________________________________________
*Christian Haas**
*Team DIVOS, Software Engineer
FREQUENTIS AG

Innovationsstraße 1, 1100 Vienna, Austria
Phone   +43-1-811 50 – 8353
Mobile   +43-664-60 850 – 8353
Fax       +43-1-811 50 – 77 8353
Web _www.frequentis.com_ <file://www.frequentis.com>
E-Mail [email-masked] 
<mailto:[email-masked]>

Handelsgericht Wien (Vienna Commercial Court): FN 72115 b
DVR 0364797, ATU 14715600

____________________________________________________
Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte 
Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder 
diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den 
Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie 
die unbefugte Weitergabe dieser E-Mail sind nicht gestattet.

This e-mail may contain confidential and/or privileged information. If 
you are not the intended recipient (or have received this e-mail in 
error) please notify the sender immediately and destroy this e-mail. Any 
unauthorised copying, disclosure or distribution of the material in this 
e-mail is strictly forbidden.

Jean-Francois Mule wrote:
> This is to initiate a 4-week Working Group Last Call of draft-ietf-mmusic-rfc2326bis-23.txt.
> The comment period will end Friday, April 23, 2010 at midnight US Pacific Time.
> Please post all your comments to the list (spelling errors, minor suggested wording changes, technical issues, etc.). If you have read the document and believe it is good to go, please indicate so as well on the list.
>
> The document is somewhat large and we have started to seek reviewers willing to take a one or more sections at a time.  If you would like to volunteer, please send your name and the chapters you are willing to review to the WG chairs.
>
> Jean-Francois
> MMUSIC co-chair.
>
>    
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Magnus Westerlund
>> Sent: Tuesday, March 09, 2010 2:10 AM
>> To: mmusic (E-mail)
>> Subject: Re: [MMUSIC] I-D Action:draft-ietf-mmusic-rfc2326bis-
>> 23.txt
>>
>> Hi,
>>
>> This update intends to take care of all the remaining open issues.
>> We
>> have also done a consistency check of the spec. Thus the amount of
>> changes in this one is fairly large. The side by side diff:
>>
>> http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-rfc2326bis/draft-ietf-mmusic-rfc2326bis-23-from-22.diff.html
>>
>> Will show that the changes are from high to low. Editorial, naming,
>> change of header classifications, corrected or changed RFC 2119
>> language
>> levels, corrected examples and usage of the new test/example IP
>> address
>> ranges, copying and adjusting more text from the HTTP spec, the
>> Conditional RAP policy for Seek-Style, proxy muxing, putting an
>> upper
>> limit on a number of numerical values, updated the changes section.
>>
>> I am sorry that it has taken this long to get to this stage. But I
>> think
>> the document is ready for a second WG last call. It is now your
>> turn to
>> see if you think everything is in order or if we messed things up.
>>
>> Cheers
>>
>> Magnus
>>
>>
>> [email-masked] skrev 2010-03-08 23:00:
>>      
>>> A New Internet-Draft is available from the on-line Internet-
>>>        
>> Drafts directories.
>>      
>>> This draft is a work item of the Multiparty Multimedia Session
>>>        
>> Control Working Group of the IETF.
>>      
>>>
>>> 	Title           : Real Time Streaming Protocol 2.0 (RTSP)
>>> 	Author(s)       : H. Schulzrinne, et al.
>>> 	Filename        : draft-ietf-mmusic-rfc2326bis-23.txt
>>> 	Pages           : 291	
>>> 	Date            : 2010-03-08
>>>
>>> This memorandum defines RTSP version 2.0 which obsoletes RTSP
>>>        
>> version
>>      
>>> 1.0 which is defined in RFC 2326.
>>>
>>> The Real Time Streaming Protocol, or RTSP, is an application-
>>>        
>> level
>>      
>>> protocol for setup and control of the delivery of data with real-
>>>        
>> time
>>      
>>> properties.  RTSP provides an extensible framework to enable
>>> controlled, on-demand delivery of real-time data, such as audio
>>>        
>> and
>>      
>>> video.  Sources of data can include both live data feeds and
>>>        
>> stored
>>      
>>> clips.  This protocol is intended to control multiple data
>>>        
>> delivery
>>      
>>> sessions, provide a means for choosing delivery channels such as
>>>        
>> UDP,
>>      
>>> multicast UDP and TCP, and provide a means for choosing delivery
>>> mechanisms based upon RTP (RFC 3550).
>>>
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-
>>>        
>> 23.txt
>>      
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> Below is the data which will enable a MIME compliant mail reader
>>> implementation to automatically retrieve the ASCII version of the
>>> Internet-Draft.
>>>        
>>      
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: "Martin Stiemerling" <[email-masked]>
Date: Tue, 20 Apr 2010 15:27:34 +0200

Wolfgang,

Thanks - I'm currently working through them and will come with specific points, if needed.

  Martin

[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 

> 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: