Archived here for reference. - Tantek

Much of this feedback has been incorporated into vCard draft 15.

See the vCard4 page for the latest draft, reviews, issues etc.

vCard4 draft 13 review

intro

As of vCard4 draft 13:

In many ways vCard4 breaks backward compatibility with vCard3.

In addition, vCard4 appears to be evolving in a different direction from (and in some way incompatibly with) the nascent Portable Contacts standard, which itself evolved incrementally and fairly cleanly/compatibly from hCard which was based on vCard3.

This page documents known vCard4 issues from our analysis of the work in progress, in comparison to hCard/vCard3 and in comparison to Portable Contacts.

Our goal is to encourage vCard4 to converge with (or at least become compatible with) Portable Contacts in order to avoid a schism in identity/profile formats on the web.

— Tantek 17:50, 14 August 2010 (PDT)

draft 13

vCard4 draft 13:

• http://www.ietf.org/internet-drafts/draft-ietf-vcarddav-vcardrev-13.txt

high level proposal for improving vCard4

Based on a thorough section by section review, the changes and feedback I have for vCard4 draft 13 fall into a general outline as follows:

1. Explicitly state as a goal to have vCard4 be reasonably backward compatible (i.e. with current implementations) of vCard3, both syntactically, and from a schema perspective (e.g. don't mess with structure of properties like N). This kind of practical backward compat enabled publishers to start posting vCard3 even when most consuming applications still only supported vCard2.1. The presence of vCard3 data then encouraged consuming applications over time to adopt it as well. I'd like to see the same successful adoption occur for vCard4.

2. Keep the vCard4 core set of properties down to a minimum that has been well established either in:

• Popular address book programs (e.g. ANNIVERSARY)
• Current well adopted mature RFCs (e.g. IMPP)
• Common additions by OpenID / Portable Contacts that have seen adoption (e.g. SEX/GENDER, LANGUAGE, ACCOUNTS)

I believe this too will encourage better vCard4 adoption.

3. Drop other new vCard4 properties from the core and if they seem to make sense, move them to extension specifications instead where they can prove themselves out, e.g.:

• KIND - vCard should not expand scope like this. For new kinds of objects new vThings should be created, and can be, outside the vCard spec.
• XML - bad idea. Don't violate DRY. This encourages breaking interop by potentially allowing implementations to look only at the XML or at the actual properties in a vCard. Same on the publishing side.

Potential Extensions:

• genealogy extension (BIRTH location, DEATH location, DDAY datetime of death, maybe more from GEDCOM)
• social networking extension (MEMBER, RELATED, maybe more from PoCo)
• calendar contact extension (FBURL, CALADRURI, CALURI)

issues

This is a rough list of issues that is incomplete.

Please see the section by section review below that has both a much more detailed and comprehensive coverage of the problems in the current vCard4 draft13 with suggestions for improvement too.

divergence from vCard3

• N property
  • dropped 'additional-name's - this makes it non-backward compat with vCard3

FIXED in draft 15.

divergence from Portable Contacts

• SEX (in vCard4) vs GENDER (in PoCo)
  • different property names and values that don't necessarily map
  • this might actually be ok if we document how to keep and use *both* properties, each for a specific purpose, that is:
    • SEX - biological value (enum: (M)ale, (F)emale, (O)ther, (N)one)
    • GENDER - gender identity value (a string)

see also 2009 Joseph Smarr post

Joseph Smarr wrote about Portable Contacts and vCardDAV (IETF 74) on his blog in March of 2009 also covering challenges/issues around vCard4 vs PoCo.

new properties not used by address books

New properties in vCard4 were supposed to have some basis in existing address book features. The following properties do not appear to meet this criteria:

• DDAY - date of death
  • opinion: +0 - this is parallel to the existing BDAY field, and could help solve longstanding UI problems with address book entries for people who have passed away (and social network profiles as well that are memorialized). mostly harmless, may be interesting to include. I'm ok with this property going into the public last call and seeing what implementations do with it, but want to point out that there is no basis for inclusion based on existing address book features / interfaces. Tantek 18:36, 14 August 2010 (PDT)
• BIRTH - birth location
  • opinion: -1 - this seems like a bad idea. many sites use birth location as a pseudo-security question/answer. What is the use case for keeping track of other people's birth locations in your address book? (nevermind that this property is also poorly worded - something like BLOCATION - reusing B prefix from BDAY and LOCATION property from iCalendar - would be better) vCard4 should drop this property. Tantek 18:36, 14 August 2010 (PDT)
• DEATH - death location (this is not their grave location, but rather the place they died)
  • opinion: -1 - again, seems like a bad idea. What is the use case for keeping track of other people's death locations in your address book? (nevermind that this property is also poorly worded - something like DLOCATION - reusing D prefix from DDAY and LOCATION property from iCalendar - would be better) vCard4 should drop this property. Tantek 18:36, 14 August 2010 (PDT)

other properties and problems

• KIND property - this seems like the wrong way to add new data types. vCard4 appears to be extended to represent (in addition to people and organizations)
  • a group (of vCard items)
  • a "thing" (like a conference room projector
  • opinion: -1 - this seems like a bad way to extend type information. shoehorning all types of objects into being "vCards" seems like a really bad design decision. the MIME/Content type mechanism should be used instead. e.g. create a vGroup and vThing if necessary instead. it is also unnecessary for differentiating a person vs organization - that is organization is already inferred by FN == ORG. thus vCard4 should drop this property. Tantek 18:36, 14 August 2010 (PDT)

• XML - this seems like a total hack and encourages DRY violation.

other new properties that should go into extension instead

The following new properties should not be in core vCard and should be considered for extensions instead.

Social Networking extension:

• MEMBER - related to GROUPs
• RELATED

Synchronization extension:

• CLIENTPIDMAP
• PID paramater

Calendar contact extension:

• FBURL
• CALADRURI
• CALURI

draft 13 section by section review

section 3.1

3.1. Line Delimiting and Folding

Editorial comment:

Examples use "DESCRIPTION" property - which is not in vCard.

Suggestion: use "NOTE" property instead.

FIXED in draft 14.

section 4.1

4.1. TEXT

Editorial comment:

Examples use "DESCRIPTION" property - which is not in vCard.

Suggestion: use "NOTE" property instead.

FIXED in draft 14.

section 4.4

4.4. BOOLEAN

Editorial comment:

TYPO:

"boolean": The "boolean" value type is used to express boolen values.

Should be:

"boolean": The "boolean" value type is used to express boolean values.

FIXED in draft 14.

section 5.1

5.1. LANGUAGE

Editorial comment:

Please provide a simple example use of the LANGUAGE property parameter, e.g.

ROLE;LANGUAGE=en:teacher
ROLE;LANGUAGE=tr:hoca

See below ALTID property parameter for how to associate these two ROLE properties as being alternatives for the same property value.

section 5.4

5.4. PREF

Preferred value between 1 and 100 seems a bit arbitrary.

What is the use-case for this?

Also, from a synchronization perspective, picking absolute numbers for indicating preference would seem to make little sense, as the values themselves only make sense relative to other values.

Suggestion: drop this property parameter - it seems like a bad design, and unnecessary.

UNCHANGED - need to check email threads.

section 5.5

5.5. ALTID

This seems like a good mechanism for publishing multilingual alternatives on a per-property basis.

I'm interested to see how implementations support this, but overall optimistic about its potential.

NO CHANGES NEEDED.

section 5.6

5.6. PID

This definition is very short and abstract and is not very useful out of context as it is. There should be at least one concrete example, otherwise move this section to "Section 7" since that's where it says there are "more details on its usage".

My recommendation just reading its description would be to drop this new property parameter.

NO CHANGES MADE, CONSIDER AS PART OF SYNC ISSUE.

section 5.7

5.7. TYPE

No specific comments. General comment - type seems like a catch-all of sorts - not very well designed. Some of the uses are quite flawed. E.g. the notions of "work" and "home" have not worked well in practice. In particular "work" doesn't make much sense given that there is an "ORG" property with which any work email/phone/address should be associated, rather than just implied.

NO CHANGES MADE, MAY STILL BE AN ISSUE.

section 5.8

5.8. CALSCALE

In practice have there been any address books that implement a CALSCALE *other* than the specific default of "gregorian"?

I think this should be dropped until there is at least some evidence produced that there is address book software out there that bothers to even try to support part of the existing vCard3 spec and that provides a non-gregorian calendar scale user interface.

Recommended we drop this property parameter.

PARAMETER KEPT. HOWEVER, PERHAPS IT IS OK TO HAVE A "MUST IGNORE" FOR NON-GREGORIAN VALUES.

section 5.9

5.9. SORT-AS

Having this as a property *parameter* seems like an improvement over the previous 'sort-string' property which I've not really seen used in the wild.

NO CHANGE NEEDED.

section 5.10

5.10. GEO

This makes sense as an addition/refinement to the ADR property, to assign a specific lat/long to a particular address, especially when multiple addresses are involved. hCard backward compat will be a little interesting but I'm sure we can figure it out.

NO CHANGE NEEDED.

section 5.11

5.11. TZ

Makes sense in the same way as GEO parameter.

NO CHANGE NEEDED.

section 5.12

5.12. VERSION

I don't think this is necessary, and in fact encourage future breaking as well as pushing the burden of handling multiple versions of a property onto implementations.

Let's NOT add this, and instead work hard to:

• specify forward compatible parsing rules (i.e. ignore any params you don't recognize)
• keep properties backward compatible in general, just adding detail params (like TZ and GEO) where it progressively enhances the property without breaking any existing semantics.

THIS HAS BEEN DROPPED ACCORDINGLY! (not sure if it was dropped in 14 or 15)

section 5.13

5.13. FMTTYPE

This seems like a reasonable property parameter addition for binary value types.

THIS HAS BEEN DROPPED AS IT IS NO LONGER NECESSARY.

section 6.

The current cardinality shorthands are cryptic, please use something more typically readable, e.g.:

• (1) - exactly one instance must be present
• (1-n) - at least one instance must be present
• (0-1) - at most one instance may be present
• (0-n) - any number of instances may be present

section 6.1

6.1. General Properties

no content.

NO CHANGE NEEDED.

section 6.1.1. BEGIN

no comment. seems compatible.

NO CHANGE NEEDED.

section 6.1.2. END

no comment. seems compatible.

NO CHANGE NEEDED.

section 6.1.3. SOURCE

6.1.3. SOURCE

no comment. seems compatible.

NO CHANGE NEEDED.

section 6.1.4. KIND

6.1.4. KIND

I think this is a really bad idea.

While existing usage of vCard3 for both people and organizations is something we have to support moving forward, I really don't want to see this expanded further (with the possible exception of a named location - which we've found utility for with hCard as well).

Object to: group, thing

Groups should not just be a form of vCard. And thing? I think both of these are horrible abuse of existing vCard semantics.

If you want to add new objects, let's add new objects like a vGroup or a vThing etc. But please let's not bloat vCard with these things.

THING REMOVED. GROUP REMAINS. GROUP SHOULD BE DROPPED AND PUSHED TO BE AN (OR PART OF AN) EXTENSION.

section 6.1.5. XML

6.1.5. XML

I think this is totally unnecessary and a bad idea because it violates DRY.

Seriously? An XML property that represents all the rest of the data in the same vCard? Ugh. Which do you trust? The XML or the actual vCard properties?

SPEC CLARIFIED TO INDICATE NON-VCARD DATA. STILL A HORRIBLE EXTENSION POINT AND SHOULD BE DROPPED.

section 6.2. Identification Properties

6.2. Identification Properties

no comment on intro.

section 6.2.1. FN

6.2.1. FN

The possibility of having multiple FNs is introduced, which seems both reasonable and useful in practice from personal experience with developing address book code.

However, there is no advice/guidance given regarding how to treat multiple FNs and thus I fear this new capability may introduce some interoperability problems.

I suggest some wording and examples clarifying what the purpose may be for multiple FNs, e.g. multiple ways of displaying a name (perhaps some with additional names, some without), or multiple ways (character sets? languages?) to write a name (e.g. a Japanese name may be written with Kanji or transliterated Hiragana).

ISSUE STILL EXISTS IN DRAFT 15

section 6.2.2. N

Not requiring an N is a big improvement.

The new N structure is different enough from vCard3 to be problematic.

Minor change:

• Use "family name" as a primary (perhaps with "also known as surname") since vCard3 referred to "family name", and hCard adopted that wording in the subproperty "family-name".

Major changes:

• Consider allowing multiple family names. In my experience giving microformats workshops around the world, I have found that there are languages/cultures that actually use multiple family names in practice, e.g. in Spain.
• Restore the "additional name" structural component that was in vCard3 for better schematic compatibility.
• Am ok with multiple Given Names as that does reflect common practice.

THIS SECTION HAS ACCEPTED AND RESOLVED ALL ISSUES AS OF DRAFT 15.

section 6.2.3. NICKNAME

6.2.3. NICKNAME "belonging to a person, place, or thing" - avoid such itemizations of what a vCard could represent as it will be (is) a maintenance nightmare.

Use "belonging to the object the vCard represents" instead.

THIS SECTION HAS ACCEPTED AND RESOLVED ALL ISSUES AS OF DRAFT 15.

section 6.2.4. PHOTO

6.2.4. PHOTO

Seems about the same as vCard3.

Provide a data: URI example as implementations do seem to support that, and note how the data URI may contain the content/MIME-type and thus that can be used instead of the FMTTYPE param. For reference:

http://en.wikipedia.org/wiki/Data_URI_scheme

data:[<MIME-type>][;charset=<encoding>][;base64],<data>

THIS SECTION HAS ACCEPTED AND RESOLVED ALL ISSUES AS OF DRAFT 15.

section 6.2.5. BDAY

6.2.5. BDAY

The expansion of permitting month-day only or year only are both very good. Would also suggest permitting year-month as well, e.g. 1996-04

ISSUE STILL EXISTS IN DRAFT 15

section 6.2.6. DDAY

6.2.6. DDAY

No evidence of address books that support this property have been presented.

This would make more sense as part of a "genealogy" extension to vCard4 rather than part of the core.

That being said:

I for one have personally found it there to be a user-interface challenge in managing the contact information in an address book of people that have passed away.

While some may suggest simply deleting such entries, I don't think that reflects that necessary history/attachment/notes of common usage of such address book entries.

However, given that address books are often used to "auto-fill/suggest" things like email program "To:" fields etc. (e.g. Mail.app on MacOSX with the Address Book app), it makes sense to provide some way to mark a contact as deceased so that they don't show up in auto-fill/suggest user interfaces.

A DDAY property could serve as a proxy for such a "deceased" checkbox on an entry.

It should explicitly allow the same data type as BDAY, and provide examples accordingly.

Thus while there is no existing evidence of address books that provide this kind of user interface feature, I believe this may be an instance where it makes sense to add this field, given the *address book* use cases documented above.

Naming: while the name "DDAY" I'm sure appeals as a parallel to the BDAY property, the term DDay already has a widely known/used historical semantic and thus it may unnecessarily cause confusion.

I suggest instead the term "DECEASED" as that is much more indicative of the meaning (less cryptic).

"Deceased" was also the original suggestion provided on the microformats page for this property: http://microformats.org/wiki/vcard-suggestions#Deceased

In addition, consider permitting a simple "Y" value to indicate that the person is deceased but no precise date or even year is known. This would enable modeling of a simple checkbox interface to indicate that someone has passed away without burdening the user with entering a date or year.

I would also be ok postponing this property to a "genealogy" extension.

PRIMARY ISSUE RESOLVED, PROPERTY DROPPED AS OF DRAFT 15.

section 6.2.7. BIRTH

6.2.7. BIRTH

No evidence of address books that support this property have been presented.

This would make more sense as part of a "genealogy" extension to vCard4 rather than part of the core.

And this is a horrible property name to boot for a "location".

Recommendation: drop from vCard4.

PRIMARY ISSUE RESOLVED, PROPERTY DROPPED AS OF DRAFT 15.

section 6.2.8. DEATH

6.2.8. DEATH

No evidence of address books that support this property have been presented.

This would make more sense as part of a "genealogy" extension to vCard4 rather than part of the core.

And this is a horrible property name to boot for a "location".

Recommendation: drop from vCard4.

PRIMARY ISSUE RESOLVED, PROPERTY DROPPED AS OF DRAFT 15.

section 6.2.9. ANNIVERSARY

6.2.9. ANNIVERSARY

I have seen "anniversary" as a field in address book application user interfaces (anecdotal, off the top of my head), and thus this seems like a reasonable addition to vCard.

Should allow same date-and-or-time data type as BDAY, including year-only, month-day, year-month etc.

ISSUE STILL EXISTS IN DRAFT 15

section 6.2.10. SEX

6.2.10. SEX

It's a good idea to add the general idea of this feature to vCard.

The specific implementation is roughly close but does leave something to be desired.

The current draft has: The value 0 stands for "not known", 1 stands for "male", 2 stands for "female", and 9 stands for "not applicable".

While this discretization into 4 values makes sense, and if I'm not mistaken, is based on the work in the microformats community:

http://microformats.org/wiki/gender-brainstorming

The translation to opaque numerical values is a negative.

Instead use the single letter prefixes of the English terms as noted in the microformats page:

sex: M(ale) F(emale) O(ther) N(one or Not applicable)

This reflects common use in both social networking sites which permit M or F (see microformats research at above URLs), as well as previous formats that have worked on representing this information, e.g. openid.sreg.gender permits "M" for male, "F" for female.

Finally, sex without gender is problematic from a gender identity perspective and discriminatory against a marginalized minority.

Thus for the sake of allowing a more flexible representation that avoids such marginalization, an additional property should be introduced:

GENDER-IDENTITY

which takes a string that the user can assign any label.

Alternatively (and preferably), rather than the SEX property, introduce a new *structured* property:

GENDER

Purpose: To specify the components of the sex and gender identity of the object the vCard represents.

Value type: A single structured text value. Each component can have a single value.

Cardinality: (0-1)

Special notes: The structured property value corresponds, in sequence, to the sex (biological), and (optional) gender identity. The text components are each optional and separated by the SEMI-COLON character (ASCII decimal 59).

Sex component: The value M stands for "male", F stands for "female", O stands for "other", N stands for "none or not applicable", U stands for "unknown".

Gender identity component: a single text value.

Gender property examples:

GENDER:M 
GENDER:F 
GENDER:M;Fellow 
GENDER:F;Bird 
GENDER:O;intersex 
GENDER:;queer 

When you might you see 'N':

...
FN:IETF
ORG:IETF
KIND:org
GENDER:N
...

Notes:

The examples of "Fellow" and "Bird" are taken from the actual user interface of Digg, and see Wikipedia for intersex.

ISSUE PARTIALLY RESOLVED AS OF DRAFT 15.

STILL NEED COMPLETE TWO PART GENDER PROPERTY.

section 6.3. Delivery Addressing Properties

6.3. Delivery Addressing Properties

No comment on intro section.

section 6.3.1. ADR

6.3.1. ADR

I think it is good that the ADR structure has been maintained from vCard3.

In practice however, the user interfaces for entering/editing address information do not correspond to the vCard ADR structure and have thus posed challenges for mapping user data to vCard ADR subproperties.

I would recommend:

• deprecate post office box (keep it in the structure, but suggest an empty string)
• deprecate extended address (keep it in the structure, but suggest an empty string)
• encourage multiline (lines delimited with the COMMA character as the draft suggests) in the "street address" subproperty, with the first line being the actual street address with number and name of street, or if there is none (e.g. in the case of a PO BOX only address), simply include the replacement that you would on a mailing label, corresponding to the "address line 1" field that we see on so many forms.

THIS SECTION HAS ACCEPTED AND HAS SUFFICIENTLY RESOLVED THESE ISSUES AS OF DRAFT 15.

section 6.3.2. LABEL

6.3.2. LABEL

Seems unchanged from vCard3. Better to deprecate the LABEL property and add a LABEL parameter to the ADR property.

PRIMARY ISSUE RESOLVED, PROPERTY DROPPED AS OF DRAFT 15.

section 6.4. Communications Properties

6.4. Communications Properties

Intro sentence needs to be reworded - total awkward run-on.

THIS SECTION HAS ACCEPTED AND RESOLVED ALL ISSUES AS OF DRAFT 15.

section 6.4.1. TEL

6.4.1. TEL

The change to a URI makes sense on the surface but does not from a compat perspective.

Rather, leave TEL alone (as was in vCard3), and suggest using the URI property for TEL URIs.

Adjusting/updating the set of TYPEs for a TEL seems reasonable.

The notion of PREF is badly outdated and needs to be rethought *across* different types of communications, not just among instances of a specific type of communication (e.g. what is preferred: phone vs email, not just which phone number).

ALL ISSUES BUT PREF RESOLVED AS OF DRAFT 15.

section 6.4.2. EMAIL

6.4.2. EMAIL

Same comment about PREF. Good to see the useless TYPE param dropped.

PREF ISSUE REMAINS IN DRAFT 15.

section 6.4.3. IMPP

6.4.3. IMPP

Seems like a reasonable addition, and good example of an extension being tried for a new feature before inclusion in the core. A lesson to be applied to the genealogy properties that have been proposed.

ALL STATED ISSUES RESOLVED BUT PREF ISSUE REMAINS IN DRAFT 15.

section 6.4.4. LANG

6.4.4. LANG

This also seems like a reasonable addition, based on the presence of a similar property in OpenID Attribute Exchange: openid.sreg.language

I recommend using the full property name LANGUAGE instead, per re-use from OpenID.

The term "lang" is already a commonly used HTML attribute that appears to be similar in syntax (e.g. takes a single language-tag value) but is quite different in meaning, in that it indicates the language of the text being marked up, rather than a preference for communication.

ISSUE STILL EXISTS IN DRAFT 15.

section 6.5. Geographical Properties

6.5. Geographical Properties

This is a good intro clarifying what the properties apply to. (has been a source of confusion in vCard3 in the past)

section 6.5.1. TZ

6.5.1. TZ

Looks good in general, compatible with vCard3.

A bit concerned about the forward-looking references to potential efforts - those don't belong in a specification.

Cardinality should be (0-1) - how can a vCard object be in multiple time zones?

ISSUES STILL EXIST IN DRAFT 15.

section 6.5.2. GEO

6.5.2. GEO

Looks good in general, compatible with vCard3.

Cardinality should be (0-1) - how can a vCard object be in multiple locations?

ISSUE STILL EXISTS IN DRAFT 15.

section 6.6. Organizational Properties

6.6. Organizational Properties

Minor typo in intro sentence. should be:

These properties are concerned with information associated with characteristics of the organization or organizational units of the object that the vCard represents.

section 6.6.1. TITLE

6.6.1. TITLE

Seems fine, compatible with vCard3.

section 6.6.2. ROLE

6.6.2. ROLE

Seems fine, compatible with vCard3.

section 6.6.3. LOGO

6.6.3. LOGO

In practice this property has caused confusion with respect to the PHOTO property. Which should you use when?

Also, why is this included in the Organizational Properties section rather than alongside PHOTO?

If there is a more specific semantic to be applied, e.g. this is the LOGO for the organization that the person the vCard object represents works for, then that specific semantic should be explicitly mentioned.

Recommend also providing an example with both LOGO and PHOTO that clearly demonstrates the proper/intended use of each.

ISSUES STILL EXIST IN DRAFT 15.

section 6.6.4. ORG

6.6.4. ORG

Seems fine, compatible with vCard3.

section 6.6.5. MEMBER

6.6.5. MEMBER

Groups should not be in vCard but rather should be in another spec/schema.

Recommend drop this property.

ISSUE STILL EXISTS IN DRAFT 15.

section 6.6.6. RELATED

6.6.6. RELATED

This is an interesting idea that merits exploration as an extension, not part of vCard core.

Also, rather than inventing another taxonomy of relationship, consider simply re-using by reference the XFN 1.1 taxonomy:

http://gmpg.org/xfn/11

And then proposing or adding support for additional terms on the XFN brainstorming page.

http://microformats.org/wiki/xfn-brainstorming

ISSUES MOSTLY RESOLVED IN DRAFT 15.

section 6.7. Explanatory Properties

Sounds more like a miscellaneous section.

Organizationally I'm not sure this makes much sense. Most of these apply to the vCard object as a whole and are perhaps identity related and could be grouped into section 6.2.

ISSUE STILL EXISTS IN DRAFT 15 BUT IS LARGELY EDITORIAL.

section 6.7.1. CATEGORIES

6.7.1. CATEGORIES

Nice to see this section/semantic upgraded to mention tags.

Suggestion: explicitly allow URIs as text values to represent specifically scoped tags, with the last path segment of the URI representing the "keyword" of the tag, as specified by the rel-tag specification http://microformats.org/wiki/rel-tag

ISSUE STILL EXISTS IN DRAFT 15 BUT IS ACCEPTABLE TO PUNT.

There was some mailing list traffic on this that we can look up and consider following up to.

Will raise again noting the similarity to TEL's addition of URI values.

section 6.7.2. NOTE

Seems fine, compatible with vCard3.

section 6.7.3. PRODID

This seems fine. In practice this is not used much.

section 6.7.4. REV

6.7.4. REV

Seems fine, compatible with vCard3.

Would be nice to allow whole dates as well (without time).

ISSUE STILL EXISTS IN DRAFT 15 BUT IS ACCEPTABLE TO PUNT.

In practice this property is not used much by authors (or rather, we have little or any documented evidence of such), thus we can delay extending it until we have supporting evidence.

section 6.7.5. SOUND

6.7.5. SOUND

Seems fine, compatible with vCard3.

section 6.7.6. UID

6.7.6. UID

Seems fine, compatible with vCard3. Nice improvement to use URI.

section 6.7.7. CLIENTPIDMAP

6.7.7. CLIENTPIDMAP

Lacking an example with a use-case, this property should be dropped.

This was later clarified as being part of how versioning of property values with PIDs works.

section 6.7.8. URL

6.7.8. URL

Seems fine, compatible with vCard3.

new property ACCOUNT

Related suggestion:

PoCo has the notion of an "account" property which is a tuple of domain, username, userid. There is sufficient additional utility (above and beyond "URL") to having explicit structured account information that I propose the following new property:

ACCOUNT

Purpose: To specify the components of an account of the object the vCard represents.

Value type: A single structured text value. Each component can have one value.

Cardinality: (0-n)

Special note: The structured property value corresponds, in sequence, to the domain name, username, user-id , and canonical profile URL. The text components are separated by the SEMI-COLON character (ASCII decimal 59). This property is based on the semantics of the Portable Contacts Account property. The property SHOULD be present in the vCard object when one or more URLs for the object represent online profiles of the object.

The SORT-AS parameter MAY be applied to this property.

ISSUE STILL EXISTS IN DRAFT 15 BUT IS ACCEPTABLE TO PUNT.

section 6.7.9. VERSION

6.7.9. VERSION

Seems fine, compatible with vCard3. Not used much in practice.

section 6.8. Security Properties

6.8. Security Properties

Seems fine.

section 6.8.1. CLASS

6.8.1. CLASS

In practice we have seen no use of this property in hCard.

I don't think it is clear how to use it, and it should be dropped from vCard4 (or at least deprecated/ignored).

ISSUE HAS BEEN ACCEPTED AND RESOLVED AS OF DRAFT 15 - PROPERTY DROPPED.

section 6.8.2. KEY

6.8.2. KEY

This property has light use but much potential in both vCard and hCard.

It would be great if there were an example with PGP.

ISSUE ACCEPTED AND RESOLVED IN DRAFT 15.

section 6.9. Calendar Properties

6.9. Calendar Properties

This whole section should be dropped from core and placed into an extension.

section 6.10. Extended Properties and Parameters

6.10. Extended Properties and Parameters

Seems about the same as vCard3.

section 7. Synchronization

7. Synchronization

This entire section, the PID property, and the CLIENTPIDMAP property should all be moved to an extension spec.

section 8. Example: Authors' vCards

8. Example: Authors' vCards

Seems fine. Didn't review/test for vCard validity but assume the authors will do that.

section 9. Security Considerations

Seems fine. If we deprecate the CLASS property, the text referring to Section 6.8.1. should be amended.

ISSUE ACCEPTED AND RESOLVED IN DRAFT 15.

section 10. IANA Considerations

Seems fine as much as any other IANA-based registration assumptions/plans.

Obviously 10.3.1. Properties Registry will have to be updated as any properties are added or dropped.

Similarly 10.3.2. Parameters Registry if any parameters are added/dropped.

10.3.3. Value Data Types Registry no changes expected.

10.3.4. Values Registries will have to be updated if/when KIND and CLASS are dropped/deprecated.

ISSUES ACCEPTED AND RESOLVED IN DRAFT 15.

section 11. Acknowledgements

11. Acknowledgements

No comments.

section 12. References

12. References

No comments.

section Appendix A. Differences from RFCs 2425 and 2426

Appendix A. Differences from RFCs 2425 and 2426

will need updates accordingly.

section Appendix B. Change Log

Appendix B. Change Log (to be removed by RFC Editor prior to publication)

No comments.

see also

• vCard4
• standards