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

[Magnus Westerlund <magnus.westerlund at ericsson.com>]

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: magnus.westerlund at ericsson.com
----------------------------------------------------------------------