[Sipping] Comment on draft-haluska-sipping-directory-assistance-07

"DRAGE, Keith (Keith)" <drage@alcatel-lucent.com> Fri, 17 April 2009 10:12 UTC

Return-Path: <drage@alcatel-lucent.com>
X-Original-To: sipping@core3.amsl.com
Delivered-To: sipping@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DED13A682F for <sipping@core3.amsl.com>; Fri, 17 Apr 2009 03:12:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.021
X-Spam-Level:
X-Spam-Status: No, score=-4.021 tagged_above=-999 required=5 tests=[AWL=-1.772, BAYES_00=-2.599, HELO_EQ_FR=0.35]
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 lyo0xYCsuEbc for <sipping@core3.amsl.com>; Fri, 17 Apr 2009 03:12:36 -0700 (PDT)
Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 6AEBA3A69F9 for <sipping@ietf.org>; Fri, 17 Apr 2009 03:12:36 -0700 (PDT)
Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3HADmrv019956 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <sipping@ietf.org>; Fri, 17 Apr 2009 12:13:48 +0200
Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 17 Apr 2009 12:13:48 +0200
From: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>
To: sipping <sipping@ietf.org>
Date: Fri, 17 Apr 2009 12:13:47 +0200
Thread-Topic: Comment on draft-haluska-sipping-directory-assistance-07
Thread-Index: Acm/RTJ2EbvUXhxAR/KrDHu+9GO0sA==
Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D6758C60D6@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84
Subject: [Sipping] Comment on draft-haluska-sipping-directory-assistance-07
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipping>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Apr 2009 10:12:37 -0000

I was just glancing through:

http://tools.ietf.org/html/draft-haluska-sipping-directory-assistance-07

I believe the ISUP used within this document in parts is the North American specific version, and as it currently stands the document is not applicable where such specifics do not apply.

I would suggest that either:

-	the document is reviewed and suggestions incorporated from ISUP experts outside North America; or

-	the document states up from that it is North American specific.

I also note that the document makes reference to draft-mahy-iptel-cpc. While this is used by a number of other SDOs, it has expired and I do not know what the future of it is. My understanding was that RFC 5341 defined the registration policy as below, but I know of no work in progress to put that in place:

4.2.  Registration Policy for tel URI Parameters

   As per the terminology in [3] and actions accorded to such a role,
   the registration policy for tel URI parameters shall be
   "Specification Required, Designated Expert" (the former implicitly
   implies the latter.)

   The Designated Expert when deliberating on whether to include a new
   parameter in the tel URI registry may use the criteria provided below
   to reach a decision (this is not an exhaustive list but
   representative of the issues to consider when rendering an equitable
   decision):

   o  If the tel URI -- with the parameter under consideration -- will
      be converted to a URI used by other signaling protocols such as
      the Session Initiation Protocol (SIP [5]) or H.323 [7], then the
      expert must consider whether this parameter merely encapsulates
      signaling information that is not meaningful to the processing of
      requests in the domain of the converted URI.  For example, certain
      Integrated Services Digital Network (ISDN) User Part (ISUP, [8])
      parameters have no equivalent corollary in SIP; thus their
      presence or absence in a SIP URI will not hinder the normal rules
      for processing that URI.  Other parameters may affect the normal
      processing rules associated with the URI; in such cases, the
      expert must consider carefully the ramifications, if any, of the
      presence of such parameters.

   o  Certain parameters of a tel URI can be optional.  These parameters
      act as metadata about the identifier in the tel URI.  Optional
      parameters should provide additional information to a service for
      which they apply instead of acting as enablers of that service in
      the first place.  The service must continue to be invoked and
      operate normally even in the absence of these parameters.

regards

Keith