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

Sorry if that was baffling, I thought we were entertaining a case where
611 was intended to be a telephone number: say that instead of "foo", that
URI contained a carrier's domain, and this happened to be the unhelpful
way the carrier in question stored all telephone numbers in SIP URIs. In
the case where "611" is instead in a tel URL, or there is a clear
user=phone parameter to the SIP URI, it is a bit more obvious - but no
less clear how to canonicalize it for international transport or something.

Jon Peterson
Neustar, Inc.

On 12/15/15, 11:45 AM, "DRAGE, Keith (Keith)"
<keith.drage@alcatel-lucent.com> wrote:

>I'm lost.
>
>sip:611@foo.com, before conversion to canonical form, is a SIP URI
>belonging to foo.com. It is not a telephone number or a dial string.
>Depending on how foo.com assigns its SIP URIs it might relate to a
>dialstring 611 in foo.com land, but that is an entirely arbitrary
>decision of foo.com, and nothing that should be verified anywhere as a
>telephone number.
>
>This might be a string that exists after conversion of a tel-URI or
>dialstring to canonical form, but that is not what is being stated below.
>
>As such it is outside the scope of STIR.
>
>Keith
>
>
>
>
>-----Original Message-----
>From: Peterson, Jon [mailto:jon.peterson@neustar.biz]
>Sent: 15 December 2015 19:09
>To: Paul Kyzivat; DRAGE, Keith (Keith); stir@ietf.org
>Subject: Re: [stir] stir-06: Reality check on numbers (6.1.1)
>
>
>
>The use of service numbers in the From is a case where our text is
>necessarily speculative. This gets into territory where it's unclear that
>we even want the verification to work. If a callee in, say, Austria
>receives a call from sip:611@foo.com (presumably they wouldn't see a
>service number in the To), is it useful for the callee to know that the
>call came from "611"? One can argue it isn't even particularly useful for
>callees in America.
>
>
>Does that mean we shouldn't allow service numbers in these fields? If
>they are permitted in To and From in baseline SIP, we should at least
>have a story about them. There is some use in signing the To field for
>service numbers to prevent cut-and-paste attacks. On balance, I don't see
>any decisive reason to forbid it. Again, the worst thing that can happen
>is verification will fail, and if the number is weird, or has leaked into
>a place where it shouldn't be, failure is probably the right thing.
>
>Jon Peterson
>Neustar, Inc.
>
>On 12/15/15, 10:52 AM, "Paul Kyzivat" <pkyzivat@alum.mit.edu> wrote:
>
>>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
>>>
>>>
>>
>