Re: [stir] stir-06: Reality check on numbers (6.1.1)

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 15 December 2015 18:52 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 048861AC3DB for <stir@ietfa.amsl.com>; Tue, 15 Dec 2015 10:52:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgVVwIgPDd0A for <stir@ietfa.amsl.com>; Tue, 15 Dec 2015 10:52:11 -0800 (PST)
Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 908911AC3D9 for <stir@ietf.org>; Tue, 15 Dec 2015 10:52:11 -0800 (PST)
Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-06v.sys.comcast.net with comcast id turP1r00B2D5gil01usATG; Tue, 15 Dec 2015 18:52:10 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-06v.sys.comcast.net with comcast id tusA1r00B3KdFy101usAS6; Tue, 15 Dec 2015 18:52:10 +0000
To: "Peterson, Jon" <jon.peterson@neustar.biz>, "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>, "stir@ietf.org" <stir@ietf.org>
References: <9C95CF4B-88BD-4EFF-9076-E59CF165E22D@standardstrack.com> <566AF294.6090001@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8BADE23BB6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <D29595DF.17587A%jon.peterson@neustar.biz>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <56706158.3080905@alum.mit.edu>
Date: Tue, 15 Dec 2015 13:52:08 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <D29595DF.17587A%jon.peterson@neustar.biz>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1450205530; bh=53uH3MAoiQijUH80ocwHmiNzJIVF9lYyy3C0jmCbw2w=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=SRRfO/yTRjg10JwnnTLPT7xUoJ/5D//vlxaAWCX70qwT4oCArUw4h3wnTWRF4IXXg J8ywh2zUtniwsIqjSjb3NcztyW/9JGF8Qr7abpsubp6HYlx5AURWTK/t3GEcax2dzZ BXpQ7XjhsfJTiLS6FA17fA0UlckIyRx/07nishEdl6UA63n/2lIA2oMDpx5syjYa9X nBzwVJCDYFcRZ6f+6TblpFFpsjQnG1SnslZp7A8dAQ4Xt3ml5vcwfaisOlXY1Fcc4A w6lpf7wibM62CV6e/KvAEdPpVWsx+1p9ixfINS2Jd/FOfVTGI5owBvM+1ASaJIvvmz oUXsyh8Yi3s+Q==
Archived-At: <http://mailarchive.ietf.org/arch/msg/stir/BSEOwDFpb7pO6n5tEC4FzCyKgXI>
Subject: Re: [stir] stir-06: Reality check on numbers (6.1.1)
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Dec 2015 18:52:13 -0000

On 12/15/15 1:30 PM, Peterson, Jon wrote:
>
> The canonicalization rules are not designed with the assumption that the
> string inputted to the algorithm is an E.164 number. They are designed to
> be as flexible as possible given the presence of a dial string -
> remembering that we canonicalize To as well as From. Ideally, everything
> we deal with would follow the dictates of RFC3966, sure. We just proceed
> with an abundance of caution.

So, do you assume that a uri of sip:611@foo.com will be canonicalized 
the same way by everybody?

I suppose everyone in the NANP might do so. But what about a recipient 
in some other locale?

I guess the theory is that at the borders between domains numbers will 
be rewritten to be understandable in the receiving domain. If the number 
doesn't contain its country code then it presumably needs to be added at 
a country boundary to be understood. That works for numbers that 
correspond to E.164 numbers. But what about 611? There is no standard 
way to put a country code on it.

	Thanks,
	Paul

> I would be happy to add some text saying that escaped characters should be
> removed as part of the canonicalization process.
>
> Jon Peterson
> Neustar, Inc.
>
> On 12/13/15, 9:34 AM, "stir on behalf of DRAGE, Keith (Keith)"
> <stir-bounces@ietf.org on behalf of keith.drage@alcatel-lucent.com> wrote:
>
>> The international E.164 number can only be decimal digits.
>>
>> That therefore means that the country code, the national destination
>> code, and the subscriber number, all of which are component parts of an
>> international E.164 number, can only be decimal digits.
>>
>> That would imply that the only part that could contain such a character
>> is a prefix to an E.164 number, or if the number is not an E.164 number,
>> such as a private dial plan.
>>
>> I'd note that RFC 3966 states: "All phone numbers MUST use the global
>> form unless they cannot be represented as such."
>>
>> I suspect that "*", "#", etc have more usage in numbers that are
>> dialstrings rather than telephone numbers.
>>
>> Regards
>>
>> Keith
>>
>> -----Original Message-----
>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Paul Kyzivat
>> Sent: 11 December 2015 15:58
>> To: stir@ietf.org
>> Subject: Re: [stir] stir-06: Reality check on numbers (6.1.1)
>>
>> On 12/10/15 9:15 PM, Eric Burger wrote:
>>> Section 6.1.1 on Canonicalization states:
>>>         Once an implementation has identified a telephone number, it must
>>>         construct a number string.  Implementations MUST drop any leading
>>>         +'s, any internal dashes, parentheses or other non-numeric
>>>         characters, excepting only the leading "#" or "*" keys used in
>>>         some special service numbers (typically, these will appear only
>>> in
>>>         the To header field value).  This MUST result in an ASCII string
>>>         limited to "#", "*" and digits without whitespace or visual
>>>         separators.
>>>
>>> Survey time: does pound or star  EVER appear in a From field? E.164
>>> does not allow it.
>>
>> pound isn't allowed at all in a sip uri, except via escaping.
>>
>> There is no mention of escaping (or unescaping) in the text. If there is
>> the possibility of pound coming through then that is needed.
>>
>> Also, * and # (as well as A-D) are never valid in global numbers, but are
>> valid within local numbers not just first, but anywhere in the number. So
>> why is there special treatment for a *leading* star or pound?
>>
>> ISTM that canonicalization of dialstrings that represent local rather
>> than global numbers is fraught with difficulty.
>>
>> 	Thanks,
>> 	Paul
>>
>>
>>
>> _______________________________________________
>> stir mailing list
>> stir@ietf.org
>> https://www.ietf.org/mailman/listinfo/stir
>>
>> _______________________________________________
>> stir mailing list
>> stir@ietf.org
>> https://www.ietf.org/mailman/listinfo/stir
>
>