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

From: Eric Burger <[email-masked]>
Date: Thu, 10 Dec 2015 21:15:58 -0500

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.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Dec 2015 10:58:12 -0500

> 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

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 13 Dec 2015 17:34:32 +0000

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:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 11 December 2015 15:58
To: [email-masked]
Subject: Re: [stir] stir-06: Reality check on numbers (6.1.1)

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
[email-masked]
https://www.ietf.org/mailman/listinfo/stir

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 15 Dec 2015 18:30:52 +0000

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.

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)"
<[email-masked] on behalf of [email-masked]> wrote:

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Dec 2015 13:52:08 -0500

> with an abundance of caution.

So, do you assume that a uri of sip:[email-masked] 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

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 15 Dec 2015 19:08:44 +0000

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:[email-masked] (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" <[email-masked]> wrote:

>>>>         some special service numbers (typically, these will appear
>>>>only
>>>> in
>>>are

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 15 Dec 2015 19:45:00 +0000

I'm lost.

sip:[email-masked], 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:[email-masked]] 
Sent: 15 December 2015 19:09
To: Paul Kyzivat; DRAGE, Keith (Keith); [email-masked]
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:[email-masked] (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" <[email-masked]> 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.
>
>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.
>>
>>> 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."
>>>
>>>>only  in
>>> 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
>>> ISTM that canonicalization of dialstrings that represent local 
>>> rather than global numbers is fraught with difficulty.
>>>
>>> 	Thanks,
>>> 	Paul
>>>
>>>
>>>

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 15 Dec 2015 19:57:23 +0000

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)"
<[email-masked]> wrote:

>I'm lost.
>
>sip:[email-masked], 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.
>
>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.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Dec 2015 15:24:58 -0500

> way the carrier in question stored all telephone numbers in SIP URIs. In

Yes, that is what I meant in this case.

> less clear how to canonicalize it for international transport or something.

Except that <tel:611>, <sip:[email-masked];user=phone> or 
<sip:[email-masked];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=[email-masked];user=phone> or 
<sip:611;phone-context=[email-masked];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

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 15 Dec 2015 21:55:44 +0000

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" <[email-masked]> wrote:

>>>>>>>          characters, excepting only the leading "#" or "*" keys
>>>>>>>used
>>>>>>> in

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 15 Dec 2015 22:31:11 +0000

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.

Keith

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]] 
Sent: 15 December 2015 19:57
To: DRAGE, Keith (Keith); Paul Kyzivat; [email-masked]
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)"
<[email-masked]> wrote:

>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:[email-masked] (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.
>
>
>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.
>
>>>> 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.
>>>>
>>>>>used in

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Dec 2015 18:04:14 -0500

> 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, th…

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

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 15 Dec 2015 23:48:15 +0000

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.

Regards

Keith

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 15 December 2015 23:04
To: DRAGE, Keith (Keith); Peterson, Jon; [email-masked]
Subject: Re: [stir] stir-06: Reality check on numbers (6.1.1)

> 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, th…

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

>> decision of foo.com, and nothing that should be verified anywhere as 
>> a telephone number.
>>
>> Austria receives a call from sip:[email-masked] (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.
>>
>>
>> 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.
>>
>>>> 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.
>>> So, do you assume that a uri of sip:[email-masked] 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
>>>
>>>>> but are  valid within local numbers not just first, but anywhere 
>>>>> in the number.
>>>>> So

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Dec 2015 20:00:50 -0500

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

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

---

From: Eric Burger <[email-masked]>
Date: Tue, 15 Dec 2015 20:34:48 -0500

And local arrangements are… local… out of scope. The PBX/AS/SBC will have to make To/From into something sensible. At that point, it is an E.164 number that STIR can deal with.

There is no point worrying about my phone saying “From: x74107”. You cannot get there from here unless you are inside my enterprise already, at which point you are not STIRing anyway.

> On Dec 15, 2015, at 6:48 PM, DRAGE, Keith (Keith) <[email-masked]> wrote:
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Dec 2015 00:50:03 -0500

> There is no point worrying about my phone saying “From: x74107”. You cannot get there from here unless you are inside my enterprise already, at which point you are not STIRing anyway.

Since you don't live in the US you may not know what 611 is. It is not a 
local number, like an internal extension on a PBX. It is a service 
number. It is among the family of N11 numbers, of which 911 is best known.

This discussion is, loosely, about most/all of the service numbers. 911 
is extra special, and has customized treatments, so we should probably 
exclude it from this particular discussion.

There is in general no E.164 number that the service numbers can be 
transformed to for purposes of canonicalization.

The answer may be that these numbers can't be canonicalized, and calls 
to/from them cannot be signed.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Wed, 16 Dec 2015 09:34:12 -0500

Please don’t do that.

It would be extremely valuable for calls to any of the n-1-1 numbers to be signed, and especially 9-1-1.

Read 1-1-2 for EU.

“Swatting” is a very serious problem, which can only reasonably be stopped by having some assurances of the callers identity.  It works today because the caller’s identity can be spoofed.

In fact, just because the called party can’t be canonicalized shouldn’t make the entire mechanism fail.  I think we should have canonicalization rules for service numbers, but even in the absence of canonicalization of the “To:”, the mechanism should still work as long as the To is not mangled by downstream elements.

It doesn’t have to be foolproof, it just has to work most of the time.  The call takers will take extra precautions if the mechanism fails occasionally, but if it rarely works, then it’s useless.

Brian

> On Dec 16, 2015, at 12:50 AM, Paul Kyzivat <[email-masked]> wrote:
> 
> Since you don't live in the US you may not know what 611 is. It is not a local number, like an internal extension on a PBX. It is a service number. It is among the family of N11 numbers, of which 911 is best known.
> 
> This discussion is, loosely, about most/all of the service numbers. 911 is extra special, and has customized treatments, so we should probably exclude it from this particular discussion.
> 
> There is in general no E.164 number that the service numbers can be transformed to for purposes of canonicalization.
> 
> The answer may be that these numbers can't be canonicalized, and calls to/from them cannot be signed.
> 
> 	Thanks,
> 	Paul
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Dec 2015 09:40:25 -0500

On 12/16/15 9:34 AM, Brian Rosen wrote:
> “Swatting” is a very serious problem, which can only reasonably be
> stopped by having some assurances of the callers identity.  It works
> today because the caller’s identity can be spoofed.
>
> In fact, just because the called party can’t be canonicalized shouldn’t
> make the entire mechanism fail.  I think we should have canonicalization
> rules for service numbers, but even in the absence of canonicalization
> of the “To:”, the mechanism should still work as long as the To is not
> mangled by downstream elements.
>
> It doesn’t have to be foolproof, it just has to work most of the time.
>   The call takers will take extra precautions if the mechanism fails
> occasionally, but if it rarely works, then it’s useless.

I think that is fine. But then some text is needed for how to handle 
such cases. Just assuming that the two ends will figure out how to do 
this is fantasy.

	Thanks,
	Paul

> Brian
>
>> On Dec 16, 2015, at 12:50 AM, Paul Kyzivat <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>> And local arrangements are… local… out of scope. The PBX/AS/SBC will
>>> have to make To/From into something sensible. At that point, it is an
>>> E.164 number that STIR can deal with.
>>>
>>> There is no point worrying about my phone saying “From: x74107”. You
>>> cannot get there from here unless you are inside my enterprise
>>> already, at which point you are not STIRing anyway.
>>
>> Since you don't live in the US you may not know what 611 is. It is not
>> a local number, like an internal extension on a PBX. It is a service
>> This discussion is, loosely, about most/all of the service numbers.
>> 911 is extra special, and has customized treatments, so we should
>> probably exclude it from this particular discussion.
>>
>>>> On Dec 15, 2015, at 6:48 PM, DRAGE, Keith (Keith)
>>>> <[email-masked]
>>>> <mailto:[email-masked]>> wrote:
>>>>
>>>> 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.
>>>>
>>>> Regards
>>>>
>>>> Keith
>>>>
>>>> <mailto:[email-masked]>
>>>>> 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.)
>>>>
>>>> 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.
>>>>
>>>>> <mailto:[email-masked]>
>>>>> 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.
>>>>>
>>>>> <[email-masked]
>>>>> <mailto:[email-masked]>> wrote:
>>>>>
>>>>>> I'm lost.
>>>>>>
>>>>>> belonging to foo.com <http://foo.com>. It is not a telephone
>>>>>> number or a dial string.
>>>>>> Depending on how foo.com <http://foo.com> assigns its SIP URIs it
>>>>>> might relate to a
>>>>>> dialstring 611 in foo.com <http://foo.com> land, but that is an
>>>>>> entirely arbitrary
>>>>>> decision of foo.com <http://foo.com>, and nothing that should be
>>>>>> verified anywhere as
>>>>>> a telephone number.
>>>>>>
>>>>>> <mailto:[email-masked]>
>>>>>> On 12/15/15, 10:52 AM, "Paul Kyzivat" <[email-masked]
>>>>>> <mailto:[email-masked]>> wrote:
>>>>>>
>>>>>>>> <[email-masked] <mailto:[email-masked]> on behalf
>>>>>>>> of [email-masked]
>>>>>>>> <mailto:[email-masked]>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> To: [email-masked] <mailto:[email-masked]>

---

From: <[email-masked]>
Date: Wed, 16 Dec 2015 14:48:08 +0000

> 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
+33 (0) 1 45 29 58 13

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

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

>>> 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.
>>>
>>>>> 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.
>>>> 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
>>>>
>>>>> <[email-masked] on behalf of 
>>>>> [email-masked]>
>>>>> wrote:
>>>>>

_________________________________________________________________________________________________________________________

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.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 16 Dec 2015 16:01:00 +0000

Apart from the issues of uniqueness of canonical form, one aspect of this that I do not understand how works, is that many of these numbers do not relate to a single user or a single organization, and that applies for many of these local service numbers.

This gets even worse with emergency numbers.

112 is mean to work for roaming users. So depending on whether I am in country A or country B, I will get the emergency service organization in country A or country B respectively. These are different users and should sign differently. Further depending on where I am in that country or the category or URN subtype I use, I may get an entirely different emergency organization, presumably with its own signing. Depending on PSAP load conditions, there may be overflow arrangements that take you to an entirely different organization.

So using this with a non-unique local service number to identify somehow the called party would seem to achieve little – at least tell me what it achieves.

I’d note in your mail you also seem to switch between calling and called direction. Are you trying to ensure that the calling user knows they have reached an emergency number, or that the calling user is known to the call taker (presumably not a service number problem). I think it is your last paragraph that is confusing me.

Keith

From: stir [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: 16 December 2015 14:34
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [stir] stir-06: Reality check on numbers (6.1.1)

Please don’t do that.

Read 1-1-2 for EU.

Brian

On Dec 16, 2015, at 12:50 AM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:

                Thanks,
                Paul

On Dec 15, 2015, at 6:48 PM, DRAGE, Keith (Keith) <[email-masked]<mailto:[email-masked]>> wrote:

Regards

Keith

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: 15 December 2015 23:04
To: DRAGE, Keith (Keith); Peterson, Jon; [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] stir-06: Reality check on numbers (6.1.1)

                Thanks,
                Paul

Keith

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: 15 December 2015 19:57
To: DRAGE, Keith (Keith); Paul Kyzivat; [email-masked]<mailto:[email-masked]>
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)"
<[email-masked]<mailto:[email-masked]>> wrote:

I'm lost.

sip:[email-masked], before conversion to canonical form, is a SIP URI
belonging to foo.com<http://foo.com>. It is not a telephone number or a dial string.
Depending on how foo.com<http://foo.com> assigns its SIP URIs it might relate to a
dialstring 611 in foo.com<http://foo.com> land, but that is an entirely arbitrary
decision of foo.com<http://foo.com>, and nothing that should be verified anywhere as
a telephone number.

Keith

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: 15 December 2015 19:09
To: Paul Kyzivat; DRAGE, Keith (Keith); [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] stir-06: Reality check on numbers (6.1.1)

Jon Peterson
Neustar, Inc.

On 12/15/15, 10:52 AM, "Paul Kyzivat" <[email-masked]<mailto:[email-masked]>> wrote:

                Thanks,
                Paul

Jon Peterson
Neustar, Inc.

On 12/13/15, 9:34 AM, "stir on behalf of DRAGE, Keith (Keith)"
<[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>>
wrote:

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.

Regards

Keith

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Paul
Kyzivat
Sent: 11 December 2015 15:58
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] stir-06: Reality check on numbers (6.1.1)

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.

                Thanks,
                Paul

_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir

---

From: Eric Burger <[email-masked]>
Date: Wed, 16 Dec 2015 11:41:22 -0500

I think it is easier and harder than this makes it out to be.

It is easier, because we are only talking about including 112/911/et al. in the JWT for the To: field. We only include it in the signature to prevent cut-and-paste attacks. As such, the string 112/911/et al. is sufficient to sign. No need to work out what it “looks like” in E.164 land.

It is harder, because emergency access needs to be ubiquitous. If I have my UK phone roaming in Austria, when I dial 112 I expect the local, Austrian PSAP (+41 112?) to answer, not my home (+44 112?) number to be the To. More especially if I am roaming in the US: +1 112 will not get you far, but 911 will.

Brian’s point is key: we cannot leave a gaping hole in STIR for people to do cut-and-paste attacks against calls to emergency services numbers. That is, we cannot punt and say if you are calling an emergency services number, that because it is not an E.164 number, we cannot STIR sign it. We would lose the #1 use case for STIR!

How about this for text:
Canonicalize E.164 numbers as specified already
If To: is a service number, pass it on as understood by the network (e.g., if 9,112, canonicalize as 112)
Usual caveats about how you need to really KNOW that 9112 is 9 for outside line and 112 for emergency services. I.e., you are a PBX, Proxy, or Whatever that takes the local dial string, which is a matter of local policy and beyond the scope of STIR, and hack it into the network address of interest. I.e., a random proxy in the Internet, when it sees 9112, has no idea if that is 9,112; extension 9112; or user 9112 (i.e., not a phone number at all).

> On Dec 16, 2015, at 11:01 AM, DRAGE, Keith (Keith) <[email-masked]> wrote:
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Dec 2015 12:16:17 -0500

> Usual caveats about how you need to really KNOW that 9112 is 9 for outside line and 112 for emergency services. I.e., you are a PBX, Proxy, or Whatever that takes the local dial string, which is a…

We may need to address emergency calling (911/112) from other service 
numbers because they are handled specially. At the least there are RFCs 
dealing with them, and not so much for other service numbers.

In the case of emergency calls, the mechanism that has been standardized 
results in the dialed number being replaced by urn:service:sos.

But I *think* that is only for the R-URI, not the To-URI. (Brian - is 
that right?) If so, that still leaves canonicalization open. If the 
To-URI is also to be replaced, then it cannot be canonicalized into a 
number.

This might highlight something. What if the From-URI is a number, and 
wants to be treated as such for signing, but the To-URI is non-numeric. 
How is signing done? I would think that the the entire To-URI would be 
used, in lieu of a canonicalized To number, in the signature.

But I think we must assume that there will be emergency calls that don't 
use urn:service:sos. So there had better be a solution for them too.

Just taking the service number "as understood" runs the risk that it 
isn't understood the same at both ends. And having these "canonical" 
forms overlap with the number space for canonical E.164 numbers could 
cause trouble. ISTM that the canonical form for service numbers ought to 
be disjoint from the canonical form for E.164 numbers.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Dec 2015 12:22:57 -0500

On 12/16/15 11:01 AM, DRAGE, Keith (Keith) wrote:

> So using this with a non-unique local service number to identify somehow
> the called party would seem to achieve little – at least tell me what it
> achieves.

As Eric noted, it reduces the potential for cut/paste attacks.

> I’d note in your mail you also seem to switch between calling and called
> direction. Are you trying to ensure that the calling user knows they
> have reached an emergency number, or that the calling user is known to
> the call taker (presumably not a service number problem). I think it is
> your last paragraph that is confusing me.

The mechanisms for canonicalizing are the same for From and To. But the 
use cases are different.

I think this is much more about To than From. I suspect it is much more 
common to see a service number in To than in From. And we aren't trying 
to prove anything about who the To is.

I'm not sure, but I have the impression that there *might* be use cases 
for putting a service number in From. (E.g., getting a callback from a 
PSAP.) Can somebody who knows comment on this? Authorization to sign a 
call from a service number might be challenging.

	Thanks,
	Paul

> Keith
>
> *From:*stir [mailto:[email-masked]] *On Behalf Of *Brian Rosen
> *Sent:* 16 December 2015 14:34
> *To:* Paul Kyzivat
> *Cc:* [email-masked]
> *Subject:* Re: [stir] stir-06: Reality check on numbers (6.1.1)
>
> Please don’t do that.
>
>     have to make To/From into something sensible. At that point, it is
>     an E.164 number that STIR can deal with.
>
>     Since you don't live in the US you may not know what 611 is. It is
>     not a local number, like an internal extension on a PBX. It is a
>     service number. It is among the family of N11 numbers, of which 911
>     is best known.
>
>         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.
>
>         Regards
>
>         Keith
>
>         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
>         parameters, they were still present. As none were specified,
>         there could be none, and therefore the URI was a SIP URI pure
>         and simple.
>
>
>         (After all, the results of canonicalization for the bis are not
>         put into the URI.)
>
>         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.
>
>         *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
>         "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.
>
>         Depending on how foo.com <http://foo.com> assigns its SIP URIs
>         it might relate to a
>         callee