Subject: [MMUSIC] RTSP: Implementation-specific status codes

From: Sean Sheedy <[email-masked]>
Date: Fri, 08 Dec 2006 08:57:18 -0800

The current revision of RTSP 2.0 contains the following statement:

        A new status code can only be registered by an IETF standards
        track document.
        
However, on several occasions I've had customers insist that they need
additional, private error status codes.  In such a case, a full-blown
IETF standards document is neither appropriate nor likely to ever be
written.  I think it would be good to have some status code space
reserved to allow for this without sacrificing compatibility with future
versions of the protocol.

Discussing this with Magnus, we came up with two options:
      * Reserve a range of status codes (e.g., 490-499 and 590-599) for
        implementation-specific error codes.
      * Reserve a single status code of each type (e.g., 499 and 599),
        and specify an additional header which implementations may use
        for a free-form error message.

So my questions to the list:
      * Should we reserve implementation-specific status codes?
      * If so, which of the two above approaches is preferable?

Sean

-- 
Sean Sheedy                                         [email-masked]
(503) 531-6427

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

---

From: Kylin Wei <[email-masked]>
Date: Mon, 11 Dec 2006 15:39:18 +0800

I think the first method is better. It's similar to RTP dynamic payload
type.

Kylin Wei 
> -----Original Message-----
> From: Sean Sheedy [mailto:[email-masked]]
> Sent: Saturday, December 09, 2006 12:57 AM
> To: [email-masked]
> Subject: [MMUSIC] RTSP: Implementation-specific status codes
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 11 Dec 2006 14:13:52 +0100

> I think the first method is better. It's similar to RTP dynamic payload

And how is the dynamic payload range applicable to the error codes? The 
dynamic payload range works because it is negotiated prior to use in 
each and every context. I don't see that being applicable for RTSP 
status codes. I think assigning a couple of these to applications would 
only result in confusion about the meaning as they would need to be 
scoped. Therefore to avoid the whole space collision issue I prefer a 
single code with a secondary header that starts with an error code 
identity which contains a vendor id plus the vendors error id. The user 
readable string is still available in the status line of the response.

We also need to remember that the status message class provide basic 
information using its class and that the extension would provide 
improved recovery, especially for proprietary extensions.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
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]
----------------------------------------------------------------------

---

From: Kylin Wei <[email-masked]>
Date: Tue, 12 Dec 2006 09:54:24 +0800

> status codes. 

I mean that we can negotiate these status codes by SETUP request and
response prior to use in every presentation. Client adds 490-499 error code
and their corresponding readable string into SETUP request entity body and
then sends SETUP request to server. Server adds 590-599 error code and their
corresponding readable string into SETUP response entity body and then sends
SETUP response to client. 

Kylin Wei

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 12 Dec 2006 09:15:08 +0100

> SETUP response to client. 

Then how do you handle the stateless OPTIONS and DESCRIBE requests? In 
addition to responses to SETUP itself. There is the potential for using 
feature tags and require header. However my main concern is collision 
based on proxy or server supporting multiple feature modules that try to 
use the same codes, or when the sum of codes are more than the available 
10 numbers or so. 10 error codes per class is not a particular large 
space. I think it will be saturated quite quickly. Please consider that 
how many codes normal PLAY uses.

Cheers

Magnus Westerlund