Hi,
About the TEL format, the draft specification says "as specified in RFC3966" and I do not agree with that.
Preamble :
- vCard is an exchange format used between people, softwares, people <==> softwares
- "how a Tel number is stored in a database" and "how a Tel number is exchanged" are not the same thing
One example :
- in my personnal address book, in my "personnal card" I have these 3 phone numbers
- "02 96 91 08 46" <== my personnal phone number at home ....... Beginning with "0" and with blanks
- "0296053116" <== my professionnal phone number............... ….Beginning with "0" without blanks
- "+33 6 87 06 16 02" <== my mobile phone number....................................Beginning with "+" and with blanks
If I send my personnal card to "somebody" "somewhere in the world" using the vCard format :
a) all these 3 numbers are valid according to RFC3966 then they can be sent as they are within a vCard
b) if the receiving person or software is french (as I am), he/it will understand what these three
numbers mean. So all goes well.
c) if the receiving personn or software is not french, he/it will only understand my mobile
number and will be able to use only this one. Why ? He/it does know the rules (french rules)
for converting my personnal and professionnal number in order to use them from an other country
(replace the leading "0" by "+33").
Not french people will have to find a book where these rules are written
Not french software will have to implement these rules in order to store/display correct
phone numbers ...... and it's also true for american, italian, australian,...... rules.
I think that : If I send my 3 phone numbers in an international format, that is to say :
- +33296910846 for my personnal number
- +33296053116 for my professionnal number
- +33687061602 for my mobile number
then all people in the world can understand and use these 3 numbers (a french person will convert himself
and foreigners will do nothing)
and all softwares in the world can understand and use and store as they are these 3 numbers (as they
begin with "+33" a french software can easily translate them in order to store them in a database and
foreigner softwares will do nothing).
My conclusion :
1) if in 'vCard format specification' the TEL format references RFC3966 then :
- phone numbers can be sent as they as stored (in a database, in an address book) without any translation
- people or software receiving phone numbers must know or implement all the rules (i.e. french rules and
american rules and canadian rules and chines rules, ......) in order to translate a local phone number
into an international phone number format (for people it's not very easy and for softwares it involves a
lot of code lines and it is not so easy).
You think that it's not necessary ? Let's try this :
Here is the content of my address book :
a) me and my phone number is 0296053116 (RFC3966 compliant)
b) my father and his phone number is (02)95255903 (RFC3966 compliant)
c) my sister and her phone number is 01065052266 (RFC3966 compliant)
A ) imagine you received these numbers within 3 different vCards
B) put these 3 people in you address book
C) then, try to call these 3 people
D) what ? It's not possible ? Oh, sorry, I forgot to say something :
- I live in France
- My father lives in Australia
- My sister lives in China
C) you succeeded ? Without special informations, without books or internet ? I cannot believe it.
D) you need the rules for translating "0296053116" into "+33296053116", "(02)95255903" into
"+61295255903" and "01065052266" into "+861065052266". Right ?
2) if in 'vCard format specification' we make TEL value stricter, that is to say "a tel number is something
like "+xxxxxxxxxxxxx" which correspond to an international phone number then :
a) senders (people or softwares) must send phone numbers as "+xxxxxxxxxxxx". Before sending, they (people
or software) must detect if the number (coming from a database, an address book, ...) is a local
number and then translate it (for example, for a french sender (person or software), if the number
begins with 01, 02, 03, 04, 05,06..., then it's probably/certainly a french number which can be
translated to +33xxxxxxxxx. )
Note that if the number is not a local number there is nothing to do.
NB : it's right, in my explanation 1), all the 3 numbers begin with "02" or "01" and then could be
translated into french numbers beginning with "+33" and they are not all french numbers but I would
like to say that explanation 1) and explanation 2) are different and probably in my address book
my father's phone number is already "+61295255903" and my sister's number is already "+861065052266".
* : when I say "local" it means "local to a country : french, canadian, australian" not to a region
or something like that
b) receivers must, in most cases, do nothing. Eventually, for numbers received beginning with "+33" a
french people/software can translate them to "0xxxxxxxx", for numbers beginning with "+1" a north
american people/software can translate them, for numbers beginning with "+86" a chinese people/software
can translate them in order to display them for french, american, chinese people.
==> that is to say : senders and receivers (people or software) must only know the rules applied in their
own country
My suggestion
In 'vCard format specification", TEL format must be stricter : the format must be "+xxxxxxxxxxx" without blanks,
spaces, brackets. It's the only way to have :
- a real exchange format
- sending and receiving softwares as simple as possible (... And people also !)
- something which is like the LABEL attribute regarding Postal Address attributes. LABEL contains
a delivery address label, so everyone in the world can use LABEL in order to send a letter to
a contact and this letter will arrive. Can we do something equivalent for phone numbers that is
to say "phone numbers understandable everywhere is the world" ? As it is not sensible to create
LABELphonenumber attribute, the best way is to have phone numbers like "+xxxxxxxxxx".
_______________________________________________ VCARDDAV mailing list VCARDDAV at ietf.org https://www.ietf.org/mailman/listinfo/vcarddav