Subject: [Sip] Resource Priority header - multiple namespaces

From: [email-masked]
Date: Wed, 25 Jun 2003 13:58:02 EDT

In a message dated 6/25/2003 7:13:23 AM Eastern Standard Time, 
[email-masked] writes:

> > 
> > 3. The definition of the Resource-Priority header should not allow 
> > multiple resource values to be carried. I am unaware of any requirement 
> > for this. The use described always needs exactly one value within one 
> > namespace. Anything beyond this will bring on questions like "Which 
> > priority has priority?"
> > 
> > Note: REQ-13 says that "Some UAs will need to support multiple different 
> > priority schemes". It does not say that the indication (header) needs to 
> > support a "list of names".
> 
> The only reason that I can think of is to support the case where I'm 
> operating in a multi-namespace environment and where I want to say 
> "please use namespace X if you can, or Y if that suits you". I don't 
> know whether this is likely to occur in practice. The priority 
> resolution is easy - the entity receiving the header ignores the stuff 
> it doesn't know and picks the highest priority among those it does. 
> However, I agree that this is probably more complication than warranted. 
> The Accept-R-P header can achieve roughly the same thing, with less 
> trouble, albeit more round-trips.
> 

This seems to be a very significant conceptual difference of ideas on what 
the namespace is used for and how. I believe the "namespace" exists only to 
allow an easy-to-manage way to define different sets of priority levels for 
different cases. Definition of a priority level "high" for one case is independent 
from "high" for the other. Namespace does not exist for use by the user.

In practice, in actual use, the orginator does not select (and then maybe 
change, as you wrote) a namespace. The device is configured to use the right one, 
while the person selects the proper priority level. If there are cases in 
which one of several namespaces could be used, it is not the human who selects 
the "namespace", except indirectly by what is dialed. The human in unaware of 
this concept. For example, if a military phone is setup and authorized to handle 
MLPP priorities, an emergency worker with GETS access may use the phone, 
perform the magic procedures to get such GETS authorization, which may result in a 
Resource-Priority header being sent with namespace=gets, priority=enabled (to 
use the values currently in the draft). It does not result in sending two 
different priority values with some other entity being given the chance to decide 
which is better. In fact, the treatments may be different, with one using 
preemption and the other queuing for resources.

No, it should never happen that the user would ask "please use namespace X if 
you can, or Y if that suits you". The request is always "use namespace X with 
priority level Z and do the best you can", (with the actual user being 
unaware of the namespace). If the call is blocked, the user may do something else 
(which might not have anything to do with a namespace).

I'm mostly afraid that any attempts to describe use of multiple namespaces 
will cause significant difficulty in moving this draft forward, since there are 
lots of unexplained interactions.

Mike Pierce
Artel

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 27 Jun 2003 18:37:48 -0400

[email-masked] wrote:

> one case is independent from "high" for the other. Namespace does not 
> exist for use by the user.

Why not?

> 
> In practice, in actual use, the orginator does not select (and then 
> maybe change, as you wrote) a namespace. The device is configured to use 
> the right one, while the person selects the proper priority level. If 

While this may be true in current devices, I see no reason that this has 
to be true in the future. If I have a generic SIP device, why shouldn't 
this be usable in, say, a Q.735 network and a GETS-enabled network or, 
most likely, a network where I can reach both?

> there are cases in which one of several namespaces could be used, it is 
> not the human who selects the "namespace", except indirectly by what is 
> dialed. The human in unaware of this concept. For example, if a military 
> phone is setup and authorized to handle MLPP priorities, an emergency 
> worker with GETS access may use the phone, perform the magic procedures 
> to get such GETS authorization, which may result in a Resource-Priority 
> header being sent with namespace=gets, priority=enabled (to use the 
> values currently in the draft). It does not result in sending two 
> different priority values with some other entity being given the chance 
> to decide which is better. In fact, the treatments may be different, 
> with one using preemption and the other queuing for resources.

I'm not arguing that there should be two simultaneously, in the same 
request. That was removed a few email iterations ago...

> 
> No, it should never happen that the user would ask "please use namespace 
> X if you can, or Y if that suits you". The request is always "use 
> namespace X with priority level Z and do the best you can", (with the 
> actual user being unaware of the namespace). If the call is blocked, the 
> user may do something else (which might not have anything to do with a 
> namespace).

> 
> I'm mostly afraid that any attempts to describe use of multiple 
> namespaces will cause significant difficulty in moving this draft 
> forward, since there are lots of unexplained interactions.

Namespaces are only used sequentially, not simultaneously. If you reach 
a device that understands namespace X, but you supply Y, it helps if the 
device tells you that you should be using X. After all, you might well 
have authorization for both or just forgotten to reconfigure the phone 
from one mode to another. I fail to see the problem.

> Artel

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