P496 XTN Data Type Change

This is a page of type Category:InM Closed Action Items.

P496 XTN Data Type Change

Sponsoring Person

Doug Pratt, Siemens

Disposition

Accepted by INM 28-Apr-07 Larson/Stuart 10-0-0

Short Description:

Change the data type of XTN components country code, area code, local phone number and extension components from numeric (NM) to string numeric (SNM). (see P495_Character-Constrained_String_of_Decimal_Digits for definition of the SNM)

Justification:

The Extended Telecommunication Number (XTN) data type specifies the country code, area code, local phone number and extension components as numeric. A literal interpretation of this definition poses the following conflicts:

• Minus and plus signs, and decimal points, are permitted in NM-typed fields but are not valid for phone numbers on the wire (notwithstanding that country codes are sometimes written as +49, on the wire 49 would be transmitted). The wire value ^+132.0089^ is a valid NM but not a valid phone number.
• Leading zeros are significant and required in some phone systems (e.g., Italy). Leading zeros are not significant in NM data types, and may be stripped off en route, invalidating the telephone number. A sender might transmit ^0678989^ but the receiver only see 678989.

Changing the data type of these XTN components from NM to SNM solves these problems.

Compatibility with Prior Releases

This change adheres to compatibility rules for prior releases. 2.6 Sender, 2.7 Receiver – The 2.7 receiver interpreting an affected component as a SNM would not interpret the phone number any differently than would a 2.6 receiver. The 2.6 wire format of any legitimate phone number formatted as an NM would be interpreted the same as a SNM. However, an illegitimate phone number formatted as an NM (e.g., ^+132.0089^) would reject – as it should.

2.7 Sender, 2.6 Receiver – Any SNM value placed on the wire is inherently a valid numeric value. However, a 2.6 receiver may strip leading zeros from the transmitted value, whereas a 2.7 receiver may not. This could result in the 2.6 receiver losing a significant character of an Italian phone number. However, this loss would occur anyway, had the sender been on Version 2.6.