Standard format for phone numbers

[shea256]

Couldn't there be a standard format for phone numbers? I'm just thinking that this could be helpful for any application that enables calling and reads the JSON resumes.

@mwaclawek said: Should definitely be E.164

[thomasdavis]

Great reference! That makes sense but I wonder if we will bundle it straight into the first release of the validator. We will certainly recommend E.164 but it might cause to many headaches while we are getting the project off the ground.

[shea256]

OK cool.

How comfortable do you think people will be with having their phone numbers publicly crawl-able?

[thomasdavis]

The specification doesn't require phone numbers so it shouldn't be a
problem, people can choose what they want.

On Wed, Jul 9, 2014 at 3:44 PM, Ryan Shea notifications@github.com wrote:

OK cool.

How comfortable do you think people will be with having their phone
numbers publicly crawl-able?

—
Reply to this email directly or view it on GitHub
#69 (comment)
.

Thomas Davis
http://thomasdav.is

VP of Tech - Earbits - http://earbits.com
Co-founder - Cdnjs - http://cdnjs.com
Founder - Backbone Tutorials - http://backbonetutorials.com

[shea256]

Yes, of course. Just wondering if people will realize what they're getting into. I have an internal conflict with it myself. I would really like to make my phone number available, but I'm concerned about the risks. Thought you might have some insights on this.

[wdoekes]

I wouldn't put my phone# just anywhere online. If you make the phone field mandatory, it'll get populated with crap.

As for using E.164: if you're going to force (less readable) standards on people, you might as well prefix it with a schema, like suggested -- but discarded for now -- in the phone/email thread:
contact:[{ description:"phone during the day", uri:"tel:+12-456-78" }]

Remember that the templating will put this on a printed PDF page too. Being too rigid with the formatting of fields may make it less usable for that purpose. (Besides, converting free-form to E.164 by a machine is about as easy as it gets.)

[DonDebonair]

I don't think it's likely that phonenumbers will be used for searching/sorting, so it's really up to the creator of the resume to put in that field what s/he wants. So I vote not to require some standard.

[thomasdavis]

I vote not to do either for now, need a label that puts things on the back burner. Maybe use Github milestones?

[shea256]

Based on your arguments, I agree, probably best not to enforce it, at least for now. Like you said, too much of a headache.

[thomasdavis]

Though I want to keep this issue for future reference without closing it. So going to label as "Backlog"

[thomasdavis]

Actually will close and reference in README as ideas to reinvestigate

[mboudreau]

a lot of places I've seen implement phone numbers as an object with a country code and then the phone number itself. Whoever ingests the data is the one that needs to figure out how to display it.

We could always have a standard that this object can be used or a string if you want to keep backwards compatibility

[stp-ip]

I think for now we are looking into having a standard format of the phone number field in addition to helper tools/libs, which make it easy for theme developers to parse phone data into this standard format. This is just a vague idea and will probably be done post-v1.

[justinphelps]

My unsolicited input having work several years in telco and handling phone numbers using the MVC paradigm.
Views should be able to parse away any various user formatting preferences and reformat into E.164 (without the + since it's redundant and used is an operator/reserved character) for CUD operations before submitting to controller. E.g 0046 (0)76 94-22-2323 becomes 467694222323 when POSTed. Form validators can be flexible, controller/model validators are rigid.
View formatting for Read operations handled by controller or in js. Sadly there isno phone number formatting in css.
Models should write phone numbers to the storage layer as string or varchar. It might seem natural to use integers, but that requires longints everywhere. Strings make it easier to index on countrycode/areacode/region and hash.

Perhaps a solution would be to have 2 optional fields for phone numbers:
"phone": "0046 (0)76 94-22-2323 ", <-- no formatting requirements. Stored however the user wants it presented
"phoneE164": "+467694222323", <-- rigid formatting requirements. Can be used programmatically. Then you could generate <a href="tel:"+467694222323" rel="nofollow">0046 (0)76 94-22-2323 without controller or js.