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

[Paul Kyzivat <[e-mail]>]

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
>>>>
>>>>
>>>
>>
>
>