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

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 9 Feb 2006 17:21:42 -0000

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

---

From: Dean Willis <[email-masked]>
Date: Thu, 9 Feb 2006 12:09:27 -0600

On Feb 9, 2006, at 11:21 AM, 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".

That's basically the approach we took in draft-ietf-sip- 
answermode-00.txt, which does not have the offending table.

However, the representation is not concise enough to be able to  
populate an IANA registry, if we think we need something like that.

Do we?

--
dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 10 Feb 2006 07:16:57 -0500

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
>> 
>> 
>>  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,
>>> 
>>>  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
>> 
>>> be meaningless in a method, unless it is specifically written
>>> down somewhere what it means there.
>>> 
>>> 
>>> 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

---

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

At 07:16 AM 2/10/2006 -0500, Jonathan Rosenberg wrote:
>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.

bingo!

... and someone(s), say the WG or the WG chairs, ought to ensure this text 
is in each ID prior to passing WGLC.

But this is just my opinion... and I'm always wrong wrt SIP   ;-)