New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specify phone type #24

Closed
pigmonkey opened this Issue Apr 12, 2013 · 4 comments

Comments

Projects
None yet
2 participants
@pigmonkey
Contributor

pigmonkey commented Apr 12, 2013

Most of my contacts have multiple phone numbers. I need some way to keep straight which is which. Currently I'm adding them like this:

$ ppl phone jdoe "1115551234 (work)"
$ ppl phone jdoe "1115556789 (cell)"

This works fine, but the vCard specification does include telephone types. As seen in the Wikipedia example:

TEL;TYPE=WORK,VOICE:(111) 555-1212
TEL;TYPE=HOME,VOICE:(404) 555-1212

It would be nice if ppl supported this. It could be achieved like this:

$ ppl phone jdoe --type work 1115551234
$ ppl phone jdoe --type cell 1115556789

The --type argument would be optional so it shouldn't break compatibility with previous versions.

@pigmonkey

This comment has been minimized.

Show comment
Hide comment
@pigmonkey

pigmonkey Apr 19, 2013

Contributor

I've been playing around with using ppl's vcards to build the contacts on my phone. Unfortunately, it doesn't work too well because I have a bunch of phone numbers like 1115556789 (cell). My phone doesn't know what to think about letters and parenthesis in phone numbers!

Contributor

pigmonkey commented Apr 19, 2013

I've been playing around with using ppl's vcards to build the contacts on my phone. Unfortunately, it doesn't work too well because I have a bunch of phone numbers like 1115556789 (cell). My phone doesn't know what to think about letters and parenthesis in phone numbers!

@hnrysmth

This comment has been minimized.

Show comment
Hide comment
@hnrysmth

hnrysmth Apr 19, 2013

Owner

Haha, that sounds pretty annoying. Yeah, ppl has some growing to do so that users can represent data like this in an RFC-compliant way.

I'm eager to be able to mark phone numbers in this way, myself. Don't worry, this is definitely gonna get added.

Owner

hnrysmth commented Apr 19, 2013

Haha, that sounds pretty annoying. Yeah, ppl has some growing to do so that users can represent data like this in an RFC-compliant way.

I'm eager to be able to mark phone numbers in this way, myself. Don't worry, this is definitely gonna get added.

hnrysmth added a commit that referenced this issue Apr 20, 2013

Enable users to update the type of existing phone numbers
This brings hnrysmth/ppl#24 near to completion. For the sake of being thorough I'm
not going to ship this until the colorization work is complete as well.
@hnrysmth

This comment has been minimized.

Show comment
Hide comment
@hnrysmth

hnrysmth Apr 20, 2013

Owner

This is in 1.21.0. Thanks for motivating me to build this. I've been needing it myself for some time.

I mentioned RFC compliance earlier in this thread. In fact, I learned today that RFC 2426 is pretty strict about which values it considers valid in the TYPE field.

   tel-type     = "HOME" / "WORK" / "PREF" / "VOICE" / "FAX" / "MSG"
                / "CELL" / "PAGER" / "BBS" / "MODEM" / "CAR" / "ISDN"
                / "VIDEO" / "PCS" / iana-token / x-name
        ; Values are case insensitive

This came up because the gem I'm using for vCard encoding & decoding made me jump through some hoops to decode standard and non-standard values simultaneously.

The upshot of this is that ppl is perfectly happy to help you create vCards that aren't RFC-compliant. It seems that pretty much all address book software does this, though. Personally, I don't think it's worth worrying about, and I'm pretty much only even writing this as a means of going on record to say "I know this allows non-standard vCards to be created, and I don't mind".

Owner

hnrysmth commented Apr 20, 2013

This is in 1.21.0. Thanks for motivating me to build this. I've been needing it myself for some time.

I mentioned RFC compliance earlier in this thread. In fact, I learned today that RFC 2426 is pretty strict about which values it considers valid in the TYPE field.

   tel-type     = "HOME" / "WORK" / "PREF" / "VOICE" / "FAX" / "MSG"
                / "CELL" / "PAGER" / "BBS" / "MODEM" / "CAR" / "ISDN"
                / "VIDEO" / "PCS" / iana-token / x-name
        ; Values are case insensitive

This came up because the gem I'm using for vCard encoding & decoding made me jump through some hoops to decode standard and non-standard values simultaneously.

The upshot of this is that ppl is perfectly happy to help you create vCards that aren't RFC-compliant. It seems that pretty much all address book software does this, though. Personally, I don't think it's worth worrying about, and I'm pretty much only even writing this as a means of going on record to say "I know this allows non-standard vCards to be created, and I don't mind".

@hnrysmth

This comment has been minimized.

Show comment
Hide comment
@hnrysmth

hnrysmth Apr 20, 2013

Owner

Oops, missed something

Phone Numbers:
  #<Ppl::Entity::PhoneNumber:0x000000013e4238>

Fixed now.

Owner

hnrysmth commented Apr 20, 2013

Oops, missed something

Phone Numbers:
  #<Ppl::Entity::PhoneNumber:0x000000013e4238>

Fixed now.

@hnrysmth hnrysmth closed this Apr 21, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment