From calsify-bounces@ietf.org Fri Apr 1 08:41:39 2011 Return-Path: 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 52F3D3A6879; Fri, 1 Apr 2011 08:41:39 -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 220203A686A for ; Fri, 1 Apr 2011 08:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] 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 hJ2uugc4QtF5 for ; Fri, 1 Apr 2011 08:41:37 -0700 (PDT) Received: from smtp7.server.rpi.edu (smtp7.server.rpi.edu [128.113.2.227]) by core3.amsl.com (Postfix) with ESMTP id C80DA3A6879 for ; Fri, 1 Apr 2011 08:41:35 -0700 (PDT) Received: from [128.113.124.225] (blue-eyes-white-dragon-17.dynamic2.rpi.edu [128.113.124.225]) (authenticated bits=0) by smtp7.server.rpi.edu (8.13.1/8.13.1) with ESMTP id p31FhC0M031003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 1 Apr 2011 11:43:12 -0400 Message-ID: <4D95F290.3090809@rpi.edu> Date: Fri, 01 Apr 2011 11:43:12 -0400 From: Mike Douglass User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: calsify@ietf.org References: In-Reply-To: X-Bayes-Prob: 0.0001 (Score 0) X-RPI-SA-Score: 1.40 (*) [Hold at 10.00] RATWARE_GECKO_BUILD,22490(-25) X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.227 Subject: Re: [calsify] Individual submission: new iCalendar properties X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: calsify-bounces@ietf.org Errors-To: calsify-bounces@ietf.org Wrt Version 3: On the TZID property defined in version3... I'd prefer to see this renamed to TIMEZONE-ID. I'm aware there's a TZID property in the VTIMEZONE component but that already causes some issues with defining an extensible XML schema for use with SOAP, JAXB etc. The problem is caused by having properties and parameters with the same name and I'd rather not see the problems get worse. In addition, I'd like to see this property allowed on all components. We have many issues with all day events which are essentially floating and other floating events and - for example in athletics calendars - we find different events in different timezones. On 02/26/2010 03:07 PM, Cyrus Daboo wrote: > Hi folks, > I have just uploaded a new draft that defines some new iCalendar > properties > (). > Several of these are ones that have various X- variants floating > around, so this draft is an attempt to standardise the name and usage > as per our new IANA registry process. > > Comments welcome. > -- 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 From douglm@rpi.edu Fri Apr 1 08:41:38 2011 Return-Path: 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 220203A686A for ; Fri, 1 Apr 2011 08:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] 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 hJ2uugc4QtF5 for ; Fri, 1 Apr 2011 08:41:37 -0700 (PDT) Received: from smtp7.server.rpi.edu (smtp7.server.rpi.edu [128.113.2.227]) by core3.amsl.com (Postfix) with ESMTP id C80DA3A6879 for ; Fri, 1 Apr 2011 08:41:35 -0700 (PDT) Received: from [128.113.124.225] (blue-eyes-white-dragon-17.dynamic2.rpi.edu [128.113.124.225]) (authenticated bits=0) by smtp7.server.rpi.edu (8.13.1/8.13.1) with ESMTP id p31FhC0M031003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 1 Apr 2011 11:43:12 -0400 Message-ID: <4D95F290.3090809@rpi.edu> Date: Fri, 01 Apr 2011 11:43:12 -0400 From: Mike Douglass User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: calsify@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0) X-RPI-SA-Score: 1.40 (*) [Hold at 10.00] RATWARE_GECKO_BUILD,22490(-25) X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.227 Subject: Re: [calsify] Individual submission: new iCalendar properties X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 15:41:38 -0000 Wrt Version 3: On the TZID property defined in version3... I'd prefer to see this renamed to TIMEZONE-ID. I'm aware there's a TZID property in the VTIMEZONE component but that already causes some issues with defining an extensible XML schema for use with SOAP, JAXB etc. The problem is caused by having properties and parameters with the same name and I'd rather not see the problems get worse. In addition, I'd like to see this property allowed on all components. We have many issues with all day events which are essentially floating and other floating events and - for example in athletics calendars - we find different events in different timezones. On 02/26/2010 03:07 PM, Cyrus Daboo wrote: > Hi folks, > I have just uploaded a new draft that defines some new iCalendar > properties > (). > Several of these are ones that have various X- variants floating > around, so this draft is an attempt to standardise the name and usage > as per our new IANA registry process. > > Comments welcome. > -- 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 From Dave.Thewlis@calconnect.org Tue Apr 5 12:58:07 2011 Return-Path: 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 A963D3A6997; Tue, 5 Apr 2011 12:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 0-TxtSEST+tt; Tue, 5 Apr 2011 12:58:06 -0700 (PDT) Received: from newredwood.morsemedia.net (newredwood.morsemedia.net [69.50.246.34]) by core3.amsl.com (Postfix) with ESMTP id 780803A6407; Tue, 5 Apr 2011 12:58:05 -0700 (PDT) Received: from [75.111.59.123] (helo=[192.168.0.218]) by newredwood.morsemedia.net with esmtpa (Exim 4.69) (envelope-from ) id 1Q7CPS-0001Ix-Ne; Tue, 05 Apr 2011 12:59:30 -0700 From: Dave Thewlis Content-Type: multipart/alternative; boundary=Apple-Mail-20--543654319 Date: Tue, 5 Apr 2011 12:59:36 -0700 To: caldeveloper-l@lists.calconnect.org, caladmin-l@lists.calconnect.org, calsify@ietf.org, caldav@ietf.org, vcarddav@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-MorseMedia-MailScanner-Information: Please contact the ISP for more information X-MorseMedia-MailScanner-ID: 1Q7CPS-0001Ix-Ne X-MorseMedia-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-MorseMedia-MailScanner-SpamCheck: X-MorseMedia-MailScanner-From: dave.thewlis@calconnect.org X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - newredwood.morsemedia.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - calconnect.org Subject: [calsify] Registration is open for CalConnect XXI, May 23-27, 2011, at NASA Ames, Mountain View, California X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 19:58:07 -0000 --Apple-Mail-20--543654319 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This e-mail is going to multiple calendaring-related lists; my apologies = if you receive more than one copy but you probably will, as so many = folks are on multiple lists. Dear Colleagues, Registration is now open for CalConnect XXI, May 23-27, 2011, at NASA = Ames Research Center, Moffett Field, Mountain View, California. = Please see http://www.calconnect.org/calconnect21.shtml for logistics = and registration information.=20 As usual, we will be conducting an Interoperability Test Event = Monday-Wednesday, May 23-25. Information about the Test Event is at = http://www.calconnect.org/iop1105.shtml. The Roundtable Members' = Meeting will be Wednesday-Friday May 25-27. =20 We will be conducting a Workshop on Tasks on Wednesday afternoon during = the Roundtable. This workshop is open to non-CalConnect members and you = do not have to register for the Roundtable to attend; however you do = need to register for the workshop. See the logistics page noted above = for more information. NASA will also offer a tour of the Ames Rsearch = Center on Friday afternoon following the close of our meeting. The meeting venue is at the NASA Ames Conference Center, 500 Severyns = Avenue, located in the NASA Ames Research Center on Moffett Field. The = logistics page includes a map of the area (including the location of the = meeting venue and hotel). =20 Note well: NASA Ames is a government installation and has security = controls. If you are a U.S. citizen you must show your driver's license = or proof of identify If you are a non-citizen permanent resident you = will need to show a driver's license or passport and your "green card"). = If you are a non-citizen visitor, you will need a special invitation = from NASA and visitor pass; see the logistics page for more details. =20 The Conference Hotel will be the Sheraton Sunnyvale, which is very close = to NASA Ames. They are offering a discounted rate for our conference. = This is a courtesy rate and we do not have a room block, so you should = book early to ensure you get the special rate. We have a special = booking arrangement so be sure to review the Hotel section of the = logistics page carefully. We will be announcing additional and special sessions of interest as = more material becomes available. We expect to set the actual schedule = for TC sessions by mid-month and announce the topical agendas early in = May. =20 See you at NASA! Best Regards, Dave Thewlis -- Dave Thewlis, Executive Director CalConnect - The Calendaring and Scheduling Consortium +1 707 840 9391 voice | +1 707 498 2238 mobile | +1 415 946 3454 fax http://www.calconnect.org | Dave.Thewlis@calconnect.org --Apple-Mail-20--543654319 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
This e-mail is going to multiple calendaring-related lists; my apologies if you receive more than one copy but you probably will, as so many folks are on multiple lists.

Dear Colleagues,

Registration is now open for CalConnect XXI, May 23-27, 2011, at NASA Ames Research Center, Moffett Field, Mountain View, California.    Please see http://www.calconnect.org/calconnect21.shtml for logistics and registration information. 

As usual, we will be conducting an Interoperability Test Event Monday-Wednesday, May 23-25.  Information about the Test Event is at http://www.calconnect.org/iop1105.shtml.  The Roundtable Members' Meeting will be Wednesday-Friday May 25-27.  

We will be conducting a Workshop on Tasks on Wednesday afternoon during the Roundtable.  This workshop is open to non-CalConnect members and you do not have to register for the Roundtable to attend; however you do need to register for the workshop.  See the logistics page noted above for more information.   NASA will also offer a tour of the Ames Rsearch Center on Friday afternoon following the close of our meeting.

The meeting venue is at the NASA Ames Conference Center, 500 Severyns Avenue, located in the NASA Ames Research Center on Moffett Field.  The logistics page includes a map of the area (including the location of the meeting venue and hotel).    

Note well:  NASA Ames is a government installation and has security controls.  If you are a U.S. citizen you must show your driver's license or proof of identify  If you are a non-citizen permanent resident  you will need to show a driver's license or passport and your "green card").  If you are a non-citizen visitor, you will need a special invitation from NASA and visitor pass; see the logistics page for more details.  

The Conference Hotel will be the Sheraton Sunnyvale, which is very close to NASA Ames.  They are offering a discounted rate for our conference.  This is a courtesy rate and we do not have a room block, so you should book early to ensure you get the special rate.  We have a special booking arrangement so be sure to review the Hotel section of the logistics page carefully.

We will be announcing additional and special sessions of interest as more material becomes available.  We expect to set the actual schedule for TC sessions by mid-month and announce the topical agendas early in May.  

See you at NASA!

Best Regards,

Dave Thewlis


--
Dave Thewlis, Executive Director
CalConnect - The Calendaring and Scheduling Consortium
+1 707 840 9391 voice | +1 707 498 2238 mobile | +1 415 946 3454 fax

--Apple-Mail-20--543654319-- From calsify-bounces@ietf.org Tue Apr 5 12:58:09 2011 Return-Path: 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 943B828C138; Tue, 5 Apr 2011 12:58:09 -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 A963D3A6997; Tue, 5 Apr 2011 12:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 0-TxtSEST+tt; Tue, 5 Apr 2011 12:58:06 -0700 (PDT) Received: from newredwood.morsemedia.net (newredwood.morsemedia.net [69.50.246.34]) by core3.amsl.com (Postfix) with ESMTP id 780803A6407; Tue, 5 Apr 2011 12:58:05 -0700 (PDT) Received: from [75.111.59.123] (helo=[192.168.0.218]) by newredwood.morsemedia.net with esmtpa (Exim 4.69) (envelope-from ) id 1Q7CPS-0001Ix-Ne; Tue, 05 Apr 2011 12:59:30 -0700 From: Dave Thewlis Date: Tue, 5 Apr 2011 12:59:36 -0700 To: caldeveloper-l@lists.calconnect.org, caladmin-l@lists.calconnect.org, calsify@ietf.org, caldav@ietf.org, vcarddav@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-MorseMedia-MailScanner-Information: Please contact the ISP for more information X-MorseMedia-MailScanner-ID: 1Q7CPS-0001Ix-Ne X-MorseMedia-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-MorseMedia-MailScanner-SpamCheck: X-MorseMedia-MailScanner-From: dave.thewlis@calconnect.org X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - newredwood.morsemedia.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - calconnect.org Subject: [calsify] Registration is open for CalConnect XXI, May 23-27, 2011, at NASA Ames, Mountain View, California X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0762235892==" Sender: calsify-bounces@ietf.org Errors-To: calsify-bounces@ietf.org --===============0762235892== Content-Type: multipart/alternative; boundary=Apple-Mail-20--543654319 --Apple-Mail-20--543654319 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This e-mail is going to multiple calendaring-related lists; my apologies = if you receive more than one copy but you probably will, as so many = folks are on multiple lists. Dear Colleagues, Registration is now open for CalConnect XXI, May 23-27, 2011, at NASA = Ames Research Center, Moffett Field, Mountain View, California. = Please see http://www.calconnect.org/calconnect21.shtml for logistics = and registration information.=20 As usual, we will be conducting an Interoperability Test Event = Monday-Wednesday, May 23-25. Information about the Test Event is at = http://www.calconnect.org/iop1105.shtml. The Roundtable Members' = Meeting will be Wednesday-Friday May 25-27. =20 We will be conducting a Workshop on Tasks on Wednesday afternoon during = the Roundtable. This workshop is open to non-CalConnect members and you = do not have to register for the Roundtable to attend; however you do = need to register for the workshop. See the logistics page noted above = for more information. NASA will also offer a tour of the Ames Rsearch = Center on Friday afternoon following the close of our meeting. The meeting venue is at the NASA Ames Conference Center, 500 Severyns = Avenue, located in the NASA Ames Research Center on Moffett Field. The = logistics page includes a map of the area (including the location of the = meeting venue and hotel). =20 Note well: NASA Ames is a government installation and has security = controls. If you are a U.S. citizen you must show your driver's license = or proof of identify If you are a non-citizen permanent resident you = will need to show a driver's license or passport and your "green card"). = If you are a non-citizen visitor, you will need a special invitation = from NASA and visitor pass; see the logistics page for more details. =20 The Conference Hotel will be the Sheraton Sunnyvale, which is very close = to NASA Ames. They are offering a discounted rate for our conference. = This is a courtesy rate and we do not have a room block, so you should = book early to ensure you get the special rate. We have a special = booking arrangement so be sure to review the Hotel section of the = logistics page carefully. We will be announcing additional and special sessions of interest as = more material becomes available. We expect to set the actual schedule = for TC sessions by mid-month and announce the topical agendas early in = May. =20 See you at NASA! Best Regards, Dave Thewlis -- Dave Thewlis, Executive Director CalConnect - The Calendaring and Scheduling Consortium +1 707 840 9391 voice | +1 707 498 2238 mobile | +1 415 946 3454 fax http://www.calconnect.org | Dave.Thewlis@calconnect.org --Apple-Mail-20--543654319 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
This e-mail is going to multiple calendaring-related lists; my apologies if you receive more than one copy but you probably will, as so many folks are on multiple lists.

Dear Colleagues,

Registration is now open for CalConnect XXI, May 23-27, 2011, at NASA Ames Research Center, Moffett Field, Mountain View, California.    Please see http://www.calconnect.org/calconnect21.shtml for logistics and registration information. 

As usual, we will be conducting an Interoperability Test Event Monday-Wednesday, May 23-25.  Information about the Test Event is at http://www.calconnect.org/iop1105.shtml.  The Roundtable Members' Meeting will be Wednesday-Friday May 25-27.  

We will be conducting a Workshop on Tasks on Wednesday afternoon during the Roundtable.  This workshop is open to non-CalConnect members and you do not have to register for the Roundtable to attend; however you do need to register for the workshop.  See the logistics page noted above for more information.   NASA will also offer a tour of the Ames Rsearch Center on Friday afternoon following the close of our meeting.

The meeting venue is at the NASA Ames Conference Center, 500 Severyns Avenue, located in the NASA Ames Research Center on Moffett Field.  The logistics page includes a map of the area (including the location of the meeting venue and hotel).    

Note well:  NASA Ames is a government installation and has security controls.  If you are a U.S. citizen you must show your driver's license or proof of identify  If you are a non-citizen permanent resident  you will need to show a driver's license or passport and your "green card").  If you are a non-citizen visitor, you will need a special invitation from NASA and visitor pass; see the logistics page for more details.  

The Conference Hotel will be the Sheraton Sunnyvale, which is very close to NASA Ames.  They are offering a discounted rate for our conference.  This is a courtesy rate and we do not have a room block, so you should book early to ensure you get the special rate.  We have a special booking arrangement so be sure to review the Hotel section of the logistics page carefully.

We will be announcing additional and special sessions of interest as more material becomes available.  We expect to set the actual schedule for TC sessions by mid-month and announce the topical agendas early in May.  

See you at NASA!

Best Regards,

Dave Thewlis


--
Dave Thewlis, Executive Director
CalConnect - The Calendaring and Scheduling Consortium
+1 707 840 9391 voice | +1 707 498 2238 mobile | +1 415 946 3454 fax

--Apple-Mail-20--543654319-- --===============0762235892== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify --===============0762235892==-- From calsify-bounces@ietf.org Thu Apr 7 09:29:17 2011 Return-Path: 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 431E328C121; Thu, 7 Apr 2011 09:29:17 -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 184F728C112 for ; Thu, 7 Apr 2011 09:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.799 X-Spam-Level: X-Spam-Status: No, score=-103.799 tagged_above=-999 required=5 tests=[AWL=-1.200, 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 aOqVBPzrzUkQ for ; Thu, 7 Apr 2011 09:29:15 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id 6703928C102 for ; Thu, 7 Apr 2011 09:29:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 810A31C60595E for ; Thu, 7 Apr 2011 12:30:59 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07XfKhNKuPAu for ; Thu, 7 Apr 2011 12:30:59 -0400 (EDT) Received: from [10.0.1.7] (unknown [17.101.34.182]) by daboo.name (Postfix) with ESMTPSA id ADDDE1C605953 for ; Thu, 7 Apr 2011 12:30:58 -0400 (EDT) Date: Thu, 07 Apr 2011 12:31:08 -0400 From: Cyrus Daboo To: calsify@ietf.org Message-ID: X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline; size=363 Subject: [calsify] iCalendar extensions draft - review please X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: calsify-bounces@ietf.org Errors-To: calsify-bounces@ietf.org 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 calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify From cyrus@daboo.name Thu Apr 7 09:29:16 2011 Return-Path: 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 184F728C112 for ; Thu, 7 Apr 2011 09:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.799 X-Spam-Level: X-Spam-Status: No, score=-103.799 tagged_above=-999 required=5 tests=[AWL=-1.200, 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 aOqVBPzrzUkQ for ; Thu, 7 Apr 2011 09:29:15 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id 6703928C102 for ; Thu, 7 Apr 2011 09:29:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 810A31C60595E for ; Thu, 7 Apr 2011 12:30:59 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07XfKhNKuPAu for ; Thu, 7 Apr 2011 12:30:59 -0400 (EDT) Received: from [10.0.1.7] (unknown [17.101.34.182]) by daboo.name (Postfix) with ESMTPSA id ADDDE1C605953 for ; Thu, 7 Apr 2011 12:30:58 -0400 (EDT) Date: Thu, 07 Apr 2011 12:31:08 -0400 From: Cyrus Daboo To: calsify@ietf.org Message-ID: X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=363 Subject: [calsify] iCalendar extensions draft - review please X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 16:29:16 -0000 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 From timhare@comcast.net Thu Apr 7 12:19:52 2011 Return-Path: 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 C0D733A6957 for ; Thu, 7 Apr 2011 12:19:52 -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 nqOn7RMhfY4u for ; Thu, 7 Apr 2011 12:19:51 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by core3.amsl.com (Postfix) with ESMTP id 805123A690A for ; Thu, 7 Apr 2011 12:19:51 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta15.westchester.pa.mail.comcast.net with comcast id UjLD1g0061HzFnQ5FjMdr3; Thu, 07 Apr 2011 19:21:37 +0000 Received: from THARE ([71.203.98.77]) by omta14.westchester.pa.mail.comcast.net with comcast id UjMb1g00m1gAkVz3ajMcnU; Thu, 07 Apr 2011 19:21:36 +0000 From: "Tim Hare" To: "'Cyrus Daboo'" , References: In-Reply-To: Date: Thu, 7 Apr 2011 15:21:31 -0400 Message-ID: <00a801cbf559$00cd2550$02676ff0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv1QTAr+QTXq3zpQDu7c/2gOr9+0AAFVLFg 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 19:19:52 -0000 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: calsify-bounces@ietf.org [mailto:calsify-bounces@ietf.org] On Behalf Of Cyrus Daboo Sent: Thursday, April 07, 2011 12:31 PM To: calsify@ietf.org Subject: [calsify] iCalendar extensions draft - review please 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 calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify From calsify-bounces@ietf.org Thu Apr 7 12:19:53 2011 Return-Path: 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 993CC3A6957; Thu, 7 Apr 2011 12:19:53 -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 C0D733A6957 for ; Thu, 7 Apr 2011 12:19:52 -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 nqOn7RMhfY4u for ; Thu, 7 Apr 2011 12:19:51 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by core3.amsl.com (Postfix) with ESMTP id 805123A690A for ; Thu, 7 Apr 2011 12:19:51 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta15.westchester.pa.mail.comcast.net with comcast id UjLD1g0061HzFnQ5FjMdr3; Thu, 07 Apr 2011 19:21:37 +0000 Received: from THARE ([71.203.98.77]) by omta14.westchester.pa.mail.comcast.net with comcast id UjMb1g00m1gAkVz3ajMcnU; Thu, 07 Apr 2011 19:21:36 +0000 From: "Tim Hare" To: "'Cyrus Daboo'" , References: In-Reply-To: Date: Thu, 7 Apr 2011 15:21:31 -0400 Message-ID: <00a801cbf559$00cd2550$02676ff0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv1QTAr+QTXq3zpQDu7c/2gOr9+0AAFVLFg 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: calsify-bounces@ietf.org Errors-To: calsify-bounces@ietf.org 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: calsify-bounces@ietf.org [mailto:calsify-bounces@ietf.org] On Behalf Of Cyrus Daboo Sent: Thursday, April 07, 2011 12:31 PM To: calsify@ietf.org Subject: [calsify] iCalendar extensions draft - review please 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 calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify From cyrus@daboo.name Thu Apr 7 12:37:45 2011 Return-Path: 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 DE3CE28C0D6 for ; Thu, 7 Apr 2011 12:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.69 X-Spam-Level: X-Spam-Status: No, score=-103.69 tagged_above=-999 required=5 tests=[AWL=-1.091, 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 ByXZaCZ6dZdF for ; Thu, 7 Apr 2011 12:37:43 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id A14573A690A for ; Thu, 7 Apr 2011 12:37:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 23E541C6064A8; Thu, 7 Apr 2011 15:39:27 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2OEY8jUgr0D; Thu, 7 Apr 2011 15:39:26 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTPSA id CFA281C60649D; Thu, 7 Apr 2011 15:39:25 -0400 (EDT) Date: Thu, 07 Apr 2011 15:39:23 -0400 From: Cyrus Daboo To: Tim Hare , calsify@ietf.org Message-ID: <91FAC5F4A1589EEBC2DF9B9D@caldav.corp.apple.com> In-Reply-To: <00a801cbf559$00cd2550$02676ff0$@net> References: <00a801cbf559$00cd2550$02676ff0$@net> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=3036 Subject: Re: [calsify] iCalendar extensions draft - review please X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 19:37:46 -0000 Hi Tim, --On April 7, 2011 3:21:31 PM -0400 Tim Hare 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. -- Cyrus Daboo From calsify-bounces@ietf.org Thu Apr 7 12:37:47 2011 Return-Path: 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 A19F128C0D6; Thu, 7 Apr 2011 12:37:47 -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 DE3CE28C0D6 for ; Thu, 7 Apr 2011 12:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.69 X-Spam-Level: X-Spam-Status: No, score=-103.69 tagged_above=-999 required=5 tests=[AWL=-1.091, 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 ByXZaCZ6dZdF for ; Thu, 7 Apr 2011 12:37:43 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id A14573A690A for ; Thu, 7 Apr 2011 12:37:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 23E541C6064A8; Thu, 7 Apr 2011 15:39:27 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2OEY8jUgr0D; Thu, 7 Apr 2011 15:39:26 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTPSA id CFA281C60649D; Thu, 7 Apr 2011 15:39:25 -0400 (EDT) Date: Thu, 07 Apr 2011 15:39:23 -0400 From: Cyrus Daboo To: Tim Hare , calsify@ietf.org Message-ID: <91FAC5F4A1589EEBC2DF9B9D@caldav.corp.apple.com> In-Reply-To: <00a801cbf559$00cd2550$02676ff0$@net> References: <00a801cbf559$00cd2550$02676ff0$@net> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline; size=3036 Subject: Re: [calsify] iCalendar extensions draft - review please X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: calsify-bounces@ietf.org Errors-To: calsify-bounces@ietf.org Hi Tim, --On April 7, 2011 3:21:31 PM -0400 Tim Hare 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. -- Cyrus Daboo _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify From calsify-bounces@ietf.org Thu Apr 7 12:42:37 2011 Return-Path: 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 5A6763A696D; Thu, 7 Apr 2011 12:42:37 -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 32C873A696D for ; Thu, 7 Apr 2011 12:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] 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 6YP5lpRVC7K9 for ; Thu, 7 Apr 2011 12:42:35 -0700 (PDT) Received: from smtp5.server.rpi.edu (smtp5.server.rpi.edu [128.113.2.225]) by core3.amsl.com (Postfix) with ESMTP id D19DE3A690A for ; Thu, 7 Apr 2011 12:42:34 -0700 (PDT) Received: from [128.113.124.225] (blue-eyes-white-dragon-17.dynamic2.rpi.edu [128.113.124.225]) (authenticated bits=0) by smtp5.server.rpi.edu (8.13.1/8.13.1) with ESMTP id p37JiIgO016473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 7 Apr 2011 15:44:18 -0400 Message-ID: <4D9E1412.3060505@rpi.edu> Date: Thu, 07 Apr 2011 15:44:18 -0400 From: Mike Douglass User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: calsify@ietf.org References: <00a801cbf559$00cd2550$02676ff0$@net> <91FAC5F4A1589EEBC2DF9B9D@caldav.corp.apple.com> In-Reply-To: <91FAC5F4A1589EEBC2DF9B9D@caldav.corp.apple.com> X-Bayes-Prob: 0.0001 (Score 0) X-RPI-SA-Score: 1.40 (*) [Hold at 10.00] RATWARE_GECKO_BUILD,22490(-25) X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.225 Subject: Re: [calsify] iCalendar extensions draft - review please X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: calsify-bounces@ietf.org Errors-To: calsify-bounces@ietf.org 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&recurrenceId= On 04/07/2011 03:39 PM, Cyrus Daboo wrote: > Hi Tim, > > --On April 7, 2011 3:21:31 PM -0400 Tim Hare 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 From douglm@rpi.edu Thu Apr 7 12:42:36 2011 Return-Path: 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 32C873A696D for ; Thu, 7 Apr 2011 12:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] 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 6YP5lpRVC7K9 for ; Thu, 7 Apr 2011 12:42:35 -0700 (PDT) Received: from smtp5.server.rpi.edu (smtp5.server.rpi.edu [128.113.2.225]) by core3.amsl.com (Postfix) with ESMTP id D19DE3A690A for ; Thu, 7 Apr 2011 12:42:34 -0700 (PDT) Received: from [128.113.124.225] (blue-eyes-white-dragon-17.dynamic2.rpi.edu [128.113.124.225]) (authenticated bits=0) by smtp5.server.rpi.edu (8.13.1/8.13.1) with ESMTP id p37JiIgO016473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 7 Apr 2011 15:44:18 -0400 Message-ID: <4D9E1412.3060505@rpi.edu> Date: Thu, 07 Apr 2011 15:44:18 -0400 From: Mike Douglass User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: calsify@ietf.org References: <00a801cbf559$00cd2550$02676ff0$@net> <91FAC5F4A1589EEBC2DF9B9D@caldav.corp.apple.com> In-Reply-To: <91FAC5F4A1589EEBC2DF9B9D@caldav.corp.apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0) X-RPI-SA-Score: 1.40 (*) [Hold at 10.00] RATWARE_GECKO_BUILD,22490(-25) X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.225 Subject: Re: [calsify] iCalendar extensions draft - review please X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 19:42:36 -0000 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&recurrenceId= On 04/07/2011 03:39 PM, Cyrus Daboo wrote: > Hi Tim, > > --On April 7, 2011 3:21:31 PM -0400 Tim Hare 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 From quillaud@gmail.com Fri Apr 8 02:57:38 2011 Return-Path: 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 332F628C0E9 for ; Fri, 8 Apr 2011 02:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 y+QZqQ7WH3JD for ; Fri, 8 Apr 2011 02:57:37 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 431BE3A69EE for ; Fri, 8 Apr 2011 02:57:37 -0700 (PDT) Received: by wwa36 with SMTP id 36so2839296wwa.13 for ; Fri, 08 Apr 2011 02:59:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=OpTCwp/UNRrqjrnikdBXXQE8jtOxH8XdOCLQMT7lSR4=; b=cz8m29AsDy2e8G5r+3WjnN5yR/5+dlMrc1io/u5CN2cXK99MJw179gbtByKwkq+fFN Aos9EHCayWZ763E+VGwFaNh0u07g4zUj6q1N7GP/J5vVaoM74TuKvtVoaC39kkrhKeSG WFtPlmrBdw1KiA/com7A88K0QhhQsIEVwANtQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=C9XsGf1TKG+PzR/dEdrojwpjO4HE8AeWeQ/hU4435KD/bzxvRyD1nR7nzJIISvW6fR lUG60Jkf0shLAUJs1rJuzfDFg5zBFolccKrnuzdC/unXmmwsaTl26Si31J1e6YcAAv/e dcy8T8T5Aevly7EZ1mwZNUbyxNqADEub6tnF0= Received: by 10.216.184.129 with SMTP id s1mr1785991wem.32.1302256762005; Fri, 08 Apr 2011 02:59:22 -0700 (PDT) Received: from [192.168.0.60] (ron34-2-82-227-203-159.fbx.proxad.net [82.227.203.159]) by mx.google.com with ESMTPS id w25sm1590710wbd.22.2011.04.08.02.59.20 (version=SSLv3 cipher=OTHER); Fri, 08 Apr 2011 02:59:21 -0700 (PDT) Sender: Arnaud Quillaud Message-ID: <4D9EDC77.8060604@quillaud.org> Date: Fri, 08 Apr 2011 11:59:19 +0200 From: Arnaud Quillaud User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 OracleBeehiveExtension/1.1.0.0pre29-Alpha Thunderbird/3.1.8 MIME-Version: 1.0 To: calsify@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [calsify] iCalendar extensions draft - review please X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 09:57:38 -0000 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 calsify-bounces@ietf.org Fri Apr 8 02:57:39 2011 Return-Path: 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 603F428C0E9; Fri, 8 Apr 2011 02:57:39 -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 332F628C0E9 for ; Fri, 8 Apr 2011 02:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 y+QZqQ7WH3JD for ; Fri, 8 Apr 2011 02:57:37 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 431BE3A69EE for ; Fri, 8 Apr 2011 02:57:37 -0700 (PDT) Received: by wwa36 with SMTP id 36so2839296wwa.13 for ; Fri, 08 Apr 2011 02:59:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=OpTCwp/UNRrqjrnikdBXXQE8jtOxH8XdOCLQMT7lSR4=; b=cz8m29AsDy2e8G5r+3WjnN5yR/5+dlMrc1io/u5CN2cXK99MJw179gbtByKwkq+fFN Aos9EHCayWZ763E+VGwFaNh0u07g4zUj6q1N7GP/J5vVaoM74TuKvtVoaC39kkrhKeSG WFtPlmrBdw1KiA/com7A88K0QhhQsIEVwANtQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=C9XsGf1TKG+PzR/dEdrojwpjO4HE8AeWeQ/hU4435KD/bzxvRyD1nR7nzJIISvW6fR lUG60Jkf0shLAUJs1rJuzfDFg5zBFolccKrnuzdC/unXmmwsaTl26Si31J1e6YcAAv/e dcy8T8T5Aevly7EZ1mwZNUbyxNqADEub6tnF0= Received: by 10.216.184.129 with SMTP id s1mr1785991wem.32.1302256762005; Fri, 08 Apr 2011 02:59:22 -0700 (PDT) Received: from [192.168.0.60] (ron34-2-82-227-203-159.fbx.proxad.net [82.227.203.159]) by mx.google.com with ESMTPS id w25sm1590710wbd.22.2011.04.08.02.59.20 (version=SSLv3 cipher=OTHER); Fri, 08 Apr 2011 02:59:21 -0700 (PDT) Message-ID: <4D9EDC77.8060604@quillaud.org> Date: Fri, 08 Apr 2011 11:59:19 +0200 From: Arnaud Quillaud User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 OracleBeehiveExtension/1.1.0.0pre29-Alpha Thunderbird/3.1.8 MIME-Version: 1.0 To: calsify@ietf.org References: In-Reply-To: Subject: Re: [calsify] iCalendar extensions draft - review please X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: calsify-bounces@ietf.org Errors-To: calsify-bounces@ietf.org 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 _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify From douglm@rpi.edu Fri Apr 8 07:15:30 2011 Return-Path: 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 886083A6918 for ; Fri, 8 Apr 2011 07:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] 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 Lsh0SOt-eyd2 for ; Fri, 8 Apr 2011 07:15:30 -0700 (PDT) Received: from smtp5.server.rpi.edu (smtp5.server.rpi.edu [128.113.2.225]) by core3.amsl.com (Postfix) with ESMTP id D5AE83A690C for ; Fri, 8 Apr 2011 07:15:29 -0700 (PDT) Received: from [128.113.124.225] (blue-eyes-white-dragon-17.dynamic2.rpi.edu [128.113.124.225]) (authenticated bits=0) by smtp5.server.rpi.edu (8.13.1/8.13.1) with ESMTP id p38EH9ef013972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Apr 2011 10:17:10 -0400 Message-ID: <4D9F18E5.8010104@rpi.edu> Date: Fri, 08 Apr 2011 10:17:09 -0400 From: Mike Douglass User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Cyrus Daboo , calsify@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.5795 (Score 0) X-RPI-SA-Score: 1.40 (*) [Hold at 10.00] RATWARE_GECKO_BUILD,22490(-25) X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.225 Subject: [calsify] availability question X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 14:15:30 -0000 What's the interaction of (v)availability with date-ranged queries? Do we need a limit-availability-set? (probably overkill) Does finding any (sub)component in a supplied date-range imply returning ALL of the available components? In: BEGIN:VAVAILABILITY ORGANIZER:mailto:bernard@example.com UID:20061005T133225Z-00001@example.com DTSTAMP:20061005T133225Z DTSTART;TZID=America/Montreal:20061002T000000 BEGIN:AVAILABLE UID:20061005T133225Z-00001-A@example.com SUMMARY:Monday to Friday from 9:00 to 17:00 DTSTART;TZID=America/Montreal:20061002T090000 DTEND;TZID=America/Montreal:20061002T170000 RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR END:AVAILABLE END:VAVAILABILITY If we search for a date range that covers the weekend only the AVAILABLE doesn't cover it but the date range on the VAVAILABILITY does - though what does the DTSTART by itself mean? For events For cases where a "VEVENT" calendar component specifies a "DTSTART" property with a DATE value type but no "DTEND" nor "DURATION" property, the event's duration is taken to be one day. For cases where a "VEVENT" calendar component specifies a "DTSTART" property with a DATE-TIME value type but no "DTEND" property, the event ends on the same calendar date and time of day specified by the "DTSTART" property. Tasks and journals it doesn't say: You seem to be defining DTSTART standing alone as meaning it starts on the given date(-time) and continues. Should we do that? I argued against doing that with some of the smart-grid components on the grounds of compatability with event usage -- 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 From calsify-bounces@ietf.org Fri Apr 8 07:15:31 2011 Return-Path: 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 E73223A6918; Fri, 8 Apr 2011 07:15:31 -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 886083A6918 for ; Fri, 8 Apr 2011 07:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] 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 Lsh0SOt-eyd2 for ; Fri, 8 Apr 2011 07:15:30 -0700 (PDT) Received: from smtp5.server.rpi.edu (smtp5.server.rpi.edu [128.113.2.225]) by core3.amsl.com (Postfix) with ESMTP id D5AE83A690C for ; Fri, 8 Apr 2011 07:15:29 -0700 (PDT) Received: from [128.113.124.225] (blue-eyes-white-dragon-17.dynamic2.rpi.edu [128.113.124.225]) (authenticated bits=0) by smtp5.server.rpi.edu (8.13.1/8.13.1) with ESMTP id p38EH9ef013972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Apr 2011 10:17:10 -0400 Message-ID: <4D9F18E5.8010104@rpi.edu> Date: Fri, 08 Apr 2011 10:17:09 -0400 From: Mike Douglass User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Cyrus Daboo , calsify@ietf.org X-Bayes-Prob: 0.5795 (Score 0) X-RPI-SA-Score: 1.40 (*) [Hold at 10.00] RATWARE_GECKO_BUILD,22490(-25) X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.225 Subject: [calsify] availability question X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: calsify-bounces@ietf.org Errors-To: calsify-bounces@ietf.org What's the interaction of (v)availability with date-ranged queries? Do we need a limit-availability-set? (probably overkill) Does finding any (sub)component in a supplied date-range imply returning ALL of the available components? In: BEGIN:VAVAILABILITY ORGANIZER:mailto:bernard@example.com UID:20061005T133225Z-00001@example.com DTSTAMP:20061005T133225Z DTSTART;TZID=America/Montreal:20061002T000000 BEGIN:AVAILABLE UID:20061005T133225Z-00001-A@example.com SUMMARY:Monday to Friday from 9:00 to 17:00 DTSTART;TZID=America/Montreal:20061002T090000 DTEND;TZID=America/Montreal:20061002T170000 RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR END:AVAILABLE END:VAVAILABILITY If we search for a date range that covers the weekend only the AVAILABLE doesn't cover it but the date range on the VAVAILABILITY does - though what does the DTSTART by itself mean? For events For cases where a "VEVENT" calendar component specifies a "DTSTART" property with a DATE value type but no "DTEND" nor "DURATION" property, the event's duration is taken to be one day. For cases where a "VEVENT" calendar component specifies a "DTSTART" property with a DATE-TIME value type but no "DTEND" property, the event ends on the same calendar date and time of day specified by the "DTSTART" property. Tasks and journals it doesn't say: You seem to be defining DTSTART standing alone as meaning it starts on the given date(-time) and continues. Should we do that? I argued against doing that with some of the smart-grid components on the grounds of compatability with event usage -- 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 From calsify-bounces@ietf.org Fri Apr 8 10:00:07 2011 Return-Path: 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 ; 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 ; 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 ; 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" To: "'Mike Douglass'" , References: <00a801cbf559$00cd2550$02676ff0$@net> <91FAC5F4A1589EEBC2DF9B9D@caldav.corp.apple.com> <4D9E1412.3060505@rpi.edu> In-Reply-To: <4D9E1412.3060505@rpi.edu> Date: Fri, 8 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 From timhare@comcast.net Fri Apr 8 10:00:05 2011 Return-Path: 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 ; 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 ; 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 ; 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" To: "'Mike Douglass'" , References: <00a801cbf559$00cd2550$02676ff0$@net> <91FAC5F4A1589EEBC2DF9B9D@caldav.corp.apple.com> <4D9E1412.3060505@rpi.edu> In-Reply-To: <4D9E1412.3060505@rpi.edu> Date: Fri, 8 Apr 2011 13:01:41 -0400 Message-ID: <00c501cbf60e$a297bf20$e7c73d60$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 17:00:05 -0000 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 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 From quillaud@gmail.com Mon Apr 18 05:14:54 2011 Return-Path: X-Original-To: calsify@ietfc.amsl.com Delivered-To: calsify@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 69B6FE06AF for ; Mon, 18 Apr 2011 05:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjHqEF4KaqVW for ; Mon, 18 Apr 2011 05:14:50 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 30AE1E065A for ; Mon, 18 Apr 2011 05:14:47 -0700 (PDT) Received: by wyb29 with SMTP id 29so4353362wyb.31 for ; Mon, 18 Apr 2011 05:14:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; bh=+eOfCn7wwmd/iddkvWv4LTtC8M9cYgMFy/OAv/14ZJM=; b=o2ugCpEH/tVqRNA87Pb9b2TkwV3S3YQGl0ENzAEX8vpe9l3N551LKM6B5ywTa3TqAn A0+UsIw3hEU2wJ9My/t9yYVRBQKtj/Rcq1wCQC3aOzi+G+3ocm1oVCOURatxV/C0zFWr lgCrhuw2TViBMZYu1h1A6/VeAJhoS8UWgQ1Bw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=VvotfnAUiHlrtqyKuc2WH1q0OraKbWJZk3yqRFZv+Vb/otda6XjWlofT/ijp8jJTPQ AHOx/crlFQcGnn4QwvcAjbYmweb05VGHY/6tu12cOEyDXSEjSIlMwNSXVDRp9FERPdea Cd7sZbNUaXr+EkyzY1KzaqI/f7lSkkDn1WGJQ= Received: by 10.227.206.84 with SMTP id ft20mr2778979wbb.161.1303128886208; Mon, 18 Apr 2011 05:14:46 -0700 (PDT) Received: from [192.168.0.60] (ron34-2-82-227-203-159.fbx.proxad.net [82.227.203.159]) by mx.google.com with ESMTPS id p5sm3225761wbg.28.2011.04.18.05.14.44 (version=SSLv3 cipher=OTHER); Mon, 18 Apr 2011 05:14:45 -0700 (PDT) Sender: Arnaud Quillaud Message-ID: <4DAC2B33.1050507@quillaud.org> Date: Mon, 18 Apr 2011 14:14:43 +0200 From: Arnaud Quillaud User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 OracleBeehiveExtension/1.1.0.0pre29-Alpha Thunderbird/3.1.8 MIME-Version: 1.0 To: calsify@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [calsify] xCal examples (unescaping) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 12:14:54 -0000 In the examples at http://tools.ietf.org/html/draft-daboo-et-al-icalendar-in-xml-08#appendix-B , it would have been nice to show the unfolding and unescaping of properties and parameter values in the example (e.g. removal of \n in DESCRIPTION value, removal of double quote and comma escaping in parameters). + a really minor detail: Section 3 is titled "Converting from iCalendar to xCal" when section 4 is called "Converting from XML into iCalendar" instead of "Converting from xCal to iCalendar" Looks really good otherwise, Arnaud Quillaud From calsify-bounces@ietf.org Mon Apr 18 05:14:55 2011 Return-Path: X-Original-To: calsify-archive-feit0ahl@lists.ietf.org Delivered-To: ietfarch-calsify-archive-Feit0ahl@ietfc.amsl.com Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 973D7E06AF; Mon, 18 Apr 2011 05:14:55 -0700 (PDT) X-Original-To: calsify@ietfc.amsl.com Delivered-To: calsify@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 69B6FE06AF for ; Mon, 18 Apr 2011 05:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjHqEF4KaqVW for ; Mon, 18 Apr 2011 05:14:50 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 30AE1E065A for ; Mon, 18 Apr 2011 05:14:47 -0700 (PDT) Received: by wyb29 with SMTP id 29so4353362wyb.31 for ; Mon, 18 Apr 2011 05:14:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; bh=+eOfCn7wwmd/iddkvWv4LTtC8M9cYgMFy/OAv/14ZJM=; b=o2ugCpEH/tVqRNA87Pb9b2TkwV3S3YQGl0ENzAEX8vpe9l3N551LKM6B5ywTa3TqAn A0+UsIw3hEU2wJ9My/t9yYVRBQKtj/Rcq1wCQC3aOzi+G+3ocm1oVCOURatxV/C0zFWr lgCrhuw2TViBMZYu1h1A6/VeAJhoS8UWgQ1Bw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=VvotfnAUiHlrtqyKuc2WH1q0OraKbWJZk3yqRFZv+Vb/otda6XjWlofT/ijp8jJTPQ AHOx/crlFQcGnn4QwvcAjbYmweb05VGHY/6tu12cOEyDXSEjSIlMwNSXVDRp9FERPdea Cd7sZbNUaXr+EkyzY1KzaqI/f7lSkkDn1WGJQ= Received: by 10.227.206.84 with SMTP id ft20mr2778979wbb.161.1303128886208; Mon, 18 Apr 2011 05:14:46 -0700 (PDT) Received: from [192.168.0.60] (ron34-2-82-227-203-159.fbx.proxad.net [82.227.203.159]) by mx.google.com with ESMTPS id p5sm3225761wbg.28.2011.04.18.05.14.44 (version=SSLv3 cipher=OTHER); Mon, 18 Apr 2011 05:14:45 -0700 (PDT) Message-ID: <4DAC2B33.1050507@quillaud.org> Date: Mon, 18 Apr 2011 14:14:43 +0200 From: Arnaud Quillaud User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 OracleBeehiveExtension/1.1.0.0pre29-Alpha Thunderbird/3.1.8 MIME-Version: 1.0 To: calsify@ietf.org Subject: [calsify] xCal examples (unescaping) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: calsify-bounces@ietf.org Errors-To: calsify-bounces@ietf.org In the examples at http://tools.ietf.org/html/draft-daboo-et-al-icalendar-in-xml-08#appendix-B , it would have been nice to show the unfolding and unescaping of properties and parameter values in the example (e.g. removal of \n in DESCRIPTION value, removal of double quote and comma escaping in parameters). + a really minor detail: Section 3 is titled "Converting from iCalendar to xCal" when section 4 is called "Converting from XML into iCalendar" instead of "Converting from xCal to iCalendar" Looks really good otherwise, Arnaud Quillaud _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify From calsify-bounces@ietf.org Mon Apr 18 07:06:11 2011 Return-Path: X-Original-To: calsify-archive-feit0ahl@lists.ietf.org Delivered-To: ietfarch-calsify-archive-Feit0ahl@ietfc.amsl.com Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 10032E0770; Mon, 18 Apr 2011 07:06:11 -0700 (PDT) X-Original-To: calsify@ietfc.amsl.com Delivered-To: calsify@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 251FAE0770 for ; Mon, 18 Apr 2011 07:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tm02jjwMSbmU for ; Mon, 18 Apr 2011 07:06:06 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by ietfc.amsl.com (Postfix) with ESMTP id 0E8BFE06D6 for ; Mon, 18 Apr 2011 07:06:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id AA6891C7E63C2; Mon, 18 Apr 2011 10:06:05 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtJNDbeK1zQz; Mon, 18 Apr 2011 10:05:58 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTPSA id 85D371C7E63B0; Mon, 18 Apr 2011 10:05:57 -0400 (EDT) Date: Mon, 18 Apr 2011 10:05:54 -0400 From: Cyrus Daboo To: Arnaud Quillaud , calsify@ietf.org Message-ID: <7695942845478CF074997DCC@caldav.corp.apple.com> In-Reply-To: <4DAC2B33.1050507@quillaud.org> References: <4DAC2B33.1050507@quillaud.org> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline; size=721 Subject: Re: [calsify] xCal examples (unescaping) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: calsify-bounces@ietf.org Errors-To: calsify-bounces@ietf.org Hi Arnaud, --On April 18, 2011 2:14:43 PM +0200 Arnaud Quillaud wrote: > In the examples at > http://tools.ietf.org/html/draft-daboo-et-al-icalendar-in-xml-08#appendix > -B , it would have been nice to show the unfolding and unescaping of > properties and parameter values in the example (e.g. removal of \n in > DESCRIPTION value, removal of double quote and comma escaping in > parameters). Good idea - I will change the examples to cover those cases. > + a really minor detail: Section 3 is titled "Converting from iCalendar > to xCal" when section 4 is called "Converting from XML into iCalendar" > instead of "Converting from xCal to iCalendar" Thanks, I will fix that. -- Cyrus Daboo _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify From cyrus@daboo.name Mon Apr 18 07:06:10 2011 Return-Path: X-Original-To: calsify@ietfc.amsl.com Delivered-To: calsify@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 251FAE0770 for ; Mon, 18 Apr 2011 07:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tm02jjwMSbmU for ; Mon, 18 Apr 2011 07:06:06 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by ietfc.amsl.com (Postfix) with ESMTP id 0E8BFE06D6 for ; Mon, 18 Apr 2011 07:06:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id AA6891C7E63C2; Mon, 18 Apr 2011 10:06:05 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtJNDbeK1zQz; Mon, 18 Apr 2011 10:05:58 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTPSA id 85D371C7E63B0; Mon, 18 Apr 2011 10:05:57 -0400 (EDT) Date: Mon, 18 Apr 2011 10:05:54 -0400 From: Cyrus Daboo To: Arnaud Quillaud , calsify@ietf.org Message-ID: <7695942845478CF074997DCC@caldav.corp.apple.com> In-Reply-To: <4DAC2B33.1050507@quillaud.org> References: <4DAC2B33.1050507@quillaud.org> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=721 Subject: Re: [calsify] xCal examples (unescaping) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 14:06:10 -0000 Hi Arnaud, --On April 18, 2011 2:14:43 PM +0200 Arnaud Quillaud wrote: > In the examples at > http://tools.ietf.org/html/draft-daboo-et-al-icalendar-in-xml-08#appendix > -B , it would have been nice to show the unfolding and unescaping of > properties and parameter values in the example (e.g. removal of \n in > DESCRIPTION value, removal of double quote and comma escaping in > parameters). Good idea - I will change the examples to cover those cases. > + a really minor detail: Section 3 is titled "Converting from iCalendar > to xCal" when section 4 is called "Converting from XML into iCalendar" > instead of "Converting from xCal to iCalendar" Thanks, I will fix that. -- Cyrus Daboo From calsify-bounces@ietf.org Wed Apr 20 08:02:29 2011 Return-Path: X-Original-To: calsify-archive-feit0ahl@lists.ietf.org Delivered-To: ietfarch-calsify-archive-Feit0ahl@ietfc.amsl.com Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3A730E075F; Wed, 20 Apr 2011 08:02:29 -0700 (PDT) X-Original-To: calsify@ietfc.amsl.com Delivered-To: calsify@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3A12DE075F; Wed, 20 Apr 2011 08:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.068 X-Spam-Level: X-Spam-Status: No, score=-102.068 tagged_above=-999 required=5 tests=[AWL=-0.865, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EH8GIrFGY6zK; Wed, 20 Apr 2011 08:02:27 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by ietfc.amsl.com (Postfix) with ESMTP id 47EF8E073A; Wed, 20 Apr 2011 08:02:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id A85961C842C0D; Wed, 20 Apr 2011 11:02:23 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NG0dkfJBh8Pf; Wed, 20 Apr 2011 11:02:18 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTPSA id C87D51C842BFC; Wed, 20 Apr 2011 11:02:16 -0400 (EDT) Date: Wed, 20 Apr 2011 11:02:13 -0400 From: Cyrus Daboo To: Arnaud Quillaud , CardDAV Message-ID: In-Reply-To: <4DAEEB3D.5080205@quillaud.org> References: <4DAEEB3D.5080205@quillaud.org> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline; size=2415 Cc: Calsify Subject: Re: [calsify] [VCARDDAV] GENDER property inconsistency X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: calsify-bounces@ietf.org Errors-To: calsify-bounces@ietf.org SGkgQXJuYXVkLAooY2MnZCBjYWxzaWZ5IGxpc3QgYmVjYXVzZSBvZiBjb21tZW50IGF0IHRoZSBl bmQgcHJvcG9zaW5nIGEgY2hhbmdlIGluIHhDYWwpCgotLU9uIEFwcmlsIDIwLCAyMDExIDQ6MTg6 MzcgUE0gKzAyMDAgQXJuYXVkIFF1aWxsYXVkIDxhcm5hdWRxQHF1aWxsYXVkLm9yZz4gCndyb3Rl OgoKPiB3aGVuIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdmNhcmRkYXYt dmNhcmR4bWwtMDkgZGVmaW5lcwo+IGl0IGFzOgo+Cj4gPDwKPgo+IHByb3BlcnR5LWdlbmRlciA9 IGVsZW1lbnQgZ2VuZGVyIHsKPiAgICAgIGVsZW1lbnQgc2V4IHsKPiAgICAgICAgZWxlbWVudCB0 ZXh0IHsgIk0iIHwgIkYiIHwgIk8iIHwgIk4iIHwgIlUiIH0/Cj4gICAgICB9LAo+ICAgICAgZWxl bWVudCBpZGVudGl0eSB7IHZhbHVlLXRleHQtbGlzdD8gfQo+ICAgIH0KPgo+ICA+Pgo+Cj4gT24g b25lIGhhbmQsIHdlIGhhdmUgYSB0ZXh0IGFuZCBvbiB0aGUgb3RoZXIgYSB0ZXh0LWxpc3QuIERv bnQga25vdyBob3cKPiBtdWNoIGRpZmZlcmVuY2UgaXQgd2lsbCBtYWtlIGluIHByYWN0aWNlIGJ1 dCB3ZSBtYXkgd2FudCB0byBjaGFuZ2UgdGhlCj4gbGF0ZXIgdG8gYSB2YWx1ZS10ZXh0LgoKLS1P biBBcHJpbCAyMCwgMjAxMSAyOjUxOjEyIFBNICswMDAwIFRhbnRlayDDh2VsaWsgPHRhbnRla0Bj cy5zdGFuZm9yZC5lZHU+IAp3cm90ZToKCj4gVGhlIHZjYXJkeG1sIHZlcnNpb24gaXMgY29ycmVj dCB3aXRoIHNlcGFyYXRlIHNleCBhbmQgaWRlbnRpdHkgY29tcG9uZW50cwo+IG9mIGdlbmRlciAo Y29uc2Vuc3VzIHdhcyByZWFjaGVkIG9uIHRoaXMgbGlzdCB3aXRoIHRocmVhZCBiZXR3ZWVuIG15 c2VsZiwKPiBLZXZpbiBNYXJrcywgU2FyYWggRG9wcCkuCj4KPiBQbGVhc2UgdXBkYXRlIHRoZSB2 Y2FyZHJldiB2ZXJzaW9uIGFjY29yZGluZ2x5LiBIZXJlIGlzIHZjYXJkcmV2IHNhbXBsZQo+IHNw ZWMgdGV4dCB3aXRoIGV4YW1wbGVzOgo+Cj4gaHR0cHM6Ly93aWtpLm1vemlsbGEub3JnL1ZDYXJk NCNHRU5ERVIKCkJ1dCBUYW50ZWssIGluIHlvdXIgZXhhbXBsZSB0aGVyZSBhcmUgYXQgbW9zdCB0 d28gdGV4dCBlbGVtZW50cywgd2hlcmVhcyAKdGhlIGN1cnJlbnQgeENhcmQgaGFzIHZhbHVlLXRl eHQtbGlzdCB3aGljaCBhbHdheXMgZm9yIG11bHRpcGxlIHRleHQgCmNvbXBvbmVudHMgaW4gdGhl IGlkZW50aXR5LiBJIHRoaW5rIHRoZSBjb3JyZWN0IHhDYXJkIGRlZmluaXRpb24gb3VnaHQgdG8g CmJlOgoKICAgIHByb3BlcnR5LWdlbmRlciA9IGVsZW1lbnQgZ2VuZGVyIHsKICAgICAgICAgZWxl bWVudCBzZXggewogICAgICAgICAgIGVsZW1lbnQgdGV4dCB7ICJNIiB8ICJGIiB8ICJPIiB8ICJO IiB8ICJVIiB9CiAgICAgICAgIH0/LAogICAgICAgICBlbGVtZW50IGlkZW50aXR5IHsgdGV4dCB9 PwogICAgICAgfQoKTm90ZSBob3cgSSBhbHNvIG1vdmVkIHRoZSAnPycgb250byB0aGUgPHNleD4g ZWxlbWVudC4gSSBzZWUgbm8gcmVhc29uIHdoeSAKPHNleD4gaGFzIHRvIGJlIHByZXNlbnQgd2hl biBpdCBpcyBlbXB0eS4gU2FtZSB0aGluZyBmb3IgPGlkZW50aXR5Pi4KCkhvd2V2ZXIsIHRoaXMg YnJpbmdzIHVwIGEgbWlub3IgZGlmZmVyZW5jZSB3aXRoIHhDYWwuIEluIHhDYWwgd2UgaGF2ZSB0 d28gCiJzdHJ1Y3R1cmVkIiBwcm9wZXJ0aWVzIHdoZXJlIHdlIGNyZWF0ZWQgImN1c3RvbSIgdmFs dWUgZWxlbWVudHMgZm9yIHRoZSAKc3ViLXN0cnVjdHVyZTogR0VPIGFuZCBSRVFVRVNULVNUQVRV Uy4gRm9yIHRoZSBsYXRlciB3ZSBoYXZlOgoKICAgIyAzLjguOC4zIFJlcXVlc3QgU3RhdHVzCgog ICBwcm9wZXJ0eS1yc3RhdHVzID0gZWxlbWVudCByZXF1ZXN0LXN0YXR1cyB7CgogICAgICAgZWxl bWVudCBwYXJhbWV0ZXJzIHsKICAgICAgICAgICBsYW5ndWFnZXBhcmFtPwogICAgICAgfT8sCgog ICAgICAgZWxlbWVudCB2YWx1ZSB7CiAgICAgICAgICAgZWxlbWVudCBjb2RlIHsgdGV4dCB9LAog ICAgICAgICAgIGVsZW1lbnQgZGVzY3JpcHRpb24geyB0ZXh0IH0sCiAgICAgICAgICAgZWxlbWVu dCBkYXRhIHsgdGV4dCB9PwogICAgICAgfQogICB9CgpTbyB3ZSBjaG9vc2UgdG8gd3JhcCB0aGUg InN0cnVjdHVyZWQiIHZhbHVlIGluc2lkZSBvZiBhIDx2YWx1ZT4gZWxlbWVudC4gSSAKdGhpbmsg dGhhdCBpcyB1bm5lY2Vzc2FyaWx5IHZlcmJvc2UgYW5kIHdlIHNob3VsZCByZW1vdmUgdGhlIDx2 YWx1ZT4gCmVsZW1lbnQgKGluIGZhY3QgSSB0aGluayB0aGF0IHdhcyBsZWZ0IG92ZXIgZnJvbSBh IHRpbWUgd2hlbiB3ZSB1c2VkIGEgCjx2YWx1ZT4gZWxlbWVudCBmb3IgYWxsIHZhbHVlIHR5cGVz KS4gSWYgdGhlcmUgYXJlIG5vIG9iamVjdHMgSSB3aWxsIG1ha2UgCnRoYXQgY2hhbmdlIGluIHhD YWwuCgotLSAKQ3lydXMgRGFib28KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCmNhbHNpZnkgbWFpbGluZyBsaXN0CmNhbHNpZnlAaWV0Zi5vcmcKaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jYWxzaWZ5Cg== From cyrus@daboo.name Wed Apr 20 08:02:28 2011 Return-Path: X-Original-To: calsify@ietfc.amsl.com Delivered-To: calsify@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3A12DE075F; Wed, 20 Apr 2011 08:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.068 X-Spam-Level: X-Spam-Status: No, score=-102.068 tagged_above=-999 required=5 tests=[AWL=-0.865, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EH8GIrFGY6zK; Wed, 20 Apr 2011 08:02:27 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by ietfc.amsl.com (Postfix) with ESMTP id 47EF8E073A; Wed, 20 Apr 2011 08:02:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id A85961C842C0D; Wed, 20 Apr 2011 11:02:23 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NG0dkfJBh8Pf; Wed, 20 Apr 2011 11:02:18 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTPSA id C87D51C842BFC; Wed, 20 Apr 2011 11:02:16 -0400 (EDT) Date: Wed, 20 Apr 2011 11:02:13 -0400 From: Cyrus Daboo To: Arnaud Quillaud , CardDAV Message-ID: In-Reply-To: <4DAEEB3D.5080205@quillaud.org> References: <4DAEEB3D.5080205@quillaud.org> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=2415 Cc: Calsify Subject: Re: [calsify] [VCARDDAV] GENDER property inconsistency X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 15:02:28 -0000 Hi Arnaud, (cc'd calsify list because of comment at the end proposing a change in = xCal) --On April 20, 2011 4:18:37 PM +0200 Arnaud Quillaud = wrote: > when http://tools.ietf.org/html/draft-ietf-vcarddav-vcardxml-09 defines > it as: > > << > > property-gender =3D element gender { > element sex { > element text { "M" | "F" | "O" | "N" | "U" }? > }, > element identity { value-text-list? } > } > > >> > > On one hand, we have a text and on the other a text-list. Dont know how > much difference it will make in practice but we may want to change the > later to a value-text. --On April 20, 2011 2:51:12 PM +0000 Tantek =C3=87elik = =20 wrote: > The vcardxml version is correct with separate sex and identity components > of gender (consensus was reached on this list with thread between myself, > Kevin Marks, Sarah Dopp). > > Please update the vcardrev version accordingly. Here is vcardrev sample > spec text with examples: > > https://wiki.mozilla.org/VCard4#GENDER But Tantek, in your example there are at most two text elements, whereas=20 the current xCard has value-text-list which always for multiple text=20 components in the identity. I think the correct xCard definition ought to=20 be: property-gender =3D element gender { element sex { element text { "M" | "F" | "O" | "N" | "U" } }?, element identity { text }? } Note how I also moved the '?' onto the element. I see no reason why=20 has to be present when it is empty. Same thing for . However, this brings up a minor difference with xCal. In xCal we have two=20 "structured" properties where we created "custom" value elements for the=20 sub-structure: GEO and REQUEST-STATUS. For the later we have: # 3.8.8.3 Request Status property-rstatus =3D element request-status { element parameters { languageparam? }?, element value { element code { text }, element description { text }, element data { text }? } } So we choose to wrap the "structured" value inside of a element. I=20 think that is unnecessarily verbose and we should remove the =20 element (in fact I think that was left over from a time when we used a=20 element for all value types). If there are no objects I will make=20 that change in xCal. --=20 Cyrus Daboo