Subject: Re: Missing Warning reasons to SIP

From: "Scott Petrack"<[email-masked]>
Date: Sun, 28 Jun 1998 16:39:41 +0200

From: Scott Petrack@VOCALTEC on 06/28/98 04:39 PM

>I agree with most but not all of these.  The two I have reservations
>about are Attribute and BW Type.  The others MUST be understood in
>order to join the session, and hence merit causing an error and having
>a warning field allocated to them.
>
....
>
>As we progress SDP to draft standard and it gets used in a wider range
>of circumstances, we might consider whether we need to add the SDP
>equivalent of a "Require:" header for attributes to make the
>distinction clearer.

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.

Finally, I agree entirely that if you want to force an error to occur if an
option is
not supported, you should use a Require:. In my PINT draft (soon to be out)
I define a
Require: field for each new PINT option, so that a client can get an error
if the particular option it needs is not supported.

Scott

---

From: Mark Handley <[email-masked]>
Date: Sun, 28 Jun 1998 12:01:50 -0400

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

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.  

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.

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.

Cheers,
	Mark

---

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

> 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

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

> payload might be an appropriate course of action.

message/sip would seem to be the appropriate type.

> examples section (14.8 in the 07a draft).  We need to add text to make

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

---

From: Mark Handley <[email-masked]>
Date: Mon, 29 Jun 1998 09:35:42 -0400

>any detail desirable.

The question was how to return warnings in a response that already
needed to carry a defined payload, without defining machine-readable
warning subcodes for everything that might ever happen.  The obvious
example is 200 responses where there is a requirement for an
application/sdp (or whatever) payload, but also possibly "482 Loop
Detected" if we define that this returns message/sip.  However, I like
your solution of returning a generic warning without a warning subtype
number in this case. So a 482 response could then return a generic

Warning: 482 example.com loop caused by encrypted Via field

to help provide additional information.

Cheers,
	Mark