a) Use of destination parameter in Transport header, raised by Ed Lau
Draft seems to be unduly restrictive in terms of using this parameter
for unicast, ie to direct a stream at an address other than the one
control requests are being recd from.  Henning posted a fix, reproduced
here:

\begin{changebar}
\item[\header{destination}:] The address to which a stream will be
sent.
The client may specify the destination address with the
\header{destination} parameter.  To avoid becoming the unwitting
perpetrator of a remote-controlled denial-of-service attack, a
server
{\SHOULD} authenticate the client and {\SHOULD} log such attempts
before
allowing the client to direct a media stream to an address not
chosen by
the server.  This is particularly important if RTSP commands are
issued
via UDP, but implementations cannot rely on TCP as reliable means of
client identification by itself.
\end{changebar}


b) Clarification of response code if some value within a header is not
supported.  I've add quite a few people ask me this :  what is the
response code if a server gets a PLAY with absolute time, and does not
support it.

c ) Also, the use of OPTIONS to query the support of such abilities in
addition to querying extension and method support.

d) Are there any commonly used GET/SET params that need standardization
?  The idea behind keeping it open was to see what implementation
experience brings us.  There has been one request here to use it to be
able to query the current stream state.  Such a request would come from
very simple clients who possibly stop receiving data or dont remember
their last request to the server.

e) Complaint that state machine is simplistic.  Needs to be clarified
that it is per session, not per client .(Actually, it says in the spec
that it is per media object) Any comments ?

f) Doing a SETUP with URL A followed by a PLAY on URL A, followed by a
PLAY on URL B (not a part of the same presentation as URL A).  The idea
being, of course to setup a transport channel only once.  My (somewhat
rusty) recollection and interpretation is that the spec does not
explicitly forbid this, nor does it include such an example or otherwise
ratify it as a Good Thing .  Desirable for clients, but hard to
implement for servers - at least some servers do not implement it.  I
think it is worth some clarification - if not supported by the majority,
perhaps make it an extension.


11/16/01: pablok@mobixell.com

Clarify whether Connection is mandatory or not.
Clarify whether aggregate and non-aggregate control are mandatory.


The admin password for the mail list is: 2nu7135

The archive is here:
http://www.geocrawler.com/archives/3/14262/2001/11/0/

However, the archive doesn't look complete, because I did make one small 
commit to the specification itself, which should be obvious from the CVS logs.
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rtspspec/headers.tex.diff?r1=1.1&r2=1.2


Here's the agenda for the teleconference on Wednesday, January 23 (9am
PST).  Please RSVP to me by 5pm PST on Monday.

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

To post to this list, send your email to:

  rtspspec-logistics@lists.sourceforge.net

General information about the mailing list is at:

  https://lists.sourceforge.net/lists/listinfo/rtspspec-logistics

https://lists.sourceforge.net/lists/options/rtspspec-logistics/hgs%40cs.columbia.edu


COMPANY:           RealNetworks
LEADER:            Rob Lanphier
CALL DATE:         JAN-23-2002  (Wednesday)
CALL TIME:         09:00 AM PACIFIC TIME
DURATION:              1 hr 30 min
USA Toll Free Number: 888-566-5919
Overseas/Toll Number: +1 630-395-0073
PASSCODE: 12019

telecon web page:
http://rtsp.org/telecon

Phone number:
In U.S.:            888-560-4606
International:   +1-712-271-0412
Passcode:           87327
Conference number:  2283597