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

From: "Jae-Hwan Kim" <[email-masked]>
Date: Tue, 12 Jul 2005 04:56:23 +0900

Hi
I agree. Originally, I thought it would be useful if we can restrict the
usage of some method. For instance, a server may not allow PAUSE for the
live streaming and it may want to announce only the enabled method. Then
the player may disable PAUSE key before starting the session.

And IMO:

1) If Allow is used in DESCRIBE response, it defines the possible method
list for the given presentation.
2) If Allow is used in SETUP response, it defines the method list for
the each media resource.

So, if SDP initiation is used, in other words, if client already having
SDP information sends SETUP for the first, 2) will be considered.

1) would be used for aggregate control, while 2) would be used for
non-aggregate control.

Best Regards,
Jae-Hwan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf Of
> Magnus Westerlund
> Sent: Monday, July 11, 2005 11:07 PM
> To: Magnus Westerlund
> Cc: mmusic (E-mail)
> Subject: Re: [MMUSIC] RTSP: Requirement on using Allow in
mediaresource
> specific OPTIONS responses
> 
> Hi,
> 
> I would like to reviwe the below topic regarding using the Allow
header
> in other responses than to OPTIONS and 405. Should it be optional to
> include it, or should some mandatory exist?
> 
> To me it seems that a resonable approach would be to allow it be
> included in SETUP and DESCRIBE, and RECOMMEND it to be included if the
> server supports more than the basic functionality in regards to a
> resource. What do you say??
> 
> Cheers
> 
> Magnus
> 
> Magnus Westerlund wrote:
> > Hi,
> >
> > Jae-Hwan Kim wrote:
> >
> >> 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.
> >>
> >
> > 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
> >
> > 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
> >
> 
> 
> --
> 
> 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: Tue, 12 Jul 2005 10:30:03 +0200

Hi Jae-Hwan,

I am bit concerned with having undefined behavior. I don't think 
optional usage is the best. I would prefer to have a clear and well 
defined behavior if this is going to be useful at all. Thus it would be 
in the interest to require the inclusion of allowed in either of these 
methods responses. However this will bloat the messages a bit. If one 
makes it conditional it must be in regards to some baseline that is know.

Do you have any good suggestions in that regards? I would also 
appreciate getting some specification text. Currently the Allow header 
says the following:

\subsection{Allow}
\label{sec:Allow}

The \header{Allow} entity-header field lists the methods supported
by the resource identified by the Request-URI.  The purpose of
this field is to strictly inform the recipient of valid methods
associated with the resource.  An \header{Allow} header field
{\MUST} be present in a 405 (Method Not Allowed) response. See
[H14.7] for syntax definition. \begin{changebar} The \header{Allow} 
header {\MUST}
also be present in all {\OPTIONS} responses where the content of
the header will not include exactly the same methods as listed in
the \header{Public} header.
\end{changebar}

Example of use:
\begin{verbatim}
   Allow: SETUP, PLAY, SET_PARAMETER
\end{verbatim}

Please add to the above with your text proposal.

Cheers

Magnus

-- 

Magnus Westerlund