Messages 2.5 - Make phone number claims more useful

[Michael Jones]

Breno has asked that we provide both a display form and a canonical form of phone numbers. Nat has asked that we distinguish between mobile and generic phone numbers. Mark Wahl and Nat have pointed out that generic phone numbers may have extensions. To address these requests, at least for discussion purposes, I'll propose that we replace the current single phone_number claim with these claims:

phone_number - End-User's preferred telephone number, in a format intended for display to the user.  This SHOULD contain the phone number text string as the End-User entered it, preserving any spacing charcters, etc.  For example, "[phone] x1234".
phone_tel_uri - End-User's preferred telephone number, represented as an RFC 3966 "tel" scheme URI using the global-number representation (in which the number begins with a "+" and country code).  For example, "tel:[phone];ext=1234".
mobile_number - End-User's mobile telephone number, in a format intended for display to the user.  This SHOULD contain the mobile number text string as the End-User entered it, preserving any spacing charcters, etc.  For example, "1-604-555-0123".
mobile_tel_uri - End-User's mobile telephone number, represented as an RFC 3966 "tel" scheme URI using the global-number representation (in which the number begins with a "+" and country code).  For example, "tel:[phone]".

This actually then raises the question of whether some would want these claims too:

phone_verified - True if the phone number in the End-User's "phone_tel_uri" has been verified; otherwise false.  The means by which a phone number must be verified is context-specific, and dependent upon the trust framework or contractual agreements within which the parties are operating.
mobile_verified - True if the phone number in the End-User's "mobile_tel_uri" has been verified; otherwise false.  The means by which a mobile number must be verified is context-specific, and dependent upon the trust framework or contractual agreements within which the parties are operating.

That may be going too far, but in some business contexts or trust frameworks, these claims would also make sense.

[John Bradley]

If we go down that path it is better to make phone number structured. Verified should be a sub element. as should type etc

We are moving away from the principal of simple provisioning info if we do this.
The next question is why we didn't adopt SCIM schema?

[Michael Jones]

Indeed, I agree that the "is this claim useful for enabling seamless interaction with Web sites?" test is a useful one, and what I wrote up above may not pass that test. I mainly wanted to make this specific so we could discuss a concrete possible set of claims that would satisfy these requests that people have been making.

If we decide not to split the display/canonical phone number formats and not to have both general and mobile numbers, then I think we should still try to address the issue of phone numbers with extensions. For instance, we could do that as follows:

phone_number - End-User's preferred telephone number. E.164 [E.164] is RECOMMENDED as the format of this Claim. For example, [phone] or  [phone].  If the phone number contains an extension, it is RECOMMENDED that the extension be represented using the RFC 3966 extension syntax, for example, [phone];ext=5678.

[Michael Jones]

The working group's sense was that we shouldn't go down the road of inventing structured phone number formats, as it's not in the 80% case we're trying to hit. We will clarify how to represent extensions.

If some use case needs more structure, they should use an existing schema, such as SCIM.

[Michael Jones]

Fixed #800 - Specified that phone number extensions are to be represented using RFC 3966 extension syntax.

→ <<cset 8a0fdd7728e1>>