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

From: "Thomas Zeng" <[email-masked]>
Date: Sun, 23 Jan 2005 22:01:55 -0800

Hi Magnus:

A belated reply is inlined.

Thanks,
-Thomas

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Saturday, December 25, 2004 7:47 AM
> To: Thomas Zeng
> Cc: [email-masked]
> Subject: Re: Question on the Usage of Feature Tags in 
> draft-ietf-mmusic-rfc2326bis-08.txt
> 
> 
> 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?

This looks OK to us.
> 
> 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.
> >  
> > What is your interpretation? What does the group think?
> >  
> > Thanks,
> > -Thomas
> 
> 
> -- 
> 
> 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]
> 
> 

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