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

From: "Scott Petrack"<[email-masked]>
Date: Wed, 15 Jul 1998 23:21:33 +0200

From: Scott Petrack@VOCALTEC on 07/15/98 11:21 PM

The warning codes defined at present in SIP v7 are very useful, but it does
seem to me that they fit into categories which could be useful. And once
you split them into categories you see that certain needed warnings are
missing.

The currently available warning codes from SIP v7 can be split into two
categories as follows:

Category of "resource xxx not available":

     x01 Bandwidth Not Available
     x02 Transport  Protocol Not Available
     x03 Network Protocol Not Available
     x04 Network Address Format Not Available
     x05 Media Format  Not Available
     x07 Multicast Not Available
     x08 Unicast Not Available

Category of "token not understood":
     x06  Bandwidth Description Not Understood
     x09  Other Session Description Parameter Not Understood

These are very nice, but look at x01-x05. They cover only 5 of the 7 tags
that can be registered with IANA to extend SDP. Why can't we have warnings
for the other two ("attribute" and "media type"). And why does only
"Bandwidth" merit to have two separate warnings, one for "BW not available"
and the other for "BW description not understood".  These two problems can
occur with ANY of the IANA-registerable tags.  So how's this for a more
complete scheme:

Warning code 3xx : "Something not understood"

     301 Bandwidth Type Not Understood
     302 Transport  Protocol Not Understood
     303 Network Type Not Understood
     304 Network Address Format Not Understood
     305 Media Type Not Understood
     306 Media Format Not Understood
     307 Attribute Not Understood
     390 Content-Type Not Understood
     398 Other Payload Token Not Understood
     399 Miscellaneous Not Understood

Warning code 4xx : "Resource not available"

     401 Bandwidth Not Available
     402 Transport  Protocol Not Available
     403 Network Type Not Available
     404 Network Address Format Not Available
     405 Media Type Not Available
     406 Media Format Not Available
     407 Attribute Not Available
     408 Multicast Not Available
     409 Unicast Not Available
     499 Other Resource Not Available

I have added "Media Format" warnings and "Attribute" warnings to your list.
It makes sense to have warnings so that  servers that don't understand some
newly IANA-registered tag can give useful debug information back to clients
which do.

As a very concrete example, we need to add some attributes for PINT,  and I
will want to be able to have a server which doesn't understand one of the
PINT attributes be able to report back that this is the source of the
problem.

Also, I would define two subcodes defined:  xxx.1 means that the problem
did not cause the request to fail, and xxx.2 means that the problem did
cause the request to fail.  For example, sometimes not having available a
certain media format will cause the request to fail, and sometimes it will
not. And once we have a "strict" attribute, this may determine if a xxx.1
or xxx.2 is returned.

Finally, maybe the payload of the SIP request will not be SDP, or even a
real session description. An example might be a URL (in order to transfer
the call to some URL, say a mailto: URL), or in PINT some actual MIME
content. So it is nice to have 390 and 398 in the list, to say that "390
content-type not understood: application/whatsis" or "399 Token not
understood in SIP payload application/whatsis: re12h1pq".

All these errors/warnings can be passed back and forth between the tools
that generate and read the SIP payloads, without much intervention from
SIP.

I really do think that this is the minimal set of warnings that will allow
servers to usefully interwork with new clients, as more tags are registered
with IANA. As you can see we need to register a few new tags to make PINT
work, so this is pretty practical stuff.

Scott

PS: I won't argue too strongly about the SIP warnings right now.

[email-masked] on 07/15/98 03:30:44 AM

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

Scott Petrack wrote:
> 3xx    -- SIP syntax warning
> 4xx    -- SIP semantics warning (parsed the SIP fine, but didn't
understand
> something)
> 5xx    -- Payload Syntax Warning (can't parse the Payload, includes
"don't
> recognize the content-type of payload").
> 6xx    -- Payload Semantics warning (could parse the payload, but didn't
> understand something in it).
I don't think we really need (at least initially) any SIP
syntax/semantics warnings. The 4xx codes do just fine for indicating SIP
syntax (400) and semantics problems (such as invalid call-id, no
response that matches Accept (406) or invalid session description
(415)). Thus, the warnings are really only needed for indicating
problems with processing the session description, where more detailed
information is valuable and where multiple, "parallel" error conditions
can be more readily identified.
Given our lack of experience in this area, I would tread carefully in
trying to cover every possible condition. Warning codes can be trivially
extended by IANA registration should they be needed.
---------
This message came from the IETF PINT Working Group Mailing List.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 15 Jul 1998 19:17:53 -0400

Scott Petrack wrote:

>      x09  Other Session Description Parameter Not Understood

The distinction is not particularly useful, in my opinion. What's the
practical difference as to whether I don't "understand" what TCP means
and I don't implement it? (This difference is obviously quite important
when dealing with two-year-olds, but is undistinguishable to the remote
party.)

> for the other two ("attribute" and "media type").

Added.

>  And why does only

Not really. Only bandwidth is a numeric tag. It does make a difference
whether I do not support bandwidth measured in inches or whether
(possibly temporarily) I cannot grant you 500 kb/s of bandwidth. 

> not. And once we have a "strict" attribute, this may determine if a xxx.1

This is the current first-digit distinction. I'd rather keep that to
maintain backward compability with HTTP. As I pointed out above, I
simply don't see your two categories as distinguishable in general. In
some implementations, there may be a parser and an "executive" that asks
for these, but to the outside world, this is one implementation. I will
still have to send the implementor the error message.

> understood in SIP payload application/whatsis: re12h1pq".

The first is error status 415. No need for a separate warning:

415 Unsupported Media Type application/whatsis

The second is a Warning: x99.

If you modularize the SIP "front end", you will always have to pass back
two pieces of information, just like nph-cgi: the status and any headers
(such as Warning).