Subject: [MMUSIC] Using "Supported" header from

From: Rob Lanphier <[email-masked]>
Date: Thu, 16 May 2002 19:09:15 -0700 (Pacific Daylight Time)

I'm in the process of adding the "Supported" header to RTSP, borrowed from
the latest revisions of SIP.  This is to resolve the issue described here:
http://rtsp.org/bug477427

I've logged this as a new issue, described here:
http://rtsp.org/bug557045

Here's the wording as it exists in the latest SIP spec
   20.37 Supported

   The Supported header field enumerates all the extensions supported by
   the UAC or UAS.

   The Supported header field contains a list of option tags, described
   in Section 19.2, that are understood by the UAC or UAS.  A UA
   compliant to this specification MUST only include option tags
   corresponding to standards-track RFCs. If empty, it means that no
   extensions are supported.

   Example:

     Supported: 100rel

Here's a modified version to put in the RTSP spec:

    Supported

    The Supported header field enumerates all the extensions
    supported by the client or server.  When offered in a request, the
    receiver SHOULD respond with its cooresponding Supported header.

    The Supported header field contains a list of option tags, described
    in Section 3.8, that are understood by the client or the server.

    Example:

      Supported: 100rel

I've taken out the requirement that only standards-track features are
allowed, as it seems too restrictive to me (but that's up for discussion).

In general, I'm not sure how I feel about it.  It doesn't seem to work as
a query-response mechanism, but rather as a "here's what I support"
statement.  It would be nice to have more of a query-response system, like
the "Require" header, only non-fatal (i.e. doesn't return an error
response on the associated request).

Other thoughts?

Rob

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