Subject: [MMUSIC] RTSP: The normative level for implementation of OPTIONS request

From: Magnus Westerlund <[email-masked]>
Date: Thu, 21 Oct 2004 14:37:39 +0200

In the latest RTSP core draft their is a MUST implement OPTIONS method 
for an client. I propose that we lower the bar to SHOULD implement 
OPTIONS and give a motivation as being the main capability negotiation 
mechanism.

Any objections to this proposal?

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

---

From: sunil bhargo <[email-masked]>
Date: Thu, 21 Oct 2004 10:09:47 -0700 (PDT)

Magnus,
       Actually there is some contradiction in section
11.1 and D.1 (minimal client implementation). 11.1
says
that OPTIONS is must for client but according to D.1
this is not MUST probably this is what you are
pointing 
at.
       If so then shouldn't the server support for    
   OPTIONS be also changed from MUST to should in D.2
?
        
sunil bhargo

--- Magnus Westerlund <[email-masked]>

> [email-masked]

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 22 Oct 2004 09:26:16 +0200

Hi,

> this is not MUST probably this is what you are

Yes, it is the MUST in 11.1 that I like to change to a SHOULD or 
RECOMMENDED. To be consistent that would also mean to make the necessary 
changes in Appendix D.

We have three options on this:

A. Make the Implementation of OPTIONS as a requester a MUST. There is no 
technical reason for this.

B. Make an recommendation that clients implement OPTIONS. This due to 
that it is the main method of learning the methods and feature supported 
for an resource. However really stripped down clients could skip to 
implement the method.

C. Do not say anything about implementation of OPTIONS at all.

I personally do favour B.

>    OPTIONS be also changed from MUST to should in D.2

No, then you loose the possibility to use OPTIONS at all. You need to 
know that OPTIONS is supported at the server side. Otherwise you can't 
know for certain that it is possible to learn which methods or features 
that are supported either globally or for a specific resource.

Cheers

Magnus Westerlund

---

From: sunil bhargo <[email-masked]>
Date: Fri, 22 Oct 2004 05:37:44 -0700 (PDT)

Hi Magnus,
            B makes sense, would it be better to also
recommend that the client uses OPTIONS at the start of
the session before any other request so that method
capability are known at the start of the session.

sunil bhargo

> [email-masked]

_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 22 Oct 2004 14:58:16 +0200

Hi,

> capability are known at the start of the session.

I would say that a recommendation depends on what type of session you 
are going to do. If you are going to do something plan vanilla, then you 
can simple ensure these things are true with Require header. Also in 
certain cases, where it is desirable to try to achieve a quick setup, 
without the extra round trip time, then one can use Require. If one is 
going to try something very special, not likely to be supported, then 
the usage of OPTIONS are welcome.

This is really a implementation choice for a client.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 22 Oct 2004 15:53:29 +0200

> This is really a implementation choice for a client.

Clarification: If you need to learn what methods are supported for a 
resource, then you need to use OPTIONS.

Due to the many different needs around capability discovery, I am 
hesitant to give any recommendation, more than explaining the usability 
of each method.

Cheers

Magnus Westerlund