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

From: [email-masked]
Date: Wed, 14 Jan 2004 21:25:48 EST

In a message dated 12/31/2003 4:46:50 PM Eastern Standard Time, 
[email-masked] writes:

> 1. There is no normative description of the behavior of SIP devices 
> which receive a particular priority value.  Some specifications needs 
> to either specify detailed behavior for specific priority values, or 
> the detailed semantics of those values.  I think this belongs in the 
> IANA registration of each namespace, but those references are currently 
> very thin.  I made some specific comments to this end in the 
> appropriate sections.
> 

[MAP] I believe this document should be limited to the definition of the data 
(header) and leave detailed behaviour and procedures to other documents that 
define specific services/capabilities which use it. It should not specify 
detailed behaviour for specific priority values. The references to IANA 
registration are thin because they only describe what IANA needs to deal with - 
assigning an ordered set of names for the priority levels for each "namespace".

> 
> 3. Finally, the document shows that proxies can modify, insert, and 
> delete the RP header. I don't think this is a good idea. Where 
> cooperating UAs and proxies need to agree on an RP value, I believe the 
> session policy mechanism can be used.  A proxy can reject the message 
> for policy reasons (use a lower/higher/specific resource-value) and the 
> UA can retry the request with these new values.
> 

[MAP] While it may not be normal for a proxy to modify or delete an RP 
header, there may be services defined using this header that are based on proxies 
doing exactly that. For example, an originator tries to place a call using a 
high priority header. The proxy authenticates, determines tha the user is only 
authorized a lower priority level, automatically lowers it by changing the RP 
header, and forwards the call on its way, without requiring the UA to retry the 
call. Other documents would describe various operations, possibly including 
some cases in which a proxy can not modify the RP header.

Mike Pierce

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 15 Jan 2004 09:08:51 -0800

Hi Mike,

comments inline...

On Wednesday, January 14, 2004, at 06:25 PM, [email-masked] wrote:
> [MAP] I believe this document should be limited to the definition of 
> the data (header) and leave detailed behaviour and procedures to other 
> documents that define specific services/capabilities which use it. It 
> should not specify detailed behaviour for specific priority values. 
> The references to IANA registration are thin because they only 
> describe what IANA needs to deal with - assigning an ordered set of 
> names for the priority levels for each "namespace".

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

> header, there may be services defined using this header that are based 
> on proxies doing exactly that. For example, an originator tries to 
> place a call using a high priority header. The proxy authenticates, 
> determines tha the user is only authorized a lower priority level, 
> automatically lowers it by changing the RP header, and forwards the 
> call on its way, without requiring the UA to retry the call. Other 
> documents would describe various operations, possibly including some 
> cases in which a proxy can not modify the RP header.

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.

thanks,
-rohan