Re: Query related to Expires header with value 0 in INVITE

Dale Worley wrote:
> On Tue, 2008-12-02 at 16:53 -0500, Paul Kyzivat wrote:
>> As I read 3261, a proxy can't do this. The section on adding headers 
>> from the URI to the message is in section 8, for UACs. In section 16, 
>> for proxies, there is no comparable language. Instead, the proxy must 
>> remove any parameters that aren't allowed in the R-URI, which would 
>> include the headers. And it may indeed add additional headers, but I 
>> believe it is restricted in doing so by Table 2. Table 2 doesn't permit 
>> the proxy to add, modify, or delete an Expires header.
>>
>> Now this does seem a bit inconsistent. If a URI in a 3xx includes 
>> headers, then they would apply if the 3xx is returned to the UAC, but 
>> not apply if the 3xx is recursed by a proxy.
> 
> Interesting...  People have discussed proxies for a long time as if they
> handled target URIs similarly to UASs generating initial requests, that
> is, header-parameter parts are extracted from the request-URI and turned
> into headers.

Its amazing isn't it, what we think the specs say vs. what they actually 
say?

I have to admit that before replying to you I wasn't certain where 
headers in URIs were applied. I had to review 3261 before I decided that 
it was only UACs, not Proxies.

> Looking at RFC 3261 section 16.6 step 2, none of this is discussed.
> Step 5 says "The proxy MAY add any other appropriate header fields to
> the copy at this point." which seems to allow the proxy great latitude.

Proxies *do* have a lot of latitude. But they are constrained by Table 
2. I know a lot of people don't like table 2 - there are a lot of 
limitations in what it can describe, and it isn't maintained as well as 
it might be. Yet there are things, like this, that are not stated 
anywhere else.

> Table 2 does forbid the proxy from modifying the Expires header.  But
> perhaps that's an oversight? 

We need to input from a real old-timer to answer that. Its before my time.

> One could also argue that the proxy rules
> apply to UACs when they're recursing on 3xx responses, as they're
> "acting like proxies" then.

That would have been one way to do it. But that isn't how it was written 
up. And they can't be exactly the same. A UAC can act on an http: URI in 
a 3xx, where a proxy isn't permitted to.

What this will really do is revive all the chatter about banning forking 
and recursing on 3xx.

	Thanks,
	Paul
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip