Subject: [MMUSIC] Question on the Usage of Feature Tags in draft-ietf-mmusic-rfc2326bis-08.txt

From: "Thomas Zeng" <[email-masked]>
Date: Thu, 23 Dec 2004 10:34:25 -0800

Hello Magnus:
 
Merry Christmas.
 
We have been looking at the subject of capability handling which led us to RFC2326bis-08, Chapter 10, where it is suggested that the server uses the Supported header to advertise the list of feature tags it is capable of handling.
 
It is worth clarifying whether the list of tags in the Supported header should be a function of  the request URL or not.
 
For instance, if a client issues a DESCRIBE on a audio only request URL, and the server in its 200 OK response includes the feature tag "com.A_company.video-bit-stream-switching". Is that appropriate? 
 
Clearly video-bit-stream-switching does not apply to an audio-only URL, but one could argue that video-bit-stream-switching is one of the server's capabilities and the client may choose to take advantage of it later on. 
 
What is your interpretation? What does the group think?
 
Thanks,
-Thomas
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: sunil bhargo <[email-masked]>
Date: Fri, 24 Dec 2004 09:11:31 -0800 (PST)

Hi Thomas,

          Clients having the capability to maintain
the server capabilities might require server
capabilities and not url specific capabilities. If the
client and server have exchanged the capabilities
previously. In future if the clients receives the
meta-file having multiple urls for the same content
and the SDP is received Out of Band for these urls
then the client can use the previously determined
capabilities to select which url to use to have best
experience.

          But it also might be argued that if the
client has such capability then it should use the
OPTIONS with "*" to get the server capability. And the
server capabilities will only be sent if url is "*"
and if it is presentation url then the capabilities
pretaining to the media are sent. 

          But I would prefer that the Supported Header
gives the server capabilities instead of the
capabilities related to the url. If the server
capabilities are used then it is still easy for the
client to know what pretains to the current session
(as media capabilities will be subset of total
capabilities). 
          
sunil bhargo

--- Thomas Zeng <[email-masked]> wrote:

> Hello Magnus:
>  
> Merry Christmas.
>  
> We have been looking at the subject of capability
> handling which led us to RFC2326bis-08, Chapter 10,
> where it is suggested that the server uses the
> Supported header to advertise the list of feature
> tags it is capable of handling.
>  
> It is worth clarifying whether the list of tags in
> the Supported header should be a function of  the
> request URL or not.
>  
> For instance, if a client issues a DESCRIBE on a
> audio only request URL, and the server in its 200 OK
> response includes the feature tag
> "com.A_company.video-bit-stream-switching". Is that
> appropriate? 
>  
> Clearly video-bit-stream-switching does not apply to
> an audio-only URL, but one could argue that
> video-bit-stream-switching is one of the server's
> capabilities and the client may choose to take
> advantage of it later on. 
>  

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: Magnus Westerlund <[email-masked]>
Date: Sat, 25 Dec 2004 16:47:19 +0100

Hi Thomas,

My intention with "Supported" is that these are not linked to the URI, 
and instead describe features supported by the client and server 
depending on the direction of the message.

In the case one has features that are media type specific, the ones 
understanding the features, knows that it is media specific. Also the 
definer of a feature must consider if further negotiation of the 
functionality is needed. The Supported mechanism is really only a 
mechanism for intial discovery of support of features. It has the 
meaning like: Hey, here is what I support, please send me what you can.

So I could see that one clarifies this in the next version, I would 
propose to make the following change in the section 14.43, see last 
sentencte of paragraph 2:

    The Supported header field enumerates all the extensions supported by
    the client or server using feature tags. The header carries the
    extensions supported by the message sending entity.  The Supported
    header MAY be included in any request.  When present in a request,
    the receiver MUST respond with its corresponding Supported header.
    Note, also in 4xx and 5xx responses is the supported header included.

    The Supported header field contains a list of feature-tags, described
    in Section 3.7, that are understood by the client or server. The list
    is not depending on the request URI context, and describes the client
    and server capabilities in general.

What do you say?

Merry Chrismtas and a Happy new Year

Magnus

Thomas Zeng wrote:
> Hello Magnus:
>  
> Merry Christmas.
>  
> We have been looking at the subject of capability handling which led us 
> to RFC2326bis-08, Chapter 10, where it is suggested that the server uses 
> the Supported header to advertise the list of feature tags it is capable 
> of handling.
>  
> It is worth clarifying whether the list of tags in the Supported 
> header should be a function of  the request URL or not.
>  
> For instance, if a client issues a DESCRIBE on a audio only request URL, 
> and the server in its 200 OK response includes the feature tag 
> "com.A_company.video-bit-stream-switching". Is that appropriate?
>  
> Clearly video-bit-stream-switching does not apply to an audio-only URL, 
> but one could argue that video-bit-stream-switching is one of the 
> server's capabilities and the client may choose to take advantage of it 
> later on.
>  

-- 

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]