Subject: Re: [MMUSIC] RTSP header table version 1

From: Gayathri Ramakrishnan <[email-masked]>
Date: Fri, 03 May 2002 16:26:06 +0530

Hi Magnus,

Comments in-line ...

Magnus Westerlund wrote:
> 
> Hi,
> 
> I will start with commenting on your proxy table.
> 
> - Data header: I believe it should be both a and m attribute for proxies.

This is correct. If the server doesn't send the Date header, then
the proxy has to append it.

> 
> - From header: I don't see any harm in allowing a proxy to add to the
> from field but what is the reason for it? Shouldn't the from filed
> contain the email of the responsible request issuing user? Shouldn't
> this header also have an "r"? Also don't understand the 4xx designation
> on this header. If the from header shall be usable it must be added onto
> request.

When the proxy is sending the 4xx response, then it should add this
header. This response is not coming from the origin server, but 
instead proxy itself is able to find that the request is not
in the correct syntax or in any such cases.

> 
> - if-match header: This seem to also be a header requiring "r" note.

This applies for a caching proxy.

> 
> - proxy-authenticate: In my opinion this should have an "amr" usage. I
> base this on what the HTTP spec says about the header.

I agree.

> 
> - Proxy-require: Should this header also be possible to add/concatenate
> by proxies?

I don't think so.  Could you please tell me in what cases we
would be having this scenario of add/concatenate these headers ?

> 
> - public seems to to require that a proxy can both add, delete and
> modify the header and of course read it, making it "admr".

If proxy, is to send the response for OPTIONS request, then it
should add this header, else whatever is being passed from the
server, it should forward them.

> 
> - Server: I don't agree that a proxy may add this header. RFC 2616 has a
> MUST NOT modify this header.

This is for the 4xx response & some other error scenarios. 
For eg. in case where the client's
request doesn't confirm to the RFC sytax or the OS doesn't exist
then in these cases, proxy will generate the appropriate response. In
such cases, it has to add this header.

Thanks,
- Gayathri

> 
> Gayathri Ramakrishnan wrote:
> 
> >As for the case of the 'Retry-After' header:
> >
> >In case of a PAUSE,'Retry-After' header cannot be present
> >in the response ,as the client will not prefer to continue
> >receiving the media data after issuing a PAUSE.
> >
> Yes, I agree,
> 
> >
> >
> >In case of a PLAY, 'Retry-After' header should be allowable
> >in the response.
> >The above could hold true in case of multiple PLay Requests.
> >
> >Lets say we assume a scenario with 3 play requests having
> >range as 10 - 20 , 25-30 , 35 - 40.
> >Then incase when the second play request (25 - 30) gets
> >a 'Retry-After' response , the media client implementation should
> >take care of only sending the play request with range as
> >25 - 30.
> >
> >or
> >
> >Would it be more appropriate to assume that once the connection
> >establishment phase is over (i.e with setup - setting of
> >transport parameters) then we would never have
> >a 'Retry-After' header in the response.
> >
> >
> >I am not sure as to whether we need to look into from
> >this perspective or mark it as "not applicable " for
> >play request.
> >
> I think we can assume that the client will not receive a 3xx response
> after setup. If the server want's to do redirect at that time it should
> use the REDIRECT method. The question is on which methods you could get
> service unavailable. For me it seems reasonable that you should not get
> that answer after the client has established a session. So I think we
> can remove the Retry-after from all methods except the stateless and setup.
> 
> Cheers
> 
> Magnus Westerlund
> 
> Multimedia Technologies, Ericsson Research ERA/T/VA
> ----------------------------------------------------------------------
> Ericsson Radio Systems AB  | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email-masked]

-- Gayathri --

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

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 03 May 2002 14:02:40 +0200

Hi Gayathri,

Thanks for a rewarding discussion.

>in the correct syntax or in any such cases.
I don't agree with you. If you look at the from header description in 
RFC 2616 it says clearly that the header should contain the address of 
the human user responsible for the REQUEST. So if the server or proxy 
generates a response it should not change the header. I think the only 
reasonable proxy is that is must be able to read it, i.e. an "r" 
designation. If a proxy generates request that is not intended for a 
specific user, the proxy takes the role of client and therefore may add 
a from header with the administrator of the proxy.

>would be having this scenario of add/concatenate these headers ?
If you have multiple proxies in series and a proxy has requirements on 
the upstream proxies that they should behave in a certain way, isn't it 
logical to allow that proxy to be able to add on the header?

>server, it should forward them.
I do believe your in error regarding this. Please look at the last 
paragraph of the definition of the Public header in RFC 2068 you will 
see that this header does only apply "hop by hop" between different 
entities. Therefore it should not forward the header received from the 
server, but instead replace it with its own capabilities.

>such cases, it has to add this header.
My interpretation of that situation is that in a error case the proxy is 
the origin server, due to the fact that it generates the response. 
Therefore it would be allowed to add a Server header. Otherwise it the 
request was forward and a response is returned the Via header shall be 
used. It may be good to add a note about this.

Regards

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A

---

From: Gayathri Ramakrishnan <[email-masked]>
Date: Mon, 06 May 2002 17:40:31 +0530

Hi Magnus,

Thanks. Comments inline...

> a from header with the administrator of the proxy.

Agreed and also since it is a Request Header only.

> logical to allow that proxy to be able to add on the header?

Yes.

> server, but instead replace it with its own capabilities.

You are correct here regarding RFC 2068.  Whatever I had commented
upon holds good for the 'Allow' header. The proxy table should also
be updated with this info. BTW, in RFC 2616, the Public header has
been removed. So does it make sense for us to implement it in
RTSP.

Thanks,
- Gayathri

************************************************************
Gayathri Ramakrishnan
HCL Technologies
Networking Technologies Lab
http://cdn.hcltech.com
*************************************************************

---

From: Aravind Narasimhan <[email-masked]>
Date: Wed, 15 May 2002 13:18:31 -0400

Gayathri Ramakrishnan wrote:

>Hi Magnus,
>
>Some comments on the RTSP header table :
>
>- Bandwidth request header can be considered as 'Not
>  Applicable' in case of the OPTIONS request.
>
One reason we may want the Bandwidth header supported in the OPTIONS 
method is that OPTIONS could be used keep a session from timing out.  We 
may want to server to decide if it can support the bandwidth needs of 
the client while making this decision.  However, is Bandwidth 
availablity a decision making point for timing out a session?  Is this a 
feature that we want to allow in RTSP?  If not, I dont see  any reason 
for have the bandwidth header.

Aravind