Subject: RE: [MMUSIC] OPTIONS method in RTSP. Is it required or not in minimal client and server implementations?

From: [email-masked]
Date: Thu, 11 Jul 2002 12:48:41 +0300

Hi Magnus,

Please see my comments inlined:

> -----Original Message-----
> From: ext Magnus Westerlund [mailto:[email-masked]]
> Sent: 11. July 2002 12:14
> To: Jeremy Worley
> Cc: Aksu Emre (NMP/Tampere); [email-masked]
> Subject: Re: [MMUSIC] OPTIONS method in RTSP. Is it required or not in
> minimal client and server implementations?
> 
> 
> Hi Jeremy,
> 
> See comments inline:
> 
> Jeremy Worley wrote:
> 
> > Hi Emre,
> >
> > At 07:05 PM 7/10/2002 +0300, [email-masked] wrote:
> >
> >> Hi Jeremy,
> >> Please find my comments inlined:
> >>
> >> > -----Original Message-----
> >> > From: ext Jeremy Worley [mailto:[email-masked]]
> >> > Sent: 10. July 2002 18:42
> >> > To: Aksu Emre (NMP/Tampere); [email-masked]
> >> > Subject: Re: RE: [MMUSIC] OPTIONS method in RTSP. Is it
> >> > required or not
> >> > in minimal client and server implementations?
> >> >
> >> >
> >> > Hello Emre,
> >> >
> >> > At 05:23 PM 7/10/2002 +0300, [email-masked] wrote:
> >> > >Hi Magnus,
> >> > >
> >> > >Thanhs for the quick answer. The reason why I asked this
> >> > mainly is that, I
> >> > >don't actually know an RTSP client which didn't implement
> >> > OPTIONS :-) (by
> >> > >implementing, I mean which can send OPTIONS request). So,
> >> > wouldn't it be
> >> > >better to make it required also for the minimal
> >> > implementation on the
> >> > >client side?
> >> >
> >> > I agree most clients implement sending of OPTIONS requests.
> >> > It also common
> >> > for clients to not implement OPTIONS response.
> >>
> >> I agree with this. But in such a case, at least a "Not 
> implemented" 
> >> error status message has to be sent by the client to the server, 
> >> right? In fact, my intention was to have the request to be 
> a mandated 
> >> requirement for the client. For the response to OPTIONS on 
> the cliet 
> >> side, I agree it can be optional as an implementation.
> >
> >
> > I agree that the client should respond if it does not support 
> > responding to a server OPTIONS request.
> >
> > My opinion is that if the client does not use optional 
> features, then 
> > it should not have to issue an OPTIONS request.
> 
> In other word you are happy with what is written today in appendix D. 
> Server must implement OPTIONS while it is totally optional 
> for a client.
> 
> >
> >
> >> > The rationale for not
> >> > requiring to send OPTIONS requests on the client is OK 
> in my opinion
> >> > because it is usually used to query features that a server
> >> > implements.  If
> >> > the client does not use any optional features, then it has no
> >> > need to send
> >> > an OPTIONS request, and so it would not need to 
> implement sending of
> >> > OPTIONS.  On the other hand, if the client uses optional RTSP
> >> > features,
> >> > then it must implement an OPTIONS request.
> >> >
> >>
> >> I see your point, but this is quite a statement, which I believe 
> >> should be present in the RFC then. Also, the minimal 
> implementation 
> >> for server and client has some 'or' statements in it (for 
> example for 
> >> RECORD and PLAY method), which I believe, means that 
> different sets 
> >> of minimal implementations are possible, and a client has to check 
> >> which set of  implementationthe server supports, even if 
> the server 
> >> is assumed to be a minimal implementation in the very beginning.
> >
> >
> > You raise an interesting point.  Table 2 of 2326 and 2326bis states 
> > that RECORD is optional and PLAY is mandatory for the 
> client.  However 
> > D.1 and D.2 appear to state that it is required that either PLAY or 
> > RECORD can be implemented.  RECORD is described as an 
> optional feature 
> > in several places in 2326 (e.g., 1.5, 10.11, table 2).  I think in 
> > this case, it makes sense to make Section D consistent with 
> the rest 
> > of the document.
> >
> In this case my interpretation is that Appendix D is correct. There 
> actually exist several types of minimal implementations, one 
> for doing 
> playback from server, one for doing playback for servers of on demand 
> content and a third for recording to servers. They can further also 
> support authentication. 

If these many possibilites are present for minimal implementation where the implementations actually differ in means of supported functionalities, how does a client identify what kind of a server it is dealing with without using OPTIONS method, if OPTIONS is not mandated also for the client as a way of request to check the server capabilities? Can there be a logical mismatch here? 

Best Regards,
Emre

> The contradictions we must do the best to 
> remove. They are unfortunately very common in RFC 2326. As an 
> example I 
> found one more in Appendix D. The user agent header is only 
> RECOMMENDED 
> to implement by clients in Appendix D while the header definition in 
> RFC2616 section 14.43 says: "User agents SHOULD include this 
> field with 
> requests."
> 
> >
> >> > I agree with Magnus that Table 2 should be clarified to
> >> > describe what must
> >> > be implemented as both requests and responses by client 
> and server.
> >> >
> >> >
> >> > >I also think that it is a quite clean solution to use 
> OPTIONS with
> >> > >Session-Id to check/keep session aliveness. I remember the
> >> > big discussions
> >> > >about this in this reflector, and I don't intend open them
> >> > again :-). Just
> >> > >to keep in mind, in 3GPP Packet Switched Streaming Service
> >> > definitions,
> >> > >RTCP and OPTIONS are the preferred methods for session
> >> > aliveness checking,
> >> > >in the given preference order. (Ref: Section A.2.2.2.2 in
> >> > document TS
> >> > >26.234 v4.40 (Release 4) and v5.10 (Release 5)).
> >> >
> >> > When the new RTSP draft becomes an RFC, we may want to add
> >> > PING to the list
> >> > of methods for checking session aliveness in 26.234.  In such
> >> > a scenario, I
> >> > think PING might be preferred over OPTIONS.
> >> >
> >>
> >> I agree, PING is a very good choice and I believe it will 
> definitely 
> >> find its place in the 3GPP spec. I have one question 
> though. Can PING 
> >> method identify a streaming session?. What I exactly mean is that, 
> >> can a PING request bear a Session-ID?
> >
> >
> > Table 4 in the draft states that the Session header mandatory for 
> > PING.  Interestingly, the example transaction in 10.12 does not 
> > include a Session header.  That example should be modified 
> to include 
> > a Session header.
> 
> Yes, an error which will be corrected in the next version.
> 
> >
> > A minor editorial note: table 4 also seems to have floated 
> to a later 
> > section of the document in the current draft.  That should 
> be cleaned 
> > up in the next draft.
> 
> Yes, the tables are floating around a bit. I don't think we will fix 
> that. I do feel that it is better to have as much of the table as 
> possible in one page. We still have to reformat the table as it is to 
> wide for a single page.
> 
> Regards
> 
> Magnus Westerlund 
> 
> Multimedia Technologies, Ericsson Research ERA/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, 11 Jul 2002 13:03:13 +0200

Hi Emre,

A client does not need to know in advance if its going to work, instead 
it can simply try to perform a certain task. If some functionality is 
not supported, it will fail and an error message will be generated in 
response to the unsupported request. For example a setup request for 
record contains mode=record, it the server does not support record it 
shall answer with "461 Unsupported Transport".

I have been thinking of defining option tags for the basic 
functionality's that can be used in the Require header. This allows a 
client to already during the first request to know if it will work or 
not. However I don't think we can distinguish so easily between live and 
on-demand content and the requirement that put onto a client. It may 
actually be reasonable to require that a client shall handle both live 
and on-demand content. Further input into what shall be minimal 
implementation is encouraged. Please remember that we should not 
substantially change the RFC 2326 rules but we may clarify them.

Regards

Magnus

-- 

Magnus Westerlund