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

From: "Kristoffer Gronowski \(AL/EAB\)" <[email-masked]>
Date: Thu, 9 Feb 2006 10:38:22 +0100

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

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 9 Feb 2006 09:25:18 -0600

I generally support your point Aki, however wouldn't we essentially wind up with a "table-like" design detail in any new methods to describe which headers are valid or invalid for that particular method? I would expect that any draft building off of existing RFCs would need to explain how existing headers interact with a new method introduced in the draft...

It could get messy either way.

Regards,
Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Aki
Niemi
Sent: Thursday, February 09, 2006 9:12 AM
To: ext Michael Hammer (mhammer)
Cc: Sanjay Sinha (sanjsinh); [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Sip] PUBLISH and PAI/PPI

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