Subject: Re: [Sip] re: WGLC: resource priority

From: [email-masked]
Date: Thu, 15 Jan 2004 14:44:42 EST

In a message dated 1/15/2004 12:07:39 PM Eastern Standard Time, 
[email-masked] writes:

> How will an *implementer* determine correct behavior without a 
> normative description or reference?  This kind of reference is not 
> unusual in IANA registrations.
> 

[MAP] I think the proper relationship of documents is that the implementor 
will be given a requirements document for equipment to be purchased. (Might be 
another RFC or could be a document produced by the entity that is going to 
purchase the equipement - like the DOD.) That document would point back to the 
RP-header RFC for the definition of that part of the protocol, just like it would 
point to lots of other documents.

The RP-header document does not have to make forward references to those 
documents which might come later or that give all the procedural requirements.

In a message dated 1/15/2004 12:07:39 PM Eastern Standard Time, 
[email-masked] writes:

> How is this any different from any of the other proxy modifications 
> (ex: modifying SDP) which we've decided to avoid by using session 
> policy?  Cooperating user agents can easily find out what the policy is 
> and would only very rarely have to retry a call (no extra round trips 
> for most calls).  Non-cooperating user agents have their non-policy 
> conforming requests rejected.
> 

[MAP] I understand all this, but it doesn't mean that the RP-header spec 
should mandate that Proxies can not change or insert the header, which I believe 
is what you were suggesting. I feel there are legitimate cases in which it 
could do this. For example, if the originating user does not enter a header, the 
proxy uses the default, and might insert the header with the default value. Or, 
if the user includes a header with a priority values higher than what they 
are allowed, the proxy may simply lower the value to what they are allowed and 
forward the call. The RP-header definition should not forbid this.

This is not an issue of "cooperating user agents" finding out what the policy 
is. The user (person) pushes a button and the UA (telephone) codes an INVITE 
based on what buttons they pushed. Some networks/service providers may not 
want to reject the call and make the user try it again. It may not be the UA but 
the person who controls the retry or "knows" the policy.

Mike Pierce

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 15 Jan 2004 12:10:07 -0800

On Thursday, January 15, 2004, at 11:44 AM, [email-masked] wrote:

> [MAP] I think the proper relationship of documents is that the 
> implementor will be given a requirements document for equipment to be 
> purchased. (Might be another RFC or could be a document produced by 
> the entity that is going to purchase the equipement - like the DOD.) 
> That document would point back to the RP-header RFC for the definition 
> of that part of the protocol, just like it would point to lots of 
> other documents.
>
> The RP-header document does not have to make forward references to 
> those documents which might come later or that give all the procedural 
> requirements.

I believe that the IANA *registration* does need to have such a forward 
reference and that the IESG will tend to agree with me.

> [MAP] I understand all this, but it doesn't mean that the RP-header 
> spec should mandate that Proxies can not change or insert the header, 
> which I believe is what you were suggesting. I feel there are 
> legitimate cases in which it could do this. For example, if the 
> originating user does not enter a header, the proxy uses the default, 
> and might insert the header with the default value. Or, if the user 
> includes a header with a priority values higher than what they are 
> allowed, the proxy may simply lower the value to what they are allowed 
> and forward the call. The RP-header definition should not forbid this.
>
> This is not an issue of "cooperating user agents" finding out what the 
> policy is. The user (person) pushes a button and the UA (telephone) 
> codes an INVITE based on what buttons they pushed. Some 
> networks/service providers may not want to reject the call and make 
> the user try it again. It may not be the UA but the person who 
> controls the retry or "knows" the policy.

The UA should know the policy.  There is no technical reason it can't 
know or collect the policy and then use the appropriate policy. That's 
what the session policy mechanism is for. However, there are a number 
of technical problems related to security we get when proxies start to 
insert or modify RP.

thanks,
-rohan