Subject: Re: [VCARDDAV] [apps-discuss] New Internet-Draft: jCard: The JSON format for vCard

From: "Javier Godoy" <[email-masked]>
Date: Sun, 17 Feb 2013 08:34:43 -0300

On 2/14/13 5:49 AM, Simon Perreault wrote:

>Le 2013-02-14 00:22, Philipp Kewisch a écrit :
>> On 2/13/13 10:35 PM, Simon Perreault wrote:

>>> 3.5.3. Date (RFC6350 section 4.3.1)
>>>
>>>    Description:  vCard "DATE" property values are represented by a
>>>       property with the type identifier "date".  The value elements are
>>>       JSON strings with the same date value specified by [RFC6350], but
>>>       formatted using the [ISO.8601.2004] complete representation,
>>>       extended format.  The textual format specifies a four-digit year,
>>>       two-digit month, and two-digit day of the month, separated by the
>>>       "-" character.
>>>
>>> --> Why? Also, IIRC some things in basic format don't have an
>>> equivalent in extended format. Don't remember exactly what. I'll have
>>> to re-read ISO8601 *again*!
>> We have found that the extended format is much more common in web
>> applications and APIs. Since JSON is mostly targeted at the web, we
>> decided it makes sense to use it here. This works out nicely in
>> iCalendar/jCal, because the only allowed formats are date, date-time and
>> time and reduced accuracy is not permitted. I did leave this as an open
>> issue though, especially since I am not sure omitting years or other
>> parts of a date are allowed in the extended format.
>
>Right. I'll get back to you on that. I'm pretty sure we chose to go with
>basic exactly for this kind of reason.

My 0.02:

The extended format is "an extension of the basic format that includes
additional separators". Therefore, the extended format is defined as "not
applicable" when the only separators used are those already required by the
basic format.

For instance:
   A specific year
   Basic format: YYYY
   Extended format: not applicable (there are no "additional separators")

   A specific month
   Basic format: YYYY-MM  (hyphen required in order to disambiguate with
hhmmss)
   Extended format: not applicable (all possible separators are already
written in basic format)

   A specific day of a month
   Basic format: --MMDD  (two leading hyphens representing the omitted century
and year)
   Extended format: --MM-DD

I agree that the extended format is preferable, not only because of its common
use (and greater readibility) but also because the rules for writing basic
format representations other than complete are somewhat obscure.

I guess that one could say that DATE [and TIME, and DATE-TIME] values are
"representations formatted using the [ISO.8601.2000]* extended format (if
applicable) or basic format (whenever the extended format is not applicable).
This means that a separator must be written between each date component, in
addition to leading separators for indicating the omitted components".
Followed by a list of the allowed combinations, which are:

date-complete = year "-" month "-" day ;YYYY-MM-DD

date-noreduc  = date-complete
              / "--" month "-" day; --MM-DD
           /  "---" day; ---DDD

date =  date-noreduc
     / year; YYYY
  / year "-" month ; YYYY-MM
  / "--" month; --MM

time-notrunc =  hour [":" minute [":" second]] [zone]

time = time-notrunc
     / "-" minute  ":" second [zone]; -mm:ss
     / "-" minute [zone]; -mm
     / "--" second [zone]; --ss
; (see also http://www.rfc-editor.org/errata_search.php?eid=3484)

date-time = date-noreduc time-designator time-notrunc

*The reference should be to 8601:2000 (instead of/in addition to) ISO
8601:2004, because truncated representantions were removed from the latter.
Note that both editions are referenced normatively in RFC 6350.

Best Regards

Javier

---

From: Michael Angstadt <[email-masked]>
Date: Sun, 17 Feb 2013 17:59:14 -0500

I agree with Simon about the use of the term "stream" in section 3.2.
Why not just use "vcards" instead of "vcardstream"?  And, if by
"streaming" you mean "multiple vCards in the same data stream", vCard
has always supported this.

On page 15, the text

"BDAY"'s value type is "date-or-date-time",

should be

"BDAY"'s value type is "date-and-or-time",

Also, I'm not too familiar with the ISO date formats, but in the jCard
example on page 23, I think the BDAY property value should start with
two dashes instead of one:

"--02-03" instead of "-02-03"

Thanks,
-Mike
http://code.google.com/p/ez-vcard

On Sun, Feb 17, 2013 at 6:34 AM, Javier Godoy <[email-masked]> wrote:
> _______________________________________________
> VCARDDAV mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Michael Angstadt <[email-masked]>
Date: Sun, 17 Feb 2013 18:00:01 -0500

Here's a summary of all the grouping ideas that have been proposed so
far.  Please let me know if I missed anything or got anything wrong.

1. "groupName.propertyName" (currently in the draft)

["vcard",
  [
    ["groupname.email", {}, "text", "[email-masked]"],
    ["groupname.note", {}, "text", "Hello World"],
    ["url", {}, "uri", "http://example.org"]
  ]
]

Pros:
* jCal compatibility

Cons:
* Likely to get badly implemented.  Developers may not bother to check
for the group when iterating through the properties.
* Group name is repeated

==========================================

2. New array element

["vcard",
  [
    ["groupname", "email", {}, "text", "[email-masked]"],
    ["groupname", "note", {}, "text", "Hello World"],
    ["", "url", {}, "uri", "http://example.org"]
  ]
]

Pros:
* Clean separation of group name in the data model

Cons:
* Breaks jCal compatibility
* Group name is repeated

==========================================

3. "group" data type

["vcard",
  [
    ["groupname", {}, "group", [
      ["email", {}, "text", "[email-masked]"],
      ["note", {}, "text", "Hello World"]
    ],
    ["url", {}, "uri", "http://example.org"]
  ]
]

Pros:
* Group name is not repeated
* jCal compatibility

Cons:
* The parameter object in the group's array is unnecessary, but must
remain in order to maintain jCal compatibility.
* Harder to parse--properties cannot easily be iterated over.

==========================================

4. "group" parameter

["vcard",
  [
    ["email", {"group":"groupname"}, "text", "[email-masked]"],
    ["note", {"group":"groupname"}, "text", "Hello World"],
    ["url", {}, "uri", "http://example.org"]
  ]
]

Pros:
* jCal compatibility
* Easier to parse

Cons:
* Vendors may already be using properties that have parameters named "group".
* Interoperability issues: Adds another way that groups can be
defined, which not all vendors may implement.  To resolve this, the
jCard specs should require that jCard-->vCard converters use the
"FOO.BAR:baz" syntax and not the "group" parameter. The GROUP
parameter should be registered with IANA in order to reserve the name.
* Group name is repeated

==========================================

5. group object

The object will only appear if the vCard has groups.

With groups:

["vcard",
  {
    "groupname": [
      ["email", {}, "text", "[email-masked]"],
      ["note", {}, "text", "Hello World"]
    ],
    "": [
      ["url", {}, "uri", "http://example.org"]
    ]
  }
]

Without groups (no object is added, normal jCal syntax):

["vcard",
  [
    ["email", {}, "text", "[email-masked]"],
    ["note", {}, "text", "Hello World"],
    ["url", {}, "uri", "http://example.org"]
  ]
]

Pros:
* Group name is not repeated

Cons:
* Breaks jCal compatibility (if the jCard has groups)
* Harder to parse (if the jCard has groups)--properties cannot easily
be iterated over.

Thanks,
-Mike