Subject: Re: [VCARDDAV] Making TEL value stricter (Dany CAUCHIE)

From: <[email-masked]>
Date: Fri, 16 May 2008 15:09:51 +0200

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
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Helge Hess <[email-masked]>
Date: Fri, 16 May 2008 15:41:54 +0200

On 16.05.2008, at 15:09, <[email-masked]> wrote:
> spaces, brackets.

What you say is all correct, but IMO it won't work out with vCard. A  
huge majority of real world client applications just use a simple text  
field for a phone number. They know nothing about area codes and such,  
nor would many users care to configure them even if they would.
This is mostly because the majority of the 'relative tels' just work  
because the handset knows the area etc and can resolve the number. The  
additional information is only useful for few users (and they can  
still enter + numbers and it works).

I would like to suggest something else. Maybe the vcard WebDAV  
collection could have properties which can be used by CTI apps to   
more reliably resolve 'relative numbers', that is, numbers which do  
not start with '+'. Its more likely that the server administrator  
properly configures the collection environment than each user.
(somewhat comparable to timezone settings in CalDAV collections).

Thanks,
   Helge
-- 
Helge Hess
http://www.zideone.com/

---

From: Mark Paterson <[email-masked]>
Date: Fri, 16 May 2008 11:10:19 -0400

Helge Hess wrote:
> field for a phone number. 
And they force their laziness into the Vcard and then they can't be 
exchanged successfully. How a client want to display a phone number is 
up to it but it's display choices should not effect the actual format of 
the phone number that gets exchanged.

Mark
> They know nothing about area codes and such,  

-- 

Oracle Email Signature Logo
Mark Paterson | Product Manager, UC & Mobile Services | 514.905.8649
Oracle Server Technologies - Collaboration
600 Blvd. de Maissoneuve West, Suite 1900, Montreal, Quebec, H3A 3J2
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Simon Perreault <[email-masked]>
Date: Fri, 16 May 2008 13:09:49 -0400

> they can be sent as they are within a vCard

I don't understand what you mean here. They clearly are not valid according to 
RFC3966. They must begin with "tel:", then all the spaces must be either 
removed or converted to something else (e.g. dashes), and you must resolve 
the scope issue (global or local number with context).

If you mean that these numbers are all convertible to tel URIs, then sure, 
they are.

> american, italian, australian,...... rules.

Yes, this is the scope issue that needs to be resolved for converting the 
value to a tel URI.

>        foreigner softwares will do nothing).

Yes, global-scope numbers are easier to handle and should be preferred, but 
that's out of scope for vCard and in scope for RFC 3966.

>         lot of code lines and it is not so easy).

So basically you're saying that resolving a local-scope tel URI is too much 
work for a vCard parser and that only global-scope URIs should be used, is 
that right?

If so, doesn't the following passage from RFC 3966 make you happy?

   Local numbers SHOULD NOT be used for several reasons.  Local numbers
   require that the originator and recipient are configured
   appropriately so that they can insert and recognize the correct
   context descriptors.  Since there is no algorithm to pick the same
   descriptor independently, labelling numbers with their context
   increases the chances of misconfiguration so that valid identifiers
   are rejected by mistake.  The algorithm to select descriptors was
   chosen so that accidental collisions would be rare, but they cannot
   be ruled out.

>                      c) my sister and her phone number is 01065052266

What do you mean by RFC3966-compliant? Try first formatting them as actual 
URIs and then we can have a more precise discussion.

> Postal Address attributes. LABEL contains

You're forgetting something. Sometimes local numbers have no global 
equivalent. Take for example a 1-800 toll-free number that is only valid in 
North America. This is very common. You need to include the context.

This is exactly what the tel URI does: include support for local phone 
numbers, but strongly discourage them.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: "Darryl Champagne" <[email-masked]>
Date: Fri, 16 May 2008 15:05:19 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Simon Perreault
> 

Actually, you do _not_ identify the context for the example you provide.
From RFC 3966:
"  National freephone numbers do not need a context, even though they
   are not necessarily reachable from outside a particular country code
   or numbering plan.  Recall that "tel" URIs are identifiers; it is
   sufficient that a global number is unique, but it is not required
   that it be reachable from everywhere."

   ...

   If the recipient of a "tel" URI uses it simply for identification,
   the receiver does not need to know anything about the context
   descriptor.  It simply treats it as one part of a globally unique
   identifier, with the other being the local number.  If a recipient of
   the URI intends to place a call to the local number, it MUST
   understand the context and be able to place calls within that
   context.

The problem we run across in synchronization, is that since the ultimate
recipient of the vCard is not known, it is not adequate to just talk about
the recipient needing to know something.

One can legitimately argue that this could be considered as within the scope
of RFC3966 - but it is also legitimate to say that because the ultimate
recipient is unknown, we require certain special characteristics - e.g. a
subset of 3966.

I personally do not object to the visual spacers, although I understand why
it is a concern.  

I do have a problem with local numbers that do not have a context.  Perhaps
all that is needed is to require one, such as ;context=local, or to
explicitly state that no assumptions can be made about the recipient, so RFC
3966 TELs MUST NOT just be an identifier.

It is also pretty clear that this is an area of confusion (e.g. 
   " A huge majority of real world client applications just use a simple 
   text field for a phone number. They know nothing about area codes and
   such, nor would many users care to configure them even if they would.
   This is mostly because the majority of the 'relative tels' just work 
   because the handset knows the area etc and can resolve the number. The
   additional information is only useful for few users
").

The overall problem is that we have multiple options, each of which loosens
the requirements - it might be tel: or it might not:  "It is expected that
the URI scheme will be "tel", as specified in [RFC3966], but other schemes
MAY be used.", The SHOULD be global in RFC 3966, the lack of a real
requirement for context, and then all the confusion over the combinations of
TYPEs of TELs.

Things need to be a bit stricter than they currently are.

dgc

---

From: Simon Perreault <[email-masked]>
Date: Fri, 16 May 2008 15:41:47 -0400

>    that it be reachable from everywhere."

Oops, you're right. I understood that exactly as the contrary of what it 
meant.

> explicitly state that no assumptions can be made about the recipient, so
> RFC 3966 TELs MUST NOT just be an identifier.

Did you miss this part of RFC 3966?

   Local numbers MUST have a 'phone-context' parameter that identifies
   the scope of their validity.  The parameter MUST be chosen to
   identify the local context within which the number is unique
   unambiguously.  Thus, the combination of the descriptor in the
   'phone-context' parameter and local number is again globally unique.

>    additional information is only useful for few users

Woah, I'm getting really confused here. There is a proposal for having tel 
URIs as values for the TEL property. People are asking for it to be more 
strict. And now you're telling me that because UAs display only a text field, 
somehow, this is not strict enough? How is anyone supposed to make sense out 
of that argument?
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Mark Paterson <[email-masked]>
Date: Fri, 16 May 2008 16:34:35 -0400

> 3966 TELs MUST NOT just be an identifier.
Perhaps we should indicate that the value must be global unless 
impossible in which case ;context=local should be supplied.
> Things need to be a bit stricter than they currently are.
+1

--

---

From: Simon Perreault <[email-masked]>
Date: Fri, 16 May 2008 16:41:56 -0400

On Friday 16 May 2008 16:34:35 Mark Paterson wrote:
> > I do have a problem with local numbers that do not have a context. 
> > Perhaps all that is needed is to require one, such as ;context=local, or
> > to explicitly state that no assumptions can be made about the recipient,
> > so RFC 3966 TELs MUST NOT just be an identifier.
>

That's already in RFC 3966:

   Local numbers SHOULD NOT be used
   unless there is no way to represent the number as a global number.

   Local numbers MUST have a 'phone-context' parameter that identifies
   the scope of their validity.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: "Darryl Champagne" <[email-masked]>
Date: Fri, 16 May 2008 17:45:46 -0400

> Sent: Friday, May 16, 2008 4:42 PM
> To: [email-masked]
> Subject: Re: [VCARDDAV] Making TEL value stricter (Dany CAUCHIE)
> 

Yet just a couple paragraphs later, there is the exact case of a non-global
number NOT having a context.  Your example, of a 1-800/877 etc. number, is
not a global number, yet does not have a context.  We are asking for EVERY
number to be either global (preferred, as in SHOULD), or have a context.  No
exceptions.

dgc

---

From: "Darryl Champagne" <[email-masked]>
Date: Fri, 16 May 2008 17:56:25 -0400

> Sent: Friday, May 16, 2008 3:42 PM
> To: [email-masked]
> > > equivalent. Take for example a 1-800 toll-free number that is only
> valid
> > > in
> Perhaps

We are talking about ALL non-globally reachable numbers having a context,
not just be unique - because there is no way a phone is going to know that a
particular number is toll-free in some other country - it's going to show up
as just some botched number.  The RFC 3966 has more than 2 categories -
globally reachable (OK), globally unique identifiers, like toll-free (NOT
OK), and local.

> somehow, this is not strict enough? How is anyone supposed to make sense

I think you missed the quotes.  I did not say this.  This was said on this
list just a couple of days ago, and I am pointing it out as an example of
some confusion on the topic.  If 'Relative tels' just worked as was claimed,
then we wouldn't be having this discussion, because we wouldn't keep having
sync and IOP issues.  In fact, the problem is more of a US and Canada
-centric view - relative tel's do generally work in the +1 country code -
it's in Europe and elsewhere that it gets to be a big problem, and why we
need to avoid them in vCards.

---

From: Helge Hess <[email-masked]>
Date: Sat, 17 May 2008 01:05:56 +0200

On 16.05.2008, at 23:56, Darryl Champagne wrote:
> In fact, the problem is more of a US and Canada
> -centric view - relative tel's do generally work in the +1 country  
> code - it's in Europe and elsewhere that it gets to be a big  
> problem, and why we need to avoid them in vCards.

Well, I'm in +49 and its certainly not a big problem in the real  
world. Users enter + numbers if they work in a cross-country context  
(in fact only for the numbers where it matters) and they don't if they  
are not.

You want to require them (the users!) to always enter absolute numbers  
(if only by configuring a base), and this definitely is not going to  
happen (can be easily proven, just check the telephony config in  
Outlook deployments).

Call them lazy, to me they are just users which use a majority subset  
of their contacts in a relative context only. I fail to see why they  
should be required to enter FQN just to be able to store a perfectly  
working relative number.

There are obvious technical merrits in requiring a fully qualified  
number, but I'm pretty sure this wouldn't catch on.

In fact I think that my suggestion for storing the context of the  
number in the environment (in this case the WebDAV collection), is  
quite awesome ;-) Puts the burden on the admin, the users can still  
store rel numbers, yet the full context is available.

Anyways, interesting discussion. I'm curious to see what will be in  
vCard4 final. And/or CardDAV.

Thanks,
   Helge

---

From: "Darryl Champagne" <[email-masked]>
Date: Fri, 16 May 2008 22:56:46 -0400

> Behalf Of Helge Hess
> Sent: Friday, May 16, 2008 7:06 PM
> To: [email-masked]

At no point did I talk about the users entering absolute numbers.  vCard, as
an interchange format, is typically composed by some software application.
My Windows PC knows my time zone, has dialing rules, and so on.  My Linux
box has most of the same info.  Both of my Mobile phones know where there
are, and their country code and area code.

Even if Outlook is all messed up (and if you try entering contacts in
Outlook, you will see it make guesses about the address style and country
anyway - so user intervention is already required at times), my Sync
software can still ask the user what their area code is.  Besides, Outlook
still only creates vCard 2.1 - perhaps by 2020 it will deal with vCard 4.0,
and by then Windows will figure out area codes (like by asking when you
setup the system, just like it deals with time zones) <grin>.  

You as a user are perfectly able to continue to enter local numbers.  What
we are talking about here is how those numbers need to be sent to other
machines, and stored (outside of some particular application).

As to the vCard format itself, I would claim that having it human readable
is far more important than human writable (although still not such a big
deal, other than for us to debug).  If it was to be completely human
writable, the need for BEGIN:VCARD, and VERSION:4.0, and all the rules about
semicolons and such pretty much guarantees it is only technical folks who
would ever just create one.  Some of the time, perhaps someone will cut and
paste, or tweak a number, but that is most certainly the exception.  I don't
see how that set of users will be inconvenienced by having to type in the
global number.
 
> store rel numbers, yet the full context is available.

Let the user's type in, and view relative/local numbers - that is an
implementation and user interface issue.  But when we want to send it
elsewhere, with different dialing rules, area codes, and such - that is a
Standards issue (sorry, an RFC issue).

And as far as how well it works in the real world - yes, the average person
can mostly do what they want when they type stuff in.  However there are
some large support issues that Sync companies and Operators deal with, or
for anybody trying to do anything remotely complicated, which is what needs
to be improved.  It is still pathetically easy to screw up one's entire
database of contacts when you accidentally use multiple sync products or
combinations of devices.

---

From: Kepeng Li <[email-masked]>
Date: Mon, 19 May 2008 09:34:01 +0800

Hi all,
 
    I concur with the comments and suggestions provided by the email below.
 
BR,
 
Kepeng Li
Huawei 

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Friday, May 16, 2008 9:10 PM
To: [email-masked]
Subject: Re: [VCARDDAV] Making TEL value stricter (Dany CAUCHIE)

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). 

                        D) what ? It's not possible ? Oh, sorry, I forgot to
say something : 

                        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". 

      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".