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

["Bob Penfield" <bpenfield@acmepacket.com>]

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
bpenfield@acmepacket.com

----- Original Message -----
From: "Henning Schulzrinne" <hgs@cs.columbia.edu>
To: "Bob Penfield" <bpenfield@acmepacket.com>
Cc: <sip@ietf.org>; <jmpolk@cisco.com>
Sent: Tuesday, March 18, 2003 7:52 PM
Subject: [Sip] Re: use of 420 in draft-polk-sip-resource-02.txt


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

_______________________________________________
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