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

[<[e-mail]>]

> But E.164 isn't an option for a service number like 611. So what are things like that to be converted to?
>
>The draft assumes that it will be converted into something consisting solely of digits, with possible leading * or #.
>
> If it is canonicalized as 611, then it will be ambiguous with a number in CC +61. (I guess there is no number "1" within +61, but it may take awhile to figure that out.)

Not necessarily (there's a couple of 1x in Australia) but clearly this does not scale, I agree. Access codes such as your x11 exist in most national dialling plans and "hacking a country code" to sign them with a risk of overlap is indeed not a good idea.  (Interestingly enough, Europe even has 11xyyy codes...... :)

The problem is that as calling party numbers (leaving stir aside) they're not converted. So either the NANP /(national dialing plans) set(s) aside a number subspace to map these access codes into some +1xxxxx611 E.164 +1 range to avoid that (it's quite ugly but I guess it would work if it can be reversed on the other side) or sign a RFC 3966 local number with +1. Any foolproof solution (and just  noting Brian's previous post that it's not necessarily a "must have", agreed) would probably have to be something like this.  

Philippe Fouquart
Orange Labs Networks
[phone]

-----Message d'origine-----
De : stir [mailto:[e-mail]] De la part de Paul Kyzivat
Envoyé : mercredi 16 décembre 2015 02:01
À : DRAGE, Keith (Keith); Peterson, Jon; [e-mail]
Objet : Re: [stir] stir-06: Reality check on numbers (6.1.1)

On 12/15/15 6:48 PM, DRAGE, Keith (Keith) wrote:
> I am aware that for example, some PBX deployments do this.
>
> But my understanding is that this is an entirely local arrangement within the PBX domain that such an arrangement applies, i.e. that a set of local numbers within the PBX map to a set of SIP URIs, and that that mapping is in this particular form, rather than to any other string of digits or alphanumeric characters.
>
> No RFC defines such a mapping, and I would not expect that any other domain would be expected to be aware of this local arrangement, anymore than it might be expected to know the relationship between the PBX numbering plan and E.164 numbers.
>
> I guess any such expectation is the crux of the matter, unless we are talking only about such a knowledge being critical for usage within the local domain, and that was not expressed within the mails.

This is all fixed by SBCs. But I don't think they all convert to E.164. 
They might convert to something else based on bilateral agreements between domains.

But E.164 isn't an option for a service number like 611. So what are things like that to be converted to?

The draft assumes that it will be converted into something consisting solely of digits, with possible leading * or #.

If it is canonicalized as 611, then it will be ambiguous with a number in CC +61. (I guess there is no number "1" within +61, but it may take awhile to figure that out.)

	Thanks,
	Paul

> Regards
>
> Keith
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:[e-mail]]
> Sent: 15 December 2015 23:04
> To: DRAGE, Keith (Keith); Peterson, Jon; [e-mail]
> Subject: Re: [stir] stir-06: Reality check on numbers (6.1.1)
>
> On 12/15/15 5:31 PM, DRAGE, Keith (Keith) wrote:
>> Well what was confusing was that the only way of reading the text in both your messages was that the example URI was prior to conversion to canonical form, i.e. if there were any URI parameters, they were still present. As none were specified, there could be none, and therefore the URI was a SIP URI pure and simple.
>
> Yes, the intent was that these were prior to canonicalization. (After 
> all, the results of canonicalization for the bis are not put into the 
> URI.)
>
> The simple fact is that URIs of the form sip:nnn@domain are very commonly used to represent phone numbers. And servers are very happy to conclude that they are numbers solely because the user part is all numeric, without the presence of user=phone.
>
> I expect that a domain that wants to use all numeric user parts that 
> are
> *not* phone numbers might have great difficulty interoperating with other domains. Probably this isn't a problem in practice because:
> - it just isn't done
> - domains that handle phone numbers don't peer with domains that
>     use non-phone-number URIs.
>
> 	Thanks,
> 	Paul
>
>> Keith
>>
>> -----Original Message-----
>> From: Peterson, Jon [mailto:[e-mail]]
>> Sent: 15 December 2015 19:57
>> To: DRAGE, Keith (Keith); Paul Kyzivat; [e-mail]
>> Subject: 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)"
>> <[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
>>>>>
>>>>>
>>>>
>>>
>>
>>
>
>

_______________________________________________
stir mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/stir

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.