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

From: Jeremy Worley <[email-masked]>
Date: Wed, 10 Jul 2002 10:14:47 -0700

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.

> > 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 
>implemenentation the 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.

> > 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.

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.

Best,
         Jeremy

>Best Regards,
>Emre
>
>
>
> > Thanks,
> >          Jeremy
> >
> >
> > >Best Regards,
> > >
> > >Emre
> > >
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > >
> > > > From: ext Magnus Westerlund
> > [mailto:[email-masked]]
> > >
> > > > Sent: 10. July 2002 17:10
> > >
> > > > To: Aksu Emre (NMP/Tampere)
> > >
> > > > Cc: [email-masked]
> > >
> > > > Subject: Re: [MMUSIC] OPTIONS method in RTSP. Is it
> > required or not in
> > >
> > > > minimal client and server implementations?
> > >
> > > >
> > >
> > > >
> > >
> > > > Hi Emre,
> > >
> > > >
> > >
> > > > Table 2 is actually rather unclear regarding the requirement
> > >
> > > > levels. It
> > >
> > > > does not specify which entity the requirements concern.
> > If you would
> > >
> > > > read both the clients and the server minimal implementation
> > >
> > > > requirements
> > >
> > > > you would find a difference. The server is required to
> > implement the
> > >
> > > > options method while the client is not.
> > >
> > > >
> > >
> > > > So follow annex D and be aware that the table is incomplete. It is
> > >
> > > > necessary to do something about it.
> > >
> > > >
> > >
> > > > I agree that options is very useful and all clients are
> > >
> > > > recommended to
> > >
> > > > implement it. I would say that options is the third or fourth
> > >
> > > > variant of
> > >
> > > > doing keep alive on my list after RTCP and PING and in hard
> > >
> > > > combat with
> > >
> > > > SET_PARAMETER. It main purpose however is capability discovery.
> > >
> > > >
> > >
> > > > Regards
> > >
> > > >
> > >
> > > > Magnus
> > >
> > > >
> > >
> > > > [email-masked] wrote:
> > >
> > > >
> > >
> > > > >Hello,
> > >
> > > > >
> > >
> > > > >I have a question related to the RTSP OPTIONS method.
> > >
> > > > >In the latest draft of RTSP RFC and also in the RFC 2326, in
> > >
> > > > Table 2, OPTIONS method requirement is listed as follows:
> > >
> > > > >
> > >
> > > > > method direction object requirement
> > >
> > > > >
> > >
> > > > >OPTIONS C->S, S->C P,S required
> > >
> > > > (S->C: optional)
> > >
> > > > >
> > >
> > > > >In the Annex D.1 , minimal RTSP Client implementation,
> > >
> > > > OPTIONS method is not included to the list of methods which
> > >
> > > > MUST be implemented.
> > >
> > > > >
> > >
> > > > >So, My question is: How should this be interpreted?
> > >
> > > > According to Table 2, OPTIONS method looks like to be
> > >
> > > > mandated at least in the C->S direction. But this seems to
> > >
> > > > conflict with the minimal implementation. If Table.2 does not
> > >
> > > > apply to the minimal implementation, how should Table 2 be
> > >
> > > > interpreted? I would really appreciate if this could be clarified.
> > >
> > > > >
> > >
> > > > >I would also like to point out the usefulness of OPTIONS,
> > >
> > > > especially for checking the 'session aliveness' according to
> > >
> > > > the latest draft...
> > >
> > > > >
> > >
> > > > >BR
> > >
> > > > >Emre
> > >
> > > > >
> > >
> > > > >
> > >
> > > > >
> > >
> > > > >
> > >
> > > > >Emre Baris Aksu
> > >
> > > > >Senior Design Engineer
> > >
> > > > >
> > >
> > > > >Nokia Mobile Phones
> > >
> > > > >Tampere / Finland
> > >
> > > > >e-mail : [email-masked]
> > >
> > > > >Mobile : +358 40 743 1972
> > >
> > > > >Fax : +358 7180 70504
> > >
> > > > >
> > >
> > > > >
> > >
> > > > >
> > >
> > > > >
> > >
> > > > >
> > >
> > > > >_______________________________________________
> > >
> > > > >mmusic mailing list
> > >
> > > > >[email-masked]
> > >
> > > > >https://www1.ietf.org/mailman/listinfo/mmusic
> > >
> > > > >
> > >
> > > >
> > >
> > > > --
> > >
> > > >
> > >
> > > > 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
> >
> >

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 11 Jul 2002 11:14:25 +0200

Hi Jeremy,

See comments inline:

Jeremy Worley wrote:

>> 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.

>> 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. 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, 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?
>
>
> 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.

> 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 

S-164 80 Stockholm, Sweden | mailto: [email-masked]