Subject: [VCARDDAV] PREF format

From: <[email-masked]>
Date: Tue, 3 Jun 2008 15:25:03 +0200

Hi, 

What do we want to do with the 'pref' value.

For phone numbers, we want to define which one is the preferred phone
number and we can write something like that :

> TEL; tel:+0101010101;				<== home
> TEL;TYPE=pref:tel:+0202020202			<= home
> TEL;TYPE=pref,work:tel:+0303030303		<== work
> TEL;TYPE=pref,home,work:tel:+0404040404	<==  home and work
> 
Issues : 

1) when several "phone numbers are declared" as "preferred home phone",
we do not know which one is the preferred one.
2) when a phone number is declared "home" and "work", we do not know if
this phone number is the preferred one when I am at home,
or when I am at work, or both.

What do we really want to do with 'pref' ?

* I want to declare which phone number is the preferred one depending on
my present location or my present activity. 

For example : if I am at home, I prefer to receive calls on my land-line
phone at home
                 or if I am at work I prefer to receive calls on my
land-line phone at work
                 or I prefer to receive all calls on my mobile phone
(when I am at home, at work or whatever)
  
One solution suggested on this mailing list was : we can use numbers 1,
2, 3, ... to indicate an order of preference. Something like :

>  					TEL; tel:+0101010101;
> <== home
> 					TEL;TYPE=pref=1:tel:+0202020202
> <= home
> 	
> TEL;TYPE=pref=2,work:tel:+0303030303		<== work
> 	
> TEL;TYPE=pref=3,home&work:tel:+0404040404	<== home and work
> (Syntax according to my previous suggestion)
> 
But, that does'nt resolve the issue with "work and home" ==> we need a
pref with 2 values ==> pref(pref at home, pref at work).

Note : I don't want to discuss here if the biggest priority value is 0
or 1 or n ==> that is an other discussion.

A) if there is only one value, this means "pref at home"
example      TEL;TYPE=pref=(3),home&work:tel:+0404040404	<==
means "phone number preferred at home" with priority=3

> B) does it work ?
> 
> 					TEL; tel:+0101010101;
> 
> 					TEL;TYPE=pref(1):tel:+0202020202
> <= means "preferred at home"
> 	
> TEL;TYPE=pref(3,1),work:tel:+0303030303		<== means
> "preferred at work" and in 3rd position for calls when I am at home
> 	
> TEL;TYPE=pref(2,2),home&work:tel:+0404040404	<==  in 2nd position for
> calls when I am at home and in second position for calls when I am at
> work
And this ?
> 					TEL; tel:+0101010101;
> <== it's not a preferred phone number
> 					TEL;TYPE=pref():tel:+0202020202
> <== it's not a preferred phone number
> 	
> TEL;TYPE=pref(,2),work:tel:+0303030303		<== in second
> position when I am at work
> 	
> TEL;TYPE=pref(1,1),home&work:tel:+0404040404	<== in first position
> when I am at home or when I am at work
> 
Yes, I guess so, it works. And it could also be used for the EMAIL, IMPP
properties if we agree that values like "home&work" could also be used
for email, impp.

_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Simon Perreault <[email-masked]>
Date: Tue, 3 Jun 2008 09:37:19 -0400

> > (Syntax according to my previous suggestion)

Another suggestion was to reuse the already existing group syntax. Here's your 
example using that syntax:

WORK.TEL;TYPE=pref:tel:+15555555555
WORK.TEL:tel:+15555555556
HOME.TEL;TYPE=pref:tel:+15555555557
HOME.TEL:tel:+15555555558
TEL;TYPE=pref:tel:+15555555559
TEL:tel:+15555555560

The big advantage is that existing vCard parsers would not need to be 
modified. What would be needed for vCard 4.0 would only be to give special 
meaning to some group names such as HOME and WORK.

Funny, I was currently working on doing exacty that. :)
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: "Javier Godoy" <[email-masked]>
Date: Wed, 4 Jun 2008 00:40:35 -0300

Simon Perreault wrote:

>> 2, 3, ...
>> to indicate an order of preference. Something like :
>>
>> TEL;TYPE=pref=1:tel:+0202020202 <= home

Yes, but I think he was talking about relative preferences among phone
numbers of the same type/group:
  TEL;TYPE=pref=1,work:tel::+1-555-555-5555
  TEL;TYPE=pref=2,work:tel::+1-555-555-5554
  TEL;TYPE=pref=3,work:tel::+1-555-555-5556
(or WORK.TYPE=pref=1, etc.)

For the home&work example, I'm fine with a "condensed" syntax such as
  TEL;TYPE=pref(3,1),home&work:tel:+0404040404
(which was proposed) or, alternatively,
  TEL;TYPE=work(1),home(3):tel:+0404040404

However, there are some solutions using a single property for each number,
- If both pref values were the same, I would write:
  TEL;TYPE=pref=3,home,work:tel:+1-555-555-5556

- If preference values were different, I would write one property for each
case:
  TEL;TYPE=pref=1,home:tel:+1-555-555-5556
  TEL;TYPE=pref=3,work:tel:+1-555-555-5556

- or I would arrange the other preference values in order to convey this
meaning
  TEL;TYPE=pref=1,work:tel::+1-555-555-5555
  TEL;TYPE=pref=2,work:tel::+1-555-555-5554
  TEL;TYPE=pref=3,home,work:tel:+1-555-555-5556
  TEL;TYPE=pref=4,home:tel::+1-555-555-5557
(for work the order is: 5555,5554,5556; for home the order is 5556,5557)

Regards,

Javier

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Wed, 4 Jun 2008 09:43:28 +0200

> >> TEL;TYPE=pref=3,home&work:tel:+0404040404 <== home and work

Hmmm... What strikes me here is that you seem to try to implement
something ENUM-like. Discovering what kind of service a certain phone
number provides, and what preference should be applied.

Generally, i have a slight guts feeling that the definition of the "TEL"
attribute is getting substantially overengineered here. Especially if
you think that in addition to all the fancy things above, you have the
options to:

- add "tel" URI parameter, which might clash with the "TYPE" information
- do lookups for phone numbers to gather even more information about a
number (ENUM)

Getting all those combinations / permutations implemented could be ...
interesting..

cheers

Alex

---

From: Simon Perreault <[email-masked]>
Date: Wed, 4 Jun 2008 08:15:53 -0400

> (or WORK.TYPE=pref=1, etc.)

I'm really not sure we want to provide that feature in vCard. As others 
mentioned, there are other means of achieving that.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: "Javier Godoy" <[email-masked]>
Date: Wed, 4 Jun 2008 09:46:00 -0300

> mentioned, there are other means of achieving that.

I'm not sure if we should delegate it to other mechanisms requiring access
to other services, instead of making vCads self-contained.
Besides, that feature would apply for preference values in general, not only
for TEL but also for ADR, EMAIL and IMPP.

Regards,

Javier.

---

From: "Chris Bryant" <[email-masked]>
Date: Wed, 4 Jun 2008 09:36:36 -0400

> (for work the order is: 5555,5554,5556; for home the order is 5556,5557)

I'd really like it if we did not allow the combination of HOME and WORK on 
any single item.  Most of the user interfaces that I have seen that people 
use to enter the data for vCards require them to specify a phone number as a 
single type (Home Phone, Work Fax, etc.).  By tagging a phone number as 
being both home and work, it just complicates the normal mapping between 
these UI fields and the data in the vCard.  If a number applies to both home 
and work, just put two lines in the vCard, one for home and one for work.

Similarly, I'd like it if things like VOICE and FAX are not combined on a 
single entry.

For the PREF modifier, instead of saying TYPE=PREF=X, why wouldn't we just 
use PREF=X?  So instead of "TEL;TYPE=pref=1,work:tel::+1-555-555-5555", use 
"TEL;TYPE=work;PREF=1:tel::+1-555-555-5555".

Chris 

USA.NET 
You Run Your Business.  We'll Run Your Email.

This message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information of USA.NET, Inc.  Any unauthorized review, use, copying, disclosure, or distribution is prohibited.  If you are not the intended recipient, please immediately contact the sender by reply email and delete all copies of the original message.

---

From: Mark Paterson <[email-masked]>
Date: Wed, 04 Jun 2008 11:43:27 -0400

How about getting rid of Pref all together? In this day and age the 
preferred number is which ever one I manage to get a hold of you on. 
It's a concept that's nice but I think for the most part ignored and it 
complicates implementations. With the emergence of concepts such as a 
"Network Address Book/Converged Address Book/insert your best buzz term" 
the idea of combining presence information and address book information 
is getting a lot of play where presence information helps you decide the 
best way to contact someone. Presumably people's preference should play 
into that as well. Perhaps it should be specified as part of such 
specifications. We could even send a liaison request to the OMA CAB 
group for more information and input.

Mark

-- 

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: Wed, 4 Jun 2008 11:59:16 -0400

> group for more information and input.

I wholeheartedly agree. Informally, the most preferred one will be the first 
one that the user sees. And that one is usually the first one that appears in 
the vCard. So UAs wishing to implement preferences could simply order the 
lines of output accordingly.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Thu, 5 Jun 2008 09:52:53 +0200

> How about getting rid of Pref all together? In this day and 
> age the preferred number is which ever one I manage to get a 
> hold of you on. It's a concept that's nice but I think for 
> the most part ignored and it complicates implementations. 

+1

Alex

---

From: "Chris Bryant" <[email-masked]>
Date: Thu, 5 Jun 2008 06:19:44 -0400

Mark Paterson wrote:
  How about getting rid of Pref all together? In this day and age the preferred number is which ever one I manage to get a hold of you on. It's a concept that's nice but I think for the most part ignored and it complicates implementations. With the emergence of concepts such as a "Network Address Book/Converged Address Book/insert your best buzz term" the idea of combining presence information and address book information is getting a lot of play where presence information helps you decide the best way to contact someone. Presumably people's preference should play into that as well. Perhaps it should be specified as part of such specifications. We could even send a liaison request to the OMA CAB group for more information and input.

For phone numbers, I'd also be happy to get rid of PREF altogether, but I figured it was important to others.  I see use of PREF with EMAIL though, as it seems common for people to have multiple email addresses, and unlike a phone call or an instant messaging session, it's a bit harder to know if you've sent mail to the right email address because you don't get real-time confirmation from the recipient.

Chris

USA.NET

---

From: "Javier Godoy" <[email-masked]>
Date: Thu, 5 Jun 2008 11:09:13 -0300

Chris Bryant wrote:

>For phone numbers, I'd also be happy to get rid of PREF altogether, but I
>figured it was important to others.  I see use of PREF with EMAIL though,
>as it seems common for people to have multiple email addresses, and unlike
>a phone call or an instant messaging session, it's a bit harder to know if
>you've sent mail to the right email address because you don't get real-time
>confirmation from the recipient.

I agree. EMAIL, and to some extent ADR (e.g. PO box versus street location) 
benefit from preference information. On the other hand, preference about TEL 
and IMPP may become too complex and/or are already addressed somewhere else.

If EMAIL and ADR allow a "pref=<integer>" parameter, TEL and IMPP may 
support it too, with little implementation cost. If preference information 
for TEL and IMPP is available from other services, it is good (such 
information may be more detailed than the vCard preference parameter). If it 
is not available (or the device cannot access it), we have a self-contained 
minimal description in the vCard (which may be enough in simple cases). If 
an implementation do not support ordered preferences, it could consider the 
strongest preference as "type=pref" and the other values as "not preferred" 
(== absence of type="pref" in vCard 3.0)

Best Regards,

Javier

---

From: Dan Brickley <[email-masked]>
Date: Fri, 06 Jun 2008 12:33:33 +0100

>> the most part ignored and it complicates implementations. 

I've been looking (with Harry Halpin, cc:'d) at how best to reflect 
vCard into RDF and specifically into FOAF. Pref was one of the pieces of 
information I was most tempted to drop, since real life preferences 
(especially with the rise of Web, IM, etc.) are very subtle, contextual 
things. At different times, and for different people, different topics, 
I have very different information preferences. While I do think these 
could be expressed in a machine format, mixing them into a relatively 
static vCard doesn't feel entirely right.

cheers,

Dan

ps. hello everyone, I've been lurking with an interest for a while...

--
http://danbri.org/

---

From: "Darryl Champagne" <[email-masked]>
Date: Tue, 24 Jun 2008 01:08:21 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Dan Brickley
> Sent: Friday, June 06, 2008 7:34 AM
> To: Alexander Mayrhofer
> Cc: Harry Halpin; [email-masked]
> Subject: Re: [VCARDDAV] PREF format
> 

+1 to dropping PREF