Subject: [Sip] Resource Priority header - unknown namespace

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

In a message dated 6/24/2003 11:54:45 PM Eastern Standard Time, 
[email-masked] writes:

> > 4.2 "Unknown namespace" error: The sentence with "it MAY serve ... if 
> > and only if" seems strange. The "if and only if" appears to be 
> > indicating a "MUST" situation. The rest of the sentence is confusing, 
> > since it is saying that it depends on "if the request would ... 
> > experience treatment no different than a non-labeled request", but the 
> > whole point of the sentence is that it's treated "as if it had no 
> > priority indication", that is, is non-labeled. Also, it seems that there 
> 
> I rephrased it, but basically the intent was that if, at the time of 
> arrival of the request, labeled and non-labeled requests are treated the 
> same, there doesn't seem to be a point to say "sorry, don't know this 
> (but it wouldn't make any difference in any event)". In other words, 
> under normal, no-overload operations conditions, where all requests are 
> served, there is no need to reject requests that have the wrong label.
> 
> I don't think treating unknown namespaces the same as no R-P is right if 
> the treatment differs. Rather than being routed into some inferior 
> corner of the network if I guessed the wrong namespace, I should be told 
> that I should be using a different namespace.
> 

I'm still confused. By definition, labeled and non-labeled requests may be 
treated differently someplace in the network at any time. In any case, an entity 
could make such a distinction between labels that it understands and requests 
without labels. But it is impossible to make decisions based on a label it 
does not understand, since it would have no way of knowing whether the request 
might be treated differently at this moment if it understood the label. What 
if, at the specific moment, one label would result in different treatment while 
a second would not? Then what would be the decision for a 3rd, unknown label?

I would hate to think that deciding how to process the incoming unknown label 
would depend on whether there is currently overload, especially since that 
question itself (is there overload) may depend on what the label is.

This again relates to my comments about the concept and use of "namespace". 
We are not concerned with someone "guessing" the wrong namespace, since the 
user doesn't select it directly.

In a message dated 6/24/2003 11:54:45 PM Eastern Standard Time, 
[email-masked] writes:

> > 
> > The 2nd paragraph (beginning "If an unknown resource ...") continue to 
> > be a problem, since it seems to mandate an impossible operation: the 
> > element must make a decision based on the operation that should have 
> > occurred for a namespace that it does not recognize. It must be assumed 
> > that the phrase "or would get a different treatment" intends to say 
> > "than if the namespace were recognized". This second paragraph should be 
> > deleted.
> 
> I disagree. It simply says that if the treatment is different I ask for 
> X, but you don't know X, and if the current treatment for some 
> priorities is better than for default, I should be given a chance to 
> apply for this better treatment rather than being silently sent into the 
> long queue.
> 
> 

I don't understand the point. It seems too complicated and unecessary. As an 
alternative to what I suggested (treat the request as if it had no R-P 
header), it would be possible instead to always reject with "Unknown 
Resource-Priority", except that code does not indicate that it was the namespace that was 
unknown. Always rejecting for an unknown namespace would be okay, since this can 
only happen due to misconfiguration in the originating device.

Mike Pierce
Artel

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 27 Jun 2003 21:45:06 -0400

[email-masked] wrote:

> I'm still confused. By definition, labeled and non-labeled requests may 
> be treated differently someplace in the network at any time. In any 

If there's no overload and no PSTN labeling (e.g., simple gateway 
priority), during normal operation, all requests will effectively be 
treated the same.

I've updated the draft with a more structured presentation of the error 
cases. I'm not sure all three error modes (lenient, semi-strict, strict) 
are necessary, but I think they span the gamut of what's plausible. We 
can either
- enumerate all three (as in this revision)
- pick one
- or remain silent on the issue and leave it up to the implementation to 
do what makes sense.

Henning

_______________________________________________
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