Subject: [calsify] iCalendar extensions draft - review please

From: Cyrus Daboo <[email-masked]>
Date: Thu, 07 Apr 2011 12:31:08 -0400

Hi folks,
I have posted a new version of draft-daboo-icalendar-extensions-04.txt with 
some changes based on feedback. At this point I am ready to proceed with 
submission to the IETF, but I want to make sure we have had adequate review 
by iCalendar experts - namely people on this list. So please review and 
post feedback to the list, thanks.

-- 
Cyrus Daboo

_______________________________________________
calsify mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/calsify

---

From: "Tim Hare" <[email-masked]>
Date: Thu, 7 Apr 2011 15:21:31 -0400

bear in mind that -04 is the first version I've read, I may have missed some
discussion here, but... (in order of importance to me)

1.  I am not sure I agree with assigning presentation properties to objects
(COLOR, IMAGE) since I think of iCalendar data as just data, and not a
"document" in and of itself. I have no quibble with them being X-
properties, of course. IF we must have presentation properties, my
preference would be for a STYLESHEET property which  referenced a CSS
stylesheet, and to define how to map iCalendar components and properties to
the stylesheet syntax.  That way, the presentation is separate from the
content, and UI implementers can leverage existing work that deals with CSS;
in fact it might then be "trivial" to transform the iCalendar objects to
XML/XHTML with a stylesheet reference internally and invoke the same
components which work within browsers to present those.

2. In discussion of the TIMEZONE-ID property: ' A "VTIMEZONE" component
having a "TZID" property matching the value specified in this property MUST
be present in the iCalendar object.'  -- with work going on (I believe) for
an actual IANA timezone registry, I think the text should allow for
reference to external "standard IANA timezone IDs" or whatever they will be
called.

3.  I can't remember the standard name (XMPP pops in the brain but I think
it's wrong) for a "notification protocol", but rather than implement polling
via REFRESH,  I would like to see a NOTIFY-LIST component which referenced a
URI where a calendar UI could register an address to receive a notification
message from the CS when the calendar had been updated.  That would
eliminate non-productive polling; however when the notifications went out it
might cause large bursts in traffic to retrieve updated calendars.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Cyrus Daboo
Sent: Thursday, April 07, 2011 12:31 PM
To: [email-masked]
Subject: [calsify] iCalendar extensions draft - review please

Hi folks,

-- 
Cyrus Daboo

---

From: "Tim Hare" <[email-masked]>
Date: Thu, 7 Apr 2011 15:21:31 -0400

Tim Hare

-----Original Message-----

Hi folks,

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 07 Apr 2011 15:39:23 -0400

Hi Tim,

--On April 7, 2011 3:21:31 PM -0400 Tim Hare <[email-masked]> wrote:

> 1.  I am not sure I agree with assigning presentation properties to
> objects (COLOR, IMAGE) since I think of iCalendar data as just data, and
> not a "document" in and of itself. I have no quibble with them being X-
> stylesheet, and to define how to map iCalendar components and properties
> to the stylesheet syntax.  That way, the presentation is separate from the
> content, and UI implementers can leverage existing work that deals with
> CSS; in fact it might then be "trivial" to transform the iCalendar
> objects to XML/XHTML with a stylesheet reference internally and invoke
> the same components which work within browsers to present those.

Well I think the next step from where this document goes is to define 
proper "rich text" options for iCalendar data (which could include the 
stylesheet concept). There are already proprietary solution being used by 
some systems. Whilst I was originally planning on tackling that in this 
document, it quickly because clear that this would be a complicated issue 
and would better be done as a separate document.

In regards to the current proposal for COLOR and IMAGE. Some of that is 
already being done so this document is trying to standardize the current 
practice.

> having a "TZID" property matching the value specified in this property
> MUST be present in the iCalendar object.'  -- with work going on (I
> believe) for an actual IANA timezone registry, I think the text should
> allow for reference to external "standard IANA timezone IDs" or whatever
> they will be called.

I think once the IANA/Olson piece is done, what we need is a document 
explaining how iCalendar objects can do "timezones by reference". That will 
need to touch on TZID parameters, this new TIMEZONE-ID, interactions via 
iTIP and CalDAV. But for the time being, with the "timezones by value" 
approach we now have, I think we need to stick with the requirement to 
include the VTIMEZONE object.

> it's wrong) for a "notification protocol", but rather than implement
> polling via REFRESH,  I would like to see a NOTIFY-LIST component which
> referenced a URI where a calendar UI could register an address to receive
> a notification message from the CS when the calendar had been updated.
> That would eliminate non-productive polling; however when the
> notifications went out it might cause large bursts in traffic to retrieve
> updated calendars.

The current property is meant to standardize the current practice of 
polling subscribed calendars (webcal: or http: calendar "feeds"). A new 
proposal for a push mechanism is fine, but I would prefer keeping it out of 
scope for this document.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 07 Apr 2011 15:39:23 -0400

Hi Tim,

-- 
Cyrus Daboo

---

From: Mike Douglass <[email-masked]>
Date: Thu, 07 Apr 2011 15:44:18 -0400

An IMAGE property has been a long standing need - especially for event 
publishers. It's useful at the calendar level and even more so at the 
event level

Try
http://events.rpi.edu/event/eventView.do?calPath=%2Fpublic%2Fcals%2FMainCal&guid=[email-masked]&recurrenceId=

On 04/07/2011 03:39 PM, Cyrus Daboo wrote:
> stylesheet concept). There are already proprietary solution being used 
> by some systems. Whilst I was originally planning on tackling that in 
> this document, it quickly because clear that this would be a 
> complicated issue and would better be done as a separate document.
>
> In regards to the current proposal for COLOR and IMAGE. Some of that 
> is already being done so this document is trying to standardize the 
> current practice.
>
> explaining how iCalendar objects can do "timezones by reference". That 
> will need to touch on TZID parameters, this new TIMEZONE-ID, 
> interactions via iTIP and CalDAV. But for the time being, with the 
> "timezones by value" approach we now have, I think we need to stick 
> with the requirement to include the VTIMEZONE object.
>
> polling subscribed calendars (webcal: or http: calendar "feeds"). A 
> new proposal for a push mechanism is fine, but I would prefer keeping 
> it out of scope for this document.
>
>

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication&  Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

---

From: Mike Douglass <[email-masked]>
Date: Thu, 07 Apr 2011 15:44:18 -0400

Try

--

---

From: Arnaud Quillaud <[email-masked]>
Date: Fri, 08 Apr 2011 11:59:19 +0200

On 04/07/2011 06:31 PM, Cyrus Daboo wrote:
> Hi folks,
> I have posted a new version of draft-daboo-icalendar-extensions-04.txt 
> with some changes based on feedback. At this point I am ready to 
> proceed with submission to the IETF, but I want to make sure we have 
> had adequate review by iCalendar experts - namely people on this list. 
> So please review and post feedback to the list, thanks.
>

General comment: most of the VCALENDAR level properties only make sense 
in the context of a webcal: type of iCalendar stream but not when used 
in conjunction with iTIP or CalDAV. Or at least *I* do feel somehow 
confused as to which one could appear in individual event.
Aren't we creating some potential interop issue by not specifying more 
clearly the intended use ?
For example, couldn't new implementations start to make the assumption 
that VCALENDAR UID should match the inner component UID, or make use of 
the VCALENDAR DESCRIPTION in recurring event ?

Is there really a need for a VCALENDAR level UID ? Isnt the URL property 
enough to identify it ?

IMAGE: do we really need support inline images ? Sounds like a bad idea, 
especially in the context of stream of events.
This property will in any case need to be integrated into the ongoing 
work on CalDAV attachment management.

5.2 typo ?:
<<

This property parameter MAY be specified on "IMAGE" or
       "IMAGE" properties.

Sorry for the late feedback.

Arnaud Quillaud

---

From: Arnaud Quillaud <[email-masked]>
Date: Fri, 08 Apr 2011 11:59:19 +0200

5.2 typo ?:
<<

Arnaud Quillaud

---

From: "Tim Hare" <[email-masked]>
Date: Fri, 8 Apr 2011 13:01:41 -0400

Trying to match existing practice should probably be handled via X-IMAGE and
X-COLOR, if it's proprietary implementations.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mike Douglass
Sent: Thursday, April 07, 2011 3:44 PM
To: [email-masked]
Subject: Re: [calsify] iCalendar extensions draft - review please

Try
http://events.rpi.edu/event/eventView.do?calPath=%2Fpublic%2Fcals%2FMainCal&
guid=[email-masked]&recurrenc
eId=

--

---

From: "Tim Hare" <[email-masked]>
Date: Fri, 8 Apr 2011 13:01:41 -0400

-----Original Message-----

Try

--