Re: [calsify] iCalendar extensions draft - review please

[Mike Douglass <[e-mail]>]

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=[e-mail]&recurrenceId=

On 04/07/2011 03:39 PM, Cyrus Daboo wrote:
> Hi Tim,
>
> --On April 7, 2011 3:21:31 PM -0400 Tim Hare <[e-mail]> 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-
>> 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.
>
> 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.
>
>> 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.
>
> 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.
>
>> 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.
>
> 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.
>
>

-- 

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

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