Subject: RTSP Tweaks

From: Rob Lanphier <[email-masked]>
Date: Wed, 07 Jan 1998 20:18:58 -0800

During the last call on RTSP, there were a few nits with the draft that
were pointed out.  We just submitted draft-07 of RTSP, which will be
available shortly.  To let you know what the changes are, I've included
both a small list of the changes here, and a context diff of the text just
before it gets run through our little paginator (sorry of the extra junk).

      * Added "Persistently suspicious behavior" to Security
        Considerations (Section 16)
      * Fixed examples in the explanation of NPT (Section 3.6)
      * Session identifiers MUST be chosen at random and must be at least
        8 octets long (Section 3.4). (Formerly, this was only SHOULD).
      * Made XXXX reference to SDP more clearly belong to SDP in Appendix
        C (still needs to be fixed when SDP gets an RFC number)

It is hoped that none of these changes are particularly controversial.
Though the IESG last call is over, please let us know if any of these
changes present a problem.

Rob

Context diff below is in the format:

*** n,n ****
    stuff
!   old stuff
    stuff
--- n,n ----
    stuff
!   new stuff
    stuff
***************

------
*** rtspmod.txt.old     Wed Jan  7 16:28:32 1998
--- rtspmod.txt Wed Jan  7 17:00:07 1998
***************
*** 1,7 ****
  Internet Engineering Task Force                                   MMUSIC WG
  Internet Draft                          H. Schulzrinne, A. Rao, R. Lanphier
! draft-ietf-mmusic-rtsp-06.txt             Columbia U./Netscape/RealNetworks
! November 21, 1997                                     Expires: May 21, 1998
  
                    Real Time Streaming Protocol (RTSP)
  
--- 1,7 ----
  Internet Engineering Task Force                                   MMUSIC WG
  Internet Draft                          H. Schulzrinne, A. Rao, R. Lanphier
! draft-ietf-mmusic-rtsp-07.txt             Columbia U./Netscape/RealNetworks
! January 7, 1998                                       Expires: July 7, 1998
  
                    Real Time Streaming Protocol (RTSP)
  
***************
*** 758,765 ****
  3.4 Session Identifiers
  
       Session identifiers are opaque strings of arbitrary length. Linear
!    white space must be URL-escaped. A session identifier SHOULD be chosen
!    randomly and SHOULD be at least eight octets long to make guessing it
     more difficult. (See Section 16.)
  
       session-id   =   1*( ALPHA | DIGIT | safe )
--- 758,765 ----
  3.4 Session Identifiers
  
       Session identifiers are opaque strings of arbitrary length. Linear
!    white space must be URL-escaped. A session identifier MUST be chosen
!    randomly and MUST be at least eight octets long to make guessing it
     more difficult. (See Section 16.)
  
       session-id   =   1*( ALPHA | DIGIT | safe )
***************
*** 823,830 ****
  
     Examples:
       npt=123.45-125
!      npt=12:05:35.3
!      npt=now
  
       The syntax conforms to ISO 8601. The npt-sec notation is optimized
       for automatic generation, the ntp-hhmmss notation for consumption
--- 823,830 ----
  
     Examples:
       npt=123.45-125
!      npt=12:05:35.3-
!      npt=now-
  
       The syntax conforms to ISO 8601. The npt-sec notation is optimized
       for automatic generation, the ntp-hhmmss notation for consumption
***************
*** 3441,3447 ****
     Authentication:
            Servers SHOULD implement both basic and digest [6]
            authentication. In environments requiring tighter security for
!           the control messages, transport layer mechanims such as TLS
            (RFC XXXX) SHOULD be used.
  
     Stream issues:
--- 3441,3447 ----
     Authentication:
            Servers SHOULD implement both basic and digest [6]
            authentication. In environments requiring tighter security for
!           the control messages, transport layer mechanisms such as TLS
            (RFC XXXX) SHOULD be used.
  
     Stream issues:
***************
*** 3452,3463 ****
            considerations brought up in these specifications (even when
            non-standard equivalents are used in place of said protocols).
  
! A RTSP Protocol State Machines
  
       The RTSP client and server state machines describe the behavior of
     the protocol from RTSP session initialization through RTSP session
     termination.
! 
     State is defined on a per object basis. An object is uniquely
     identified by the stream URL and the RTSP session identifier. Any
     request/reply using aggregate URLs denoting RTSP presentations
--- 3452,3471 ----
            considerations brought up in these specifications (even when
            non-standard equivalents are used in place of said protocols).
  
!    Persistantly suspicious behavior:
!           RTSP servers SHOULD return error code 403 (Forbidden) upon
!           receiving a single instance of behavior which is deemed a
!           security risk. RTSP servers SHOULD also be aware of attempts to
!           probe the server for weaknesses and entry points and MAY
!           arbitrarily disconnect and ignore further requests clients
!           which are deemed to be in violation of local security policy.
  
+ Appendix A: RTSP Protocol State Machines
+ ##REMOVEME
       The RTSP client and server state machines describe the behavior of
     the protocol from RTSP session initialization through RTSP session
     termination.
! ##REMOVEME
     State is defined on a per object basis. An object is uniquely
     identified by the stream URL and the RTSP session identifier. Any
     request/reply using aggregate URLs denoting RTSP presentations
***************
*** 3465,3480 ****
     states of all the streams. For example, if the presentation /movie
     contains two streams, /movie/audio and /movie/video, then the
     following command:
! 
       PLAY rtsp://foo.com/movie RTSP/1.0
       CSeq: 559
       Session: 12345
! 
     will have an effect on the states of movie/audio and movie/video.
! 
       This example does not imply a standard way to represent streams in
       URLs or a relation to the filesystem. See Section 3.2.
! 
     The requests OPTIONS, ANNOUNCE, DESCRIBE, GET_PARAMETER, SET_PARAMETER
     do not have any effect on client or server state and are therefore not
     listed in the state tables.
--- 3473,3488 ----
     states of all the streams. For example, if the presentation /movie
     contains two streams, /movie/audio and /movie/video, then the
     following command:
! ##REMOVEME
       PLAY rtsp://foo.com/movie RTSP/1.0
       CSeq: 559
       Session: 12345
! ##REMOVEME
     will have an effect on the states of movie/audio and movie/video.
! ##REMOVEME
       This example does not imply a standard way to represent streams in
       URLs or a relation to the filesystem. See Section 3.2.
! ##REMOVEME
     The requests OPTIONS, ANNOUNCE, DESCRIBE, GET_PARAMETER, SET_PARAMETER
     do not have any effect on client or server state and are therefore not
     listed in the state tables.
***************
*** 3590,3596 ****
                     TEARDOWN          Init
                     SETUP             Recording
      
! B Interaction with RTP
  ##REMOVEME
       RTSP allows media clients to control selected, non-contiguous
     sections of media presentations, rendering those streams with an RTP
--- 3598,3604 ----
                     TEARDOWN          Init
                     SETUP             Recording
      
! Appendix B: Interaction with RTP
  ##REMOVEME
       RTSP allows media clients to control selected, non-contiguous
     sections of media presentations, rendering those streams with an RTP
***************
*** 3636,3642 ****
     sequence parameter of the RTP-Info (Section 12.33) header provides the
     first sequence number of the next segment.
  
! C Use of SDP for RTSP Session Descriptions
  
       The Session Description Protocol (SDP, RFC XXXX) may be used to
     describe streams or presentations in RTSP. Such usage is limited to
--- 3644,3650 ----
     sequence parameter of the RTP-Info (Section 12.33) header provides the
     first sequence number of the next segment.
  
! Appendix C: Use of SDP for RTSP Session Descriptions
  
       The Session Description Protocol (SDP, RFC XXXX) may be used to
     describe streams or presentations in RTSP. Such usage is limited to
***************
*** 3712,3718 ****
     media attribute ``rtpmap'' is used to specify what the media is. The
     ``encoding name'' within the ``rtpmap'' attribute may be one of those
     specified in RFC 1890 (Sections 5 and 6), or an experimental encoding
!    with a ``X-'' prefix as specified in RFC XXXX. Codec-specific
     parameters are not specified in this field, but rather in the ``fmtp''
     attribute described below. Implementors seeking to register new
     encodings should follow the procedure in RFC 1890. If the media type
--- 3720,3726 ----
     media attribute ``rtpmap'' is used to specify what the media is. The
     ``encoding name'' within the ``rtpmap'' attribute may be one of those
     specified in RFC 1890 (Sections 5 and 6), or an experimental encoding
!    with a ``X-'' prefix as specified in RFC XXXX (SDP). Codec-specific
     parameters are not specified in this field, but rather in the ``fmtp''
     attribute described below. Implementors seeking to register new
     encodings should follow the procedure in RFC 1890. If the media type
***************
*** 3842,3850 ****
     streams, respectively. The URL rtsp://example.com/movie/ controls the
     whole movie.
  
! D Minimal RTSP implementation
! 
! 
  
  D.1 Client
  
--- 3850,3856 ----
     streams, respectively. The URL rtsp://example.com/movie/ controls the
     whole movie.
  
! Appendix D: Minimal RTSP implementation
  
  D.1 Client
  
***************
*** 3979,3985 ****
       * Parse and include the WWW-Authenticate header
       * Implement Basic Authentication and Digest Authentication
  
! E Changes
  
     Since draft 05 (October 28, 1997 version) of RTSP, the following
     changes were made:
--- 3985,4002 ----
       * Parse and include the WWW-Authenticate header
       * Implement Basic Authentication and Digest Authentication
  
! Appendix E: Changes
! 
!    Since draft 06 (November 21, 1997 version) of RTSP, the following
!    changes were made:
! 
!      * Added "Persistantly suspicious behavior" to Security
!        Considerations (Section 16)
!      * Fixed examples in the explanation of NPT (Section 3.6)
!      * Session identifiers MUST be chosen at random and must be at least
!        8 octets long (Section 3.4). (Formerly, this was only SHOULD).
!      * Made XXXX reference to SDP more clearly belong to SDP in Appendix
!        C (still needs to be fixed when SDP gets an RFC number)
  
     Since draft 05 (October 28, 1997 version) of RTSP, the following
     changes were made:
***************
*** 4022,4028 ****
  
     Since draft 03 (July 30, 1997 version) of RTSP, the following changes
     were made:
! 
       * PEP was removed, Require header returns. Motivation: We explored
         using the W3C's PEP proposal for this functionality. However,
         Require, Proxy-Require, and Unsupported allow the addition of
--- 4039,4045 ----
  
     Since draft 03 (July 30, 1997 version) of RTSP, the following changes
     were made:
! ##REMOVEME
       * PEP was removed, Require header returns. Motivation: We explored
         using the W3C's PEP proposal for this functionality. However,
         Require, Proxy-Require, and Unsupported allow the addition of
***************
*** 4043,4049 ****
  
     Between draft 02 (March, 1997) and draft 03 (July, 1997), the
     following changes were made:
! 
       * Definition of RTP behavior.
       * Definition of behavior for container files.
       * Remove server-to-client DESCRIBE request.
--- 4060,4066 ----
  
     Between draft 02 (March, 1997) and draft 03 (July, 1997), the
     following changes were made:
! ##REMOVEME
       * Definition of RTP behavior.
       * Definition of behavior for container files.
       * Remove server-to-client DESCRIBE request.
***************
*** 4066,4071 ****
--- 4083,4089 ----
         some methods may be allowed only on a particular type of URL.
       * Example showing the use of aggregate/presentation control using a
         single RTSP session has been added.
+ 
       * Support for the PEP (Protocol Extension Protocol) headers has been
         added.
       * Server-Client DESCRIBE messages have been renamed to ANNOUNCE for
***************
*** 4074,4080 ****
     Note that this list does not reflect minor changes in wording or
     correction of typographical errors.
  
! F Author Addresses
  
     Henning Schulzrinne
     Dept. of Computer Science
--- 4092,4098 ----
     Note that this list does not reflect minor changes in wording or
     correction of typographical errors.
  
! Appendix F: Author Addresses
  
     Henning Schulzrinne
     Dept. of Computer Science
***************
*** 4098,4104 ****
     USA
     electronic mail: [email-masked]
  
! G Acknowledgements
  
     This draft is based on the functionality of the original RTSP draft
     submitted in October 96. It also borrows format and descriptions from
--- 4116,4122 ----
     USA
     electronic mail: [email-masked]
  
! Appendix G: Acknowledgements
  
     This draft is based on the functionality of the original RTSP draft
     submitted in October 96. It also borrows format and descriptions from