[MMUSIC] Issue with E164 numbers in SDP CS draft

"Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com> Mon, 24 September 2012 20:10 UTC

Return-Path: <miguel.a.garcia@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3306221F88D6 for <mmusic@ietfa.amsl.com>; Mon, 24 Sep 2012 13:10:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.955
X-Spam-Level:
X-Spam-Status: No, score=-5.955 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZC-d6DWNDS7M for <mmusic@ietfa.amsl.com>; Mon, 24 Sep 2012 13:10:22 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 147C221F88D5 for <mmusic@ietf.org>; Mon, 24 Sep 2012 13:10:21 -0700 (PDT)
X-AuditID: c1b4fb30-b7f7d6d0000042ea-35-5060be2cbf25
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 19.DF.17130.C2EB0605; Mon, 24 Sep 2012 22:10:21 +0200 (CEST)
Received: from [159.107.48.12] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.1; Mon, 24 Sep 2012 22:10:20 +0200
Message-ID: <5060BE2B.20101@ericsson.com>
Date: Mon, 24 Sep 2012 22:10:19 +0200
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: mmusic <mmusic@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLJMWRmVeSWpSXmKPExsUyM+Jvra7uvoQAg9nZFu8v6FpMXf6YxeLc p7ssDsweU35vZPVYsuQnk8fdW5eYApijuGxSUnMyy1KL9O0SuDLu7HcsOCZbcaRZsoFxingX IyeHhICJxOF7t1ghbDGJC/fWs3UxcnEICZxilLgw4QwThLOaUeLvyd9AGQ4OXgFNidYGe5AG FgFViTm/n4M1swmYS7Ru3MgOYosKBEuc27iNDcTmFRCUODnzCQuILSIgI7F302ZmEJtZIF7i 3p4LLCAjhQUMJDaeSoQI20pcmHOdBcKWl9j+dg5YuRDQ1sk3lzJPYOSfhWTqLCQts5C0LGBk XsUonJuYmZNebq6XWpSZXFycn6dXnLqJERiEB7f8NtjBuOm+2CFGaQ4WJXFePdX9/kIC6Ykl qdmpqQWpRfFFpTmpxYcYmTg4pRoYp6q5T3Zfc/Rdm915V+9nU154njiSFzj9f5PGqWO1D8Si PKwaePdxMH+d4HdzVcHLH3/DNsT2vLixetfz+DOW/3xv/4h336251mKvgtLmd3/9lxyf8CjO ykv9a/50tUVy/sdeHLPePW3JDxH25bkRDy8ZZ5f2qHfKne3fp5vX78WybKvLgXN5iUosxRmJ hlrMRcWJADvomNMQAgAA
Cc: Flemming Andreasen <fandreas@cisco.com>
Subject: [MMUSIC] Issue with E164 numbers in SDP CS draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Sep 2012 20:10:23 -0000

Hi,

as an author of draft-ietf-mmusic-sdp-cs

The authors were addressing the comments that we got back in February 
from Flemming. His complete e-mail was this one:

http://www.ietf.org/mail-archive/web/mmusic/current/msg09367.html

The authors have addressed all the comments, except the first one. We 
require a bit more of discussion on the list. I reproduce here the comment:

1) The document defines the "E164" 'addrtype' type as well as the "-" 
'addrtype' to be used in the "c=" line and wants to register these with 
IANA. As it turns out, RFC 3108 also defined these, however they never 
got registered with IANA. While the '-' seems to be defined similarly, 
the syntax for the "164" differs between the two, which is obviously a 
problem, not least considering RFC 3108 is Standards Track. Also, for 
some reason the cs-draft lists RFC 3108 as a normative reference, but it 
does not provide any normative text for its use.

The problem that is not listed here is the definition fo the "E164" 
'addrtype' in RFC 3108. I include here the relevant text:

    E164: If the addressType is E164, the address is expressed as a
    decimal number  with up to 15 digits.  For example:

         c=ATM E164 9738294382

    The use of E.164 numbers in the B-ISDN context is defined in ITU
    E.191.  There is a disparity between the ATM forum and the ITU in the
    use of E.164 numbers for ATM addressing.  The ATM forum (e.g., UNI
    Signaling 4.0) allows only International Format E.164 numbers, while
    the ITU (e.g., Q.2931) allows private numbering plans.  Since the
    goal of this SDP specification is to interoperate with all bearer
    signaling protocols, it allows the use of numbers that do not conform
    to the E.164 International Format.  However, to maximize overall
    consistency, network administrators can restrict the provisioning of
    numbers to the E.164 International Format.


The SDP CS draft indicates that only international E164 number must be 
used, and adds a '+' sign to indicate the international format of the 
number. RFC 3108 seems to allow both international and national format, 
but does not add the '+' sign to indicate that a digit-string means 
international format.

At first glance, one solution could be that the CS draft will use another 
addrtype, for example, "INTE164", to indicate international E.164 
numbers. However, being the CS draft a dependency to 3GPP Release 8 
(which was technical frozen in 2009), I think it is not fair to do this 
last-minute change at this stage. And I will be worried if there are 
already implementations deployed.

I want to stress that the usages of ATM in SDP and CS in SDP do not 
clash. I mean, the usage is so different that it is hard to foresee an 
implementation that will use RFC 3108 and SDP CS *at the same time*.

So, let me have a proposal that I believe will satisfy both RFC 3108 and 
the SDP CS draft.

The idea is to keep on using the "E164" addrtype in both documents. SDP 
CS needs to define the E164 number indicating that can convey both 
international and national numbers. If an international number is used, 
it is prepended by a '+' sign (as the draft currently says). If a '+' is 
written, then it is an international format. If a '+' sign is absent then 
it is up to the implementation to determine the scope of the number 
(national or international). The lack of '+' sign will only occur in the 
context of RFC 3108.

SDP CS will keep on only using international E.164 numbers, represented 
with the '+' sign, and will register (as it currently does) the "E164" 
'addrtype' with IANA.

Is this acceptable?

/Miguel




-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain