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: mmusic-bounces at ietf.org on behalf of HAAS Christian
Sent: Fri 9/25/2009 7:23 AM
To: mmusic at ietf.org
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 christian.haas at frequentis.com
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: mmusic-bounces at ietf.org [mailto:mmusic-bounces at ietf.org] On Behalf Of
Joerg Ott
Sent: Sonntag, 20. September 2009 18:19
To: mmusic at ietf.org
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
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic