Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #86 - 2 msgs

From: [email-masked]
Date: Tue, 26 Aug 2003 20:27:39 -0700

This is an automatic digest of bugs submitted and changed on the RTSP bug tracker.  To see a list of bugs, visit:

http://sf.net/projects/rtspspec

When replying, please make your Subject line more specific than "Re: Rtspspec-bugs digest"

Today's Topics:

   1. [ rtspspec-Bugs-795295 ] TEARDOWN using * and the Ready-nm state (SourceForge.net)
   2. [ rtspspec-Bugs-795314 ] Caching of OPTIONS request (SourceForge.net)

--__--__--

Message: 1
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 26 Aug 2003 05:08:24 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-795295 ] TEARDOWN using * and the Ready-nm state

Bugs item #795295, was opened at 2003-08-26 14:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=795295&group_id=23194

Category: None
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: TEARDOWN using * and the Ready-nm state

Initial Comment:
The 20 february 2002 we discussed

http://rtsp.org/bug506412, for conclusion of that

discussion see minutes:

http://rtsp.org/2002/telecon/minutes20Feb.html

However to me it seems that the need for state Ready-nm

is not that great. Also the use of "*" as a URL will

not work when proxies are present, unless requirements

are put on them to maintain certain state in regards to

sessions. The use of the presentation URL also is

problematic as some sessions may not have a defined

session URL, like for example for sessions intended to

be used in non-aggregted mode. 

Therefore my suggestion is that the Ready-nm state is

removed and that teardown using "*" is dissallowed.

Comments please. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=795295&group_id=23194

--__--__--

Message: 2
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 26 Aug 2003 05:27:47 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-795314 ] Caching of OPTIONS request

Bugs item #795314, was opened at 2003-08-26 14:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=795314&group_id=23194

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Caching of OPTIONS request

Initial Comment:
Geetha Srikantan thought of the question if OPTIONS

request are cachable, and if, how to determine the

expiration of such cached command. 

My answer

Maybe, it is actually a problem of what OPTIONS is used

for. 

As long it is only used for determing server capability

it is not a problem. However if it is used to maintain

session liveness, i.e. session ID present, no. Also

depending on the URI and the possibilities to cache ma

y vary. Needs further consideration.

This is a tough problem. I don't think there are. The

Expires header is an entity header, but the text in RFC

2616 seems to mean the whole request. So this is also

something that needs consideration. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=795314&group_id=23194

End of Rtspspec-bugs Digest

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