What format should we use for phone numbers for payerPhone and PayerAddress.phone? I propose E.164, which looks like this: "+15555555555". (For UI, Chrome will probably use E.123, which shows that same phone number in more human-readable format of "+1 (555) 555-5555".)
I took a peek at HTML 5.1 [1] which has this note:
"Unlike the URL and E-mail types, the Telephone type does not enforce a particular syntax. This is intentional; in practice, telephone number fields tend to be free-form fields, because there are a wide variety of valid phone numbers. Systems that need to enforce a particular format are encouraged to use the pattern attribute or the setCustomValidity() method to hook into the client-side validation mechanism."
Should we proceed similarly?
Ian
[1] https://www.w3.org/TR/html51/sec-forms.html#element-statedef-input-telephone
+1 for E.164. I would much rather clearly define the format that will be returned. I don't think we need to define how it's displayed to the user in the UI, just how it's returned.
If we don't at least attempt to define some kind of structure then we risk merchants mishandling or rejecting otherwise valid information because they're not prepared to handle international dialing codes (or a lack thereof).
The problem is that the user agent might already have this information in its auto-complete database as free-form - or may get it from another application (e.g., Contacts.app on the Mac)... then it's kinda hard to normalize that data into E.164 or whatever because we won't have it in the correct format to start with.
If anything, the UA SHOULD make an effort to return phone numbers in a standardized format... but developers cannot expect it (robustness principle applies)
I would be happy with that.
SHOULD is OK with me.
Most helpful comment
+1 for E.164. I would much rather clearly define the format that will be returned. I don't think we need to define how it's displayed to the user in the UI, just how it's returned.
If we don't at least attempt to define some kind of structure then we risk merchants mishandling or rejecting otherwise valid information because they're not prepared to handle international dialing codes (or a lack thereof).