Subject: [VCARDDAV] TEL property and non-URI values

From: Ben Fortuna <[email-masked]>
Date: Thu, 26 Feb 2009 17:11:03 +1100

Hi everyone,

I am the primary developer of the iCal4j Java library, which includes a
vCard implementation based on the current vCard 4.0 draft spec.

A contributor to the project has suggested that requiring a URI value for
the TEL property is not always practical, as sometimes numbers may include
spaces, etc. and there's apparently no standard way of converting such a
number to a valid URI format.

Ideally the TEL property would allow for an alternate text representation
(as indicated by a VALUE=text parameter), in a similar approach to that used
in other properties such as BDAY. Is this a possible consideration?

My apologies if this isn't the right mailing list, or if this issue has been
addressed previously.

regards,
ben

---

From: Simon Perreault <[email-masked]>
Date: Thu, 26 Feb 2009 08:41:44 -0500

Ben Fortuna wrote:
> A contributor to the project has suggested that requiring a URI value
> for the TEL property is not always practical, as sometimes numbers may
> include spaces, etc. and there's apparently no standard way of
> converting such a number to a valid URI format.

Is there a reason why converting spaces to dashes wouldn't work?

Simon
-- 
STUN/TURN server    --> http://numb.viagenie.ca
Interplanetary news --> http://reeves.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Feb 2009 14:48:25 +0100

Ben Fortuna wrote:
> ...

"%20"?

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Feb 2009 14:52:49 +0100

Julian Reschke wrote:
> Ben Fortuna wrote:
>> Hi everyone,
>>
>> I am the primary developer of the iCal4j Java library, which includes 
>> a vCard implementation based on the current vCard 4.0 draft spec.
>>

OK, I just checked RFC 3966 and %20 would not be legal.

So, how about dashes, as suggested by Simon, or dots?

BR, Julian

---

From: Simon Perreault <[email-masked]>
Date: Thu, 26 Feb 2009 08:53:13 -0500

Not allowed:

   However, even though ITU-T E.123 [E.123] recommends the use of space
   characters as visual separators in printed telephone numbers, "tel"
   URIs MUST NOT use spaces in visual separators to avoid excessive
   escaping.

---

From: Ben Fortuna <[email-masked]>
Date: Fri, 27 Feb 2009 00:57:44 +1100

Here are some examples from the samples he had provided (I hope they aren't
real numbers..):

TEL;type=WORK;type=pref:+44 28 90930084

TEL;type=WORK;type=pref:+1.650.506.7000

TEL;type=WORK;type=pref:+49(721)123456

TEL;type=CELL:+49(175)1234567

TEL;type=WORK;type=pref:+94 (0800) 2255337

TEL;type=WORK;type=pref:+49(721)847932

TEL;type=CELL:+49(175)9876543

(etc.)

I noticed also that the authors of RFC2445 (iCalendar) use the following
syntax (vCard 3.0):

TEL;TYPE=WORK,MSG:+1-919-676-9515
TEL;TYPE=WORK,FAX:+1-919-676-9564

So it would seem that there are a number of different styles already in use
(vCard 3.0 or earlier). Even if it is possible to convert these styles into
a valid URI, some information from the text representation will be lost
(e.g. the brackets indicating area codes, etc.)

I guess the main benefit I can see from allowing an alternate text
representation would be improved backward compatibility with prior versions
of the standard..

regards,
ben

-- 

Rodney Dangerfield  - "When I was a kid my parents moved a lot, but I always
found them."

---

From: Simon Perreault <[email-masked]>
Date: Thu, 26 Feb 2009 09:11:36 -0500

Ben Fortuna wrote:
> representation would be improved backward compatibility with prior
> versions of the standard..

The point is to specify a format so that interpretation is easier.

In the odd case that the tel URI cannot contain the information, the NOTE
property should be used.

Simon

---

From: Ben Fortuna <[email-masked]>
Date: Fri, 27 Feb 2009 01:19:52 +1100

Hmm, I don't think a NOTE is particularly useful for this use-case, as there
may be multiple TEL properties in vCard 3.0 object, and NOTEs don't support
the TYPE params used in TEL properties. Again, from one of the samples:

I don't see how to represent this using vCard 4.0 without losing
information..

regards,
ben

-- 

Fran Lebowitz  - "You're only has good as your last haircut."

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Feb 2009 15:26:33 +0100

Ben Fortuna wrote:
> Hmm, I don't think a NOTE is particularly useful for this use-case, as 
> there may be multiple TEL properties in vCard 3.0 object, and NOTEs 
> don't support the TYPE params used in TEL properties. Again, from one of 
> the samples:
> 

Me confused.

"(" and ")" *are* allowed in tel URIs:

	visual-separator     = "-" / "." / "(" / ")"

-- <http://tools.ietf.org/html/rfc3966#section-3>

BR, Julian

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 26 Feb 2009 14:26:56 +0000

Ben Fortuna wrote:

> Here are some examples from the samples he had provided (I hope they 
> aren't real numbers..):
>
> I noticed also that the authors of RFC2445 (iCalendar) use the 
> following syntax (vCard 3.0):
>
> So it would seem that there are a number of different styles already 
> in use (vCard 3.0 or earlier). Even if it is possible to convert these 
> styles into a valid URI, some information from the text representation 
> will be lost (e.g. the brackets indicating area codes, etc.)

It seems that RFC 3966 allows for "(" and ")" (search for 
"visual-separator").
So after removing spaces it doesn't look like anything is lost.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 26 Feb 2009 09:30:15 -0500

> I don't see how to represent this using vCard 4.0 without losing

You think this has lost information?

WORK.TEL:tel:+49(721)847932
TEL;type=CELL:tel:+49(175)9876543

Simon

---

From: Simon Perreault <[email-masked]>
Date: Thu, 26 Feb 2009 09:31:36 -0500

> WORK.TEL:tel:+49(721)847932

;-) Forgot the pref. Should be:

WORK.TEL;PREF=1:tel:+49(721)847932

Simon

---

From: Helge Hess <[email-masked]>
Date: Thu, 26 Feb 2009 15:39:12 +0100

> I don't see how to represent this using vCard 4.0 without losing  

Isn't that the same like

   TEL;TYPE=WORK;TYPE=PREF:tel:+49-721-847932
   TEL;TYPE=CELL:tel:+49-175-9876543

?

I wonder whether an optional display name would be useful (like the CN  
in an email property):

   TEL;type=WORK;type=pref;label="(0721)847932":tel:+49-721-847932

Greets,
   Helge
-- 
Helge Hess
http://helgehess.eu/

---

From: Ben Fortuna <[email-masked]>
Date: Fri, 27 Feb 2009 01:40:17 +1100

Ok, so maybe it isn't an issue after all..

I'll quote the contributor in entirety just so there's no confusion:

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

So I guess the issue presented is that there isn't a standard way to create
a URI from TEL values in prior versions.

This in fact, may not be the case based on what is coming to light here, and
as long as characters that aren't valid in a URI can be converted in some
uniform way, then I guess it's a non-issue.

I will take this back to the project and see how I go. Thank you all for
your time.

regards,
ben

On Fri, Feb 27, 2009 at 1:26 AM, Julian Reschke <[email-masked]>wrote:

>> there may be multiple TEL properties in vCard 3.0 object, and NOTEs don't
>> support the TYPE params used in TEL properties. Again, from one of the
>> samples:
>>

-- 

Henny Youngman  - "When I told my doctor I couldn't afford an operation, he
offered to touch-up my X-rays."

---

From: Ben Fortuna <[email-masked]>
Date: Fri, 27 Feb 2009 01:45:25 +1100

Actually I did think of another similar approach to representing phone
number I have seen quite often:

+61 (0) 3 9283 8374

In this case the zero is included if calling from within Australia (ignoring
the "+61") and excluded when calling from overseas. Something like a label
might make this representation a bit less ambiguous..

regards,
ben

On Fri, Feb 27, 2009 at 1:39 AM, Helge Hess <[email-masked]>wrote:

> I wonder whether an optional display name would be useful (like the CN in
> an email property):
>
> _______________________________________________
> VCARDDAV mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vcarddav
>

--

---

From: Simon Perreault <[email-masked]>
Date: Thu, 26 Feb 2009 09:51:39 -0500

Ben Fortuna wrote:
> In this case the zero is included if calling from within Australia
> (ignoring the "+61") and excluded when calling from overseas. Something
> like a label might make this representation a bit less ambiguous..

These two different numbers can be represented with two URIs:

tel:+61-3-9283-8374
tel:0-3-9283-8374;phone-context:+61

Simon