Subject: Re: [Sip] update-01: the 155 response and implied errors

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 25 Apr 2002 14:46:04 -0400

inline.

Bob Penfield wrote:
> 
> Last night at the meeting I raised the issue that it is burdensome for
> the
> UAC to figure out what the problem is with a request when a 155
> provisional
> response is received. For example, there would be no way to tell that a
> 416
> (Unsupported URI scheme) problem exists. There were 2 suggestions to
> solve
> this problem.
> 
> 1. Include the proposed Reason header (or a simple version of it) which
> would indicate the associated 4xx error code.
> 
> 2. Include a status-line in a sipfrag body.
> 
> The first option was rejected because the Reason header will not be
> ready in
> time for the 2nd bundle (manyfolks, privacy, call-auth, etc.) and it has
> also been sent back to SIPPING for a better definition of requirements.
> The
> idea of a simplified reason header was rejected because we don't want to
> add
> too many headers.
> 
> The second option does not seem promising because of issues raised with
> the
> sipfrag MIME type (I'm not aware of what those are).
> 
> My fear is that we would need a new option tag when the Reason header
> was
> done because it would impose slightly different behavior requirements on
> the
> UAS and UAC.
> 
> After further investigation, it appears that only 416 is a problem and
> all
> other reason can be determined by the presence of a specific header (as
> described in the draft). Therefore, if we just added another status code
> (say 156) to cover 416, I think we would have everything covered.
> 
> 401: 155 with WWW-Authenticate
> 407: 155 with Proxy-Authenticate
> 415: 155 with Accept/Accept-Encoding/Accept-Language
> 416: 156
> 420: 155 with Unsupported
> 423: 155 with Min-Expires
> 488: 155 with Warning
> 
> This still requires the UAC to check the headers. And presence of an
> Accept
> header does not necessarily imply 415, unless we change the draft to say
> that it does. We could specify that all the other headers should be
> checked
> first.
> 
> Another alternative would be to define a 15x status codes for each
> corresponding 4xx code so that the UAS can be explicit about the
> problem.
> 
> 401&407: 151
> 415: 152
> 416: 153
> 420: 154
> 423: 155
> 488: 156
> 
> We could use 150 as a place holder for use with the future Reason header
> and
> indicate that the UAC should CANCEL if it cannot figure out what the
> problem
> is.
> 
> The new status codes may be overkill.

I don't like this. It effectively requires us to register two response
codes for every repairable error response. I would rather use Reason,
thats what its meant for.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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