Re: [cnit] CNIT Charter bashing..

"Dwight, Timothy M (Tim)" <> Mon, 15 June 2015 17:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 010161A9102 for <>; Mon, 15 Jun 2015 10:26:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.802
X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HqNy5slNcQEf for <>; Mon, 15 Jun 2015 10:26:48 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A8B541A90FD for <>; Mon, 15 Jun 2015 10:26:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=corp; t=1434389208; x=1465925208; h=from:to:cc:date:subject:message-id:references: content-transfer-encoding:mime-version; bh=je/DNL3aw1GCoaI+ATFs77qclrp5SIWMqi9eygudpoI=; b=HhodLKj/hhQ54F2gpVS2KQbGoa+5XSJvb4wdZrjgzwvM30dzy4dQiAC6 drdMq3Oe79+tQIFESzzfEHVK0om7Gjqo/6F2/lqepm19KE7KAzehx3mS4 Q9/9b1or5oqdQpIdMhNFfhf/2Uy2L8KqIa9hXt0Yol4kOiPX5EDNo/tV7 o=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO ([]) by with ESMTP; 15 Jun 2015 17:26:46 +0000
From: "Dwight, Timothy M (Tim)" <>
X-IronPort-AV: E=Sophos;i="5.13,620,1427760000"; d="scan'208";a="35762128"
Received: from (HELO ([]) by with ESMTP; 15 Jun 2015 17:26:46 +0000
Received: from ([]) by ([]) with mapi; Mon, 15 Jun 2015 13:26:44 -0400
To: Henning Schulzrinne <>, Richard Shockey <>
Date: Mon, 15 Jun 2015 13:26:43 -0400
Thread-Topic: [cnit] CNIT Charter bashing..
Thread-Index: AQHQpF27t1IjTQnD9Ee6If5FuC7/752nvtOAgAAcbYD//73Z54ABUaEAgAA9LQD//8LlU4AARHQAgAAZ6QCAAArCAIAAB9cAgAAPTgCAABkwgP//7x3tAA73xIAARAClgQAI3ukQAC96jcA=
Message-ID: <>
References: <> <> <> <> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <> <> <> <> <> <> <> <> <>, <> <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="windows-1257"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [cnit] CNIT Charter bashing..
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Calling Name Identity Trust discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 15 Jun 2015 17:26:51 -0000

A couple of clarifications suggested to me offline.  First a quote from TS 24.607, which defines the Originating Identity Presentation (OIP) and Originating Identity Restriction (OIR) services:

   "The OIP service provides the terminating user with the possibility of receiving trusted (i.e. network provided) identity information in order to identify the originating user"


a) it generally addresses network -provided identity (which normally translates to the content of a P-Asserted-Identity header; though it allows as a network option to remove P-A-ID and convey calling identity information in the From header).

b) It does not specify how the terminating network obtains the identity information it "asserts" to the UE.  The most obvious place would be from the P-Asserted-Identity header it received in the request.  But I don't see any prohibition against other things, e.g., of the terminating network modifying the information it received in P-A-ID.  One thought relevant to this discussion is that the terminating network might do a CNAM query using the calling number from a P-A-ID header extracted from the request as key, and put the result in the display-name field of a P-Asserted-Identity header it sends to the UE.  As far as I can tell the 3GPP spec does not prohibit such things.

c) it talks about providing the terminating user with the _possibility_ of receiving calling user identity information.  Which I believe means that it governs network behavior but not the behavior of the terminating device.  The network may for example communicate a calling name in a P-A-ID header, but the device might display instead the name it has in its contact list for that number.  Or the device might obtain a name from another source (e.g., query some name service), or display no name at all.  Point being, the 3GPP spec does not mandate what the human actually sees.


-----Original Message-----
From: Dwight, Timothy M (Tim) 
Sent: Sunday, June 14, 2015 1:22 PM
To: 'Henning Schulzrinne'; Richard Shockey
Subject: RE: [cnit] CNIT Charter bashing..

This sounds right.  3GPP IMS standards support both user-provided identity information (the FROM header) and network-provided identity information (the P-Asserted-Identity header).  Both can optionally include a display-name.  

The Originating Identity Presentation (OIP) and Originating Identity Restriction (OIR) services generally govern presentation to the called user of the network-provided identity information.  The network may or may not also restrict (in the case of OIR) presentation of the user-provided identity information.


-----Original Message-----
From: cnit [] On Behalf Of Henning Schulzrinne
Sent: Sunday, June 14, 2015 9:02 AM
To: Richard Shockey
Subject: Re: [cnit] CNIT Charter bashing..

The VoLTE/IMS experts listening probably know this better, but judging from some quick Googling of sample VoLTE call flows, SIP display name information is already part of the IMS/VoLTE standards, so model #1 (NNI) shouldn't be that hard, and we can then build on that, as you hint at.

I suspect we all agree that the barrier to entry should be minimal. We can discuss, for example, whether a by-reference or by-value mechanism is better, or we need both.

From: Richard Shockey []
Sent: Friday, June 12, 2015 9:29 PM
To: Henning Schulzrinne; Dwight, Timothy M (Tim); Brian Rosen
Cc:;; Stephen Farrell; Ben Campbell
Subject: Re: [cnit] CNIT Charter bashing..

Henning the biggest issue is that any form of advanced CNAM display is not currently applicable to the the mobile access devices. Which are now finally over 50% of the NANP even if you consider BYOD in the enterprise.
Yea that is another use case.

Hence the issue with Apple. This is ultimately a problem with that will have to be coordinated with US GSMA or GSMA generally.

Or IMHO with the the 8th floor on 12th st. It really is a jawboning use.
Tom needs to call Tim Cook or Larry Page and make the ask.

I do reject Brians pretense here. Given the IETF context perfection is actually the enemy of deployment.

I want a charter that is simple and clear.  Header and object. Period.  If that is impossible then Š..

Its time the AD¹s decide.

cnit mailing list