Subject: Warning Codes (was: Re: Missing Warning reasons to SIP)

From: "Scott Petrack"<[email-masked]>
Date: Mon, 29 Jun 1998 19:11:07 +0200

From: Scott Petrack@VOCALTEC on 06/29/98 07:11 PM

I would be happy to have numeric codes for warnings which do one or more of
the following:

a.  Carry some general taxonomy of warning message (like the "1xx.y SIP
Warnings" and "2xx.y SDP Warnings")
b.  Carry some suggestion about what the client should do with or about the
warning (as in Henning's examples)

Maybe the minor number of the warning code could convey the "severity" of
the Warning, so that x.0 would mean
"informational" and x.5 might mean "extremely severe."

What I'd like to avoid is having the numeric codes of a Warning somehow
repeating the numeric codes of the
Response. These should be independent. I may need to use the same warning
codes in very different SIP responses.

Scott

[email-masked] on 06/29/98 12:17:31 PM

To:   [email-masked]
cc:   Scott Petrack, [email-masked], [email-masked]
Subject:  Re: Missing Warning reasons to SIP

Mark Handley wrote:
>
> >Ahhh. I thought that it is not necessary that a Warning: header be
> >returned in an error reponse. I thought that even a response which
denotes
> >success
> >might carry a Warning: header, to indicate, well, a warning ;-).
> >
> >So basically I agree with Mark, I just assumed that this was already
> >allowed to have
> >certain Warning returned in success responses.  I merely wanted these
> >Warnings to be "pre-defined" and agreed upon.
>
> I just re-read what the spec says, and I think you're right - we need
> to extend the wording in the description of the Warning header.  It
> should be quite acceptable to return a Warning header in a wide range
> of circumstances, not just in a "606 Not Acceptable" response.
>
> However, the only existing warnings defined are 606.x warnings - those
> that cause a failure because the recipient cannot participate in the
> session as described.
>
> "Unknown attribute" and "unknown bandwidth" would appear to be 200.x
> warnings - they don't cause an error, but it might be useful to inform
> the caller that they were ignored.
>
> Off the top of my head, useful 200.x warnings would be:
>   200.1 - Unknown SIP header field
>   200.2 - Unknown session attribute
>   200.3 - Unknown session bandwidth specifier
>
> The problem is the current usage of 606.x warnings is to return in the
> response payload a modifed session description that would be
> acceptable, not to indicate directly what is unacceptable.  Thus
> getting "200.2 Unknown session attribute" doesn't tell you which
> attribute is unacceptable, and hence isn't terribly much use.  What
> you might do is remove the attribute from the session description sent
> back to the caller, although this is somewhat subtle, and may not work
> at all for unicast calls where an attribute might only be intended to
> apply to one direction.  Thus right now I'm reluctant to add these
> warning codes until we've sorted out how to make them unambiguous.
Warnings (in the compiler sense) for 200-class responses are an
interesting idea. Note that we don't really have to standardize all of
them, either. There is nothing much that prevents somebody from sending
back a generic
Warning: 200 example.com Ignored unknown "a:foobar" attribute
Warning: 200 example.com Unknown session bandwidth specifier "bucket"
Warning: 200 example.com Ich verstehe nur Bandbreiten in kb/s
  [Assuming the server has reason to believe that the client speaks
German.]
Note that the warning text is just a guideline - you can make it more
specific and tailor it to local needs as needed.
[I'll adjust the BNF and wording accordingly.]
A more subtle problem is that the user agent doesn't currently quite
know what to do with the warnings, except display them. I would suggest
that the spec can be quiet on this, with a good user interface giving
the user three choices:
(novice) don't display warnings (or hide them behind a "show details"
button), but log them somewhere on the local system so that help staff
can find them
(regular) display warnings for codes >= 300
(expert) display all warnings
>
> Most other response codes don't justify warning codes because there is
> little that can be done automatically by a UA client that receives
> them.  If there is no *automatic* course of action the UAC can take, I
> would expect a simple textual payload to be sufficient for debugging
> purposes.  We don't want to add complexity to SIP with
> additional Warning codes.  Perhaps we should define a generic warning
> code to convey this, because often we cannot use a text/plain payload
> as we're already obliged to carry an application/sdp payload (200 is
> the obvious case).  So perhaps we should define a new Warning code:
>
>   000.0 Generic Warning
>
> The idea is that the text conveyed by the warning field explains to
> someone attempting to debug code that something unexpected happened,
> but that the UA client is not expected to do anything special with the
> Warning field.  A good example of this might be with a "400 Bad
> Request" field, where the client has erred and so you don't expect it
> to be able to do anything automatic to fix the problem, but would at
> least like to be able to report what exactly the problem was that the
> server had with the request.
I'm not sure I understand what you want to happen here and why the
warning is needed. If you have a 400 (or indeed any >200) response, you
would include a text/html or text/plain or text/special-debug-format (if
client deemed it acceptable in an Accept header) that spells it out in
any detail desirable.  A good designer will have something like:
400 Bad Request
The request sent by your client had some kind of problem that is
unlikely to be fixable by a user. Below is the technical detail:
... lots of protocol mumbo-jumbo meant to be emailed to an expert ...
>
> Looking through the list of response codes, I find very few others
> that might want to return additional information that 000.0 would
> *not* be appropriate for and that appropriate mechanisms aren't
> already defined:
>
>   "482 Loop Detected"
>      it would be good to have a way to return the path that lead to it
>      because either proxies or UA clients might be able to modify
>      their future requests to avoid the problem.  Of course doing so
>      would not be mandatory for sites that wish to hide topology.
>
>   "483 Too Many Hops"
>      as 482
>
> That was all I found.  These two don't seem to be well handled by a
> warning field.  Do we want to define an alternative mechanism?  In
> these cases, returning a payload of application/sip or
> application/quoted-sip and simply returning the Via headers as a
> payload might be an appropriate course of action.
message/sip would seem to be the appropriate type.
>
> More importantly, looking at the 606.x warnings, I find that we've
> only specified how to discover what the problem really is on the
> examples section (14.8 in the 07a draft).  We need to add text to make
> this much clearer.
Indeed.
>
> Cheers,
>         Mark
> ---------
> This message came from the IETF PINT Working Group Mailing List.
--
Henning Schulzrinne         email: [email-masked]
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs
---------
This message came from the IETF PINT Working Group Mailing List.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 29 Jun 1998 18:32:31 +0200

> codes in very different SIP responses.
I have tentatively added
3xx warning, did not cause request to fail
4xx error, caused failure status

2xx responses should only have 3xx warnings, obviously. Some types of
codes will have to be repeated in both 2xx and 3xx, depending on what
severity the server associates with the condition. This scheme allows to
have non-fatal warnings in a 4xx or 5xx response.

Example in a 400 response:

Warning: 3xx isi.edu "Unknown bandwidth specifier kb/mooncycle ignored"
Warning: 4xx isi.edu "Unknown transport protocol PTP"

(1xx and 2xx are taken for cache-related warnings in HTTP/1.1, so it
seemed prudent to stay clear of those.)

Comments?