Subject: RE: [MMUSIC] RTSP: Requirement on using Allow in media resource specific OPTIONS responses

From: "Jae-Hwan Kim" <[email-masked]>
Date: Fri, 11 Mar 2005 09:33:08 +0900

Hi Magnus,
Your revised text sounds good.

BTW, I could know the 'allow' header is applicable only for OPTIONS from
the table 9 of rfc2326bis-09. In rfc2326, this field can be used for all
methods. Is there any reason for this limitation? I think 'allow' would
be beneficial if I use it in DESCRIBE or SETUP for the first place,
because some players doesn't send OPTIONS at first.

Best Regards,
Jae-Hwan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf Of
> Magnus Westerlund
> Sent: Friday, March 11, 2005 1:58 AM
> To: mmusic (E-mail)
> Subject: [MMUSIC] RTSP: Requirement on using Allow in media resource
specific
> OPTIONS responses
> 
> Hi,
> 
> It has come to my knowledge that the current specification of usage of
> Allow header may be to free to be useful.
> 
> Currently OPTIONS method text says:
> 
>     Regardless of scope of the request, the Public header MUST always
be
>     included in the OPTIONS response listing the methods that are
>     supported by the responding RTSP agent. In addition, if the scope
of
>     the request is limited to a media resource, the Allow header MAY
be
>     included in the response to enumerate the set of methods that are
>     allowed for that resource.
> 
> Thus a client indicating a specific media resource can not be
guaranteed
> to get an correct indication if the media resource specific support is
> limited compared to the general capabilities. Therefore I would
propose
> to change this to:
> 
>     Regardless of scope of the request, the Public header MUST always
be
>     included in the OPTIONS response listing the methods that are
>     supported by the responding RTSP agent. In addition, if the scope
of
>     the request is limited to a media resource, the Allow header MUST
be
>     included in the response to enumerate the set of methods that are
>     allowed for that resource unless the set of methods completely
>     matches the set in the Public header.
> 
> So what do you say about such a change?
> 
> Cheers
> 
> Magnus Westerlund
> 
> Multimedia Technologies, Ericsson Research EAB/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email-masked]
> 
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 17 Mar 2005 08:56:53 +0100

Hi,

> because some players doesn't send OPTIONS at first.

There is to my knowledge no reason to the restriction. Instead of having 
the too open statement that is present in RFC 2326, I simple documented 
where there was explicit that Allow was needed. That was only 405 and 
OPTIONS response. However I do see that there could be reasons why one 
could include Allow in DESCRIBE and SETUP responses.

However I would like to have some discussion on the requirements level 
for including this header. Should it only be optional requiring that any 
client really desiring this information uses OPTIONS? Or do you like to 
promote it to a higher level?

Also can it be expected that the Allow header is different for an 
aggregated session than for the individual media streams? In that case 
we must consider what the implications are on usage in SETUP responses.

Cheers

Magnus Westerlund