[Sip] Re: use of 420 in draft-polk-sip-resource-02.txt

[Henning Schulzrinne <hgs@cs.columbia.edu>]

> In section 4.2, it says the 420 (Extension Required) response is used if the
> SIP element does not understand the "Resource-Priority" tag or it does not
> understand the namespace or priority value.
And if the Require mechanism is in use. (This is not always the case; 
indeed, it is not usually desired.)

> I believe this is in conflict with the use of the 417 response described in
> section 4.1 and the proper use of 420 as described in RFC 3261.
Why? 417 is used if the request fails due to lack of Rewsource-Priority. 
 This is subtly different - it indicates that the priority may not be 
high enough, say.

> The 420 response should only be used if it does not understand the feature
> tag. The 417 response (as described in section 4.1) should be used when it
> does not understand the namespace or priority value. If 420 was only used as
> described in 3261, the Accept-Resource-Priority header would not appear in a
> 420 response.
Why couldn't an Accept-Resource-Priority header appear in a 420? There 
is no restriction on what header fields can appear in a response.

I agree that there may be a need to refactor the error cases, as the 
current description is less than clear. There seem to be the following 
cases:

(0) UAS does *not* know R-P and no Require --> normal SIP behavior, as 
if there was no R-P indication at all (likely, 503)

(1) UAS does *not* know R-P and it is Required --> clearly, 420

(2) UAS does know R-P:

(2s) User insists on 'strict' handling (via Require)

(2s1) UAS does not support namespace or priority --> 417, with Allow-R-P

(2s2) lack of resources --> 417

(2s3) not authorized for this level --> 403

(2L) User allows 'loose' handling (no Require)

(2L1) UAS does not support namespace or priority --> tries to queue as 
if no R-P, might fail as 2L2

(2L2) lack of resources and no queueing for non-priority calls --> 417 
or maybe 503

(2L3) not authorized for this level --> ignores R-P, might fall back to 
2L2 case

Does that cover the cases?

> cheers,
> (-:bob
>
> Robert F. Penfield
> Chief Software Architect
> Acme Packet, Inc.
> 130 New Boston Street
> Woburn, MA 01801
> bpenfield@acmepacket.com
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip