Subject: [Jcardcal] vcard, icalendar and streams

From: Philipp Kewisch <[email-masked]>
Date: Tue, 02 Jul 2013 16:24:53 +0200

Hey Folks,

as there are a few issues on the tracker about the streams, I though I'd 
put this up for discussion again.

As mentioned in the issue tracker, the stream construct originates from 
iCalendar, which explicitly defines one. I wrote jCal first, which is 
why it was included initially. Since the structure of jCard and jCal is 
very much the same, I think it would be consistent to either have both 
documents define a stream construct or none of them.

The use for having them, especially in jCal, is to put together a bunch 
of objects into an array for transport or similar. The reason I want to 
avoid leaving this to the implementer is that some might be tempted to 
use a JSON object with the UID as key. This might work for jCard, but 
for changed occurrences in iCalendar/jCal there is also the 
RECURRENCE-ID to take into account.

On the other hand, we could just go with recommending to use a plain 
array (no first string element) and write down the reasons. As the 
stream will really only be used when there are multiple objects to 
process, I think this will be less common anyway.

Then there is the name of the first value. This is currently 
"vcardstream" for jCard and "icalendar" for jCal. Not really ideal, 
again I started with jCal but then it made less sense for jCard. If we 
decide to keep the stream construct, I propose "jcardstream" for jCard 
and "jcalstream" for jCal. This keeps the naming close, and also 
coincides with the ABNF defined in the jCal draft. No more ambiguities 
with vCard vs jCard.

Philipp

---

From: Evert Pot <[email-masked]>
Date: Tue, 2 Jul 2013 16:06:58 +0100

On Jul 2, 2013, at 3:24 PM, Philipp Kewisch <[email-masked]> wrote:

> Hey Folks,
> 
> as there are a few issues on the tracker about the streams, I though I'd put this up for discussion again.
> 
> As mentioned in the issue tracker, the stream construct originates from iCalendar, which explicitly defines one. I wrote jCal first, which is why it was included initially. Since the structure of jCard and jCal is very much the same, I think it would be consistent to either have both documents define a stream construct or none of them.
> 
> The use for having them, especially in jCal, is to put together a bunch of objects into an array for transport or similar. The reason I want to avoid leaving this to the implementer is that some might be tempted to use a JSON object with the UID as key. This might work for jCard, but for changed occurrences in iCalendar/jCal there is also the RECURRENCE-ID to take into account.
> 
> On the other hand, we could just go with recommending to use a plain array (no first string element) and write down the reasons. As the stream will really only be used when there are multiple objects to process, I think this will be less common anyway.
> 
> Then there is the name of the first value. This is currently "vcardstream" for jCard and "icalendar" for jCal. Not really ideal, again I started with jCal but then it made less sense for jCard. If we decide to keep the stream construct, I propose "jcardstream" for jCard and "jcalstream" for jCal. This keeps the naming close, and also coincides with the ABNF defined in the jCal draft. No more ambiguities with vCard vs jCard.

This is no scientific argument, but I thought both stream objects were a bit odd... If the sole goal is to prevent people from indexing by UID, adding some language in there recommending arrays should be sufficient in my opinion.

Besides, if there's multiple objects with the same UID, I'd still be able to use a top-level object with UID's for keys, as long as I group the same VEVENT together in the same VCALENDAR, which is analogous to how CalDAV groups related objects as well.

In my implementation I ignored the top-level objects, because they seemed optional anyway.

Hope this helps,
Evert

---

From: Michael Angstadt <[email-masked]>
Date: Tue, 2 Jul 2013 11:23:36 -0400

Perhaps the JSON formats should follow the same naming scheme that the XML
formats use.

xCard example (top level element: "vcards", vCard element: "vcard"):

<vcards xmlns="urn:ietf:params:xml:ns:vcard-4.0">
  <vcard>
    <fn><text>John Doe</text></fn>
  </vcard>
</vcards>

xCal example (top level element: "icalendar", iCalendar element:
"vcalendar"):

<icalendar xmlns="urn:ietf:params:xml:ns:icalendar-2.0">
  <vcalendar>
    <properties>
      <prodid><text>-//Example Inc.//Example Client//EN</text></prodid>
      <version><text>2.0</text></version>
    </properties>
  </vcalendar>
</icalendar>

jCard proposal:

["vcards",
  ["vcard",
  ...
  ]
]

jCal proposal:

["icalendar",
  ["vcalendar",
  ...
  ]
]

Regards,
-Mike

On Tue, Jul 2, 2013 at 11:06 AM, Evert Pot <[email-masked]>wrote:

> iCalendar, which explicitly defines one. I wrote jCal first, which is why
> it was included initially. Since the structure of jCard and jCal is very
> much the same, I think it would be consistent to either have both documents
> define a stream construct or none of them.
> >
> avoid leaving this to the implementer is that some might be tempted to use
> a JSON object with the UID as key. This might work for jCard, but for
> changed occurrences in iCalendar/jCal there is also the RECURRENCE-ID to
> take into account.
> >
> array (no first string element) and write down the reasons. As the stream
> will really only be used when there are multiple objects to process, I
> think this will be less common anyway.
> >
> "vcardstream" for jCard and "icalendar" for jCal. Not really ideal, again I
> started with jCal but then it made less sense for jCard. If we decide to
> keep the stream construct, I propose "jcardstream" for jCard and
> "jcalstream" for jCal. This keeps the naming close, and also coincides with
> the ABNF defined in the jCal draft. No more ambiguities with vCard vs jCard.
>
> This is no scientific argument, but I thought both stream objects were a
> bit odd... If the sole goal is to prevent people from indexing by UID,
> adding some language in there recommending arrays should be sufficient in
> my opinion.
>
> Besides, if there's multiple objects with the same UID, I'd still be able
> to use a top-level object with UID's for keys, as long as I group the same
> VEVENT together in the same VCALENDAR, which is analogous to how CalDAV
> groups related objects as well.
>
> _______________________________________________
> jcardcal mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jcardcal
>

---

From: Philipp Kewisch <[email-masked]>
Date: Tue, 02 Jul 2013 17:29:15 +0200

On 7/2/13 4:24 PM, Philipp Kewisch wrote:
> The use for having them, especially in jCal, is to put together a 
> bunch of objects into an array for transport or similar. The reason I 
> want to avoid leaving this to the implementer is that some might be 
> tempted to use a JSON object with the UID as key. This might work for 
> jCard, but for changed occurrences in iCalendar/jCal there is also the 
Sorry, I was too quick on this argument. UID/RECURRENCE-ID are of course 
inside a VEVENT, not a property of the VCALENDAR (which is what is being 
put into a stream here). Afaik there is nothing that uniquely identifies 
a VCALENDAR inside a stream of VCALENDARs, so when translating to jCal, 
there is no real harm in using an object and indexing by whatever the 
implementer of the enclosed protocol feels like.

Philipp

---

From: Philipp Kewisch <[email-masked]>
Date: Tue, 02 Jul 2013 20:43:22 +0200

Hey Folks,

we just had a phone meeting within calconnect and the consensus there is 
that its perfectly fine to get rid of streams both in jCal and in jCard. 
A few arguments, some already mentioned:

* If you want to stream lots of vcards, there is no added value in the 
initial "icalendar" / "vcardstream" string element
* The only reason an identifier like "icalendar" might be needed is if 
it were possible to stream both jcard and jcal objects within one array, 
i.e:
      ["jcalstream", [ "vcalendar", ... ] , .... , "jcardstream", [ 
"vcard", ... ] ... ]
    (This is not a suggestion to add that capability though)
* If you are going to be streaming both jcards and jcal objects in a 
defined container format, they are going to define separate keys anyway
* For simple transport, the use of an array is quite obvious. No need to 
make any restrictions here.
* XML is strongly typed, JSON is not. Therefore the parallel to xCard's 
<vcards> is not necessarily applicable.

Of course the ultimate decision lies within this WG. As I haven't heard 
any strong opinions in favor the streaming construct currently defined, 
I will start removing it from both jCard and jCal. I will upload a new 
draft with these changes by midday tomorrow CET. If you have any 
objections to removing the streaming construct, please speak now.

Thanks,
Philipp

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 02 Jul 2013 12:55:59 -0600

On 7/2/13 12:43 PM, Philipp Kewisch wrote:
> Hey Folks,
> 
> we just had a phone meeting within calconnect and the consensus
> there is that its perfectly fine to get rid of streams both in jCal
> and in jCard. A few arguments, some already mentioned:
> 
> * If you want to stream lots of vcards, there is no added value in
> the initial "icalendar" / "vcardstream" string element * The only
> reason an identifier like "icalendar" might be needed is if it were
> possible to stream both jcard and jcal objects within one array, 
> i.e: ["jcalstream", [ "vcalendar", ... ] , .... , "jcardstream", [ 
> "vcard", ... ] ... ] (This is not a suggestion to add that
> capability though) * If you are going to be streaming both jcards
> and jcal objects in a defined container format, they are going to
> define separate keys anyway * For simple transport, the use of an
> array is quite obvious. No need to make any restrictions here. *
> XML is strongly typed, JSON is not. Therefore the parallel to
> xCard's <vcards> is not necessarily applicable.
> 
> Of course the ultimate decision lies within this WG. As I haven't
> heard any strong opinions in favor the streaming construct
> currently defined, I will start removing it from both jCard and
> jCal. I will upload a new draft with these changes by midday
> tomorrow CET. If you have any objections to removing the streaming
> construct, please speak now.

[not with my chair hat on]

I think this is reasonable -- IMHO streaming introduced complexity
with little benefit.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Simon Perreault <[email-masked]>
Date: Tue, 02 Jul 2013 21:07:49 +0200

Le 2013-07-02 20:55, Peter Saint-Andre a écrit :
>> and in jCard.

+1

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Michael Angstadt <[email-masked]>
Date: Tue, 2 Jul 2013 18:55:52 -0400

Just to be clear, is it just the "vcardstream" string value that is being
removed from the outer array?  If so, I agree that it's kind of unnecessary.

For example:

[
  ["vcard",
    ...
  ],
  ["vcard",
    ...
  ]
]

Thanks,
Mike

On Tue, Jul 2, 2013 at 3:07 PM, Simon Perreault <[email-masked]
> wrote:

> DTN made easy, lean, and smart --> http://postellation.viagenie.**ca<http://postellation.viagenie.ca>
> ______________________________**_________________
> jcardcal mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/jcardcal<https://www.ietf.org/mailman/listinfo/jcardcal>
>

---

From: Evert Pot <[email-masked]>
Date: Wed, 3 Jul 2013 00:22:11 +0100

On Jul 2, 2013, at 11:55 PM, Michael Angstadt <[email-masked]> wrote:

> Just to be clear, is it just the "vcardstream" string value that is being removed from the outer array?  If so, I agree that it's kind of unnecessary.
> 
> For example:
> 
> [
>   ["vcard",
>     ...
>   ],
>   ["vcard",
>     ...
>   ]
> ]
> 

I'd suggest removing any language that refers to an outer array in general.

Evert

---

From: Michael Angstadt <[email-masked]>
Date: Tue, 2 Jul 2013 19:57:20 -0400

> I'd suggest removing any language that refers to an outer array in general.

Ah, so the outer array has been completed removed?

For example:

["vcard",
  ...
]

---

From: Evert Pot <[email-masked]>
Date: Wed, 3 Jul 2013 01:00:40 +0100

> Ah, so the outer array has been completed removed?

I can't speak for what Phillipp will end up doing, but I think that was what his email implied.
The use of an array to to contain more than 1 javascript value is in my opinion quite obvious, and there's no need to specifically mention this.

Also, in the current drafts the use of the wrapper array was entirely optional anyway. (which is why I ignored it as well).

Evert

---

From: Michael Angstadt <[email-masked]>
Date: Tue, 2 Jul 2013 21:14:27 -0400

Yeah, makes sense.

On Tue, Jul 2, 2013 at 8:00 PM, Evert Pot <[email-masked]> wrote:

> The use of an array to to contain more than 1 javascript value is in my
> opinion quite obvious, and there's no need to specifically mention this.
>
> Also, in the current drafts the use of the wrapper array was entirely
> optional anyway. (which is why I ignored it as well).
>
> Evert

---

From: Philipp Kewisch <[email-masked]>
Date: Wed, 03 Jul 2013 08:37:00 +0200

> Also, in the current drafts the use of the wrapper array was entirely optional anyway. (which is why I ignored it as well).
Yes, the outer array with the "vcardstream" element is being removed. 
The toplevel construct is now ["vcard", ... ]. I've removed all traces 
of it, I hope. Since there seems to be broad consensus, I will upload 
the new draft very soon now.

Philipp

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 03 Jul 2013 14:35:54 -0600

On 7/3/13 12:37 AM, Philipp Kewisch wrote:
>>> On Tue, Jul 2, 2013 at 7:22 PM, Evert Pot
>>> <[email-masked]> wrote: I'd suggest removing any
>>> language that refers to an outer array in general.
>>> 
>>> ["vcard", ... ]
>> I can't speak for what Phillipp will end up doing, but I think
>> that was what his email implied. The use of an array to to
>> contain more than 1 javascript value is in my opinion quite
>> obvious, and there's no need to specifically mention this.
>> 
>> Also, in the current drafts the use of the wrapper array was
>> entirely optional anyway. (which is why I ignored it as well).
>> 
>> Evert _______________________________________________ jcardcal
>> mailing list [email-masked] 
> Yes, the outer array with the "vcardstream" element is being
> removed. The toplevel construct is now ["vcard", ... ]. I've
> removed all traces of it, I hope. Since there seems to be broad
> consensus, I will upload the new draft very soon now.

(no hats)

That sounds right.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Michael Angstadt <[email-masked]>
Date: Wed, 3 Jul 2013 17:05:58 -0400

> (no hats)

No hats?!  Madness! ;)