Subject: [MMUSIC] RTSP: New version draft-ietf-mmusic-rfc2326bis-12

From: Magnus Westerlund <[email-masked]>
Date: Mon, 06 Mar 2006 15:39:18 +0100

Hi,

I have submitted a new version of the RTSP 2.0 specification.

Available here until it becomes publicly available:
http://www.denstore.se/IETF/draft-ietf-mmusic-rfc2326bis-12.txt

The changes are many as a result of complete review by myself. Many 
small details has been changed. I have also performed a larger ones. 
Here is a side by side diff file between this version and the previous one:
http://www.denstore.se/IETF/rfc2326bis-diff11vs12.html

Larger changes:
- Removal of Range in PAUSE
- Changed URI definition and included IANA registration
- An IRI definition for RTSP
- Changed ETag definition
- Client includes Accept-Ranges in SETUP requests
- Introduction of the Proxy-Authorization header
- Accept credentials includes hash algorithm and IANA registry.
- IANA registration of range header formats.
- Minimal Implementation chapter updated.

It also resulted in a new open issues list. I will post separate email 
about those to facilitate discussion. However it is included below:

         1.   Procedures for establishing the TCP connections for
              RTP/AVP/TCP without interleaving in Section B.2.2 needs to
              be written.

         2.   Should the SMPTE range format be updated to support the 50
              and 60 frames per second modes?

         3.   Should we define a recommended format for error message
              bodies?

         4.   Today there is no recommended or required format for 300
              response entities containing URI lists. Should one be
              defined?

         5.   Should the dest_addr parameter in the Transport header in
              responses include the destination used by the server?

         6.   Should a IPv6 multicast scope parameter for the Transport
              header be defined? This would be similar to TTL.

         7.   Should we remove the Accept header with application/rtsl in
              Section 14.1 due to that it is not a registered media type?

         8.   The Expires header (Section 14.22 contains the below
              paragraph:

              Expires header field with a date value of some time in the
              future on a media stream that otherwise would by default be
              non- cacheable indicates that the media stream is
              cacheable, unless indicated otherwise by a Cache-Control
              header field (Section 14.10).

              Is there any purpose for this in RTSP, or could we remove
              this statement and instead rely on the Cache-Control
              header?

         9.   Should proxies strip out the credentials for themselves
              when forwarding messages with Accept-Credentials?

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