Subject: Can a client make the server return an error instead of ignore an unknown?

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

From: Scott Petrack@VOCALTEC on 06/29/98 02:34 PM

Along similar lines.....

We've agreed that "most of the time" if a server doesn't understand an
attribute it doesn't return an error, although it may do so. (An current
example might be a badly formed rtpmap line).

Is there some way for the client to request that it _wants_ the server to
return an error if the attribute cannot
be satisfied? As an example, the client may include an attribute line
"a=quality:10" to request a high quality image.
Can the client include something to say that the attribute is "required"
and not merely "requested" -- that is,
if the server can't deliver a high quality image, it should fail the
request (say with 606 Request Not Acceptable).

There are many attributes where this is useful or necessary ("If I can't
see the film in the original Swahili, I'm just not interested....").

This is a pure SDP question, but I suppose we could invent a horrible SIP
header hack to do this.

Scott

[email-masked] on 06/28/98 06:01:50 PM

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

>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.
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 15:24:24 +0200

> This is a pure SDP question, but I suppose we could invent a horrible SIP

One possibility is to say, for example:

Require: org.ietf.sip.strict-session

and then define this extension to be picky about the session
description, either in general or as described below.

How do this for a particular attribute should really be fixed at the SDP
level. Something kludgy like

a=strict:a=quality,a=payee,b

since you might want this to be media-specific.

---

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

>This is a pure SDP question, but I suppose we could invent a horrible SIP

There's no way to do this in SDP right now.  With hindsight, we should
have included some way to distinguish between required attributes and
ones that are merely a recommendation.  Not doing so was a mistake.

The problem is how to add such functionality in a backward compatible
manner?

One possibility is to define and register an SDP "require" attribute:

a=require:quality,lang

This would mean that clients that understand the require attribute
MUST also understand the quality and lang attributes to be able to
participate.  Clients that don't understand "require" would of course
not enforce the rule.

We could then make it a requirement of SIP parsers that understand SDP
to also understand the SDP "require" attribute.  When SDP goes to draft
standard, we can include "require" in the SDP spec.

This may seem a little bizarre (using an attribute to specify
attribute requirements), but it may be sufficient for our purposes,
and won't break anything existing.  Does anyone have a better
suggestion?

Cheers,
	Mark