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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 01 Feb 2000 18:02:18 -0500

There are pros and cons. The one and only pro is saving space in the
message.

The cons are more architectural in nature. It creates a special case for
naming conventions, creates an implicit namespace for this first class
set of extensions. Henning pointed out to me another interesting issue -
lets say RTSP wants to use some new header, foo, defined for SIP. Would
this extension be referred to as foo within RTSP, or org.ietf.sip.foo?

-Jonathan R.

Michelle Kitchings wrote:
> 
> 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 :^)
> 
> Jonathan Rosenberg wrote:
> >
> > I think we have clear consensus for having the presence of Supported
> > imply support for org.ietf.sip.supported.
> >
> > Issue closed.
> >
> > -Jonathan R.
> >
> > > Michelle Kitchings wrote:
> > > >
> ...
> > > > 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

-- 
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: Wed, 02 Feb 2000 10:50:42 +0000

Right, so there's one pro and one cons. Neither is entirely compelling
in itself. I would point out, though, that the large majority of
extensions to come into wide use will likely become standardized under
the org.ietf.sip namespace. I believe this is true for all extensions
currently planned and this IMHO somewhat weakens the cons argument.

> this extension be referred to as foo within RTSP, or org.ietf.sip.foo?

Presumably, if an extension *would* have fallen under the org.ietf.sip
namespace under the proposed scheme it would fall under the "default"
namespace.

Anders

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