Help Requested: E.123 Intl Formatting in Google libphonenumber
Hey all -- I hope and trust that most of you are fans of standards. I need some help convincing Google's libphonenumber team to follow the published ITU E.123 Number Formatting standard for +1 NANPA, Ecuador, and Argentina. tl;dr -- Please comment in support here: https://issuetracker.google.com/issues/221095104 Long Version: I love standards. They are often unambiguous and organize all of us around a common understanding of how we are going to interoperate. Everything we do in our daily work can be tied back to a standard: - TCP/IP, hell the whole OSI Model - SIP, RTP - ITU E.164, E.123, SS7, ISDN, DSL - DNS, Email, TLS/SSL It seems weird that an International company like Google, who practically exists ONLY BECAUSE these standards existed for Google to emerge from, is being picky about implementing a phone number formatting standard published in 2008. The crux: 168 countries use spaces in their International Format 2 countries outside of +1 NANPA, Ecuador and Argentina have dashes 25 countries in +1 NANPA all use +1 NPA-NXX-XXXX as the International Format ITU E.123 states in 9.1: Only spaces should be used in an international number. Thus the correct output would be '+1 NPA NXX XXXX' for the INTERNATIONAL format. I'm all for using (NPA) NXX-XXXX or NPA-NXX-XXXX for any of the other formats. I'm just trying to get support from the community to get rid of Dashes entirely in the INTERNATIONAL Format of phone numbers. Your support and comment is appreciated. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com https://www.angryox.com/ ---------------------------------------------------------------------------
Peter, I thought during all those years that the standard is called E.164. I also thought that a phone number has no spaces or dashes. These are only added to help humans read the phone numbers. We also used the libphonenumber and I think it is great to help us standardize. It works for all countries so I am not sure what's missing. I am sure you can add anything that you want after you normalize the number using the function. Thanks, Oren On Wed, Mar 2, 2022, 22:04 Peter Beckman <beckman at angryox.com> wrote:
Hey all --
I hope and trust that most of you are fans of standards.
I need some help convincing Google's libphonenumber team to follow the published ITU E.123 Number Formatting standard for +1 NANPA, Ecuador, and Argentina.
tl;dr -- Please comment in support here:
https://issuetracker.google.com/issues/221095104
Long Version:
I love standards. They are often unambiguous and organize all of us around a common understanding of how we are going to interoperate. Everything we do in our daily work can be tied back to a standard:
- TCP/IP, hell the whole OSI Model - SIP, RTP - ITU E.164, E.123, SS7, ISDN, DSL - DNS, Email, TLS/SSL
It seems weird that an International company like Google, who practically exists ONLY BECAUSE these standards existed for Google to emerge from, is being picky about implementing a phone number formatting standard published in 2008.
The crux: 168 countries use spaces in their International Format 2 countries outside of +1 NANPA, Ecuador and Argentina have dashes 25 countries in +1 NANPA all use +1 NPA-NXX-XXXX as the International Format
ITU E.123 states in 9.1:
Only spaces should be used in an international number.
Thus the correct output would be '+1 NPA NXX XXXX' for the INTERNATIONAL format.
I'm all for using (NPA) NXX-XXXX or NPA-NXX-XXXX for any of the other formats.
I'm just trying to get support from the community to get rid of Dashes entirely in the INTERNATIONAL Format of phone numbers.
Your support and comment is appreciated.
Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com https://www.angryox.com/ --------------------------------------------------------------------------- _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
E.164 doesn't include formatting for humans. E.164 => +12125004000 E.123 => +1 212 500 4000 (International) => (212) 500-4000 (National) => 212-500-4000 (National) We utilize E.164 when we want our servers to discuss phone numbers. We utilize E.123 when we want to convert the E.164 phone number into something more useful for human consumption. It's kind of like IPv4 addresses: A 32-bit number is harder to remember than 4 8-bit numbers each separated by a period. The crux of the issue is that 168 countries' International Format in libphonenumber looks like +44 207 597 2524 +39 4324 8893 Whereas Ecuador, Argentina, and the NANPA countries are: +1 212-500-4000 +593 4-443-3335 +54 2222 22-2224 My argument is that NANPA, Argentina, and Ecuador should be formatted for International as: +1 212 500 4000 +593 4 443 3335 +54 2222 22 2224 Beckman On Thu, 3 Mar 2022, Oren Yehezkely wrote:
Peter,
I thought during all those years that the standard is called E.164. I also thought that a phone number has no spaces or dashes. These are only added to help humans read the phone numbers.
We also used the libphonenumber and I think it is great to help us standardize. It works for all countries so I am not sure what's missing. I am sure you can add anything that you want after you normalize the number using the function.
Thanks, Oren
On Wed, Mar 2, 2022, 22:04 Peter Beckman <beckman at angryox.com> wrote:
Hey all --
I hope and trust that most of you are fans of standards.
I need some help convincing Google's libphonenumber team to follow the published ITU E.123 Number Formatting standard for +1 NANPA, Ecuador, and Argentina.
tl;dr -- Please comment in support here:
https://issuetracker.google.com/issues/221095104
Long Version:
I love standards. They are often unambiguous and organize all of us around a common understanding of how we are going to interoperate. Everything we do in our daily work can be tied back to a standard:
- TCP/IP, hell the whole OSI Model - SIP, RTP - ITU E.164, E.123, SS7, ISDN, DSL - DNS, Email, TLS/SSL
It seems weird that an International company like Google, who practically exists ONLY BECAUSE these standards existed for Google to emerge from, is being picky about implementing a phone number formatting standard published in 2008.
The crux: 168 countries use spaces in their International Format 2 countries outside of +1 NANPA, Ecuador and Argentina have dashes 25 countries in +1 NANPA all use +1 NPA-NXX-XXXX as the International Format
ITU E.123 states in 9.1:
Only spaces should be used in an international number.
Thus the correct output would be '+1 NPA NXX XXXX' for the INTERNATIONAL format.
I'm all for using (NPA) NXX-XXXX or NPA-NXX-XXXX for any of the other formats.
I'm just trying to get support from the community to get rid of Dashes entirely in the INTERNATIONAL Format of phone numbers.
Your support and comment is appreciated.
Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com https://www.angryox.com/ --------------------------------------------------------------------------- _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
--------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com https://www.angryox.com/ ---------------------------------------------------------------------------
Why spaces for NANPA? This is very unusual. Is that written in a standard somewhere? I'm not sure on the other two but in the US there are users who actually would be confused seeing spaces. ?On 3/2/22, 8:26 PM, "VoiceOps on behalf of Peter Beckman" <voiceops-bounces at voiceops.org on behalf of beckman at angryox.com> wrote: E.164 doesn't include formatting for humans. E.164 => +12125004000 E.123 => +1 212 500 4000 (International) => (212) 500-4000 (National) => 212-500-4000 (National) We utilize E.164 when we want our servers to discuss phone numbers. We utilize E.123 when we want to convert the E.164 phone number into something more useful for human consumption. It's kind of like IPv4 addresses: A 32-bit number is harder to remember than 4 8-bit numbers each separated by a period. The crux of the issue is that 168 countries' International Format in libphonenumber looks like +44 207 597 2524 +39 4324 8893 Whereas Ecuador, Argentina, and the NANPA countries are: +1 212-500-4000 +593 4-443-3335 +54 2222 22-2224 My argument is that NANPA, Argentina, and Ecuador should be formatted for International as: +1 212 500 4000 +593 4 443 3335 +54 2222 22 2224 Beckman On Thu, 3 Mar 2022, Oren Yehezkely wrote: > Peter, > > I thought during all those years that the standard is called E.164. > I also thought that a phone number has no spaces or dashes. These are only > added to help humans read the phone numbers. > > We also used the libphonenumber and I think it is great to help us > standardize. > It works for all countries so I am not sure what's missing. > I am sure you can add anything that you want after you normalize the number > using the function. > > Thanks, > Oren > > > > > On Wed, Mar 2, 2022, 22:04 Peter Beckman <beckman at angryox.com> wrote: > >> Hey all -- >> >> I hope and trust that most of you are fans of standards. >> >> I need some help convincing Google's libphonenumber team to follow the >> published ITU E.123 Number Formatting standard for +1 NANPA, Ecuador, and >> Argentina. >> >> tl;dr -- Please comment in support here: >> >> https://issuetracker.google.com/issues/221095104 >> >> >> Long Version: >> >> I love standards. They are often unambiguous and organize all of us around >> a common understanding of how we are going to interoperate. Everything we >> do in our daily work can be tied back to a standard: >> >> - TCP/IP, hell the whole OSI Model >> - SIP, RTP >> - ITU E.164, E.123, SS7, ISDN, DSL >> - DNS, Email, TLS/SSL >> >> It seems weird that an International company like Google, who practically >> exists ONLY BECAUSE these standards existed for Google to emerge from, is >> being picky about implementing a phone number formatting standard published >> in 2008. >> >> The crux: >> 168 countries use spaces in their International Format >> 2 countries outside of +1 NANPA, Ecuador and Argentina have dashes >> 25 countries in +1 NANPA all use +1 NPA-NXX-XXXX as the International >> Format >> >> ITU E.123 states in 9.1: >> >> Only spaces should be used in an international number. >> >> Thus the correct output would be '+1 NPA NXX XXXX' for the INTERNATIONAL >> format. >> >> I'm all for using (NPA) NXX-XXXX or NPA-NXX-XXXX for any of the other >> formats. >> >> I'm just trying to get support from the community to get rid of Dashes >> entirely in the INTERNATIONAL Format of phone numbers. >> >> Your support and comment is appreciated. >> >> Beckman >> --------------------------------------------------------------------------- >> Peter Beckman Internet Guy >> beckman at angryox.com >> https://www.angryox.com/ >> --------------------------------------------------------------------------- >> _______________________________________________ >> VoiceOps mailing list >> VoiceOps at voiceops.org >> https://puck.nether.net/mailman/listinfo/voiceops >> > --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com https://www.angryox.com/ --------------------------------------------------------------------------- _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On 3/2/22 20:46, Darren wrote:
Why spaces for NANPA? This is very unusual. Is that written in a standard somewhere? I'm not sure on the other two but in the US there are users who actually would be confused seeing spaces.
Agreed. If the intent of E.123 is to format telephone numbers for human readability, it should do so in a manner that is consistent with the existing convention for humans in the country where the number exists. For NANPA, the National format would be (NPA) NXX-XXXX or NPA-NXX-XXXX. If other countries typically publish phone numbers using other punctuation as separators such as dots or colons, then use those for that country's National format. For International, the use of spaces makes sense. The ambiguity for NANPA is that it is country code 1 and the local convention is to use a leading 1 for "area code follows" to differentiate from a 7-digit local number in those locations where 7-digit dialing is still in use. That ambiguity really doesn't affect the digits input, however. When dialed en banc such as on mobiles with a SEND button, the leading 1 can usually be omitted with no effect on the call going through. If a NANPA resident sees a phone number with just spaces they're likely to assume that it's an international call. -- Jay Hennigan - jay at west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV
On Thu, 3 Mar 2022, Jay Hennigan wrote:
On 3/2/22 20:46, Darren wrote:
Why spaces for NANPA? This is very unusual. Is that written in a standard somewhere? I'm not sure on the other two but in the US there are users who actually would be confused seeing spaces.
Agreed. If the intent of E.123 is to format telephone numbers for human readability, it should do so in a manner that is consistent with the existing convention for humans in the country where the number exists.
For NANPA, the National format would be (NPA) NXX-XXXX or NPA-NXX-XXXX. If other countries typically publish phone numbers using other punctuation as separators such as dots or colons, then use those for that country's National format. For International, the use of spaces makes sense.
Exactly this.
The ambiguity for NANPA is that it is country code 1 and the local convention is to use a leading 1 for "area code follows" to differentiate from a 7-digit local number in those locations where 7-digit dialing is still in use. That ambiguity really doesn't affect the digits input, however. When dialed en banc such as on mobiles with a SEND button, the leading 1 can usually be omitted with no effect on the call going through.
If a NANPA resident sees a phone number with just spaces they're likely to assume that it's an international call.
The goal is for the library to offer choices made by the implementor to decide what is best for the end user. A US-only or North American-only App or Website would use the National Format, (NPA) NXX-XXXX or NPA-NXX-XXXX. Apps that span countries, such as North America, Central America, South America, Europe, Asia, etc, would use the International Format. The problem is that the International Format provided by libphonenumber for NANPA, Ecuador, and Argentina, are a hybrid of International and National format, rather than following the International ITU convention of only using number groupings and spaces with the leading plus sign. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com https://www.angryox.com/ ---------------------------------------------------------------------------
On Thu, 3 Mar 2022, Darren wrote:
Why spaces for NANPA? This is very unusual. Is that written in a standard somewhere? I'm not sure on the other two but in the US there are users who actually would be confused seeing spaces.
International Format. How the rest of the world formats their phone numbers, even if they might use parenthesis and dashes when writing the phone number for local consumption. US users also are confused by the metric system, despite it being used by 98% of the all other countries and 95.3% of all other humans on earth.
?On 3/2/22, 8:26 PM, "VoiceOps on behalf of Peter Beckman" <voiceops-bounces at voiceops.org on behalf of beckman at angryox.com> wrote:
E.164 doesn't include formatting for humans.
E.164 => +12125004000 E.123 => +1 212 500 4000 (International) => (212) 500-4000 (National) => 212-500-4000 (National)
We utilize E.164 when we want our servers to discuss phone numbers.
We utilize E.123 when we want to convert the E.164 phone number into something more useful for human consumption.
It's kind of like IPv4 addresses: A 32-bit number is harder to remember than 4 8-bit numbers each separated by a period.
The crux of the issue is that 168 countries' International Format in libphonenumber looks like
+44 207 597 2524 +39 4324 8893
Whereas Ecuador, Argentina, and the NANPA countries are:
+1 212-500-4000 +593 4-443-3335 +54 2222 22-2224
My argument is that NANPA, Argentina, and Ecuador should be formatted for International as:
+1 212 500 4000 +593 4 443 3335 +54 2222 22 2224
Beckman
On Thu, 3 Mar 2022, Oren Yehezkely wrote:
Peter,
I thought during all those years that the standard is called E.164. I also thought that a phone number has no spaces or dashes. These are only added to help humans read the phone numbers.
We also used the libphonenumber and I think it is great to help us standardize. It works for all countries so I am not sure what's missing. I am sure you can add anything that you want after you normalize the number using the function.
Thanks, Oren
On Wed, Mar 2, 2022, 22:04 Peter Beckman <beckman at angryox.com> wrote:
Hey all --
I hope and trust that most of you are fans of standards.
I need some help convincing Google's libphonenumber team to follow the published ITU E.123 Number Formatting standard for +1 NANPA, Ecuador, and Argentina.
tl;dr -- Please comment in support here:
https://issuetracker.google.com/issues/221095104
Long Version:
I love standards. They are often unambiguous and organize all of us around a common understanding of how we are going to interoperate. Everything we do in our daily work can be tied back to a standard:
- TCP/IP, hell the whole OSI Model - SIP, RTP - ITU E.164, E.123, SS7, ISDN, DSL - DNS, Email, TLS/SSL
It seems weird that an International company like Google, who practically exists ONLY BECAUSE these standards existed for Google to emerge from, is being picky about implementing a phone number formatting standard published in 2008.
The crux: 168 countries use spaces in their International Format 2 countries outside of +1 NANPA, Ecuador and Argentina have dashes 25 countries in +1 NANPA all use +1 NPA-NXX-XXXX as the International Format
ITU E.123 states in 9.1:
Only spaces should be used in an international number.
Thus the correct output would be '+1 NPA NXX XXXX' for the INTERNATIONAL format.
I'm all for using (NPA) NXX-XXXX or NPA-NXX-XXXX for any of the other formats.
I'm just trying to get support from the community to get rid of Dashes entirely in the INTERNATIONAL Format of phone numbers.
Your support and comment is appreciated.
Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com https://www.angryox.com/ --------------------------------------------------------------------------- _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
--------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com https://www.angryox.com/ --------------------------------------------------------------------------- _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
--------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com https://www.angryox.com/ ---------------------------------------------------------------------------
Hello, as usual the problem with standards is that there are many of them. I can not comment about other countries, but even in Germany it's a bit messier as you described. Most people in the telco world use E.164 or E.123 type for formatting to represent phone numbers. But many normal businesses use the national standard "DIN 5008". This extends E.123 with the usage of a dash to separate local extensions in international format, e.g.: +49 123 123456-123 Many people recommend this format if the company is doing business mainly national, and E.123 if the company is doing business international. Cheers, Henning -----Original Message----- From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of Peter Beckman Sent: Wednesday, March 2, 2022 8:56 PM To: VoiceOps <voiceops at voiceops.org> Subject: [VoiceOps] Help Requested: E.123 Intl Formatting in Google libphonenumber Hey all -- I hope and trust that most of you are fans of standards. I need some help convincing Google's libphonenumber team to follow the published ITU E.123 Number Formatting standard for +1 NANPA, Ecuador, and Argentina. tl;dr -- Please comment in support here: https://issuetracker.google.com/issues/221095104 Long Version: I love standards. They are often unambiguous and organize all of us around a common understanding of how we are going to interoperate. Everything we do in our daily work can be tied back to a standard: - TCP/IP, hell the whole OSI Model - SIP, RTP - ITU E.164, E.123, SS7, ISDN, DSL - DNS, Email, TLS/SSL It seems weird that an International company like Google, who practically exists ONLY BECAUSE these standards existed for Google to emerge from, is being picky about implementing a phone number formatting standard published in 2008. The crux: 168 countries use spaces in their International Format 2 countries outside of +1 NANPA, Ecuador and Argentina have dashes 25 countries in +1 NANPA all use +1 NPA-NXX-XXXX as the International Format ITU E.123 states in 9.1: Only spaces should be used in an international number. Thus the correct output would be '+1 NPA NXX XXXX' for the INTERNATIONAL format. I'm all for using (NPA) NXX-XXXX or NPA-NXX-XXXX for any of the other formats. I'm just trying to get support from the community to get rid of Dashes entirely in the INTERNATIONAL Format of phone numbers. Your support and comment is appreciated. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com https://www.angryox.com/ --------------------------------------------------------------------------- _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Please post your support by adding a comment here: https://issuetracker.google.com/issues/221095104 On Thu, 3 Mar 2022, Henning Westerholt wrote:
as usual the problem with standards is that there are many of them.
I can not comment about other countries, but even in Germany it's a bit messier as you described.
Most people in the telco world use E.164 or E.123 type for formatting to represent phone numbers. But many normal businesses use the national standard "DIN 5008". This extends E.123 with the usage of a dash to separate local extensions in international format, e.g.:
+49 123 123456-123
Many people recommend this format if the company is doing business mainly national, and E.123 if the company is doing business international.
I don't see a problem here. DIN 5008 is a German standard, which would be considered a National Format. I would fully support Google's libphonenumber of using such a standard for formatting National Numbers for Germany in that manner. However, it does NOT use this standard for National formatting. However, for people outside of Germany who want to write out its phone numbers, ITU E.123 standard for International Format should be followed. National: +49 123 123456-123 International: +49 123 123456 ext. 123 libphonenumber is NOT using DIN 5008 for National: <!-- Due to the high complexity of ranges in the German numbering scheme, the regular expressions here have been automatically simplified to reduce size. This means that in some cases there may be false positives (especially in fixed line ranges), but since German ranges differ so much by length anyway, false positives are already common. --> The Zoo Duisberg is at +4920360444250. Libphonenumber outputs expected results. - National Format: 0203 60444250 - International Format: +49 203 60444250 With extension: - National: 0203 60444250 ext. 134 - International: +49 203 60444250 ext. 134 Maybe you want to submit a request to Google's Libphonenumber to follow DIN 5008 for National! I would comment in support! I would be annoyed if libphonenumber did not follow my national standard. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com https://www.angryox.com/ ---------------------------------------------------------------------------
participants (5)
-
beckman＠angryox.com -
d＠d-man.org -
hw＠gilawa.com -
jay＠west.net -
orenyny＠gmail.com