Subject: [VCARDDAV] TEL attribute parameters

From: "Chris Bryant" <[email-masked]>
Date: Tue, 25 Mar 2008 10:53:31 -0400

I think the TEL parameters somehow need to be simplified or standardized.  

It seems to me that the way these parameters are defined in the spec does not match very well to the way clients actually define telephone numbers.  For example, most pim clients will allow a user to define a telephone number by either filling in a blank next to a label (e.g., 'Work Phone' or 'Pager') or by allowing the user to enter in a phone number and then choose one corresponding type from an option list.  Verfy few clients actually allow the user to enter a phone number, then select which options should correspond to that phone number (e.g., this phone number is my home, work, voice, and fax number).

If you are dealing with a client that has fixed fields for things like Home Phone, Work Phone, Pager, etc., it can be difficult to figure out what to do with data that has multiple types on it.  Another problem is that different phone numbers could overlap, and there is no way to really understand what is really meant by this.  For example, a vcard could have the following lines:

TEL;TYPE=voice,home,fax,work:+1-213-555-1234
TEL;TYPE=voice,home:+1-213-555-2345
TEL;TYPE=voice,work:+1-213-555-3456
TEL;TYPE=fax,work:+1-213-555-4567

Which phone number should the client show for as 'Work Phone' or 'Home Phone'?  Editing the information is another problem because if a user tries to edit the 'Work Phone', what value in the vcard should it replace?

If you try to use the 'pref' parameter to help out, what does that mean?  Can 'pref' only be used for one phone number, or could it be put on all of the phone numbers listed above?  Does 'pref' just help to identify the preferred choice of two numbers with the same parameters, so for example, if you had three work phone numbers, could two be listed as 'TEL;TYPE=work' and one be listed as 'TEL;TYPE=work,pref'?  In the example above, if you add 'pref' to the first line, does that mean that that number is the preferred number for Home Phone, or does it just mean that it is the preferred number of all of the numbers that could be defined for 'voice,home,fax,work'.

I'm sure anyone that has built pim software that tries to read and write vcards has had these same questions, but I haven't seen any discussion about this on the list yet.  

Chris

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

---

From: Simon Perreault <[email-masked]>
Date: Tue, 25 Mar 2008 11:13:55 -0400

> I think the TEL parameters somehow need to be simplified or standardized.

This is a view shared by many of us. But so far there is no concrete proposal. 
Feel free to suggest something!

> For example, a vcard could have
> the following lines:
>

Here's a bit of philosophical discussion.

vCard is an "underconstrained" format. This means that you may write valid 
vCard data that doesn't have a valid meaning. Your example is one of those. 
As you add different combinations of vCard elements, you explore the 
syntactic validity space. But by doing so you may very well exit the semantic 
validity space, which is smaller and unspecified.

Underconstrained formats have numerous advantages. It's usually easier to "get 
things done" with them because you don't have to bother with technical 
detail. In the long run, as the format gains popularity, you end up 
uncovering interoperability issues like the one you mentioned.

So I think vCard is evolving toward being more constrained. Being 
unconstrained was a huge plus initially, but now our needs as a community 
have changed a little bit. We want more interoperability at the cost of 
having a little bit more complicated format. And that's normal at this point 
in the life time of a standard.

I just wanted to throw in my two cents, and also sneakily pave the way for -01 
which is coming real soon now, and which introduces a fair amount 
of "contrainage". >:-]
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 25 Mar 2008 11:24:11 -0400

Hi Chris,

--On March 25, 2008 10:53:31 AM -0400 Chris Bryant 
<[email-masked]> wrote:

> I'm sure anyone that has built pim software that tries to read and write
> vcards has had these same questions, but I haven't seen any discussion
> about this on the list yet.

Actually the OMA folks have brought up this issue before. In particular 
they wanted to limit the possible combinations of TYPE values to a strict 
subset. e.g.:

tel-param    = "TYPE" "=" tel-type *2["," tel-type]
            ; a type-tel, type-location or type-pref MUST only appear
            ; once.

tel-type      =  type-tel / type-location / type-pref

type-tel      = "VOICE" / "FAX" / "VIDEO" / "CELL" / iana-token / x-token

type-location = "HOME" / "WORK" / "MOBILE" / "OTHER" / iana-token / x-token

type-pref     = "PREF" / iana-token / x-token

Note I split out type-location and type-pref because those should also be 
used for ADR, IM and EMAIL types.

-- 
Cyrus Daboo

---

From: "Chris Bryant" <[email-masked]>
Date: Thu, 27 Mar 2008 08:53:20 -0400

Hi Cyrus,

----- Original Message ----- 
From: "Cyrus Daboo" <[email-masked]>
Sent: Tuesday, March 25, 2008 11:24 AM

> used for ADR, IM and EMAIL types.

I like this approach.  I think we could determine a small set of values for 
type-tel and type-location.
I would probably pull out CELL since I don't see any difference between that 
and VOICE,MOBILE,
and add in PAGER and TTD or something similar.

For the type-tel idea, the default value is VOICE, but should we also
specify that lacking a type-location, the location would default to HOME or 
WORK?  If a VCARD is received
with just TEL and no HOME or VOICE specified, most clients will display the 
number as either the
Home Phone or Work Phone, we just can't predict which one.  If we set a 
default, then at least it is
clear up front.  The location default applies as well to ADR, IM, and EMAIL.

For the PREF item, should there be only one PREF among all TEL items, or one 
per type/location?
Do I have one preferred work phone number and one preferred home number, or 
do I just have one preferred
phone number?

Chris

---

From: "Javier Godoy" <[email-masked]>
Date: Thu, 27 Mar 2008 13:44:18 -0300

Hi Chris,

Chris Bryant wrote:

> and VOICE,MOBILE, and add in PAGER and TTD or something similar.

I agree; understanding type-tel as a location-independent description of the 
device capabilities, a mobile phone would be "voice,mobile", 
"voice,msg,mobile", "voice,msg,video,mobile" etc. No additional information 
is provided by "cell,mobile".

Does "home" and "work" identify physical locations or roles? From the ABNF 
rule names I think it is the first, though "work, mobile" could make sense, 
and "home, mobile" could be either an absurdity or "for personal use" (if 
"home" is understood as a role).

> WORK?  If a VCARD is received with just TEL and no HOME or VOICE 
> specified, most clients will display the
> number as either the Home Phone or Work Phone, we just can't predict which 
> one.  If we set a
> default, then at least it is clear up front.  The location default applies 
> as well to ADR, IM, and EMAIL.

I think it should default to the same value than TYPE for ADR and LABEL 
properties (i.e. "work").

> do I just have one preferred phone number?

IMHO, it is reasonable to expect preferences within a combination of 
type-tel and type-location. For instance:

TEL;TYPE=work,voice,pref:+1-213-555-1230
TEL;TYPE=work,voice:+1-213-555-1231
TEL;TYPE=work,voice:+1-213-555-1232
TEL;TYPE=work,voice:+1-213-555-1233
TEL;TYPE=work,fax:+1-213-555-1230
TEL;TYPE=work,fax,pref:+1-213-555-1231
TEL;TYPE=home,voice,pref:+1-213-555-1234
TEL;TYPE=home,voice:+1-213-555-1235
TEL;TYPE=mobile,voice,msg,video,pref:+1-213-555-1236
TEL;TYPE=mobile,voice,msg:+1-213-555-1237

In this example there are four preferred numbers (work-voice, work-fax, 
home-voice and mobile). The preference cannot be applied to one of them 
only, since the preferred number for work-fax is not so for work-voice, etc.

This approach could add some complications (e.g., if the vCard is exported 
to a device with limited storage capabilities it should retain the preferred 
numbers, and discard the others if necessary... but there could be more 
preferred numbers than the storage limit!!!), but I think it worth the 
trouble.

Furthermore:

1. should several preferred numbers be allowed for *one* type-tel / 
type-location combination?

TEL;TYPE=work,voice,pref:+1-213-555-1230
TEL;TYPE=work,voice,pref:+1-213-555-1231
TEL;TYPE=work,voice:+1-213-555-1232

2. Could we outline a syntax for representing phone number ranges? This 
could be useful when several consecutive numbers are allocated.

TEL;TYPE=work,voice:+1-213-555-1231/3

instead of

TEL;TYPE=work,voice:+1-213-555-1231
TEL;TYPE=work,voice:+1-213-555-1232
TEL;TYPE=work,voice:+1-213-555-1233

Best Regards

Javier Godoy

---

From: "Darryl Champagne" <[email-masked]>
Date: Thu, 27 Mar 2008 13:15:12 -0400

Hi,
Also note that OMA has requested unique identifiers for multiples - so if
there are 3 Work numbers (with whatever other attributes set), there be a
way to say ID=1, 2, or 3 (The generic approach is that every TEL have an
identifier).  In part this is because OMA DS supports sending changes only,
so it is critical to determine which number has changed.

I forget which syntax was last discussed - I know Mark Paterson and I were
involved in that thread.

dgc

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Cyrus Daboo
> To: Chris Bryant; [email-masked]
> Subject: Re: [VCARDDAV] TEL attribute parameters
> 
> Hi Chris,
>

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 27 Mar 2008 13:19:30 -0400

Hi Darryl,

--On March 27, 2008 1:15:12 PM -0400 Darryl Champagne <[email-masked]> 
wrote:

> identifier).  In part this is because OMA DS supports sending changes
> only, so it is critical to determine which number has changed.
>

Right - I think we have agreed that each property needs a unique id - just 
what that is is still open for debate.

The other question though, going back to PREF, is whether there is a need 
to do sorting by more than "this is the preferred, and here are the rest". 
i.e. what if I want a "try this phone first, then this one next, and 
finally this last one" behavior? Since we cannot rely on the order of the 
actual properties themselves in the VCARD object, we would have to have a 
parameter to specify the order.

Is sorting like this a use case any one has?

-- 
Cyrus Daboo

---

From: "Javier Godoy" <[email-masked]>
Date: Thu, 27 Mar 2008 15:04:07 -0300

Hi Cyrus,

> parameter to specify the order.

I have just raised a question about having multiple PREFs values for one
property.

--example a--

If we sort them, as you proposed, we could write them as:

--example b--
TEL;TYPE=work,voice;PREF=3:+1-213-555-1230
TEL;TYPE=work,voice;PREF=2:+1-213-555-1231
TEL;TYPE=work,voice;PREF=1:+1-213-555-1232
(higher values means stronger preference)

here ",pref" is replaced by ";PREF=n" (only two additional bytes per
property wrt. the currently defined alternative).

The same preference value could be assigned to several property instances,
if all of them are preferrable at the same extent. If the PREF parameter is
not given it would default to 0, meaning that the lower preference applies.
If the PREF parameter is present, but no value is given it would default to
1. (This would result in no overhead if the sorting feature is not used, or
only one preferred and one non-preferred property is defined)

pref-param = "PREF" [ "=" 1*DIGIT ]

Thus we have

--example c--
TEL;TYPE=work,voice;PREF:+1-213-555-1230
TEL;TYPE=work,voice;PREF:+1-213-555-1231
TEL;TYPE=work,voice;:+1-213-555-1232

which means "+1-213-555-1230 and +1-213-555-1231 are the preferred telephone
numbers, +1-213-555-1232 could be used as a last resort.". Note its length 
is equal than example a.

> Is sorting like this a use case any one has?

I have not met this use case about TEL, although I deem it probable. Anyway,
I would find sorted-preference useful when writing the EMAIL properties of 
my
own vCard.

Best Regards

Javier

---

From: Simon Perreault <[email-masked]>
Date: Thu, 27 Mar 2008 14:20:07 -0400

> (higher values means stronger preference)

+1, except that I'd use lower values for stronger preference.

Very good idea!

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 27 Mar 2008 12:11:39 -0700

> +1, except that I'd use lower values for stronger preference.

+1 on the lower values for stronger preference.

Is there still some idea of using the "tel:" URI? I don't think the  
"ugly" factor is important, and the "tel" URI can handle all kinds of  
features like
  - a specified way of comparing telephone numbers, so you can tell if  
the "new" one you see in somebody's vcard is really new or just  
formatted differently from some other non-VCARD source
  - Support for telephone number extensions
  - support for numbers that are valid locally only, with scoping to  
say what "local" means
  - possible future support to indicate SMS capability or SMS  
preferences

Of course, there's such a thing as too many features and too much  
flexibility as well.

Lisa

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 27 Mar 2008 15:30:04 -0400

Hi Lisa,

> Of course, there's such a thing as too many features and too much

One problem with tel: is that it only defines a format for the number. It 
does not represent a "dialling sequence". i.e. you cannot put in 
",,,5555,,,333" into the tel: number so that you can dial an extension or a 
conf call number etc. So if we do require tel: I would like to see either:

1) A parameter extension to tel: to allow specifying a dialing sequence. I 
think this would be generally useful for tel: links embedded in webpages 
that mobile devices could easily make use of.
2) A vCard parameter on TEL: that indicates the dialing sequence.

-- 
Cyrus Daboo

---

From: "Javier Godoy" <[email-masked]>
Date: Thu, 27 Mar 2008 17:45:00 -0300

----- Original Message ----- 
From: "Lisa Dusseault" <[email-masked]>
To: "Simon Perreault" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 27, 2008 4:11 PM
Subject: Re: [VCARDDAV] TEL attribute parameters - PREF

> +1 on the lower values for stronger preference.

I have no problem with "lower values for stronger preference" if consensus
points in that direction.

However, I have used higher values for higher preferences because of two
reasons:

1. PREF can default to a defined value of "0", meaning that the lowest
preference applies. This is consistent with the current semantic of ommiting
the "pref" value from tel-type.
2. New values can be added with higher preferences, without modifying the
other properties. Some use cases illustrating this point are:
 - the vCard contains the corporation call center number (work phone), and
we are adding a direct line to the individual's office.
 - a new (preferred) email account is added, while the older accounts are
kept with lower preference.

If lower values are used for stronger preference:

1. There is no value for "lowest preference". PREF should default to an
unspecified value, which would be considered to be the lowest preference. On
the opposite "0" would be the "highest preference", and it would be possible
to assign PREF=0 disregarding other preferences (this could be, or could be
not, a desired feature...)
2.  When a new preferred property is added, the other properties should be
modified.

Best Regards

Javier

---

From: Simon Perreault <[email-masked]>
Date: Thu, 27 Mar 2008 17:00:20 -0400

On Thursday 27 March 2008 16:45:00 Javier Godoy wrote:
> preference applies. This is consistent with the current semantic of
> ommiting the "pref" value from tel-type.

This is implementation-specific. We can just say, in words, something to the 
effect that "A property for which PREF is absent is less preferred than one 
for which PREF is present."

Otherwise, these would be equivalent:

TEL;PREF=0:...
TEL:...

And I don't think we want that because it would be surprising.

> other properties.

When it's the other way around, new values can be added with lower 
preferences, without modifying the other properties.

> Some use cases illustrating this point are: 

I can come up with use cases for the other way around too:

- The user has been given a new phone number but wishes to keep using the old 
one. (i.e. a consultant starting work at a new location)
- Likewise for email.

> unspecified value, which would be considered to be the lowest preference.
> On the opposite "0" would be the "highest preference", and it would be
> possible to assign PREF=0 disregarding other preferences (this could be, or
> could be not, a desired feature...)

The lowest preference is the absense of the PREF tag. Then it's the presence 
without a specific value. Then all other values. I see no problem with that.

> 2.  When a new preferred property is added, the other properties should be

Not true, see above.

My point is that the only difference between the two is colloquial usage. When 
I say "That's my top priority", I may also say "That's my number 1 priority." 
Low numbers are associated with higher priority in people's mind. So, while I 
agree that it might be nifty the other way around from an implementor's 
viewpoint, we really must follow the protocol users' expectations.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 27 Mar 2008 14:37:37 -0700

Like Simon points out, there's niftiness either way.  It's either easy  
to add new lower-priority items, or it's easy to add new higher- 
priority items.

I had been thinking about XMPP when I voted for lower=better, but my  
memory was faulty.  XMPP uses a priority of -127 to 128, where  
negative values means the server MUST NOT deliver messages.  (The  
usefulness of this in VCard might be to advertise an address that you  
might use to send from , while asking people not to use that address  
to send to.)  But that means that 0 and 1 are probably low priority  
and higher numbers are higher priority. RFC3921:

  		For message stanzas, the server SHOULD deliver the stanza to
            the highest-priority available resource (if the resource did
            not provide a value for the <priority/> element, the server
            SHOULD consider it to have provided a value of zero).  If  
two
            or more available resources have the same priority, the
            server MAY use some other rule (e.g., most recent connect
            time, most recent activity time, or highest availability as
            determined by some hierarchy of <show/> values) to choose
            between them or MAY deliver the message to all such
            resources.  However, the server MUST NOT deliver the stanza
            to an available resource with a negative priority; if the
            only available resource has a negative priority, the server
            SHOULD handle the message as if there were no available
            resources (defined below).  In addition, the server MUST NOT
            rewrite the 'to' attribute (i.e., it MUST leave it as
            <user@domain> rather than change it to <user@domain/
            resource>).

Lisa

---

From: "Peter K. Sheerin" <[email-masked]>
Date: Thu, 27 Mar 2008 23:33:23 -0700

But I have a problem with home, work, and mobile all being locations!

A mobile phone may be for work, home, or both. And why discriminate? If 
you have MOBILE, why not have FIXED or LANDLINE?

We need to think about the reason someone wants to see this information 
in a business card of a person they want to contact, and why we would 
want to put it in our contact information. And a phone should not be 
assumed to be one type (landline) just because of the absence of MOBILE.

MOBILE is not a location, it's a service type. WORK and HOME convey 
purpose more importantly than location, but do imply both.

And the comments about various address book applications not always 
mapping well to each other or vCard is key. The mapping is done poorly 
and differently because not enough thought has gone into contact 
exchange and what information people wish to share, and how they want to 
present it.

If vCard 4.0 tries to adapt its new structure to current practice for 
compatibility reasons, as point releases of HTML do, it will fail 
horribly, because 1) there is very little common ground from which to 
compile a consensus and 2) because very few contact applications do it well.

The goal of vCard 4.0 should be to get the format of the data done 
right--in a way that can concisely convey the actual data and intended 
semantics of what the person creating his or her digital identity wishes 
to convey.

While very simplistic vCard records may be easier to represent by using 
HOME or WORK as parameters in the fields in which they're allowed, this 
is true only for very simplistic vCards. Once you start creating a card 
that uses much more of the spec than the typical cell phone uses, you 
start to realize its limitations.

I think location/purpose should be conveyed by the use of groups, not a 
parameter.