Re: [calsify] iCalendar extensions draft - review please
"Tim Hare" <TimHare@comcast.net> Fri, 08 April 2011 17:00 UTC
Return-Path: <calsify-bounces@ietf.org>
X-Original-To: calsify-archive-feit0ahl@lists.ietf.org
Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 674353A693B; Fri, 8 Apr 2011 10:00:07 -0700 (PDT)
X-Original-To: calsify@core3.amsl.com
Delivered-To: calsify@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 642773A68D4 for <calsify@core3.amsl.com>; Fri, 8 Apr 2011 10:00:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuAKuFutHIaR for <calsify@core3.amsl.com>; Fri, 8 Apr 2011 10:00:03 -0700 (PDT)
Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by core3.amsl.com (Postfix) with ESMTP id 99F8A3A693B for <calsify@ietf.org>; Fri, 8 Apr 2011 10:00:02 -0700 (PDT)
Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA11.westchester.pa.mail.comcast.net with comcast id V4v51g0030cZkys5B51oZp; Fri, 08 Apr 2011 17:01:48 +0000
Received: from THARE ([71.203.98.77]) by omta10.westchester.pa.mail.comcast.net with comcast id V51n1g00G1gAkVz3W51niL; Fri, 08 Apr 2011 17:01:48 +0000
From: Tim Hare <TimHare@comcast.net>
To: 'Mike Douglass' <douglm@rpi.edu>, calsify@ietf.org
References: <FA657EF8404EE7CD7A119B89@cyrus.local> <00a801cbf559$00cd2550$02676ff0$@net> <91FAC5F4A1589EEBC2DF9B9D@caldav.corp.apple.com> <4D9E1412.3060505@rpi.edu>
In-Reply-To: <4D9E1412.3060505@rpi.edu>
Date: Fri, 08 Apr 2011 13:01:41 -0400
Message-ID: <00c501cbf60e$a297bf20$e7c73d60$@net>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acv1XDJO3ivxymn+TgeNw0sGD3+ZxQAseb/A
Content-Language: en-us
Subject: Re: [calsify] iCalendar extensions draft - review please
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <calsify.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/calsify>, <mailto:calsify-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/calsify>
List-Post: <mailto:calsify@ietf.org>
List-Help: <mailto:calsify-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/calsify>, <mailto:calsify-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: calsify-bounces@ietf.org
Errors-To: calsify-bounces@ietf.org
Trying to match existing practice should probably be handled via X-IMAGE and X-COLOR, if it's proprietary implementations. -----Original Message----- From: calsify-bounces@ietf.org [mailto:calsify-bounces@ietf.org] On Behalf Of Mike Douglass Sent: Thursday, April 07, 2011 3:44 PM To: calsify@ietf.org Subject: Re: [calsify] iCalendar extensions draft - review please 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=CAL-00f18254-2d04fa82-012d-c8cf726e-000072d5calendars@rpi.edu&recurrenc eId= On 04/07/2011 03:39 PM, Cyrus Daboo wrote: > Hi Tim, > > --On April 7, 2011 3:21:31 PM -0400 Tim Hare <TimHare@comcast.net> 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 douglm@rpi.edu Senior Systems Programmer Communication& Collaboration Technologies 518 276 6780(voice) 2809 (fax) Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180 _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify
- [calsify] iCalendar extensions draft - review ple… Cyrus Daboo
- Re: [calsify] iCalendar extensions draft - review… Tim Hare
- Re: [calsify] iCalendar extensions draft - review… Cyrus Daboo
- Re: [calsify] iCalendar extensions draft - review… Mike Douglass
- Re: [calsify] iCalendar extensions draft - review… Arnaud Quillaud
- Re: [calsify] iCalendar extensions draft - review… Tim Hare