Subject: Re: [VCARDDAV] New vcardrev draft

From: "Javier Godoy" <[email-masked]>
Date: Sat, 19 Jan 2008 04:09:52 -0200

Simon Perreault wrote

> Hi all,
> 
> The new vCard spec draft is out! Get it while it's hot!
> 
> So what we've done is merge 2425 and 2426. We've removed all the non-vcard 
> parts of 2425 since nothing else ever used it it seems. The structure of the 
> draft is what we'd like to get most feedback on. We'd like to keep the 
> structure pretty much stable starting with 01 while the real content of the 
> draft, i.e. the new vcard spec, is expected to be in flux a lot. But if you 
> look closely there are a few new goodies in this draft for you to enjoy

I think the draft is well structured.

However, I have found some minor issues I would like to state now (the 3rd is a doubt for which I haven't found answer within the vCard specification).

1. I see a normative reference to RFC 2234, but RFC 2234 is not used within the text, because ABNF points to I-D.crocker-rfc4234bis.

2. PRODID

It says:
>   Special notes:  Implementations SHOULD use a method such as that
>      specified for Formal Public Identifiers in ISO 9070 to assure that
>      the text value is unique.

This requirement stands for recommending identifier uniqueness, and
Formal Public Identifiers are only refered as an example (but any other unique identifier meets the requirement). 

Since there is a good discussion about global uniqueness in the RFC series (RFC 3406 "Uniform Resource Names Namespace Definition Mechanisms"), i think it could be used instead of ISO 9070. Besides, per RFC 3967, page 2, 3rd paragraph I understand the reference to ISO 9070 (or RFC 3406) should be informative instead of normative.

3. Even though vCards are intended for information about individual subjects, in some use-cases the "contact" is a corporation as a whole (instead of a single individual).

What is the correct way for creating a valid vCard for a corporate entity? (this is not a pathological question, it was raised while discussing the corrigenda for
IEEE standard 1484.12.1, which includes vCard content).

In my opinion, vCards about corporate entities should have empty Given Name, Additional Names and Honorific Prefixes. The Family Name and Honorific Suffixes components may be used, for instance N:Corporate Entities,,,,Inc.. If no suffix is used, it falls to N:Corporate Entities (trailing commas ommited). 

But RFC 2426 does not specify how to encode corporation names in the N property, therefore my rationale is no more than a guess. 

If there is a widely accepted solution, I would suggest including some paragraph in the new draft (maybe a "SHOULD", since it does not forbid any non-conforming practice).

4. I'm posting a separate mail concerning errata for RFC 2426.

Regards,

Roberto Javier Godoy
Universidad Nacional del Litoral
Santa Fe - Argentina
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/vcarddav

---

From: Cyrus Daboo <[email-masked]>
Date: Sat, 19 Jan 2008 10:55:32 -0500

Hi Javier,

--On January 19, 2008 4:09:52 AM -0200 Javier Godoy 
<[email-masked]> wrote:

> 3. Even though vCards are intended for information about individual
> subjects, in some use-cases the "contact" is a corporation as a whole
> (instead of a single individual).
>
> What is the correct way for creating a valid vCard for a corporate
> entity? (this is not a pathological question, it was raised while
> discussing the corrigenda for
> In my opinion, vCards about corporate entities should have empty Given
> Name, Additional Names and Honorific Prefixes. The Family Name and
> Honorific Suffixes components may be used, for instance N:Corporate
> Entities,,,,Inc.. If no suffix is used, it falls to N:Corporate Entities
> (trailing commas ommited).
>
> But RFC 2426 does not specify how to encode corporation names in the N
> property, therefore my rationale is no more than a guess.
>
> If there is a widely accepted solution, I would suggest including some
> paragraph in the new draft (maybe a "SHOULD", since it does not forbid
> any non-conforming practice).

Yes, I want to emphasize this point. The current spec does imply that 
vcards are meant for individuals only but they are increasing being used 
for corporations, and there is interest in also using them for general 
location/venue information (c.f the VVENUE spec for iCalendar which is an 
attempt to introduce a new component type for giving richer information 
about calendar event locations - there is a general feeling now that it 
might be better to simply embed vcard objects in iCalendar to do the same - 
plus that allows for richer information about attendees too).

So I would certainly like to see Javier's point above addressed in addition 
to any others that restrict use to "individuals". I'll see if I can come up 
with a list of what I think those are.

-- 
Cyrus Daboo

---

From: Mark Paterson <[email-masked]>
Date: Sat, 19 Jan 2008 15:34:39 -0500

Cyrus Daboo wrote:
> vcards are meant for individuals only but they are increasing being 
> used for corporations, and there is interest in also using them for 
> general location/venue information (c.f the VVENUE spec for iCalendar 
> which is an attempt to introduce a new component type for giving 
> richer information about calendar event locations - there is a general 
> feeling now that it might be better to simply embed vcard objects in 
> iCalendar to do the same - plus that allows for richer information 
> about attendees too).
Yep
>
> So I would certainly like to see Javier's point above addressed in 
> addition to any others that restrict use to "individuals". I'll see if 
> I can come up with a list of what I think those are.
Yep again :-)

Mark
-- 

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

---

From: Marc Blanchet <[email-masked]>
Date: Sun, 20 Jan 2008 12:44:31 -0500

Le 08-01-19 à 15:34, Mark Paterson a écrit :
>
> Cyrus Daboo wrote:
>>
>> Hi Javier,
>>
>> --On January 19, 2008 4:09:52 AM -0200 Javier Godoy <[email-masked] 
>> > wrote:
>>
>> Yes, I want to emphasize this point. The current spec does imply  
>> that vcards are meant for individuals only but they are increasing  
>> being used for corporations, and there is interest in also using  
>> them for general location/venue information (c.f the VVENUE spec  
>> for iCalendar which is an attempt to introduce a new component type  
>> for giving richer information about calendar event locations -  
>> there is a general feeling now that it might be better to simply  
>> embed vcard objects in iCalendar to do the same - plus that allows  
>> for richer information about attendees too).
> Yep

agreed too. let's make sure the wg provide the use case scenarios of  
non-individual vcards so that we can make the rev more useful to the  
community.

Marc.

>> addition to any others that restrict use to "individuals". I'll see  
>> if I can come up with a list of what I think those are.
> Yep again :-)
>
> Mark
> -- 
>
>

-----
IPv6 book: Migrating to IPv6, Wiley, 2006, http://www.ipv6book.ca

---

From: Simon Perreault <[email-masked]>
Date: Mon, 21 Jan 2008 09:41:05 -0500

On Saturday 19 January 2008 01:09:52 Javier Godoy wrote:
> 1. I see a normative reference to RFC 2234, but RFC 2234 is not used within
> the text, because ABNF points to I-D.crocker-rfc4234bis.

Fixed, thanks.

> Formal Public Identifiers are only refered as an example (but any other
> unique identifier meets the requirement).
>
> Since there is a good discussion about global uniqueness in the RFC series
> (RFC 3406 "Uniform Resource Names Namespace Definition Mechanisms"), i
> think it could be used instead of ISO 9070. Besides, per RFC 3967, page 2,
> 3rd paragraph I understand the reference to ISO 9070 (or RFC 3406) should
> be informative instead of normative.

Thanks for the suggestion, this seems to make sense.

> (trailing commas ommited).

Here is my opinion on this: the N property should not be mandatory. 
Corporations are not the only objects that we want to represent with vCards 
whose name can't be split in Given Name, Family Name, etc. components. I'm 
sure that there are naming schemes out there for *people* that don't fit that 
model.

So in my opinion, FN should be mandatory, and N should be present if FN fits 
that model. In the case of a corporation, FN doesn't fit the N model, but it 
does fit the ORG model (X.520 Organization Name and Organization Unit 
attributes) so you should use that instead. For example:

FN:ABC
ORG:ABC\, Inc.;North American Division;Marketing

Do we really need to encode somewhere the bit of knowledge that says "this 
vcard is not about a person, it is about a corporation"?

---

From: "Javier Godoy" <[email-masked]>
Date: Mon, 21 Jan 2008 18:47:52 -0200

----- Original Message ----- 
From: "Simon Perreault" <[email-masked]>
To: <[email-masked]>
Sent: Monday, January 21, 2008 12:41 PM
Subject: Re: [VCARDDAV] New vcardrev draft

> Here is my opinion on this: the N property should not be mandatory.

+1

> vcard is not about a person, it is about a corporation"?

I think it is necessary if the N property is made OPTIONAL.

For instance, the ABC example may refer to:
 - The Marketing department of ABC, Inc North American Division.
 - Some individual named "ABC", which belongs to that organization.

Of course, one could realize that from reading the values (because ABC is a 
weird name for a real people), but it would be better if that distinction 
could be performed programatically:

   ;whether the entity is and individual or an organization
   ;defaults to "individual" if not specified.
   kind-param = "KIND" "=" ("individual" | "org")

   ;For name="FN"
    ;This type MUST be included in a vCard object.
    param        = text-param | kind-param
         ; Text parameters and "kind" parameter allowed.

    value        = text-value

This way, each interpretation could be made explicit:

BEGIN:VCARD
VERSION:4.0
FN;kind=org:ABC
ORG:ABC\, Inc.;North American Division;Marketing
NOTE: The Marketing department of ABC\, Inc North American Division
END:VCARD

and

BEGIN:VCARD
VERSION:4.0
FN;kind=individual:ABC
ORG:ABC\, Inc.;North American Division;Marketing
NOTE: Some individual named "ABC"\, which belongs to the marketing
 department of ABC\, Inc North American Division.
END:VCARD

Regards,

Javier.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 21 Jan 2008 16:15:46 -0500

>    kind-param = "KIND" "=" ("individual" | "org")

This looks good, but why a parameter instead of a property? It really applies 
to the vCard as a whole, not just the FN property.

So let's say...

+0.5

---

From: "Javier Godoy" <[email-masked]>
Date: Mon, 21 Jan 2008 19:34:29 -0200

Well... I did not weighed the alternatives carefully, I just picked up one 
of them for communicating the idea.

As you stated it, a property makes sense because KIND relates to vCard as a 
whole. Particularly it is related to FN, N and ORG properties in the 
following way:
- if KIND is "individual", the structured name is given by the N property 
(if present). The ORG properties retains the meaning from vCard 3.0.
- if KIND is "org", the N field SHOULD NOT (MUST NOT?) be present, and the 
ORG property is redefined as you proposed it.

;For name="KIND"

  param        = ""
         ; No parameters allowed

  value = kind value

  kind-value = "individual" / "org"

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 22 Jan 2008 15:25:59 -0500

Hi Javier,

--On January 21, 2008 7:34:29 PM -0200 Javier Godoy 
<[email-masked]> wrote:

> Well... I did not weighed the alternatives carefully, I just picked up
> one of them for communicating the idea.
>
> As you stated it, a property makes sense because KIND relates to vCard as
> a whole. Particularly it is related to FN, N and ORG properties in the
> following way:
> - if KIND is "org", the N field SHOULD NOT (MUST NOT?) be present, and
> the ORG property is redefined as you proposed it.
>
>
> ;For name="KIND"
>
>   param        = ""
>          ; No parameters allowed
>
>   value = kind value
>

iCalendar has a CUTYPE parameter for ATTENDEE's defined as:

     cutypeparam        = "CUTYPE" "="
                         ("INDIVIDUAL"          ; An individual
                        / "GROUP"               ; A group of individuals
                        / "RESOURCE"            ; A physical resource
                        / "ROOM"                ; A room resource
                        / "UNKNOWN"             ; Otherwise not known
                        / x-name                ; Experimental type
                        / iana-token)           ; Other IANA registered

I think we need to include some of those values in the vCard equivalent. 
Certainly 'GROUP' - we have discussed a little befiore about how 
groups/distribution lists should be represented in vCard and having a KIND 
property that identifies vCards as groups would be useful.

On resources - CalConnect has been doing some work on trying to see what 
level of resource information is needed for calendaring purposes (e.g. room 
capacity is an important piece of information about a room that needs to be 
used during scheduling). Whilst I don't think we should explicitly consider 
resource related properties for the base spec, I think it is something that 
may happen as an extension later.

-- 
Cyrus Daboo

---

From: "Javier Godoy" <[email-masked]>
Date: Wed, 23 Jan 2008 10:59:26 -0200

Hi Cyrus,

On Tuesday, January 22, 2008 6:25 PM Cyrus Daboo wrote,

> property that identifies vCards as groups would be useful.

As we were discussing, KIND=ORG was intended for vCards representing the 
organization itself.
Do you propose KIND=GROUP *instead of* KIND=ORG or as an alternative for 
vCards representing something else (such as a distribution list) ?

Besides, (x-name / iana-token) should be considered too. Otherwise it is too 
restrictive.

> level of resource information is needed for calendaring purposes (e.g. 
> room capacity is an important piece of information about a room that needs 
> to be used during scheduling). Whilst I don't think we should explicitly 
> consider resource related properties for the base spec, I think it is 
> something that may happen as an extension later.
>

I want to emphasize about KIND restricting other properties or altering 
their semantics (as in the "org" vs. "individual" case).
With KIND understood in that way, an extension might define properties to be 
used with a particular KIND of vCards.
(e.g. room capacity or subscribe/unsubscribe email types).