Re: [dispatch] FW: New Version Notification for draft-patel-dispatch-cpc-oli-parameter-00

Jon Peterson <jon.peterson@neustar.biz> Thu, 08 October 2009 20:44 UTC

Return-Path: <jon.peterson@neustar.biz>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78F163A6968 for <dispatch@core3.amsl.com>; Thu, 8 Oct 2009 13:44:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.363
X-Spam-Level:
X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAoWyuk1beox for <dispatch@core3.amsl.com>; Thu, 8 Oct 2009 13:44:43 -0700 (PDT)
Received: from neustar.com (ns6.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id F02C03A69F8 for <dispatch@ietf.org>; Thu, 8 Oct 2009 13:44:42 -0700 (PDT)
Received: from ([192.168.128.21]) by stihiron1.va.neustar.com with ESMTP id G6K7MJ1.896929; Thu, 08 Oct 2009 16:46:20 -0400
Message-ID: <4ACE4F9B.5090909@neustar.biz>
Date: Thu, 08 Oct 2009 13:46:19 -0700
From: Jon Peterson <jon.peterson@neustar.biz>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Milan Patel <milanpa@nortel.com>
References: <0913B6CD18F370498CD65864CF254E900AFC3BBD@zharhxm1.corp.nortel.com>
In-Reply-To: <0913B6CD18F370498CD65864CF254E900AFC3BBD@zharhxm1.corp.nortel.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: DISPATCH <dispatch@ietf.org>
Subject: Re: [dispatch] FW: New Version Notification for draft-patel-dispatch-cpc-oli-parameter-00
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Oct 2009 20:44:44 -0000

In evaluating proposals to add capabilities to SIP via a tel URI, the 
first question we ask is, "Would this be useful in SIP requests that do 
NOT use telephone numbers?" If the answer is "yes," then probably the 
capability should be added to SIP in a way that works with and without 
the tel URI. (The draft is very slightly unclear  about whether or not 
you can include this parameter in SIP URIs that do not contain embedded 
tel URIs but do contain non-tel-URI representations of telephone numbers 
- but I'm speaking here to the overall intention to couple the use of 
OLI/CPC information to telephone numbers exclusively.)

While the draft focuses on the use case where SIP is gatewaying to ISUP, 
and thus where telephone numbers are likely to be used, I would be 
hesitant to rule out uses that do not involve telephone numbers - 
especially when the motivating use case given is REGISTER in an 
emergency context. Encapsulating the opaque numeric values of OLI into a 
SIP parameter also more or less restricts the use of this to entities 
that understand ISUP. This begs the obvious question: should there be a 
way in SIP (outside of gatewaying)  to express these same concepts? 
Since you already translate the CPC values into human-readable 
equivalents ("operator", "payphone", "test"), is there some reason why 
OLI can't receive the same treatment? The only example of the semantics 
of OLI that you give ("oli=29" meaning "prison") indeed seems it could 
admit of that translation. If there is some good reason why CPC should 
be translated and OLI should be encapsulated, the draft should 
explicitly motivate it.

By the by, since the Acks mention that I submitted a version of this 
proposal prior to Rohan's, just as an historical aside I in fact split 
that out from the original draft-ietf-sip-privacy-04 by Flemming and 
Bill Marshall, which for some reason had it tacked into an appendix. The 
parameter proposed in that document (which can still be found via 
Google), the Nature of Party ("np") parameter, maps to a set of 
human-readable literals like "ordinary", "police",  "payphone", 
"emergency", and so on. The document then proposes a mapping to the ANI 
II digits; one could just as easily be provided for OLI or CPC in the 
ISUP variants of interest. The example given in that appendix shows this 
being used in a URI that doesn't contain a telephone number. In any 
event, if you want to have a pedigree of the idea in your Acks, you 
shouldn't leave out that document.

Jon Peterson
NeuStar, Inc.

Milan Patel wrote:
> Hi,
>
> A new version of the Internet Draft for the Calling Party's Category and
> Originating Line Identity URI Parameters is now available. 
> http://www.ietf.org/id/draft-patel-dispatch-cpc-oli-parameter-00.txt
>
> This is based on Rohan Mahy's draft-mahy-iptel-cpc-06
>
> Best regards,
> Milan
>
>
> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] 
> Sent: 08 October 2009 18:40
> To: Patel, Milan (MOP:EP10)
> Cc: r.jesske@telekom.de; mdolly@att.com
> Subject: New Version Notification for
> draft-patel-dispatch-cpc-oli-parameter-00 
>
>
> A new version of I-D, draft-patel-dispatch-cpc-oli-parameter-00.txt has
> been successfuly submitted by Milan Patel and posted to the IETF
> repository.
>
> Filename:	 draft-patel-dispatch-cpc-oli-parameter
> Revision:	 00
> Title:		 Uniform Resource Identifier (URI) Parameters for
> indicating the Calling Party's Catagory and Originating Line Identity
> Creation_date:	 2009-10-08
> WG ID:		 Independent Submission
> Number_of_pages: 10
>
> Abstract:
> This document defines two new URI parameters to describe the calling
> party's category and toll class of service originating line
> information which are parameters also used in SS7 ISUP and other
> telephony signalling protocols.  The intended use of these URI
> parameters is for the "tel" URI or equivalent SIP URI representation.
>  
>
>
>
> The IETF Secretariat.
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>