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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 10 Feb 2006 09:39:58 -0500

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Feb 2006 11:19:53 -0500

> the table should never be incomplete.

In theory that would cover it. But in practice it would introduce 
dependencies that would serialize the progression to rfc of all drafts 
that define headers or methods. That cure seems worse than the disease.

> Say it is undefined?  Say it is optional?  Say it is disallowed?

I think all of these are possibilities.

> It seems the latter choice is what trips us up.  

Yeah, that is the ugly case.