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

["Peterson, Jon" <[e-mail]>]

Every once in a while I do think we need to take on a RFC3966 revision to
clear these matters up; these are ambiguities beyond the scope of STIR.
I'd propose it for MODERN's charter, but there's enough controversy there
already...

Jon Peterson
Neustar, Inc.

On 12/15/15, 12:24 PM, "Paul Kyzivat" <[e-mail]> wrote:

>On 12/15/15 2:57 PM, Peterson, Jon wrote:
>>
>> 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
>
>Yes, that is what I meant in this case.
>
>> 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.
>
>Except that <tel:611>, <sip:[e-mail];user=phone> or
><sip:[e-mail];user=dialstring> are *invalid* URI forms.
>
>To be valid, they require a phone-context parameter, such as:
><tel:611;phone-context=+1>,
><sip:611;phone-context=[e-mail];user=phone> or
><sip:611;phone-context=[e-mail];user=dialstring>.
>
>But, while phone-context is required, IIUC there are no rules for what
>the context value should be. It can be a number prefix (like +1), or a
>domain name. It has to be something that makes the number globally unique.
>
>For this to be understandable, both ends will need to understand the
>context. Then for the bis to work, they will have to agree on how to
>turn this into a canonical number string.
>
>One obvious way to do it would be for 611 in NANP to be canonicalized as
>+1611. That will disambiguate it from 611 dialed in Germany.
>
>But lacking some specification for how to do this it is just a tower of
>babel.
>
>	Thanks,
>	Paul
>
>> Jon Peterson
>> Neustar, Inc.
>>
>> On 12/15/15, 11:45 AM, "DRAGE, Keith (Keith)"
>> <[e-mail]> wrote:
>>
>>> I'm lost.
>>>
>>> sip:[e-mail], 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:[e-mail]]
>>> Sent: 15 December 2015 19:09
>>> To: Paul Kyzivat; DRAGE, Keith (Keith); [e-mail]
>>> 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:[e-mail] (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" <[e-mail]> 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:[e-mail] 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)"
>>>>> <[e-mail] on behalf of [e-mail]>
>>>>> 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:[e-mail]] On Behalf Of Paul Kyzivat
>>>>>> Sent: 11 December 2015 15:58
>>>>>> To: [e-mail]
>>>>>> 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
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/stir
>>>>>>
>>>>>> _______________________________________________
>>>>>> stir mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/stir
>>>>>
>>>>>
>>>>
>>>
>>
>>
>