Subject: [VCARDDAV] Miscellaneous comments

From: "Javier Godoy" <[email-masked]>
Date: Sun, 18 Jul 2010 09:12:40 -0300

1. In draft version 12 the property TYPE was splitted into TYPE (home/work)
and FMTTYPE (content type). However, there are some examples using TYPE
instead of FMTTYPE:
 Section 6.4.1 (TYPE=text;TYPE=voice)
 Section 6.7.5 (TYPE=audio/basic)
 Section 6.8.2 (TYPE=application/pgp-keys)

2. NAME. "The NAME property is used to convey the display name of the entity
to which the directory information pertains"

Shouldn't the display name be choosen by the implementation? There is already
a mandatory FN property from which the display name could be derived.
FN accepts values in multiple languages, while NAME doesn't (that is relevant
if the vCard instance has a FN value for the user-preferred language, while
NAME is written in another language/script)

For instance, given the example provided in the draft
 NAME:Babs Jensen's Contact Information
and assuming that
 FN:Babs Jensen

I would prefer to present the user with "Información de contacto para Babs
Jensen" (spanish). The example is even most interesting if NAME is not written
in the latin alphabet (the user will probably find the "display name" is
unreadable)

I remember this issue was discussed before, but I cannot find the rationale
for not removing the NAME property.

3. RELATED, DDAY, BDAY value may be uri or text, but LANGUAGE parameter is not
allowed when they are "text", thus alternative values in different languages
cannot be specified. I think LANGUAGE should be allowed, at least for the
RELATED property.

4. I notice the restriction of "work" and "home" being used only when the KIND
property is absent or its value is "individual" was removed in draft-12. The
meaning of the "home" type is undefined when KIND is not "individual" because
"the home value implies that the property is related to an individual's
personal life". I would recommend rephrasing the requirement as a SHOULD NOT
instead of removing it, or providing a broader definition of "home" for
locations, groups and organizations, so that implementations can use it
consistently.

Best Regards

Javier

---

From: Markus Lorenz <[email-masked]>
Date: Sun, 18 Jul 2010 16:18:27 +0200

> for not removing the NAME property.

I'm also confused about the purpose of the NAME property. I think it's
not useful to let the creator of a vCard file define the value with
which the contact information is displayed to the user by his address
book. But I'm not sure if that's what is meant. Every address book I
know let's the user specify the way it presents the contacts, mostly by
letting the user define which information is display in which column of
the list view.

Maybe the NAME property is more like an explanation of the vCards
content to the user? For example when he first opens the file. You could
give some information about what is included in the file, like "Babs
Jensen's very private contact details", "Babs Jensen's contact details
at Example, Inc.", or "VCARDDAV WG mailing list". So you don't have to
understand this from the data inside the vCard.

But I'm just guessing. If someone knows what the NAME property should be
used for, I would like to know.

> locations, groups and organizations, so that implementations can use it

I remember Cyrus bringing up this topic:

Am 31.05.2010 19:38, schrieb Cyrus Daboo:
> * Section 5.6: The restriction on "work" and "home" usage related to
> presence and value of "KIND" seems a little odd. What is more, it does
> not use RFC2119 key words so it is not clear if this is a "real"
> requirement or not. This needs to be better defined, or the
> restriction should be removed.

I suggested to remove the restrictions. From my point of view it was
about a larger inconsistency of explicit restrictions. The purpose of
the restriction was to only use "home" and "work" with individuals. But
the restriction lacks completeness by just restricting it to the absence
of KIND or in case of presence to its value being "individual". You
could still use "home" and "work" for vCards by simply not using the
KIND property at all. Furthermore I think if the specification defines
such restriction it should do so for at best every similar case. It
would need restriction for type-values such as "sibling", "spouse", etc.
which also only make sense if the vCard represents an individual. But
then you have much more problems, as "agent" can be used "for a person
who may sometimes act on behalf of the individual or resource associated
with the vCard". So it may also apply to organisations and groups and
would need a different restriction than every other type-param-related
value.

I think this would become much to complex and incomplete. Thus I
favoured the removal of the restriction.

Regards

Markus

---

From: Simon Perreault <[email-masked]>
Date: Mon, 19 Jul 2010 08:35:36 -0400

> Section 6.4.1 (TYPE=text;TYPE=voice)

That's not supposed to be FMTTYPE.

> Section 6.8.2 (TYPE=application/pgp-keys)

Good catch! Thanks.

> for not removing the NAME property.

We inherited NAME from vCard 3.0 and I don't think its removal has ever
been discussed.

I, for one, have no clue how it could be useful.

Does anyone know how it is being used currently?

> cannot be specified. I think LANGUAGE should be allowed, at least for the

I think you're right. I changed the ABNF so that it is allowed for all
three of them when using a text value.

> locations, groups and organizations, so that implementations can use it

I'm not too sure what to do here. If people care about this, speak up.
Otherwise we'll stay with what we have.

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: "Javier Godoy" <[email-masked]>
Date: Mon, 19 Jul 2010 11:41:06 -0300

>That's not supposed to be FMTTYPE.

Oops... I don't know why I include it with the other occurrences. Sorry.

>> 2. NAME. "The NAME property is used to convey the display name of the
>> entity to which the directory information pertains"
>>
>> Shouldn't the display name be choosen by the implementation? There is
>> already a mandatory FN property from which the display name could be 
>> derived.
>>
>We inherited NAME from vCard 3.0

NAME is inherited from RFC 2425, thus it should have been intended as a 
minimal profile-independent representation of the display name (not only for 
vCard but also for other "directory profiles" that never existed).

>and I don't think its removal has ever been discussed.

I agree it seems we never discussed it, though it was proposed
http://www.vcarddav.org/issues.xhtml#176
"The NAME (RFC2425) property is redundant with FN (RFC2426)"
Closed without action on 2008-06-09

And yes, I said "+1" to closing it, but I cannot remember why... now I think 
we should do something about it.

Best Regards

Javier

---

From: Daisuke Miyakawa <[email-masked]>
Date: Tue, 20 Jul 2010 07:05:56 +0900

Hi,

2010/7/19 Javier Godoy <[email-masked]>
> And yes, I said "+1" to closing it, but I cannot remember why... now I
> think we should do something about it.
>

+1 to do something. I prefer removing it, but there's no strong preference.

I think one problem is that the name is too generic. If NAME is "a minimal
profile-independent representation of the display name", the name should not
be
NAME but SHORT-NAME, SN, or something more appropriate. We don't need to
inherit that name from vCard 3.0, but its intention.

Thanks,

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

-- 
Daisuke Miyakawa (宮川大輔)
[email-masked]

---

From: Markus Lorenz <[email-masked]>
Date: Tue, 20 Jul 2010 00:18:34 +0200

Am 20.07.2010 00:05, schrieb Daisuke Miyakawa:
> Hi,
> 
> 2010/7/19 Javier Godoy <[email-masked]
> <mailto:[email-masked]>>
> 
>             already a mandatory FN property from which the display name
>             could be derived.
> 
>     NAME is inherited from RFC 2425, thus it should have been intended
>     as a minimal profile-independent representation of the display name
>     (not only for vCard but also for other "directory profiles" that
>     never existed).
> 
> 
>     And yes, I said "+1" to closing it, but I cannot remember why... now
>     I think we should do something about it.
> 
> 
> I think one problem is that the name is too generic. If NAME is "a
> minimal profile-independent representation of the display name", the
> name should not be

+1 to remove it. If no one knows how to use it, it can't bring any benefit.

What could a SHORT-NAME be used for? I still can't see the intention.
Was the plan to get at least some useful information out of a
mime-directory format even if you don't understand the specific format?
Are there other mime-directory formats than vCard?

---

From: Tantek Çelik <[email-masked]>
Date: Mon, 19 Jul 2010 15:29:38 -0700

> Are there other mime-directory formats than vCard?

+1 remove it.

NAME is defined in 2445 as

2.1.2 NAME Type

   If the NAME type is present, then its value is the displayable,
   presentation text associated with the **source** for the vCard, as
   specified in the SOURCE type.

**emphasis** added.

The source is not the vCard itself.

Thus repurposing NAME in vCard4 to mean display name for a vCard
itself is a backwards incompatible change (using an existing
vocabulary term to mean something new) and is thus very much a bad
idea.

Best to just remove it.

Thanks,

Tantek

-- 
http://tantek.com/
I made an HTML5 tutorial video/book! http://tantek.com/html5