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

[Miguel Garcia <[e-mail]>]

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

Michael Hammer (mhammer) wrote:

> 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: [e-mail] 
>>[mailto:[e-mail]] On Behalf Of Miguel Garcia
>>Sent: Friday, August 26, 2005 7:44 AM
>>To: Jesske, R
>>Cc: [e-mail]; 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
>>>[e-mail]
>>>https://www1.ietf.org/mailman/listinfo/sipping-tispan
>>
>>-- 
>>Miguel A. Garcia           tel:[phone]
>>sip:[e-mail]
>>Nokia Research Center      Helsinki, Finland
>>
>>
>>_______________________________________________
>>Sipping-tispan mailing list
>>[e-mail]
>>https://www1.ietf.org/mailman/listinfo/sipping-tispan
> 
> 

-- 
Miguel A. Garcia           tel:[phone]
sip:[e-mail]
Nokia Research Center      Helsinki, Finland


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