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

"Milan Patel" <milanpa@nortel.com> Fri, 09 October 2009 13:08 UTC

Return-Path: <MILANPA@nortel.com>
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 50BDD28C143 for <dispatch@core3.amsl.com>; Fri, 9 Oct 2009 06:08:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.274
X-Spam-Level:
X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 hTdUBCmw6Xni for <dispatch@core3.amsl.com>; Fri, 9 Oct 2009 06:08:16 -0700 (PDT)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 09D9328C0FD for <dispatch@ietf.org>; Fri, 9 Oct 2009 06:08:15 -0700 (PDT)
Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n99D9sG03101; Fri, 9 Oct 2009 13:09:55 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 09 Oct 2009 14:09:35 +0100
Message-ID: <0913B6CD18F370498CD65864CF254E900AFC4335@zharhxm1.corp.nortel.com>
In-Reply-To: <4ACE4F9B.5090909@neustar.biz>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [dispatch] FW: New Version Notification for draft-patel-dispatch-cpc-oli-parameter-00
Thread-Index: AcpIWG2LEh9C79w1SGmcT5Wo0ZWxJwAiByFg
References: <0913B6CD18F370498CD65864CF254E900AFC3BBD@zharhxm1.corp.nortel.com> <4ACE4F9B.5090909@neustar.biz>
From: Milan Patel <milanpa@nortel.com>
To: Jon Peterson <jon.peterson@neustar.biz>
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: Fri, 09 Oct 2009 13:08:17 -0000

Hi Jon,

Thanks for your initial evaluation for the draft. Your points make sense
and I'll discuss them with the co-authors prior to revising the
document. Indeed, I need to reconsider use of the oli and cpc for SIP
URIs that do not use telephone numbers. I think use cases beyond gateway
scenarios interworking SIP and ISUP would be useful to document if
indeed it is valuable to use the cpc and oli in SIP URIs that do not
include telephone numbers.

Using the Bellcore text terms of the OLI values was my initial
intention, but the use of the 2 digit code seemed clean and less
restrictive. Of course I could have extended this to the CPC and used
the 8 bit binary values assigned to CPC and OLI. I'll reconsider how the
CPC and OLI are represented as URI parameters based on your comments. 

Regards,
Milan

Milan Patel
Carrier Networks Core Standards
Nortel
milanpa@nortel.com
Telephone +44 162 843 2381 / ESN 560 2381
Mobile +44 774 053 9261 / ESN 748 9261


-----Original Message-----
From: Jon Peterson [mailto:jon.peterson@neustar.biz] 
Sent: 08 October 2009 21:46
To: Patel, Milan (MOP:EP10)
Cc: DISPATCH
Subject: Re: [dispatch] FW: New Version Notification for
draft-patel-dispatch-cpc-oli-parameter-00


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
>