Subject: [VCARDDAV] vCard 4 Summary

From: Simon Perreault <[email-masked]>
Date: Wed, 2 Jul 2008 15:58:59 -0400

* Recently closed issues:

- #166 Private extensions namespace
- #183 Change ref to ISO 9070 to ref to RFC 3406
- #226 Formatting of ABNF comments
- #235 Ordering of pref
- #252 Many typos in ABNF

* Current issues being considered for closure:

The following issues may be closed soon. Please review the proposals  
and speak up (either in favour or against) soon.

- #152 TEL Type Definition
- #154 New sub-property: Initials
- #155 Geographic properties
- #156 Alternative dates
- #159 New property: Global Location Number
- #176 The NAME (RFC2425) property is redundant with FN (RFC2426)
- #181 vcard should be an exchange format with no loss
- #187 Proper format for TZ values
- #236 Suggestion for allowance of truncated date format in BDAY
- #301 Remove TYPE parameter for EMAIL and IMPP properties

* Current issues being discussed:

- #171 Per-property UID
- #225 Mandatory UID property
- #306 Define the cardinality of each property
- #307 Replace AGENT with a type of RELATED

See also: http://www.vcarddav.org/issues.xhtml

-- 
Please try Numb, a STUN/TURN server implementation.
Free access at http://numb.viagenie.ca/.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: "Javier Godoy" <[email-masked]>
Date: Thu, 3 Jul 2008 01:11:37 -0300

I was writing a batch comment about recently closed issues and others being
considered for closure, but I realized I had too many comments about #236.
I was writing my comments about #236, but I realized I had some comments
about date / time ABNF.
Let's start from the end.

1. Update examples from section 5.3
 - Add some example with reduced precision (yyyy-mm, hh:mm,
yyyy-mm-ddThh:mm)
 - Remove examples without separators (e.g. 102200), which are no longer
valid.
(Note: add some examples of truncated representations if #236 is accepted)

2. There are some redundant definitions in ABNF
  date-value   = <A single date value as defined in [RFC2425]>
  time-value   = <A single time value as defined in [RFC2425]>
which I understand are synonyms of "date" and "time". Their usage should be
unified.

3. per the updated ABNF we have:
  date = date-fullyear ["-" date-month ["-" date-mday]]
  time = time-hour [":" time-minute [":" time-second [time-secfrac]]]
[time-zone]

then "yyyy-mm" is a valid date, and "hh:mm:ss" is a valid time (OK so far)

We also have
  date-time-value = <A single date-time value as defined in [RFC2425]>
which will be fixed later...  (though it is only defined at the beggining of
section 5, and it is not used later; I think it could be safely removed but
that reminds me the ABNF is in need for some cleaning). IIRC there were some
datatypes from RFC2425 which RFC2426 didn't use,

Now look at
  date-time-list = date "T" time *("," date "T" time)
Shouldn't it be
  date-time-list = date-time-value *("," date-time-value)
?

If date-time-list is correct, it follows that date-time-value = date "T"
time
which says it is possible to construct a date-time-value by concatenating
any date (e.g., yyyy-mm) with any time (e.g., hh:mm:ss), which yields
"yyyy-mmThh:mm:ss". Not acceptable.

Indeed ISO 8601:2000 (Section 5.4.2.c, page 19) adds the following
requirement for datetime representations other than complete "the date
component shall not be represented with reduced precision and the time
component shall not be truncated (...)".

In other words, yyyy-mmThh:mm:ss (whatever it means) is not allowed, and we
should define

  date-time-value = date-fullyear "-" date-month "-" date-mday "T" time
  date-time-list = date-time-value *("," date-time-value)

Best Regards

Javier

---

From: "Javier Godoy" <[email-masked]>
Date: Thu, 3 Jul 2008 03:06:39 -0300

Simon Perreault wrote:

> Current issues being considered for closure:
> The following issues may be closed soon. Please review the proposals and
> speak up (either in favour or against) soon.

1. From your message dated --06-25
(http://www.ietf.org/mail-archive/web/vcarddav/current/msg00373.html) I
assume the resolution will be allowing truncated dates (+1) but
> Mark suggested we remove delimiters, which conflicts with allowing issue
> #236. Some discussion is still needed

2. In http://www.ietf.org/mail-archive/web/vcarddav/current/msg00374.html I
have started drafting my position about this issue: the format of truncated
dates should be consistent with the format of complete dates (when
applicable). For instance,
--0625 is a truncated date in basic format, consistent with 20080625
--06-25 is a truncated date in extended format, consistent with 2008-06-25

Just a matter of choice.

3. Should we define a new "truncated-date" datatype or will it be included
into the current "date" datatype?

I'm for the latter, because REV is date-time-value / date, and allowing
truncated revision dates (REV:--06-25 ??) makes no sense.

4. Which components may be truncated? The initial statement of this issue
refers to truncated date representation of the form --mm-dd (and some
misadventures with individuals who refused to report their date-fullyear
component when told about RFC 2425 section 5.8.4 ;-) However, this was
worded as "truncation", and ISO 8601:2000 allows arbitrary truncation of any
component (provided that higher order components are truncated too). For
instance, ---03 (the third day of the implied month) is a valid truncated
date representation.

Just to be sure, are we *only* talking about --mm-dd ?
(optionally --mm-ddThh:mm:ss).

4. Other question is about truncated representations with reduced precision.
According to ISO 8601:2000 a date representation could be both truncated and
with reduced precision, which would allow us to specifiy not only --07-03T03
(3 AM on July 3rd) and --07 (the month of July in the implied year) but
lso  -16 (the 16th minute of the implied hour... yes, it starts with hyphen
and has no colon)

I'am tempted to assume that the month component is always required, and
truncation should not be allowed for the time datatype.

I look forward to hearing your opinions.

Best Regards

Javier

---

From: Simon Perreault <[email-masked]>
Date: Thu, 3 Jul 2008 08:49:12 -0400

> > #236. Some discussion is still needed

I was very wrong. There is no conflict because basic format still allows 
truncated dates.

> --06-25 is a truncated date in extended format, consistent with 2008-06-25

We'll definitely be going with basic format unless someone voices strong 
opposition. Many people mentioned they preferred basic format.

> truncated revision dates (REV:--06-25 ??) makes no sense.

So you're for the former, right?

> worded as "truncation", and ISO 8601:2000 allows arbitrary truncation of
> any component (provided that higher order components are truncated too).
> For instance, ---03 (the third day of the implied month) is a valid
> truncated date representation.
>

No. The proposition was for truncation as per ISO 8601:2000. There was no 
demand on this list for constraining it to only truncating the year 
component.

> 4. Other question is about truncated representations with reduced
> precision. According to ISO 8601:2000 a date representation could be both
> truncated and with reduced precision, which would allow us to specifiy not
> only --07-03T03 (3 AM on July 3rd)

Assuming you mean datetime (section 5.4.1 in ISO 8601:2000), that's correct.

> and --07 (the month of July in the implied year)

Assuming you mean date (section 5.2.1 in ISO 8601:2000), that's correct.

> but lso  -16 (the 16th minute of the implied hour... yes, it 
> starts with hyphen and has no colon)

Assuming you mean time (section 5.3.1 in ISO 8601:2000), that's correct.

> truncation should not be allowed for the time datatype.

You raise a good point. How about we create these new ABNF tokens and assign 
them to properties where it makes sense?

date
date-truncateable
date-reduceable
date-truncateable-reduceable
time
time-truncateable
time-reduceable
time-truncateable-reduceable

date-time-value would be gone. Instead we would specify it for each property 
that requires it with the above, separated by "T". So we could control what 
can ben truncated/reduced for individual properties. For example:

; **** BDAY ****
param        = ("VALUE" "=" "date")
     ; Only value parameter allowed

param        =/ ("VALUE" "=" "date-time")
     ; Only value parameter allowed

value        = date-truncateable-reduceable
     ; Value parameter MUST be "date"

value        =/ date-truncateable-reduceable "T" time-reduceable
     ; Value parameter MUST be "date-time"

---

From: "Javier Godoy" <[email-masked]>
Date: Thu, 3 Jul 2008 16:14:23 -0300

> opposition. Many people mentioned they preferred basic format.

OK. I prefer it too, but draft -02 actually requires extended format. I 
though there was some preference for it.

> So you're for the former, right?

Oops... Yes, I'm for a new datatyoe (I switched the order and forgot to 
update the second paragraph.)

> demand on this list for constraining it to only truncating the year

The proposition was (note the last line): [[
So, although ISO 8601:2000 has now been superseded by ISO 8601:2004 and
deletes the ability to truncate the left side of a date, I propose that
this specific feature from the older standard be specifically allowed as
a means of indicating a recurring birthday when no year is known.
]]

We could understand it as a request for supporting ISO 8601:2000 truncation 
(as you did), or a request for only supporting truncation of the year 
component (as I did).

Is there a feasible use case for "BDAY:---01" and the like?

> Assuming you mean datetime (section 5.4.1 in ISO 8601:2000), that's 
Actually it was 5.4.2 (combinations of date and time of the day: 
representations other than complete). 5.4.1 is about "complete 
representations".

> Assuming you mean date (section 5.2.1 in ISO 8601:2000), that's correct.
Yes, I do (particularly section 5.2.1.3, example e)

> Assuming you mean time (section 5.3.1 in ISO 8601:2000), that's correct.
Yes, I do (particularly section 5.3.1.2, example b)

> time-truncateable-reduceable

It seems a good idea, but I'm not sure we really need all of them.

First, there is no standard property allowing time-only values (TZ is 
defined as utc-offset-value, which is quite different), then we only need 
date, date-*, time (complete representation) and time-reduceable (unless you 
also want defining the others for completeness).

Second, the only standard date / date-time properties are REV, BDAY and 
DDAY. (Note: DDAY is missing from -02 ABNF, but it should be the same as 
BDAY). So we could discuss about BDAY/DDAY and REV instead of generalizing 
ISO precision/truncation and then applying it no more than two cases..

date-complete     = yyyy mm dd
date-reduceable  = yyyy [mm [ dd]]
date-truncateable =  date-complete / ("--" mm dd) / ("---" dd)
date-truncateable-reduceable = date-reduceable  / date-truncateable / ( "--" 
mm )
time-complete = hh mm ss
time-reduceable = hh [mm [ss]]

>     ; Value parameter MUST be "date-time"

It should be (same for DDAY):
  value        = date-truncateable-reduceable
  value        =/ date-truncateable "T" time-reduceable
otherwise it would allow "yyyymmThhmmss"

About REV, it is defined as a (complete) date-time, and "can also be reset 
to a single date value"  (then representations reduced to the minute and 
reduced to the hour should be allowed). In other words:
    value        = date-complete "T" time-reduceable
    value        =/ date-complete

or
    value        = date-complete "T" time-reduceable
    value        =/ date-reduceable
(which also allows "REV:2008" and "REV:200807")

IMHO, date-truncateable (e.g., REV:--0703) is too ambiguous in this context.

Best Regards

Javier