Subject: [MMUSIC] How to identify the updated RTSP specification ?

From: Thomas Zeng <[email-masked]>
Date: Thu, 24 Apr 2003 18:39:02 -0700

Dear MMUSIC Mailing List:

During last week's RTSP teleconference, we had a discussion on how to
distinguish the updated RTSP (i.e., the ongoing work
around draft-ietf-mmusic-rfc2326bis-03.txt, see
http://rtsp.org/2003/drafts/draft03/draft-ietf-mmusic-rfc2326bis-03.pdf).

There is enough change on the table that we feel version number should be
increased to avoid confusion when RTSP server and client might be
implementing the old (rfc2326) and the new RTSP spec (will be a new RFC).

Should we increase the minor version to say RTSP/1.1, or should we up the
major version (to say RTSP/2.0)?

Your comments are welcome.

Thanks,
thomas

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

---

From: Colin Perkins <[email-masked]>
Date: Fri, 25 Apr 2003 09:23:09 -0400

>implementing the old (rfc2326) and the new RTSP spec (will be a new RFC).

Okay, that makes sense.

>major version (to say RTSP/2.0)?

If implementations of the two specifications can still interwork, albet
with reduced functionality, then I'd go for RTSP/1.1.  

Colin

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 25 Apr 2003 09:28:56 -0400

Unless there is a real and significant backwards-compatibility issue, I 
would strongly recommend against this. It gratuitously breaks existing 
implementations and greatly increases the deployment pain and confusion.

---

From: Colin Perkins <[email-masked]>
Date: Fri, 25 Apr 2003 09:35:50 -0400

It may be less painful in the long run than a long list of supported
features tags, etc.  

Colin

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 25 Apr 2003 09:39:31 -0400

To make a more informed communications, I would like to have a clear 
list of issues that would interfere with backward-compability.

---

From: Rob Lanphier <[email-masked]>
Date: 25 Apr 2003 19:10:29 -0700

Read the draft.  You are a co-author after all  ;-)

Rob

-- 
Rob Lanphier, Helix Community Coordinator - RealNetworks
http://helixcommunity.org http://rtsp.org http://realnetworks.com

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 28 Apr 2003 09:39:31 +0200

Hi Henning,

The major incompatibilities are:

1. State machine change. A old client that want to play a media again 
after reaching the end of the media may not be able to restart.

2. Transport header changes:
    - Defined extensible
    - New source and destination header types that handle lists and IPv6 
addresses
 
Plus all the small things that really are quite a number of. Depending 
on the use case you might be able to avoid most of them.

The three options available to us in this question are:

1. Stay with version 1.0 and use feature tags to allow clients and 
server to know that the other party supports the functionality. Feature 
tags will still be need within a version to detect functionality support.

2. Go to version 1.1, i.e. a minor version upgrade. By looking into RFC 
2616 and RFC 2145 the accepted changes shall not effect the general 
parsing mechanism. And from RFC 2145 the following quote can be made:

       It is, and has always been, the explicit intent of the
      HTTP specification that the interpretation of an HTTP message
      header does not change between minor versions of the same major
      version.

Another interesting quote is:

   One consequence of these rules is that an HTTP/1.1 message sent to an
   HTTP/1.0 recipient (or a recipient whose version is unknown) MUST be
   constructed so that it remains a valid HTTP/1.0 message when all
   headers not defined in the HTTP/1.0 specification [1] are removed.

3. Change the major version number, i.e. version 2.0.

The big questions to consider is:
- What effect on deployment will a change of the version number?
- What is acceptable from the protocol side?

To the second question the quotes seems to indicate that we would be 
forced to a version 2.0 for what we have done. We have after all changed 
a rather large number of header syntax's. I don't know it this is a good 
thing for deployment.

More input into this question is encouraged.

Best Regards

Magnus

-- 

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]