Subject: RE: AW: AW: AW: [Sipping-tispan] TISPAN requirements, first requiements

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 26 Aug 2005 13:39:01 -0400

My concern over what gets put into the message, is that those indicators
could potentially be leaked to the UAS because some intermediate node
was not updated with the latest RFC, and according to SIP merely passed
on what it did not understand.

Mike

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Miguel Garcia
> Sent: Friday, August 26, 2005 7:44 AM
> To: Jesske, R
> Cc: [email-masked]; Alexeitsev, D
> Subject: Re: AW: AW: AW: [Sipping-tispan] TISPAN 
> requirements, first requiements
> 
> Hi Roland:
> 
> If you don't have a P-Asserted-Identity in the signalling, is 
> because the trust relationship has been broken at some point, 
> in which case, you shouldn't trust also the role parameter 
> independently of the header where you put it.
> 
> The nice property of adding a role parameter to the 
> P-Asserted-Identity header is that you get the trust for 
> free, which is the expected behaviour for this service.
> 
> /Miguel
> 
> Jesske, R wrote:
> 
> >>>I think it might be worth considering adding role parameters to 
> >>>P-Asserted-ID.
> >>
> >>That is OK with me and solves most of the problems.
> >>
> > 
> > 
> > 
> > Paul,
> > I have to revice my proposal. 
> > I thought that is the solution to bind it to the 
> P-Asserted-Id. But in the case were we have a anonymous 
> communication restricted by the network. We usually have no 
> Calling Party number. And therefore also no P-Asserted-Identity.
> > So we cannot bind this to the P-Asserted-Identity.
> > 
> > Perhaps we can bind it to the privacy header?
> > 
> > Or any other?
> > 
> > Best Regards.
> > 
> > Roalnd
> > 
> > _______________________________________________
> > Sipping-tispan mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sipping-tispan
> 
> -- 
> Miguel A. Garcia           tel:+358-50-4804586
> sip:[email-masked]
> Nokia Research Center      Helsinki, Finland
> 
> 
> _______________________________________________
> Sipping-tispan mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sipping-tispan
> 

_______________________________________________
Sipping-tispan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sipping-tispan

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 29 Aug 2005 09:50:02 +0300

But this solution of adding a parameter to the P-Asserted-Identity 
works. IMS supports from day one RFC 3325, so there are procedures to 
add/delete the P-Asserted-Identity when traversing a trust domain.

Now, if you add a parameter to that header field, proxies that do not 
support the extension will not act upon it, so they will forward it if 
present and if the P-Asserted-Identity header fiedl has to be forwarded. 
If the header field is stripped, it will include the parameter, which 
is, in my opinion, the correct behaviour.

/Miguel