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

Paul Kyzivat <pkyzivat@cisco.com> Mon, 29 August 2005 02:31 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9ZQs-0005TH-VA; Sun, 28 Aug 2005 22:31:34 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9ZQr-0005TC-8n for sipping-tispan@megatron.ietf.org; Sun, 28 Aug 2005 22:31:33 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26327 for <sipping-tispan@ietf.org>; Sun, 28 Aug 2005 22:31:31 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9ZS7-0006Yr-3r for sipping-tispan@ietf.org; Sun, 28 Aug 2005 22:32:51 -0400
Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 28 Aug 2005 19:31:23 -0700
X-IronPort-AV: i="3.96,148,1122879600"; d="scan'208"; a="208132019:sNHT32209458"
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j7T2VK2i027597; Sun, 28 Aug 2005 19:31:20 -0700 (PDT)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 28 Aug 2005 19:31:20 -0700
Received: from cisco.com ([10.86.240.70]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 28 Aug 2005 19:31:19 -0700
Message-ID: <43127376.5000706@cisco.com>
Date: Sun, 28 Aug 2005 22:31:18 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Miguel Garcia <Miguel.An.Garcia@nokia.com>
Subject: Re: AW: AW: AW: [Sipping-tispan] TISPAN requirements, first requiemen ts
References: <E7666D92C64C2845AEF12636FF94F95202319EB1@S4DE8PSAAGQ.blf.telekom.de> <430F006A.1040901@nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 29 Aug 2005 02:31:19.0791 (UTC) FILETIME=[BD40A7F0:01C5AC41]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Content-Transfer-Encoding: 7bit
Cc: sipping-tispan@ietf.org, "Alexeitsev, D" <D.Alexeitsev@t-com.net>
X-BeenThere: sipping-tispan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion of requirements for SIP introduced by ETSI TISPAN <sipping-tispan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping-tispan>, <mailto:sipping-tispan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/sipping-tispan>
List-Post: <mailto:sipping-tispan@ietf.org>
List-Help: <mailto:sipping-tispan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping-tispan>, <mailto:sipping-tispan-request@ietf.org?subject=subscribe>
Sender: sipping-tispan-bounces@ietf.org
Errors-To: sipping-tispan-bounces@ietf.org

I agree with Miguel.

I understand that there are cases where the system doesn't know who the 
caller is, but in that case I have already suggested that you insert a 
P-Asserted-Identity with a special value, such as perhaps just an 
identity of the originating network that is making assertions about the 
role of the caller. Once you have that header you can add role 
parameters to it.

In the case where the identity has to be made up in this way you can 
also, if you wish, insert a Privacy header that causes this made-up 
identity to be restricted.

	Paul

Miguel Garcia wrote:
> 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
>> Sipping-tispan@ietf.org
>> https://www1.ietf.org/mailman/listinfo/sipping-tispan
> 
> 

_______________________________________________
Sipping-tispan mailing list
Sipping-tispan@ietf.org
https://www1.ietf.org/mailman/listinfo/sipping-tispan