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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 9 Feb 2006 09:43:12 -0500

Are you suggesting that such tables should no longer be embedded in each
RFC?

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.  

But, that may require an uber-table RFC on which that IANA registry is
based.

Mike

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Aki Niemi
> Sent: Thursday, February 09, 2006 5:04 AM
> To: ext Andrew Allen
> Cc: Sanjay Sinha (sanjsinh); [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [Sip] PUBLISH and PAI/PPI
> 
> I think it only makes sense to list applicability of a header 
> field to specific methods if they are only supposed to be 
> used with those methods alone.
> 
> Outside of that, the IANA registry is the place to look for 
> header fields and methods alike. The tables in individual 
> RFCs only add to the confusion.
> 
> Cheers,
> Aki
> 
> ext Andrew Allen wrote:
> > Interesting dilemma.
> > 
> > The P-Asserted-Identity is a "P-header" that is not a 
> standards track 
> > RFC. But RFC 3903 is standards track.
> > 
> > Should the table in standards track RFC include all headers 
> that are 
> > not standards track?
> > 
> > Andrew
> > 
> > -------------------------- Andrew Allen Manager Standards 
> Research In 
> > Motion Ltd BlackBerry Mobile  +1 847 809 8636 http://www.rim.com/
> > 
> > Sent from my BlackBerry Wireless Handheld
> > 
> > 
> > ----- Original Message ----- From: [email-masked] To: Dean 
> > Willis; Sanjay Sinha ((sanjsinh)) Cc: [email-masked] Sent: Thu Feb 09
> > 04:38:22 2006 Subject: RE: [Sip] PUBLISH and PAI/PPI
> > 
> > Yes it is used in IMS systems that run OMA PAG. In the 3GPP spec
> > 24.229 there is a reference to that Publish has a P-Asserted-ID and 
> > then it refers to rfc3325 section 9.1 But in that section there is 
> > nothing about Publish but I think that it is a matter of oversight 
> > both in IETF and 3GPP. The 3325 can not point to PUBLISH 
> rfc since it 
> > was released after. The RFC 3903 should have had PAI listed 
> in section 
> > 11.1.1.
> > 
> > BR Kristoffer
> > 
> > -----Original Message----- From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Dean Willis Sent: den 9 
> > februari 2006 09:51 To: Sanjay Sinha ((sanjsinh)) Cc: [email-masked]
> > Subject: Re: [Sip] PUBLISH and PAI/PPI
> > 
> > 
> > 
> > On Feb 8, 2006, at 1:43 PM, Sanjay Sinha ((sanjsinh)) wrote:
> > 
> > 
> >> RFC 3325 lists out SIP methods in which P-Asserted-Identity/P- 
> >> Preferred-Identity header is applicable. But PUBLISH is 
> missing from 
> >> the list. Neither is this header support listed in PUBLISH 
> RFC, 3903. 
> >> Just wanted to confirm if these headers are applicable to 
> PUBLISH or 
> >> not?
> >> 
> > 
> > 
> > I'm aware of no reason it would not work. I believe we 
> discussed this 
> > on one of the lists about two years ago and decided this 
> was simply an 
> > oversight in the RFC. I believe the IMS people are using p-aid with 
> > PUBLISH.
> > 
> > -- Dean
> > 
> > 
> > 
> > _______________________________________________ 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
> > 
> > 
> > 
> > 
> ---------------------------------------------------------------------
> >  This transmission (including any attachments) may contain 
> > confidential information, privileged material (including material 
> > protected by the solicitor-client or other applicable 
> privileges), or 
> > constitute non-public information. Any use of this information by 
> > anyone other than the intended recipient is prohibited. If you have 
> > received this transmission in error, please immediately 
> reply to the 
> > sender and delete this information from your system. Use, 
> > dissemination, distribution, or reproduction of this 
> transmission by 
> > unintended recipients is not authorized and may be unlawful.
> > 
> > _______________________________________________ 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: Aki Niemi <[email-masked]>
Date: Thu, 09 Feb 2006 17:11:47 +0200

Hi Michael,

> Are you suggesting that such tables should no longer be embedded in each

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.

> registry that can be updated every time we discover a new header-method

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

I'm also not suggesting anything like that. I'm suggesting we forget 
about tables altogether.

Cheers,
Aki

---

From: Dean Willis <[email-masked]>
Date: Thu, 9 Feb 2006 10:02:58 -0600

> Are you suggesting that such tables should no longer be embedded in  

That's what I think. This part of the documentation has caused far  
more headpain than the rest of the specification family, and that's a  
lot!

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 09 Feb 2006 11:27:47 -0500

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