Subject: [VCARDDAV] I-D Action:draft-ietf-vcarddav-vcardrev-08.txt

From: [email-masked]
Date: Mon, 13 Jul 2009 05:00:02 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the vCard and CardDAV Working Group of the IETF.

	Title           : vCard Format Specification
	Author(s)       : S. Perreault, P. Resnick
	Filename        : draft-ietf-vcarddav-vcardrev-08.txt
	Pages           : 76
	Date            : 2009-07-13

This document defines the vCard data format for representing and
exchanging a variety of information about an individual (e.g.,
formatted and structured name and delivery addresses, email address,
multiple telephone numbers, photograph, logo, audio clips, etc.).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-vcarddav-vcardrev-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 13 Jul 2009 08:05:59 -0400

> 	Filename        : draft-ietf-vcarddav-vcardrev-08.txt

Here's the change log:

   o  Allow 1985 (year only) in date ABNF.

   o  Fixed missing country in ADR example.

   o  Added the DATE-AND-OR-TIME value.

   o  Made BDAY and DDAY use DATE-AND-OR-TIME.

   o  Prefixed "param" and "value" production rules specific to
      properties with the property name.

   o  Replaced the GENDER property with the SEX property.

   o  Added the ANNIVERSARY property.

   o  Added the "friend" and "spouse" types of RELATED.

   o  TZ property now has text / uri value.

   o  Refined the definitions of TITLE and ROLE.

The last remaining known issue is with the vendor namespace. This should get 
fixed pretty soon.

Simon
-- 
STUN/TURN server    --> http://numb.viagenie.ca
Interplanetary news --> http://reeves.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: "Javier Godoy" <[email-masked]>
Date: Mon, 13 Jul 2009 10:07:14 -0300

On Monday, July 13, 2009 12:05Z
Simon Perreault<[email-masked]> wrote:

>  -  Added the DATE-AND-OR-TIME value
>  -  Made BDAY and DDAY use DATE-AND-OR-TIME.

Is it useful to allow time-only values for BDAY/DDAY? And if it is useful, 
why?

I could understand it if it were "date-or-datetime" (date/date-time); but 
date-and-or-time seems too general to me, at least for these properties.

(BTW, there is a missing hypen in "date-and-ortime" in page 11)

Best Regards

Javier

---

From: Simon Perreault <[email-masked]>
Date: Mon, 13 Jul 2009 09:11:40 -0400

> date-and-or-time seems too general to me, at least for these properties.

For the record: I really have no opinion on this. I just implemented what I 
thought was your suggestion.

Anyone else have an opinion?

> (BTW, there is a missing hypen in "date-and-ortime" in page 11)

Thanks, will fix.

Simon

---

From: "Javier Godoy" <[email-masked]>
Date: Mon, 13 Jul 2009 11:56:15 -0300

----- Original Message ----- 
From: "Simon Perreault" <[email-masked]>
To: "Javier Godoy" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, July 13, 2009 10:11 AM
Subject: Re: [VCARDDAV] I-D Action:draft-ietf-vcarddav-vcardrev-08.txt

> thought was your suggestion.

Yes, my suggestion was about specifying a single data type for BDAY/etc. This
issue was addressed in draft version-08, and I agree about this change .
Neither my suggestion nor your solution modify the property value-space.

> 2009-04-29 Re: [VCARDDAV] Issue 236 (Suggestion for allowance of
> truncateddateformat in BDAY)
>When the value type is date-time / date / time, the value parameter is
>redundant, and it should be possible to omit it.
>This proposed modification would remove the requirement for specifying a
>VALUE
>parameter in BDAY, DDAY and any aniversary-like extension property.

Another issue (independent of whether BDAY accepts several date/time datatypes
or a single date-or-whatever one), is if whe should allow time-only values for
this property, and if we should drop the unused types.

Further, an extension property would likely be like ANNIVERSARY (thus
accepting date-or-whatever values), or would impose additional restrictions on
trunctation/precision, thus requiring a new data type (such as defining
date-complete as a data type, or importing other representation from ISO 8601,
such as week-day or time periods). In the later case, a new datatype could be
registered. (We also discussed about defining each possible combination as a
datatype, but I we agreed not to do it)

Best Regards

Javier

---

From: Caleb Richardson <[email-masked]>
Date: Mon, 13 Jul 2009 12:31:14 -0700

Simon Perreault wrote:
>> Simon Perreault wrote:

We have always used text data types for BDAY and ANNIVERSARY (actually 
we use X-EON-BDAY and X-EON-AN because of this non standard behavior).

In my experience the range of values users want to enter in these fields 
is limitless, and ISO 8601 is rarely used when the choice is presented. 
This is all anecdotal of course.

Some mining and calendaring cross functionality is lost, but we viewed 
that as acceptable (parse what you can, ignore the rest).

-- 
Caleb Richardson
Software Engineer
Everyone.net