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

From: Magnus Westerlund <[email-masked]>
Date: Sun, 01 Nov 2009 16:46:51 +0100

Thanks for your review Christian,

Please see comments and proposed ways forwards inline.

HAAS Christian skrev:
> 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?

There will still be possibility for ambiguity here, but I guess that is
the simplest. q can always be added and reduces the possible conflict
between media type parameters and accept-parameters to a single token,
namely q.

I would propose follow your suggestion as it also are in-line with what
HTTP does.

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

Are you meaning Accept-Languages instead of Accept-Ranges here?

In that case I do agree with you.

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

Agreed.

> 
> 
> 4. Retry-After:
> a) 16.40 allows this header to specify seconds or a date, the syntax
> only allows delta-seconds.

Yes, clearly broken.

> b) What is the comment for? Maintenance description?

Actually I don't know.

> c) Usage of duration retry-param is not described in 16.40 nor anywhere else

Yes, I don't know.

> 
> Suggestion (assuming no further description text is added):
> 
> Retry-After          = "Retry-After" HCOLON ( RTSP-date / delta-seconds )

Find this suggestion good.

> 
> 
> 5. channel (for transport parameter)
> I suggest a comment like at ttl:
> 
> channel              = 1*3DIGIT ; 0 to 255

Good suggestion.

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

Yes, that is true.

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

My interpretation of the text is that an empty header would mean that no
language is acceptable.

Do you think this should be clarified in the text?

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

I agree that an Allow header that is empty are of no help. This is
clearly a corner-case. The question is how to resolve this issue.

We can disallow non-empty as it doesn't make sense. If you have a
request for a resource that no method is allow then I would think it is
a broken resource and thus another error message.

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

I agree that this should be removed. We aren't using short forms in
RTSP, thus I would suggest that we remove the short form.

Cheers

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

---

From: Magnus Westerlund <[email-masked]>
Date: Sun, 01 Nov 2009 16:56:37 +0100

Thomas Schierl skrev:
> 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 <http://tools.ietf.org/html/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 <http://tools.ietf.org/html/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.
> 
> 

I guess we need to clarify this. Grouping of media lines will require
that one understands the semantic that is used. But from an RTSP point
of view most semantics would be easy to incorporate as long as they
describe the relationship between media streams that you all most
receive. If any semantic would be more in the context of alternatives or
play only one at the time that creates also interaction with RTSP. I
think we can add text to clarify that it is required to understand the
semantics, and define what to do with the known semantics.

Cheers

Magnus Westerlund

---

From: "HAAS Christian" <[email-masked]>
Date: Mon, 2 Nov 2009 09:16:51 +0100

Hello!

From: Magnus Westerlund [mailto:[email-masked]] 
> In that case I do agree with you.

Yes, I mixed them up :)

> > 1. Accept-Language:
> > [...]
>
> My interpretation of the text is that an empty header would mean
> that no language is acceptable.
>

If no language is acceptable, how should the server form a response? As 16.4.
notes, the language applies to the presentation description and reason
phrases - What reason phrase to give if no language is acceptable?

Or is the loophole in here the part "[...] restricts the set of natural
languages that are _preferred_ as a response to the request." (16.4) - Then I
would interpret an empty Accept-Language header as if it was not sent (I, the
requester, have no language preference - it is up to you, responder). In that
case I'd disallow an empty header as not sending it has the same effect.
Disallowing an empty header closes this corner-case and no description text
must be modified.

> > 2. Allow:
> > [...]
>
> I agree that an Allow header that is empty are of no help. This
> is clearly a corner-case. The question is how to resolve this
> issue.
>
> We can disallow non-empty as it doesn't make sense. If you
> have a request for a resource that no method is allow then I
> would think it is a broken resource and thus another error message.

Yes. (Although I think you meant to write 'disallow empty' :)

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.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 02 Nov 2009 13:54:06 +0100

> Disallowing an empty header closes this corner-case and no description text

Yes, that is probably easiest.

> Yes. (Although I think you meant to write 'disallow empty' :)

Yes!

Cheers

Magnus Westerlund