Subject: RE: [Sip] PUBLISH and PAI/PPI

From: "James M. Polk" <[email-masked]>
Date: Fri, 10 Feb 2006 13:59:34 -0600

Mike

When was the last Method defined? (hint: PUBLISH in RFC 3903) What year? 
(Oct 2004)

When was the Method before that defined (hint: REFER)? What year? (April 2003)

Will we have one in the next 2 years?

Will we have two in the next 4 years?

We do *not* define several Methods per year.

We aren't even at 1 new Method a year.

We do define new Headers every once in a while, but only a couple a 
year.  This race condition you talk of isn't going to be that overlapping 
IMO.  I think we're past that scenario - which was present between 3261 and 
3515

At 09:39 AM 2/10/2006 -0500, Michael Hammer \(mhammer\) wrote:
>Jonathan,
>
>Re: incompleteness.
>
>If an RFC defining a new header addresses all known methods, and
>if an RFC defining a new method addresses all known headers, then
>the table should never be incomplete.
>
>The question is what should an RFC author define for headers/methods
>that were not the main focus of their draft?
>
>Say it is undefined?  Say it is optional?  Say it is disallowed?
>
>It seems the latter choice is what trips us up.
>I guess this is an extensibility process question.
>
>Mike
>
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of Jonathan Rosenberg (jdrosen)
> > Sent: Friday, February 10, 2006 7:17 AM
> > To: Drage, Keith (Keith)
> > Cc: Sanjay Sinha (sanjsinh); 'Aki Niemi';
> > [email-masked]'; [email-masked]'; Paul Kyzivat
> > (pkyzivat); [email-masked]'
> > Subject: Re: [Sip] PUBLISH and PAI/PPI
> >
> > The problem with the tables is that they assume an easily
> > enumerable and consistent approach across documents of
> > defining what methods a request go in. The problem is, it
> > sometimes depends on other factors.
> > Content-Type for example reuqires a special value in the
> > table in 3261 to indicate why it needs to be there.
> >
> > Another problem is that you need to worry about consistency
> > of the tables with normative text that appears elsewhere in
> > the document about where the headers are used.
> >
> > And, of course, the problem that the tables become incomplete
> > as new methods and headers get added in other specifications.
> >
> > The main benefit of the tables is, in principal, to provide
> > clear guidance on construction of requests and responses. The
> > tables force you to think about applicability of extensions.
> > Another way to do that is to simply require that
> > specifications of new methods include text that clearly
> > discusses, using normative terms, applicability of various
> > headers, and furthermore, for new header specs, defines
> > applicability to methods.
> >
> > -Jonathan R.
> >
> > Drage, Keith (Keith) wrote:
> >
> > > I have suggested in the past that rather than putting
> > method names in
> > > this table, we would be better off using columns like
> > "method outside
> > > dialog", "method used within an existing dialog", "method used to
> > > initiate a dialog", "target refresh request".
> > >
> > > However any such suggestion always seems to get lost in noise from
> > > Jonathan about how these tables cannot be relied upon,
> > therefore it is
> > > not worth maintaining them.
> > >
> > > regards
> > >
> > > Keith
> > >
> > >
> > >> -----Original Message----- From: [email-masked]
> > >> [mailto:[email-masked]]On Behalf Of Paul Kyzivat Sent: 09
> > >> February 2006 16:28 To: Aki Niemi Cc: Sanjay Sinha (sanjsinh);
> > >> [email-masked]; [email-masked];
> > >> [email-masked] Subject: Re: [Sip] PUBLISH and PAI/PPI
> > >>
> > >>
> > >> While the existing tables are a mess, I think there is
> > considerable
> > >> value in having a well defined way to determine where things are
> > >> allowed to be used. It should be possible to come up with a formal
> > >> way to say things like: "H can be used in any method", or
> > "H may only
> > >> be used in methods X,Y,Z". Then this formalized language can be
> > >> included in the IANA header registry. From it, anyone
> > could construct
> > >> their own table.
> > >>
> > >> Paul
> > >>
> > >> Aki Niemi wrote:
> > >>
> > >>> Hi Michael,
> > >>>
> > >>> ext Michael Hammer (mhammer) wrote:
> > >>>
> > >>>
> > >>>> Are you suggesting that such tables should no longer be
> > >>
> > >> embedded in each
> > >>
> > >>>> RFC?
> > >>>
> > >>>
> > >>> Yes; I'm suggesting we quit copy-pasting and augmenting
> > >>
> > >> tables 2 and 3
> > >>
> > >>> of RFC 3261. It will simply never produce tables that are
> > >>
> > >> complete. It
> > >>
> > >>> will only produce questions like the one that started the thread.
> > >>>
> > >>>
> > >>>
> > >>>> Or, are you suggesting it would be better to have an
> > >>
> > >> uber-table IANA
> > >>
> > >>>> registry that can be updated every time we discover a new
> > >>
> > >> header-method
> > >>
> > >>>> usage mapping.
> > >>>
> > >>>
> > >>> No, I'm not proposing any new registry.
> > >>>
> > >>> Instead of saying that header field H is "o" (as in
> > optional) for
> > >>> methods X, Y, and Z, we could simply say that H can be
> > used in any
> > >>> method. Then again for header fields like Refer-To, it should be
> > >>> sufficient to say that it is only allowed in REFER, instead
> > >>
> > >> of marking
> > >>
> > >>> it as "-" (as in not applicable) for every known method
> > >>
> > >> there is at the
> > >>
> > >>> time of writing.
> > >>>
> > >>> PAI is a good example of a header field whose entire reason for
> > >>> existance is that it can indicate the asserted identity of
> > >>
> > >> the sender of
> > >>
> > >>> any method. So it really makes no sense to specifically
> > >>
> > >> create a "usage"
> > >>
> > >>> of PAI with, say, PUBLISH.
> > >>>
> > >>> Then again, SIP-ETag is another good example of a header
> > >>
> > >> field that will
> > >>
> > >>> be meaningless in a method, unless it is specifically
> > written down
> > >>> somewhere what it means there.
> > >>>
> > >>>
> > >>>> But, that may require an uber-table RFC on which that IANA
> > >>
> > >> registry is
> > >>
> > >>>> based.
> > >>>
> > >>>
> > >>> I'm also not suggesting anything like that. I'm suggesting
> > >>
> > >> we forget
> > >>
> > >>> about tables altogether.
> > >>>
> > >>> Cheers, Aki
> > >>>
> > >>> _______________________________________________ Sip mailing list
> > >>> https://www1.ietf.org/mailman/listinfo/sip This list is for NEW
> > >>> development of the core SIP Protocol Use
> > >>> [email-masked] for questions on current sip Use
> > >>> [email-masked] for new developments on the application of sip
> > >>>
> > >>
> > >> _______________________________________________ Sip mailing list
> > >> https://www1.ietf.org/mailman/listinfo/sip This list is for NEW
> > >> development of the core SIP Protocol Use
> > >> [email-masked] for questions on current sip Use
> > >> [email-masked] for new developments on the application of sip
> > >>
> > >
> > >
> > > _______________________________________________ Sip mailing list
> > > https://www1.ietf.org/mailman/listinfo/sip This list is for NEW
> > > development of the core SIP Protocol Use
> > > [email-masked] for questions on current sip Use
> > > [email-masked] for new developments on the application of sip
> > >
> >
> > --
> > Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> > Cisco Fellow                                   Parsippany, NJ
> > 07054-2711
> > Cisco Systems
> > [email-masked]                              FAX:   (973) 952-5050
> > http://www.jdrosen.net                         PHONE: (973) 952-5000
> > http://www.cisco.com
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use
> > [email-masked] for questions on current sip
> > Use [email-masked] for new developments on the application of sip
> >
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use [email-masked] for questions on current sip
>Use [email-masked] for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 10 Feb 2006 18:27:51 -0500

Well, we all know that we have few new headers since INFO or MESSAGE 
appear to do the job for everything ;)

I'll take this opportunity to remind folks of an old draft I wrote on 
that topic:

http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt

-Jonathan R.

James M. Polk wrote:

> year.  This race condition you talk of isn't going to be that 
> overlapping IMO.  I think we're past that scenario - which was present 
> between 3261 and 3515
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com