Subject: RE: Comments on "Supported:" header draft

From: "Schroeder, Tim" <[email-masked]>
Date: Wed, 26 Jan 2000 17:31:49 -0600

Adam B. Roach wrote:
> 1) The paragraph at the bottom of page 4 suggests that:
> 
>   "If the protocol mechanisms followed here are operating
>    correctly, these features will only be among the set supported by the
>    UAC. If that is not the case, the client SHOULD resubmit the request
>    as if it were a 421 response."
> 
>    This seems somewhat dangerous to me. If the protocol features
>    are not operating correctly, you must have a broken implementation
>    somewhere. Under those circumstances, the inadvertant introduction
>    of an undetected loop may occur. I'd suggest that the appropriate
>    behavior for the client in this error situation would be:
> 
>     - For 1xx, CANCEL the call and be prepared to send a BYE.
>     - For 2xx, ACK the response and then send a BYE.
>     - For 300+, ACK the response and carry on as if the unsupported
>       headers listed in the "Require" header are not present.

I agree with making the failure more explicit.  If the server does this (and
hence makes the protocol features not operate correctly), it's best to get
out of the session immediately.  I'm not sure about the above approach for
300+ responses though; what exactly does "carry on" mean?  Maybe they should
all be treated as 500 "Server Internal Error".

If all 421 responses are to list the full set of features that might be
used(which I agree is a good idea), these rules would apply to any
subsequent 421 responses, without the need to compare lists or check for
subsets.

> 3) The otherwise innocuous attempt to negotiate features using
>    421 has the strong possibilty of being destroyed by intervening
>    forking proxies.
> 
>    The only alternative I can propose without some pretty massive
>    changes would be to revise your 421 response code to be something
>    like 299. 

Hmm.  How do things work with the 401 Unauthorized response across forking
proxies?  This case seems analogous.  One UAS responds with either 401 (try
again with appropriate authorization) or 421 (try again with the interesting
feature in the Supported header), while another UAS responds with a 400 Bad
Request.  Granted there are a lot more potential responses 400 <= N < 421
than there are 400 <= N < 401.  

One could imagine cases involving 407 Proxy Authentication Required or 402
Payment Required as well; these are basically "try again, but better"
responses that could be blocked by lower numbered but more fatal (404 Not
Found, e.g.) responses.

> 4) In the message examples, the final message on page 7 (from A to B)
>    contains no "Unsupported" header. This is consistent with the text.
> 
>    This leads to the strong possibility of loops. It doesn't seem
>    too much of a stretch that some faulty code in the server,
>    not seeing "com.dynamicsoft.foo" in either a "Supported" or
>    "Unsupported" header may decide to once again query the client
>    for its supported features. That response may contain only
>    the "Unsupported: com.dynamicsoft.foo," without the
>    "Supported: com.dynamicsoft.bar." You see how messy this could
>    get.

If the server must send all the possible features it cares about in a single
421 response, then this problem goes away, right?  Section 4.1 says the
client MUST explicitly put each feature from the 421 into either the
Supported or Unsupported header.  
 
> 5) Open issue 1:
>             "The current specification does not support extensions which
>              require a proxy to modify responses as they travel along.
>              This can probably be added without too much complexity. Is
>              this a useful function?"

Maybe it could be added without too much complexity, but I'm not convinced.
If a proxy is modifying responses, it's processing them.  Then I'm thinking
(off the top of my head) that we need to be able to determine where the
features are required or supported -- in a proxy, or at the user agent?
Wouldn't we end up needing something like Required and Proxy-Required to
distinguish?  Supported and Proxy-Supported, Unsupported and
Proxy-Unsupported?

This could tie in to open issue 2 as well.  Suppose a server wants a feature
from a proxy, and the proxy can support it, but that the client cannot.  The
client will end up responding with an Unsupported header, which will convey
the wrong information to the server.  Alternatively, the proxy could change
the header to Supported, but to do so would have to know that the server was
asking for a proxy feature, not a client feature.

> 7) Open issue 3:
>             "Do we need the Require header in the final non-421 response
>              to indicate what features were finally applied?"

Definitely.  If the client sends Supported: A,B because it supports both,
the server needs to send a response indicating which one was chosen.
Without the Require header, the client would have to assume that neither was
used.

> 8) Open issue 4:
>             "Should we remove org.ietf.sip.supported and have the
>              presence of the Supported header alone indicate support for
>              this extension?"

I like the org.ietf.sip.supported.  It seems odd that the presence of
Supported means something that the presence of Unsupported does not.  Or
would Unsupported in a request also imply org.ietf.sip.supported?  Since
Unsupported already exists in responses, the presence of Unsupported there
could not be used to imply anything.  The fewer "hidden" implications the
better, I think.

Tim Schroeder

---

From: Michelle Kitchings <[email-masked]>
Date: Mon, 31 Jan 2000 08:53:11 -0600

> could not be used to imply anything.  The fewer "hidden" implications the

Here is my first post, so bear with me.  :)

If the motivation for making "Supported:" imply "org.ietf.sip.supported" is
because of the extensive length of the feature name, couldn't the feature
lists be interpreted such that any feature without a reverse domain is assumed
to be "org.ietf.sip"?  This would mean that

  supported = org.ietf.sip.supported
  100rel = org.ietf.sip.100rel
  info = org.ietf.sip.info
  etc. ...

This mechanism makes any/all IETF extension cheaper in terms of bandwidth. 

The downfall to my idea is that if a provider (eg, Ericsson) defines an
extension called "info" without using a reverse domain, then the servers could
inadvertantly interpet that as the wrong kind of info--which would happen
anyway if some other provider (eg, MCI) was also using info without reverse
domain.  Perhaps this default domain interpretation would "blackmail"
providers into making sure that they fully-qualify all features?

Cheers,
Michelle :^)

-- 
Michelle Kitchings | Ph:  +1 972 583 7101 | 1010 E. Arapaho, MS L-04
Ericsson, Inc.     | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

---

From: Anders Kristensen <[email-masked]>
Date: Mon, 31 Jan 2000 15:48:54 +0000

I like your proposal of omitting the lengthy prefix org.ietf.sip from
IETF sanctioned SIP extensions -- I see no problem with that at all. 
I'd still like to make Supported:" imply support for the "supported"
extension as well, though.

All these little savings add up ya' know.

Regards,
Anders

-- 
Anders Kristensen <[email-masked]>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 31 Jan 2000 11:02:16 -0500

I think we have clear consensus for having the presence of Supported
imply support for org.ietf.sip.supported.

Issue closed.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Anders Kristensen <[email-masked]>
Date: Mon, 31 Jan 2000 16:12:42 +0000

> imply support for org.ietf.sip.supported.

Right. There was another proposal, though: to loose the "org.ietf.sip"
prefix from "official" extensions. 

Anders

---

From: Michelle Kitchings <[email-masked]>
Date: Mon, 31 Jan 2000 10:29:51 -0600

Jonathan,

I agree with presence-imply and wasn't attempting to re-open that particular
issue.

But, the whole discussion made me think of the idea of an implied
"org.ietf.sip" in general.  Do you think the idea has merit as a means to
shortening messages that have Require, Proxy-require, Supported, and
Unsupported?  Like someone said in another post, we could end up having dozens
of IETF extensions.

Cheers,
Michelle :^)

> > Michelle Kitchings wrote:
...