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

From: "Bob Penfield" <[email-masked]>
Date: Mon, 17 Mar 2003 11:07:39 -0500

I have a comment on the use of the 420 response in the resource priority
draft.

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.

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.

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.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

_______________________________________________
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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 18 Mar 2003 19:52:27 -0500

> 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.)

> 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.

> described in 3261, the Accept-Resource-Priority header would not appear in a

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?

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 18 Mar 2003 21:24:22 -0500

You seem to be supporting my point of view. But just to clarify, I think the
text in section 4.2 which now reads:
                                         Following standard behavior
   (Section 8.2.2.3 of [2]), a UAS MUST then reject the request with
   response code 420 (Bad Extension) if it does not understand the
   mechanism, the namespace or the priority value. If the UAS is capable
   of the resource priority indication in general, but does not
   understand the namespace or priority value, it MUST also include a
   Accept-Resource-Priority header field indicating the namespace-
   priority combinations it can accept.

Should be changed to:
                                         Following standard behavior
   (Section 8.2.2.3 of [2]), a UAS MUST then reject the request with
   response code 420 (Bad Extension) if it does not understand the
   mechanism. If the UAS is capable of the resource priority indication
   in general, but does not understand the namespace or priority
   value, it MUST reject the request with response code 417 and
   also include a Accept-Resource-Priority header field indicating the
   namespace-priority combinations it can accept.

It should not use 420 if the UAS *does* understand the mechanism.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]