Subject: Re: [MMUSIC] Is Supported Header in RTSP changeable by a proxy ?

From: Magnus Westerlund <[email-masked]>
Date: Tue, 19 Oct 2004 13:16:14 +0200

Hi,

Lets revive this issue so that I can edit in the resolution if possible.

I had proposed that we consider either of the solutions:

> 1. Define a separate proxy-supported header, similar to the 
> proxy-require header. This header would then be populated by the 
> requester with all proxy-related feature tags that it supports. Then the
> proxy would simply forward the header with the common set of tags it 
> support. The server simply echoes the header in the response. The 
> proxies should ignore the header in the response messages.
> 
> 2. Allow the server to modify the supported headers to only contain 
> functionality it also supports.

Sunil Bhargo:
>      Therefore i am ok with the suggestion number 2
> that you have mentioned. Please let me know your
> suggestions.

When I looked at this now, I think we have a serious problem with 
proposal number 2. The problem is that the proxy chain can remove 
feature tags that are applicable only to servers. This is not good as 
the proxies could prevent the client or server from learning about a 
feature that the proxy will simply do pass-through on.

The only solution that I currently can think of for this problem would 
be to prefix the feature tags with its type; proxy, server or both. 
However that may be problematic to deploy.

I would also like to respond to some of Sunil's comments:
>      We also need to take into consideration that the
> client sometime might not be aware of the existence of
> the proxy. This can be in the cases of transparency or
> accelerated proxy deployment. In such cases even if we
> add the proxy-Supported header the client is not going
> to send it but will send the Supported header. 

I don't think this is a real issue, if a proxy sees a Supported header 
but no Proxy-Supported, the first proxy in the chain simply adds it. It 
is after all also the proxy that needs to learn if it can support any 
functionality that the session may consider. Also I think that we in 
this specification can simply request that any updates client simply 
always add the proxy-supported header, if it intends to use supported.

>    Also one problem in having a separate header
> proxy-supported and Supported is that even if the
> client receives both the proxy-supported and supported
> header in the response it should use the common set of
> features in both the proxy-supported and nsupported
> headers and this can be acheived by only having the
> supported header.

Yes, I agree that one needs to consider what the common set is. However 
that is the issue for the requester, that desires to use a feature. If 
that feature is supported by the requester it needs to understand it, 
and will also be able to determine which server and/or proxy features 
that needs to be supported to make the desired feature work. Thus I 
think it much easier for the requesting peer to make that combination 
than for an entity in the middle to do it.

Having two headers also allows for a nice separation of any feature tag 
depending on its type. Server only features goes in supported, proxy 
only goes in proxy-supported and feature for both domains goes in both.

This also gives a client that are capable of bypassing proxies to do it 
if required to get a certain feature that are not supported by the proxy 
chain.

Please comment!

Cheers

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

---

From: sunil bhargo <[email-masked]>
Date: Tue, 19 Oct 2004 11:17:28 -0700 (PDT)

Hi Magnus,
          Thanks for the reply. I agree to your
concerns regarding the option 2 of not modifying the
Supported header by the intervening proxy or server. 
I am ok with option 1. In case of proxy chain then the
client will receive the common set of features in the
proxy-supported header. But what is the solution about
clients supporting the previous versions ,that is only
the supported header. In that case i think the proxy
should be allowed to write the supported headers. 
          Just wanted add one thing that the
user/player should never make the bypassing decision
based on the Supported headers feature-tags as
inclusion of any feature-tag in Supported header
should be optional session feature and the
player/client should be able to live with/without this
feature tag. If something is mandatory then it should
be included  into require and proxy-require headers.
Can we add the  text that the client is advised to use
only the common set of features in proxy-supported and
supported headers ?

sunil bhargo
--- Magnus Westerlund <[email-masked]>

> [email-masked]

_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

---

From: Awais Ali <[email-masked]>
Date: Tue, 19 Oct 2004 11:27:08 -0700

Hi all,

I can't seem to figure out the purpose of  derived-from attribute in 
section 9 of draft-ietf-mmusic-ice-02. It is mentioned anywhere in the 
draft. Can anybody explain that to me?

Regards
Ali

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Oct 2004 11:23:16 +0200

> should be allowed to write the supported headers.

First if the client do not indicate support for the new specification. 
Then it will ignore the Supported header, because that is also added by 
this specification. RFC 2326 only has Require and Unsupported to make 
this negotiation. Thus I don't see a problem with supported. A RFC 2326 
client will never add it, and thus will never need to interpret it. If 
proxy adds the proxy-supported header to a request it should be ignored 
by the receiving client.

It might be an issue if there is a proxy in the chain which do not 
support the new specification. Thus one should consider using 
proxy-require: play.basic to ensure that all proxies do correctly handle 
the supported header.

Please note that it will be mandatory to handle the supported and 
proxy-supported headers.

> be included  into require and proxy-require headers.

First, I like to clarify that if one uses Supported and proxy-supported 
it is to find out if the proxies and server do understand a feature that 
one likes to use. It might be that one requires the feature to work. 
Therefore I don't think that it is reasonable after a exchange with 
Supported and Proxy-Supported that results in that a feature is not 
supported should still do Require and Proxy-Require. Supported is 
intended to find out things before one actually tries them. Require is 
to ensure that this functionality is in place as the request actually 
requires them.

Thus as I see it a client may very well decided to bypass a proxy-chain 
based on the Proxy-Supported header.

 > only the common set of features in proxy-supported and

I do agree for a need to add text explaining that feature tags that are 
classified as needing support by both servers and proxies, needs to 
considered using the common set from both headers.

Cheers

Magnus Westerlund

---

From: sunil bhargo <[email-masked]>
Date: Wed, 20 Oct 2004 03:38:01 -0700 (PDT)

Hi Magnus,
        thanks for the reply. I agree now on the
bypassing decision. but just one clarification below
:-

> client will never add it, and thus will never need
to
> interpret it. If 
> proxy adds the proxy-supported header to a request
it > should be ignored by the receiving client.

> It might be an issue if there is a proxy in the
chain > which do not 

> Please note that it will be mandatory to handle the
         What i meant by backward compatibility is not
with RFC2326 but with client complying to
rfc2326bis02-07. I am not sure whether a client can
say that it complies to a draft. If it can then the
client will only send the supported header and no
proxy-supported header. So should the new 
specification proxies fall to not modifying the
supported header or should it be modified.

thanks,
sunil bhargo

__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Oct 2004 13:00:57 +0200

Hi,

> supported header or should it be modified.

A draft is a draft and may change at any point in time. If one starts 
implementing draft documents, one must be ready to update that 
implementation at any time when updates becomes available. Any draft 
implementation should not be commerially or large scale deployed at all. 
To be able to do good technical work we need to possibility to change 
things, thus we can't have such arguments that we need to preserver 
compatibility with a previous draft version. Especially not when draft 
still has some way to go before being ready for WG last call.

Cheers

Magnus Westerlund

---

From: sunil bhargo <[email-masked]>
Date: Wed, 20 Oct 2004 08:42:58 -0700 (PDT)

We have resoloution then if nobody has any additions.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 20 Oct 2004 23:48:00 -0400

This attribute is a leftover from previous versions and is not needed. 
It'll be removed in the next rev of the draft.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                        FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com