Subject: Extension negotiation draft

From: Anders Kristensen <[email-masked]>
Date: Mon, 14 Feb 2000 19:59:31 +0000

I have a couple of suggestions wrt. the serverfeatures draft:

  1. Define Supported in the base spec.
  2. Do *not* let presence of the Supported header implicitly
     signal support for the extension negotiation mechanism.
  3. Drop the reversed domain name extension naming convention.
  4. Rename the negotiation extension.
  5. Define "all-extensions-listed" tag to be used in Supported
     header.

I'll go through these in turns.

  1. Define Supported in the base spec.

The draft can be seen as having two parts: the definition of the
Supported header and a proposal for a feature negotiation mechanism. I
think the two should be separated. It makes perfectly good sense for a
server to signal supported features in an OPTIONs response without
having to implement the negotiation mechanism, and likewise, clients
should be allowed to indicate that they support, say, reliable 1xx's
without having to implement the negotiation mechanism.

So assuming the two should be split, the Supported header must be
defined elsewhere. I think it belongs in the base spec because it's the
direct equivalent to Unsupported which is in the base spec, it's
universally useful, and it's really simple enough to go in there.

  2. Do *not* let presence of the Supported header implicitly
     signal support for the extension negotiation mechanism.

This is a corollory of the previous argument. If UAs can list supported
features independent of the negotiation mechanism then presence of the
Supported header cannot be taken to implicitly indicate support for the
latter.

  3. Drop the reversed domain name feature naming convention.

It makes messages longer and is unnecessary.

The (primary) justifiction for the extension negotiation mechanism is
that servers need to know what features are supported by clients. It
seems to me that the simplest way to meet this requirement is for
clients to always tell servers what features they support (and BTW this
is another argument for defining Supported in the base spec).

Now, the reason why this answer is not enough must be the potentially
large overhead of listing all these extensions all the time. Hence SIZE
MATTERS! Anything we can do to minimize the size overhead of signaling
supported features makes it more practical for us to use the simpler and
more efficient mechanism of just listing all supported features always. 
The use of the short header form and the proposed implicit serverfeature
support is further testament to the need to keep messages short. There
may be times where it really isn't practical to list all supported
extensions, and for these cases we still need the negotiation.

For this reason, and *because it's unnecessary*, I propose we drop the
convention of using reversed domain name prefixes as namespace
identifiers for extension tags.  First, as I've mused on a previous
occasion, the vast majority (if not all) extensions to come into
widespread, regular use will belong to the org.ietf.sip namespace
anyway, making this prefix redundant, and secondly, I don't even think
we need these namespaces anyway. We don't have namespaces for header
names or status codes, and MIME has gotten along just fine for years
without namespaces for its media types (of which there will probably
always be many more than there will be SIP extensions). We could use the
"x-" prefix for experimental or proprietary extensions or continue to
use the domain namespaces for this purpose. 

  4. Rename the negotiation extension.

Follows from 1. and 4. Maybe just call the extension "negotiate".

  5. Define "all-extensions-listed" tag to be used in Supported
     header.

In order to avoid unnecessary round-trips it would be good if clients
can indicate that they have listed *all* supported extensions in the
Supported header. This can be done by defining a new token with that
meaning. I'd propose using "." since the semantics are kind of like that
of "."s use in natural written language (and tokens doesn't come much
shorter).  So, for example

  Supported: negotiate, 100rel, .

would indicate that the sender supports the 100rel and negotiate
extensions and *no* other extension. Hence there is no point for the
server to ask whether extension "foo" is supported - it isn't. This tag
can be seen as just identifying an extension of its own, and could be
defined in its own document, or it could go into the base spec. I'd
prefer the latter, since it seems like a generally very useful feature.

Of course the same mechanism can be used by servers.

So to summarize: the serverfeatures draft is a fine piece of work, but
it just makes sense to try and minimize the need for extra
"multiple-roundtrip" negotiation. Hence

  - UAs should be allowed to signal what features are supported
    without supporting negotiation
  - feature tags should be kept shortish
  - UAs should be able to say *all* features have been listed

My 2 pence worths.

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, 21 Feb 2000 14:02:36 -0500

> without having to implement the negotiation mechanism.

I agree that Supported has uses outside of the negotiation mechanism. In
fact,
rfc2543bis has a definition of Supported.

However, you cannot separate the header from the protocol semantics and
exchanges it is used in. To date, there are two applications:

1. Returned in response to OPTIONS to indicate capabilities (this is
what is described in rfc2543bis)
2. the negotiation mechanism in the draft

So, I would argue that (1) is something which might well be included in
the next version of the base spec - its completely backwards compatible
and easy, and well in line with OPTIONS operation now. The other use,
(2), is new and different. So, where does the SYNTAX itself of Supported
get defined? Doesn't really matter... may very well be both.

> Supported header cannot be taken to implicitly indicate support for the

Again, you can't separate the header from the protocol behavior. I would
agree that adding Supported to an OPTIONS response does not imply
understanding of the negotiation mechanism. However, placement of
Supported in a request is strongly coupled with the negotiation
mechanism, and I would be reluctant to allow it without the full thing.
So, in the interests of short fields (which you argue for below), I
would prefer to allow the presence of Supported alone in a request be
used to indicate this.

> use the domain namespaces for this purpose.

OK.... I'll buy on this one. However, I'd still like the base spec to
define usage of the domain-based namespaces for unregistered extensions.

> Follows from 1. and 4. Maybe just call the extension "negotiate".

Rename the draft? The feature tag?

> prefer the latter, since it seems like a generally very useful feature.

Very good idea. I like this a lot. The period is nice too since its got
that
email connotation of "thats all". We must make sure implementations are
prepared
to not receive it last, though, since ordering is not important among
feature tags.

> My 2 pence worths.

I thank you for your insightful comments. I apologize for the delay in
responding... I'd like to get this whole thing closed soon so we can
move on to other things.

-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: Henning Schulzrinne <[email-masked]>
Date: Mon, 21 Feb 2000 14:41:18 -0500

Jonathan Rosenberg wrote:

> what is described in rfc2543bis)

I see the ability to declare capabilities in *all* requests as an
alternative model that is also backwards-compatible, as long as we
define it before the first capability extension is standardized. (All we
would need to say is that an implementation that supports "foo" also has
to support the "Supported" header, which seems trivial enough.)

There are two models, it seems:

- Reveal all, one round-trip: The client lists all capabilities that it
wants the server to use. Asking again is not going to elicit additional
capabilities.

  +: lot simpler, still backward compatible with existing systems
  +: uniform call setup delay
  -: longer headers (but see below)

- Selective disclosure: Be coy and wait to be asked for particular
features.

  The trade-off is pretty much the opposite as above.

The draft mainly deals with the shy persons. Maybe giving SIP
implementations some powdermilk biscuits might help (don't ask).

In terms of efficiency, it depends on how often a second round-trip is
required. If it is even 10% of the time, I would guess that declaring
all capabilities ahead of time is a good move, both in terms of time and
space (since you need a lot of options to compensate for the 500 bytes
of repeated request, even ignoring the crucial issue of call setup
delay).

Given that, I'm somewhat tempted to explore a different, simpler avenue
initially: assume that the client declares all beyond-RFC2543
capabilities, possibly allow short-hand feature names (as Anders is
suggesting) and wait until we have a better idea as to whether we'll
have 10 or 100 extensions. Clients that have 100 extensions, can offer
the

  btw-I-know-more-than-this-please-ask-again

extension in Supported (with a somewhat shorter name, like "shy"), which
is the current model.

If 100 turns out to be closer to the mark, it might well be that there
will be agreed-upon groups of capabilities, similar to "Host
Requirements" (see the TIA work), shrinking that number to a smaller
number of aliases again.

> get defined? Doesn't really matter... may very well be both.

I'd rather have one place. If timing dictates this, we can have a
Proposed Standard for the Supported header syntax and use (nothing else)
pushed out in a matter of weeks, which would then be labeled as
"obsoleted by" RFC2543bis whenever it reaches Draft.

> define usage of the domain-based namespaces for unregistered extensions.

I would turn the "we don't do 'com.hp.header: foo' argument around and
say that if you see a header that looks unfamiliar (and it's important,
i.e., you can't just ignore it), it should show up in the Supported
header, giving others a much smaller number of places to ask and look
around for where this new unfamiliar header might be defined.

Thus, header names are not so much to avoid collisions (those haven't
really been a major problem in HTTP or email - these usually get
discovered early and can be fixed before major damage occurs), but
rather the ability to see who's responsible for a particular feature.

The x- mechanism, by the way, is not very helpful. It tends to stick
around forever (even if the header gets widely used), since nobody wants
to change all those implementations that caused it to be widely use. 

Thus, my overall modified agreement with Anders: org.ietf.sip is implied
(but can be spelled out?) and proprietary extensions need the reverse
path. If the length penalty encourages people to write informational or
standards-track RFCs to describe the feature, I wouldn't mind.

> to not receive it last, though, since ordering is not important among

I would argue that the "I have declared everything unless I put in some
special token" as being a better option, until we have a better idea
what's happening and whether we need a relatively complicated mechanism
to solve what turns out to be a non-problem.

At the rate that we are pushing out extensions, we're a long way of
having to worry about listing them all.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 21 Feb 2000 15:23:20 -0500

> extension in Supported (with a somewhat shorter name, like "shy"), which

That certainly would simplify things. Its all a matter of engineering
goals - the negotiation mechanism is quite powerful and flexible, and
will grow to handle a large extension space, whilst what you are
proposing is far simpler and handles a smaller case. Which is our goal?
Well, I'm inclined to agree with you that KISS probably wins over a
yet-to-be-fully demonstrated need. We can wait on the more extensive
negotiation stuff, so long as there is a way to add it later ("shy", as
you suggest).

> "obsoleted by" RFC2543bis whenever it reaches Draft.

Thats fine. Basically the server features draft does this now, except I
don't know if we were going to fold it into draft when the time came.

So, the current proposal is to write a draft that:

1. Defines the Supported header syntax
2. specifies its usage in OPTIONS responses
3. specifies its usage in requests - basically, it lists all features
with short names
4. supports no negotiation

This draft will be obsoleted by rfc2543bis when it goes to rfc, but no
way we can wait that long for this.

How do people feel about this? If we get consensus, I'll do another rev
on the document and we can push it out the door.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 21 Feb 2000 15:30:12 -0500

Jonathan Rosenberg wrote:

> negotiation stuff, so long as there is a way to add it later ("shy", as

I'd rather get the KISS draft out in a week and then worry about it
again when/if the need arises. At that time, we'll also have a better
idea, for example, if we need parameterized extensions, as has been
mentioned somewhere along the way. 

> way we can wait that long for this.

Agreed. I've already included the changes in today's version of
rfc2543bis. It might be useful to have the wording in the draft and
rfc2543bis agree, to simplify the merging later. (Obviously, rfc2543bis
spreads things around a bit more, e.g., the redefinition of the
option-tag and the table indicating allowable use.)

---

From: Anders Kristensen <[email-masked]>
Date: Tue, 22 Feb 2000 11:42:00 +0000

Cool beans. I think we're all in agreement now. Comments below anyway.

> 2. the negotiation mechanism in the draft

There is a third which is the one I'm concerned about here, which is to
allow clients to tell the server which features it supports without
having to implement the negotiation mechanism.  Like Henning, I believe
that many clients can get away with not implementing the negotiation
mechanism simply by listing all known features.

> mechanism, and I would be reluctant to allow it without the full thing.

Well, this is really what I argued against. A great part of the value of
letting clients list features known to them is that it becomes a
mechanism for not having to implement the negotiation. I think this
advantage weighs much more heavily than saving listing the extra tag
when negotiation *is* supported.

If I understand your 4-step plan correctly this is what it is saying
also with the "shy" tag. Basically the Supported header can be used in
requests without it signaling support for negotiation, which is instead
signalled explicitly with the inclusion of the "shy" tag.

> > [...]

Agreed.

I must say I really don't like the idea of making it optional whether or
not to include the "org.ietf.sip" prefix. It complicates matters for no
extra gain.

---

From: Michelle Kitchings <[email-masked]>
Date: Wed, 23 Feb 2000 10:41:53 -0600

...
> on the document and we can push it out the door.

FWIW, I like it!
(I especially like #3 :)

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