Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-rfc2326bis-22

From: "HAAS Christian" <[email-masked]>
Date: Sat, 3 Oct 2009 11:34:08 +0200

Hello again!

In here I list my findings of my first pass of the syntax review. As always,
I'm optimistic to find extra time for another pass.

I) Syntax modifications

1. accept-param:
The syntax does not enforce using the q parameter as 'delimeter' between
media-type-range and accept-range parameters; HTTP does this more explicitly
in 14.1
Suggestion:

accept-range      =  media-type-range [ SEMI accept-params ]
accept-params     =  "q" EQUAL qvalue *( SEMI generic-param )

this then also affects other definitions that rely on current accept-param:

encoding          =  codings [ SEMI accept-params ]
language          =  language-range [ SEMI accept-params ]

...although this then requires the q parameter to be first for the encoding
and language definitions as well. Bad / Not Bad?

2. language-range (for Accept-Ranges):
It could reference the language-tag definition (one page below), suggestion:

language-range    =  language-tag / "*"

3. Proxy-Require and Proxy-Supported:
They can both reference the feature-tag-list below, suggestion:

Proxy-Require        =  "Proxy-Require" HCOLON feature-tag-list
Proxy-Supported      =  "Proxy-Supported" HCOLON feature-tag-list

4. Retry-After:
a) 16.40 allows this header to specify seconds or a date, the syntax only
allows delta-seconds.
b) What is the comment for? Maintenance description?
c) Usage of duration retry-param is not described in 16.40 nor anywhere else

Suggestion (assuming no further description text is added):

Retry-After          = "Retry-After" HCOLON ( RTSP-date / delta-seconds )

5. channel (for transport parameter)
I suggest a comment like at ttl:

channel              = 1*3DIGIT ; 0 to 255

6. User-Agent
I guess the syntax should be identical to the one of Server; the extra '0'
for the * list is unnecessary.

II) Things I might have not properly understood:

1. Accept-Language:
The header allows to be empty. If this is the case, does this mean all
languages have a q value of 1 or does the last sentence in 16.4 imply NO
language is acceptable: "If an Accept-Language header is present, then all
languages which are assigned a quality factor greater than 0 are acceptable."
I guess it of course means all languages are equally acceptable, especially
with the default q value of 1 -- yet, does this mean for all explicitly given
languages or all the server knows of which are not explicitly given?

2. Allow:
This header may also be empty. How can I reach a valid resource that does not
produce 404, but 405 and allows no request to be performed?

3. Content-Type:
May be given in SIP-like short form "c" -- This is the only header to allow
this according to the syntax.
Why?

Regards,
ch

-----Original Message-----
From: [email-masked] on behalf of HAAS Christian
Sent: Fri 9/25/2009 7:23 AM
To: [email-masked]
Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-rfc2326bis-22
 
Hello all!

I've read through the draft (skipping the syntax definitions) and found only
minor issues regarding wording, typos and consistency so far, which I already
sent to Magnus directly.

I will try to find some time during the upcoming days for a dedicated check
of the syntax.

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
E-Mail    [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. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Joerg Ott
Sent: Sonntag, 20. September 2009 18:19
To: [email-masked]
Cc: Magnus Westerlund; Jean-Francois Mule; Martin Stiemerling
Subject: [MMUSIC] WGLC: draft-ietf-mmusic-rfc2326bis-22

Folks,

as agreed in Stockholm, we are issuing working group last call on the revised
RTSP spec, draft-ietf-mmusic-rfc2326bis-22 heading for Proposed Standard.
(http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-22)

The WGLC will expire in four weeks, on 19 Oct 2009.

We know that this is a long spec, the more important is it to receive
thorough review by the community.  While we have three volunteer reviewers
(thanks again!), we urge everyone who cares to provide detailed feedback.

Please review the document and post your comments to the MMUSIC list and/or
the authors.

Thanks,
Joerg

MMUSIC co-chair

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Thomas Schierl <[email-masked]>
Date: Mon, 19 Oct 2009 13:49:37 +0200

Dear authors,

I have one question, which came into my mind reading Appendix D.

In section D.1.2, I read "

Usage of grouping of media lines [RFC3388] to determine which media
lines should or should not be included in a RTSP session is
unspecified.

"

Earlier in the Appendix, I read "

However
,the SDP extension "Grouping of Media Lines in the Session
Description Protocol (SDP)" [RFC3388] may provide such functionality
depending on need. Also future grouping semantics may in the future
be developed.

"

What does it mean?  Is SDP grouping allowed to be used with this spec?
If not, then there might
be an issue with respect of using the RFC 5583 decoding dependency
signaling required for multi flow
transmission of layered codecs such as SVC.

Thanks,

Thomas

--
Thomas Schierl
--------------
Fraunhofer HHI

Joerg Ott wrote:

Folks,

as agreed in Stockholm, we are issuing working group last

call on the revised RTSP spec, draft-ietf-mmusic-rfc2326bis-22

heading for Proposed Standard.

We know that this is a long spec, the more important is it

to receive thorough review by the community.  While we have

three volunteer reviewers (thanks again!), we urge everyone

who cares to provide detailed feedback.

Please review the document and post your comments to the

MMUSIC list and/or the authors.

Thanks,

Joerg

MMUSIC co-chair

mmusic mailing list

[email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 23 Oct 2009 16:18:44 +0200

Thanks to everyone that has provided comments. In additions to the one
on the mailing list I have received some private ones. Unfortunately I
don't have time to resolve these and provide an updated draft by Monday.
I will do my best to go through your comments next week and provide
proposals for resolutions and bring up where I think additional
discussion are needed.

Best Regards

Magnus

-- 

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
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: [email-masked]
----------------------------------------------------------------------