VCARD: having an URI as the value of TEL property is bad
Brought to you by:
fortuna
Menu
▾
▴
#47 VCARD: having an URI as the value of TEL property is bad
I have lots of files with telephone numbers that contain spaces. This breaks the builder. I see no benefit from having an URI. There is no code that normalizes the telephone number to the URI form (E.164 or RFC 3966). In a general case it might be difficult to do. I propose to use plain strings for this purpose.
Hmm, the spec does say that this property should be a URI, however I'm happy to consider having a fallback plain text field for when a URI doesn't parse..
As the vCard 4.0 spec is still a draft this is probably something that should be raised with the spec. maintainers. If you would rather not do it I can see if I can forward this issue to them and see what they say.
regards,
ben
FYI: I have asked the question about support for non-URI values in the TEL property:
http://www.ietf.org/mail-archive/web/vcarddav/current/msg00747.html
Ok, I had a pretty lengthy discussion with the vCard maintainers and they seem pretty adamant that you can convert any telephone number to a URI consistently - see this link for details:
http://www.ietf.org/mail-archive/web/vcarddav/current/msg00747.html
So I have applied a change to the Telephone class that will replace all spaces with a hyphen ('-') character. So far this seems to work with the current set of examples, let me know if you have further issues with this.
regards,
ben
Great, thanks for clarifying this.
Though, if we're supposed to use URIs, then why not add the tel: prefix in front of that string. Then the getValue method would return the number (without the tel: prefix), and the getURI method would return the full proper tel: uri as per RFC3966.
Yup I've added the "tel:" scheme now where it isn't specified. Was debating whether to do it for compatibility with prior versions, but I think it makes sense to conform to vCard 4.0 for now.
Changes now in CVS.