Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3CACE7F56C for ; Tue, 29 Nov 2005 17:57:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2FC4A1422B1 for ; Tue, 29 Nov 2005 17:57:01 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09264-07 for ; Tue, 29 Nov 2005 17:57:00 -0800 (PST) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.122.30]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id DA7541422AE for ; Tue, 29 Nov 2005 17:57:00 -0800 (PST) Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id jAU1uxG2001002 for ; Tue, 29 Nov 2005 18:56:59 -0700 Received: from localhost (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id jAU1uwdQ025989 for ; Tue, 29 Nov 2005 18:56:59 -0700 Received: from [127.0.0.1] (dhcp-amer-rmdc-csvpn-gw5-141-144-104-182.vpn.oracle.com [141.144.104.182]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAU1unfo025936; Tue, 29 Nov 2005 18:56:51 -0700 Message-ID: <438D06E5.4070505@oracle.com> Date: Tue, 29 Nov 2005 20:56:53 -0500 From: Bernard Desruisseaux User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, fr-ca MIME-Version: 1.0 To: ietf-caldav@osafoundation.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.5 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Subject: [Ietf-caldav] [Fwd: Re: PUT vs strong ETags] X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2005 01:57:01 -0000 -------- Original Message -------- Subject: Re: PUT vs strong ETags Resent-Date: Tue, 29 Nov 2005 21:26:37 +0000 Resent-From: ietf-http-wg@w3.org Date: Tue, 29 Nov 2005 22:19:41 +0100 From: Julian Reschke To: Scott Lawrence CC: HTTP Working Group References: <438C27D3.9010500@gmx.de> <1133296986.4529.17.camel@sukothai.pingtel.com> Scott Lawrence wrote: > On Tue, 2005-11-29 at 11:05 +0100, Julian Reschke wrote: > >> If a server like this would return an ETag upon PUT, would it apply to >> the PUT request body, or the server's internal representation returned >> in a subsequent GET? > > I think that the simple rule is that when responding to a PUT, if the > server returns an Etag, then it should be the same value that would have > been returned in a GET of the resource that immediately followed the > PUT. Somebody else pointed out in the meantime that the same question applies to Last-Modified. Anyway, if this is what everybody agrees upon, this IMHO should be put into the RFC2616 errata. Also, it means that an ETag obtained from a PUT response can not be used as validator in byte-range operations, right? That may come as a surprise to some ;-) Best regards, Julian Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2CE207F517 for ; Wed, 23 Nov 2005 12:30:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 237711422BB for ; Wed, 23 Nov 2005 12:30:03 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18888-02 for ; Wed, 23 Nov 2005 12:30:02 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1FB451422B6 for ; Wed, 23 Nov 2005 12:30:02 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v623) To: CalDAV DevList Message-Id: <3797e2304e0d3057fb34e89deaa1d795@osafoundation.org> Content-Type: multipart/alternative; boundary=Apple-Mail-1--148225853 From: Lisa Dusseault Date: Wed, 23 Nov 2005 12:29:56 -0800 X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Subject: [Ietf-caldav] Fwd: Question on bug 15 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2005 20:30:03 -0000 --Apple-Mail-1--148225853 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed FYI -- If RFC2518bis moves to this kind of precondition wording, then CalDAV should as well. For example, when somebody does a PUT to a calendar collection with a UID where the iCalendar UID already exists in that collection, we defined an error, so that the server can explain to the client that the client violated the uniqueness requirement for UIDs within each calendar. With the "consistent with ACL" approach that would look like With the way we have it now, the error explains the error, rather than the success condition, so the draft currently would require So if you care about how this looks, speak up on the WebDAV list. Lisa Begin forwarded message: > Resent-From: w3c-dist-auth@w3.org > From: Cullen Jennings > Date: November 23, 2005 10:05:12 AM PST > To: WebDav > Subject: Question on bug 15 > > > > I am going to call consensus on this one in a week so give me your > input > before then.... > > The basic issue is that the names are sort of reverse what people think > because they are based on post conditions. ACL (and others) already > exists > and do it the reverse way. The question is we should we define future > stuff > in the "forward" way... > > Proposal 1: Stay consistent with ACL - put in note for implementers > that > points out this is reverse of what they might expect. > > Proposal 2: Switch the way we do it. Leave old document reverse and > make new > documents forward. > > > Pros/Cons - It is a questions of it having both reverse and forward > will be > more or less confusing to implementers that just having it all reverse. > > > --Apple-Mail-1--148225853 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII FYI -- If RFC2518bis moves to this kind of precondition wording, then CalDAV should as well. For example, when somebody does a PUT to a calendar collection with a UID where the iCalendar UID already exists in that collection, we defined an error, so that the server can explain to the client that the client violated the uniqueness requirement for UIDs within each calendar. With the "consistent with ACL" approach that would look like <<< With the way we have it now, the error explains the error, rather than the success condition, so the draft currently would require <<< So if you care about how this looks, speak up on the WebDAV list. Lisa Begin forwarded message: 0000,0000,0000Resent-From: w3c-dist-auth@w3.org 0000,0000,0000From: Cullen Jennings < 0000,0000,0000Date: November 23, 2005 10:05:12 AM PST 0000,0000,0000To: WebDav < 0000,0000,0000Subject: Question on bug 15 I am going to call consensus on this one in a week so give me your input before then.... The basic issue is that the names are sort of reverse what people think because they are based on post conditions. ACL (and others) already exists and do it the reverse way. The question is we should we define future stuff in the "forward" way... Proposal 1: Stay consistent with ACL - put in note for implementers that points out this is reverse of what they might expect. Proposal 2: Switch the way we do it. Leave old document reverse and make new documents forward. Pros/Cons - It is a questions of it having both reverse and forward will be more or less confusing to implementers that just having it all reverse. --Apple-Mail-1--148225853-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 774C17F4F4 for ; Mon, 21 Nov 2005 08:26:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 65CA114229C for ; Mon, 21 Nov 2005 08:26:24 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11621-02 for ; Mon, 21 Nov 2005 08:26:24 -0800 (PST) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.122.30]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 07C9E14229B for ; Mon, 21 Nov 2005 08:26:23 -0800 (PST) Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id jALGQJWg016678; Mon, 21 Nov 2005 09:26:19 -0700 Received: from localhost (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id jALGQIwF018967; Mon, 21 Nov 2005 09:26:19 -0700 Received: from [144.23.219.186] (bdesruis-ca.ca.oracle.com [144.23.219.186]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jALGQCBi018933 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 21 Nov 2005 09:26:13 -0700 Message-ID: <4381F523.7080200@oracle.com> Date: Mon, 21 Nov 2005 11:26:11 -0500 From: Bernard Desruisseaux User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kai Pan Subject: Re: [Ietf-caldav] Some questions with respect to the CalDAV specification draft 6 References: <007c01c58bef$a622cbb0$9e3c7280@alan> In-Reply-To: <007c01c58bef$a622cbb0$9e3c7280@alan> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2005 16:26:25 -0000 Kai, See reply inline. Sorry for the long delay. Thanks! Bernard Kai Pan wrote: > Hi, > I am reading the CalDAV specification draft 6 and have some questions > about it. > > 1. In Section 8.3.1, Page 26, there is an example for > the calendar-query REPORT method. In this example, the calendar-data > element is like this > > > > > > > ...... > > As shown above, the element comes before the name="VEVENT"> element, but the XML definition for the comp element in > Section 10.2.1, Page 45 says that the allprop element should be behind > the comp element at the same level as it: > (comp*, (allprop | prop*)))> > > So, I am a bit confused here. Did I understand wrong or something? The CALDAV:comp XML element definition will be changed in the next draft to match the examples, that is, > 2. In Section 10.1, Page 44, the calendar-query element is defined as below: > calendar-data? filter> > > I just wonder whether it is a sequence and there is order among > (DAV:allprop | DAV:propname | DAV:prop)?, calendar-data?, and filter. > Should there be commas among them and a pair of parenthesis that enclose > them? It is a sequence. The commas were missing. The CALDAV:calendar-query XML element will be defined as follows in the next draft: FYI, a new CALDAV:timezone XML element will be added in the next draft to allow CalDAV servers to resolve DATE values and "floating time" values in UTC time unambiguously. > > 3. The calendar-data element is defined as > #PCDATA)?> > But, when calendar-data elements appear in the REPORT response, can I > assume that the calendar-data element can only be PCDATA, but comp or > expand-recurrence-set? In a response body, the CALDAV:calendar-data XML element must be #PCDATA. The CALDAV:calendar-data XML element will be defined as follows in the next draft: FYI, a new CALDAV:limit-freebusy-set XML element will be added in the next draft to allow clients to limit the set of FREEBUSY properties in returned VFREEBUSY calendar components. > > Thanks. > > Kai Pan > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7036D7F511 for ; Mon, 21 Nov 2005 08:07:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 658C014229C for ; Mon, 21 Nov 2005 08:07:15 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09329-01 for ; Mon, 21 Nov 2005 08:07:15 -0800 (PST) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.122.30]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id F30AC14229B for ; Mon, 21 Nov 2005 08:07:14 -0800 (PST) Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id jALG7D98002256; Mon, 21 Nov 2005 09:07:13 -0700 Received: from localhost (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id jALG7DfR010423; Mon, 21 Nov 2005 09:07:13 -0700 Received: from [144.23.219.186] (bdesruis-ca.ca.oracle.com [144.23.219.186]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jALG770R010397 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 21 Nov 2005 09:07:08 -0700 Message-ID: <4381F0AB.5000000@oracle.com> Date: Mon, 21 Nov 2005 11:07:07 -0500 From: Bernard Desruisseaux User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] Confused about calendar query filters References: <4366C6ED.4070709@oracle.com> <436B918D.50206@oracle.com> In-Reply-To: <436B918D.50206@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2005 16:07:15 -0000 The CALDAV:is-defined XML element will be removed in the next draft. Cheers, Bernard Bernard Desruisseaux wrote: > Wilfredo, > > The original intent was that for a component, or a property or a > parameter to match, one of the following condition would need to be > true: is-defined, time-range, text-match. Clearly not all conditions > apply to components, to all properties and all parameters. > > The "is-defined" XML elements was there for the sake of completeness > more than anything else. The idea was that one of the above condition > would be required in every filter. That being said, you are quite > correct that the DTD snippet in draft is broken... > > You are not the first implementer to wonder about the existence of > the "is-defined" XML element and I'm tempted to remove it now. > > The next draft will address this issue one way or the other. > > Thanks! > Bernard > > Wilfredo Sánchez Vega wrote: > >> Ew, right. So my example with the missing if-defined would match >> all resources? If so, I think this little bit of extra XML >> complicates 8.3.1 significantly. >> >> 8.3.1 should add a qualifier that the filter doesn't match if the >> component type doesn't match the name attribute. That's somewhat >> obvious, but it should be stated explicitly in the spec. >> >> But that's not quite enough because of the element... >> it doesn't match if the component type doesn't match the name >> attribute *unless* the comp-filter is empty *or* all of its children >> (or, recursively all of their children) are empty. Right? >> >> I wonder what the value of having this element around is, rather >> than making the present of comp-filter simply imply that it should be >> defined. >> >> Or is the empty EVENT filter illegal? That would be simpler again, >> but it's not stated as illegal in the spec. The DTD snippet in 8.3.1 >> would need to be something more like: >> >> > (is-defined | time-range | comp-filter | prop-filter) >> comp-filter* prop-filter*> >> >> But I would still wonder why is-defined exists at all... >> >> -wsv >> >> >> On Oct 31, 2005, at 5:37 PM, Bernard Desruisseaux wrote: >> >>>> So if I had this instead: >>>> >>>> >>>> >>>> >>>> >>>> I'd interpret it as "give me all data for any resource which >>>> contains an event." and going t the extreme: >>> >>> >>> >>> Right, but you forgot the "is-defined" XML element. >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> > > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D79367F503 for ; Mon, 21 Nov 2005 07:20:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CA0AB142272 for ; Mon, 21 Nov 2005 07:20:45 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31544-03 for ; Mon, 21 Nov 2005 07:20:45 -0800 (PST) Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 79BE2142267 for ; Mon, 21 Nov 2005 07:20:45 -0800 (PST) Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jALFWjXK010012; Mon, 21 Nov 2005 09:32:45 -0600 Received: from localhost (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id jALFJ0QW009410; Mon, 21 Nov 2005 08:19:00 -0700 Received: from [144.23.219.186] (bdesruis-ca.ca.oracle.com [144.23.219.186]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jALFImJ3009346 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 21 Nov 2005 08:18:49 -0700 Message-ID: <4381E558.3010009@oracle.com> Date: Mon, 21 Nov 2005 10:18:48 -0500 From: Bernard Desruisseaux User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML References: <43727541.8080501@Royer.com> <4378DEBE.1000004@oracle.com> <0354a46b3687d70b6cdc0fd41112e208@osafoundation.org> <437A3507.4050000@gmx.de> In-Reply-To: <437A3507.4050000@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2005 15:20:46 -0000 +1 The next CalDAV draft (i.e., -09) will specify that the CR character (US-ASCII decimal 13) MAY be omitted in iCalendar objects specified in the CALDAV:calendar-data XML elements. That being said, the content lines of iCalendar objects specified in the request body of a PUT or in the response body of a GET will still be required to be delimited by a CRLF sequence (US-ASCII decimal 13, followed by US-ASCII decimal 10). Cheers, Bernard Julian Reschke wrote: > Wilfredo Sánchez Vega wrote: > >> ... >> 2: Allow the dropping the CRs in the data when adding iCalendar data >> to an XML document and replace LF with CRLF when pulling that data out. >> >> The only change to CalDAV is to note the CRs will be lost in XML >> processing and that it is up whose reading the calendar-data element >> to replace LF with CRLF in order to obtain iCalendar-compliant data >> (or just deal with it as-is, eg. if your iCalendar parser doesn't >> care). This has the advantage of being what people are apparently >> already doing. >> >> ... > > > +1 > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 384D27F511 for ; Tue, 15 Nov 2005 18:07:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 20CF9142281 for ; Tue, 15 Nov 2005 18:07:22 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06481-02 for ; Tue, 15 Nov 2005 18:07:21 -0800 (PST) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by laweleka.osafoundation.org (Postfix) with ESMTP id BC8DC142279 for ; Tue, 15 Nov 2005 18:07:21 -0800 (PST) Received: from thare.comcast.net (pcp03614075pcs.micske01.fl.comcast.net[68.84.31.33]) by comcast.net (sccrmhc11) with SMTP id <200511160207200110024to1e>; Wed, 16 Nov 2005 02:07:20 +0000 Message-Id: <6.2.1.2.0.20051115210316.01eaee68@mail.comcast.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 15 Nov 2005 21:07:16 -0500 To: ietf-caldav@osafoundation.org From: Tim Hare Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML In-Reply-To: <437A3507.4050000@gmx.de> References: <43727541.8080501@Royer.com> <4378DEBE.1000004@oracle.com> <0354a46b3687d70b6cdc0fd41112e208@osafoundation.org> <437A3507.4050000@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.5 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2005 02:07:22 -0000 As Doug Royer pointed out elsewhere, the only place CRLF is used in an=20 un-escaped manner in iCalendar data, is when a text line is wrapped at 75=20 columns, and US-ASCII CR, LF, and space are inserted at the wrap point.=20 These whitespace characters can safely be ignored inside the XML, correct? At 02:20 PM 11/15/2005, Julian Reschke wrote: >Wilfredo S=E1nchez Vega wrote: >>... >> 2: Allow the dropping the CRs in the data when adding iCalendar data=20 >> to an XML document and replace LF with CRLF when pulling that data out. >> The only change to CalDAV is to note the CRs will be lost in XML=20 >> processing and that it is up whose reading the calendar-data element to= =20 >> replace LF with CRLF in order to obtain iCalendar-compliant data (or=20 >> just deal with it as-is, eg. if your iCalendar parser doesn't care). >>This has the advantage of being what people are apparently already doing. >>... > >+1 >_______________________________________________ >Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org >See http://ietf.webdav.org/caldav/ for more CalDAV resources >http://lists.osafoundation.org/mailman/listinfo/ietf-caldav Tim Hare Interested Bystander, Non-Inc.=20 Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id EE2DF7F52E for ; Tue, 15 Nov 2005 14:45:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DC9CA142277 for ; Tue, 15 Nov 2005 14:45:23 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00649-05 for ; Tue, 15 Nov 2005 14:45:23 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 92ADF142275 for ; Tue, 15 Nov 2005 14:45:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 83B2735350A; Tue, 15 Nov 2005 23:44:19 +0100 (CET) Received: from [192.168.0.233] (port-ip-213-211-241-152.reverse.mdcc-fun.de [213.211.241.152]) by mail.mdlink.net (Postfix) with ESMTP id D008B353509; Tue, 15 Nov 2005 23:44:18 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Date: Tue, 15 Nov 2005 23:45:28 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO, SUBJ_ALL_CAPS X-Spam-Level: Cc: groupdav@opengroupware.org, =?ISO-8859-1?Q?=C1lvaro_del_Castillo?= , Cornelius Schumacher , Till Adam Subject: [Ietf-caldav] FOSDEM 2006 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2005 22:45:24 -0000 Hi, we managed to get a devroom again at the FOSDEM 2006, which is probably the biggest OpenSource developer conference in Europe: http://www.fosdem.org/2006 Last year we had a very small informal meeting of GroupDAV implementors at the event, including Till (KDE), Alvaro (Evolution) and Stelian (back then working on Sunbird): http://www.groupdav.org/images/groupdav-fosdem-2005.jpg I wonder whether there is interest to have a small 1-2 hour meeting in the devroom to discuss GroupDAV _and_ of course CalDAV. If so, I could reserve a slot, make FOSDEM announce the sub-event and try to contact further projects for participation. Please let me know whether you are interested. best regards, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 4759F7F527 for ; Tue, 15 Nov 2005 12:36:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2D500142279 for ; Tue, 15 Nov 2005 12:36:16 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18240-05 for ; Tue, 15 Nov 2005 12:36:15 -0800 (PST) Received: from fed1rmmtao04.cox.net (fed1rmmtao04.cox.net [68.230.241.35]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9FA9C142276 for ; Tue, 15 Nov 2005 12:36:15 -0800 (PST) Received: from [192.168.0.102] (really [70.191.49.25]) by fed1rmmtao04.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20051115203511.PZZV17690.fed1rmmtao04.cox.net@[192.168.0.102]>; Tue, 15 Nov 2005 15:35:11 -0500 Message-ID: <437A46BA.2060402@calconnect.org> Date: Tue, 15 Nov 2005 12:36:10 -0800 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav list Content-Type: multipart/alternative; boundary="------------060907090401000004070303" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.4 tagged_above=-50.0 required=4.0 tests=AWL, HTML_40_50, HTML_FONT_FACE_CAPS, HTML_MESSAGE, HTML_TAG_EXIST_TBODY X-Spam-Level: Subject: [Ietf-caldav] Registration open for Calconnect Roundtable and Interop Testing Event, January 2006 - The Calendaring and Scheduling Consortium X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2005 20:36:16 -0000 This is a multi-part message in MIME format. --------------060907090401000004070303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit ------------------------------------------------------------------------ * Date:* 12/2/2004 07:52 * From:* David C. Thewlis * To:* "calconnect-l reflector" , "ietf-caldav reflector" , "IETF CALSCH" , "ietf-calsify reflector" , "www-rdf-calendar reflector" * Copy:* "Robert Tolmach - WellGood Group" , "Brian Dear" , "John Carbone" , cherot@convoq.com, georges@google.com * Subject:* Call for Participantion -- Second Calconnect Interop - 11-12 January 2005 - Seattle, Washington ------------------------------------------------------------------------ Received: from psmtp.com (exprod6mx6.postini.com [64.18.1.146]) by home.humboldt1.com (8.12.10/8.12.10) with SMTP id iB2Fq3mR014814 for Thu, 2 Dec 2004 07:52:03 -0800 (PST) Received: from source ([208.31.106.91]) by exprod6mx6.postini.com ([64.18.5.10]) with SMTP; Thu, 02 Dec 2004 07:52:02 PST Received: from aix2.egenconsulting.com (localhost [127.0.0.1]) by aix2.egenconsulting.com (8.13.1/8.13.1) with ESMTP id iB2FlvWi018040 for Thu, 2 Dec 2004 10:47:57 -0500 Received: (from majordom@localhost) by aix2.egenconsulting.com (8.13.1/8.13.1/Submit) id iB2FlvFI018426 for calconnect-l-list; Thu, 2 Dec 2004 10:47:57 -0500 X-Authentication-Warning: aix2.egenconsulting.com: majordom set sender to owner-calconnect-l@calconnect.org using -f Received: from fed1rmmtao04.cox.net (fed1rmmtao04.cox.net [68.230.241.35]) by aix2.egenconsulting.com (8.13.1/8.13.1) with ESMTP id iB2FlcTM019480; Thu, 2 Dec 2004 10:47:38 -0500 Received: from davet23 ([24.254.88.112]) by fed1rmmtao04.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20041202154833.YTO5357.fed1rmmtao04.cox.net@davet23> Thu, 2 Dec 2004 10:48:33 -0500 Message-ID: <200412020748000071.082E3FF1@smtp.west.cox.net> References: <200411181732510014.00FA5091@smtp.west.cox.net> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Thu, 02 Dec 2004 07:48:00 -0800 Reply-To: Dave.Thewlis@calconnect.org From: "David C. Thewlis" To: "calconnect-l reflector" , "ietf-caldav reflector" , "IETF CALSCH" , "ietf-calsify reflector" , "www-rdf-calendar reflector" Cc: "Robert Tolmach - WellGood Group" , "Brian Dear" , "John Carbone" , cherot@convoq.com, georges@google.com Subject: Call for Participantion -- Second Calconnect Interop - 11-12 January 2005 - Seattle, Washington Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====_11020024806334=_" Sender: owner-calconnect-l@calconnect.org Precedence: bulk X-pstn-levels: (S:99.90000/99.90000 R:95.9108 P:95.9108 M:94.8624 C:98.9754 ) X-pstn-settings: 5 (2.0000:2.0000) s gt3 gt2 gt1 r p m c X-pstn-addresses: from forward (user good) [2395/93] /Please note that this announcement is being posted on multiple calendaring-related reflectors and to the Calconnect mailing lists to ensure as wide a distribution as possible. Our apologies if you receive multiple copies. / //*CALCONNECT INTEROP TESTING EVENT - 09-10 January 2006* *CALCONNECT ROUNDTABLE V - 10-12 January 2006* * * CalConnect - The Calendaring and Scheduling Consortium - invites you to our January 2006 Roundtable and to the associated Calendaring and Scheduling Interop Testing Event, to be held 9-12 January, 2006 in Provo, Utah, hosted by Novell, Inc. _Registration is now open for these events as of 15 November 2005._ In a departure from previous events, the Interop and Roundtable will be held serially instead of in parallel, to ensure that Interop participants can actively participate in the Roundtable. The *Interop* will take place 09-10 January, all day the 9th and until lunch on the 10th. It will offer multiple Interop Testing Scenarios including * extensive CalDAV testing, * RFC (iCalendar, iMIP, iTIP) interoperability and RFC conformance testing * CALSIFY minimum interoperability testing. Participating organizations may choose one or more than one scenario for testing -- however these scenarios will be going on simultaneously so you will probably need a person for each scenario you participate in. Interop participation is _open to all_ interested organizations that wish to test calendaring and scheduling implementations, and _is not limited to members of the Consortium _(although members receive a significant discount on the Interop participation fee). More information about the Interop is available at http://www.calconnect.org/iopjan2006.html. The *Roundtable* will commence after lunch on Tuesday 10 January and run through lunch on Thursday 12 January (Roundtable participants are invited to lunch on Tuesday prior to the opening of the Roundtable). It will feature Technical Committee meetings, ad hoc meetings, and a full Plenary of the Consortium. You must represent a member of CalConnect to attend the Roundtable _unless_ your organization chooses to participate as an Observer (a non-member who wishes to attend a Roundtable to evaluate participation in the Consortium). More information about the Roundtable is available at http://www.calconnect.org/roundtable5.html. * REGISTRATION FEES **Interop:* $1500 for Consortium members and $2500 for non-members. The registration fee covers two individuals; additional individuals are $150 each for members or non-members. (If you are planning to participate in more than one Interop scenario, you may need additional people.) ** *Roundtable:* $275 per individual until 01 January and $325 thereafter. The Roundtable is limited to representatives of Consortium members or declared Observers (an non-member that wishes to attend a Roundtable to evaluate participation in the Consortium). / A combined registration fee for both the Interop and Roundtable is available; please see http://www.calconnect.org/iopfees.html. / * * *ADDITIONAL DETAILS AND REGISTRATION INFORMATION* Information on the Roundtable, including logistics, current schedule and agenda planning, and registration information is available on the Consortium website at http://www.calconnect.org/roundtable5.html. More information on the Interop including logistics, planning, and registration information is available on the Consortium website at http://www.calconnect.org/iopjan2006.html. You may also go to Consortium site at http://www.calconnect.org and select "Coming Events" from the sidebar to find logistics, planning and registration information for both the Roundtable and the Interop. For questions and additional information please contact the Consortium's Executive Director, Dave Thewlis, via the contact information listed below. Space will be limited, so register as soon as possible. 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 --------------060907090401000004070303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Please note that this announcement is being posted on multiple calendaring-related reflectors and to the Calconnect mailing lists to ensure as wide a distribution as possible.  Our apologies if you receive multiple copies.

CALCONNECT INTEROP TESTING EVENT -  09-10 January 2006

CALCONNECT ROUNDTABLE V - 10-12 January 2006
 
 
CalConnect - The Calendaring and Scheduling Consortium - invites you to our January 2006 Roundtable and to the associated Calendaring and Scheduling Interop Testing Event, to be held 9-12 January, 2006 in Provo, Utah, hosted by Novell, Inc.

Registration is now open for these events as of 15 November 2005.

In a departure from previous events, the Interop and Roundtable will be held serially instead of in parallel, to ensure that Interop participants can actively participate in the Roundtable. 

The Interop will take place 09-10 January, all day the 9th and until lunch on the 10th.  It will offer multiple Interop Testing Scenarios including
  • extensive CalDAV testing,
  • RFC (iCalendar, iMIP, iTIP) interoperability and RFC conformance testing
  • CALSIFY minimum interoperability testing. 
Participating organizations may choose one or more than one scenario for testing -- however these scenarios will be going on simultaneously so you will probably need a person for each scenario you participate in. 

Interop participation is open to all interested organizations that wish to test calendaring and scheduling implementations, and is not limited to members of the Consortium (although members receive a significant discount on the Interop participation fee).

More information about the Interop is available at http://www.calconnect.org/iopjan2006.html.

The Roundtable will commence after lunch on Tuesday 10 January and run through lunch on Thursday 12 January (Roundtable participants are invited to lunch on Tuesday prior to the opening of the Roundtable).  It will feature Technical Committee meetings, ad hoc meetings, and a full Plenary of the Consortium.  You must represent a member of CalConnect to attend the Roundtable unless your organization chooses to participate as an Observer (a non-member who wishes to attend a Roundtable to evaluate participation in the Consortium).

More information about the Roundtable is available at http://www.calconnect.org/roundtable5.html.


REGISTRATION FEES

Interop: $1500 for Consortium members and $2500 for non-members.  The registration fee covers two individuals; additional individuals are $150 each for members or non-members.  (If you are planning to participate in more than one Interop scenario, you may need additional people.) 
 
Roundtable:  $275 per individual until 01 January and $325 thereafter.  The Roundtable is limited to representatives of Consortium members or declared Observers (an non-member that wishes to attend a Roundtable to evaluate participation in the Consortium).  

A combined registration fee for both the Interop and Roundtable is available; please see http://www.calconnect.org/iopfees.html.
 

 
ADDITIONAL DETAILS AND REGISTRATION INFORMATION

Information on the Roundtable, including logistics, current schedule and agenda planning, and registration information is available on the Consortium website at http://www.calconnect.org/roundtable5.html.  More information on the Interop including logistics, planning, and registration information is available on the Consortium website at http://www.calconnect.org/iopjan2006.html.

You may also go to Consortium site at http://www.calconnect.org and select "Coming Events" from the sidebar to find logistics, planning and registration information for both the Roundtable and the Interop.

For questions and additional information please contact the Consortium's Executive Director, Dave Thewlis, via the contact information listed below.

Space will be limited, so register as soon as possible.

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

--------------060907090401000004070303-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 8A1C47F52E for ; Tue, 15 Nov 2005 11:21:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7E5B3142281 for ; Tue, 15 Nov 2005 11:21:28 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05571-08 for ; Tue, 15 Nov 2005 11:21:28 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id C37BA14226E for ; Tue, 15 Nov 2005 11:21:27 -0800 (PST) Received: (qmail invoked by alias); 15 Nov 2005 19:21:26 -0000 Received: from p508F9BD7.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.155.215] by mail.gmx.net (mp021) with SMTP; 15 Nov 2005 20:21:26 +0100 X-Authenticated: #1915285 Message-ID: <437A3507.4050000@gmx.de> Date: Tue, 15 Nov 2005 20:20:39 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML References: <43727541.8080501@Royer.com> <4378DEBE.1000004@oracle.com> <0354a46b3687d70b6cdc0fd41112e208@osafoundation.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2005 19:21:28 -0000 Wilfredo Sánchez Vega wrote: >... > 2: Allow the dropping the CRs in the data when adding iCalendar data > to an XML document and replace LF with CRLF when pulling that data out. > > The only change to CalDAV is to note the CRs will be lost in XML > processing and that it is up whose reading the calendar-data element to > replace LF with CRLF in order to obtain iCalendar-compliant data (or > just deal with it as-is, eg. if your iCalendar parser doesn't care). > This has the advantage of being what people are apparently already doing. > > ... +1 Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 875C57F51A; Tue, 15 Nov 2005 10:09:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6EED8142281; Tue, 15 Nov 2005 10:09:51 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08848-03; Tue, 15 Nov 2005 10:09:51 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 2A12E142279; Tue, 15 Nov 2005 10:09:51 -0800 (PST) Received: from relay8.apple.com (a17-128-113-38.apple.com [17.128.113.38]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id jAFI9pj5019642; Tue, 15 Nov 2005 10:09:51 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay8.apple.com (Apple SCV relay) with ESMTP id C66103B7; Tue, 15 Nov 2005 10:09:50 -0800 (PST) In-Reply-To: <0354a46b3687d70b6cdc0fd41112e208@osafoundation.org> References: <43727541.8080501@Royer.com> <4378DEBE.1000004@oracle.com> <0354a46b3687d70b6cdc0fd41112e208@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML Date: Tue, 15 Nov 2005 10:09:49 -0800 To: Lisa Dusseault X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2005 18:09:51 -0000 On Nov 14, 2005, at 6:30 PM, Lisa Dusseault wrote: > There may not be a way in DOM to require that, but there is a way > in English: "Servers MUST encapsulate iCalendar data in CDATA when > building CalDAV REPORT responses". Y'all are making me learn XML... :-) This won't work. Both producers and generators of XML using a library are not supposed to be aware of CDATA sections, because CDATA sections vs. escaped XML data are supposed to be indistinguishable to library clients, and you are supposed to be able to covert from one to the other. Using an entity to escape CR ( ) is also problematic for similar reasons. The moral of the story is that it's the XML library's job to decide how to escape data going in and how to decode it going out. If you start breaking that abstraction barrier, you may are well not be using XML. > The question is, would that be the right requirement? I see two workable options: 1: Encode (eg. base64) the iCalendar data. This is undesireable since it make the data harder to read, assuming that we care about human readable data, and that it would require changing existing code that works today by working around the CR problem. 2: Allow the dropping the CRs in the data when adding iCalendar data to an XML document and replace LF with CRLF when pulling that data out. The only change to CalDAV is to note the CRs will be lost in XML processing and that it is up whose reading the calendar-data element to replace LF with CRLF in order to obtain iCalendar-compliant data (or just deal with it as-is, eg. if your iCalendar parser doesn't care). This has the advantage of being what people are apparently already doing. -wsv Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D73BD7F518 for ; Tue, 15 Nov 2005 01:16:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C41B114228D for ; Tue, 15 Nov 2005 01:16:00 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27080-04 for ; Tue, 15 Nov 2005 01:16:00 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id 108A4142267 for ; Tue, 15 Nov 2005 01:15:59 -0800 (PST) Received: (qmail invoked by alias); 15 Nov 2005 09:15:58 -0000 Received: from p508F9BD7.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.155.215] by mail.gmx.net (mp016) with SMTP; 15 Nov 2005 10:15:58 +0100 X-Authenticated: #1915285 Message-ID: <4379A71E.30201@gmx.de> Date: Tue, 15 Nov 2005 10:15:10 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML References: <43727541.8080501@Royer.com> <4378DEBE.1000004@oracle.com> <0354a46b3687d70b6cdc0fd41112e208@osafoundation.org> In-Reply-To: <0354a46b3687d70b6cdc0fd41112e208@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2005 09:16:01 -0000 Lisa Dusseault wrote: > ... > There may not be a way in DOM to require that, but there is a way in > English: "Servers MUST encapsulate iCalendar data in CDATA when > building CalDAV REPORT responses". > > The question is, would that be the right requirement? > ... No, that would be an *extremely* bad idea. 1) It should be up to the producer to decide on specifics of XML serialization, as long as it doesn't affect the XML Infoset. 2) There may be platforms/XML libraries that do not even support explicitly generating CDATA. Best regards, Julian Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 814817F554 for ; Mon, 14 Nov 2005 19:43:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 73A6C142289 for ; Mon, 14 Nov 2005 19:43:16 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00975-02 for ; Mon, 14 Nov 2005 19:43:16 -0800 (PST) Received: from S2.cableone.net (s2.cableone.net [24.116.0.228]) by laweleka.osafoundation.org (Postfix) with ESMTP id 05CC9142269 for ; Mon, 14 Nov 2005 19:43:15 -0800 (PST) Received: from [192.168.168.10] (unverified [69.92.70.67]) by S2.cableone.net (CableOne SMTP Service S2) with ESMTP id 36173779 for ; Mon, 14 Nov 2005 20:53:33 -0700 Message-ID: <43795951.6050408@Royer.com> Date: Mon, 14 Nov 2005 20:43:13 -0700 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML References: <43727541.8080501@Royer.com> <4378DEBE.1000004@oracle.com> <0354a46b3687d70b6cdc0fd41112e208@osafoundation.org> In-Reply-To: <0354a46b3687d70b6cdc0fd41112e208@osafoundation.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090201030806080809070109" X-SpamDetect: *: 1.250000 NakedCR=2.0,Aspam=-0.8 X-NakedCr: Body contained naked cr characters X-NotAscii: charset=us-ascii; X-IP-stats: Incoming Outgoing Last 1, First 44, in=76, out=65, spam=0 Known=true X-External-IP: 69.92.70.67 X-Abuse-Info: Send abuse complaints to abuse@cableone.net X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf-caldav@osafoundation.org List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2005 03:43:16 -0000 This is a cryptographically signed message in MIME format. --------------ms090201030806080809070109 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > The question is, would that be the right requirement? CALDAV could adapt xCal :-) -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------ms090201030806080809070109 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMzDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBK8wggQYoAMCAQICEFsGSvEntexpo94qqcjJuhAwDQYJKoZIhvcNAQEFBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDUwOTE4MDAw MDAwWhcNMDYwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDZ BFhLbROJ3gBYIeuP8+vR6G9dT4K3lXeeK+a9TO0qfqkxm6B3RDcXyhjd000rAUjGGRvVkyBX 6EjXkqCILRMAkbU5Zvk8nMyh0a27CzZH5JPHgw9bUutozhECZSDn/F5GRB/nwlOS3ip2Q+30 AvwX7x2h/12yyjyO9op9HIZLnpKXqgJETp/fmiOgfPg7xu8OBrwch1k9f48As0/8YCstHjka 32q/jEqWboVtE40sk48ROWca6KMLXli3HfVdj/NIZkYc8UFjK6Y5ojZ8hCYUo6H6hZanIyqd ptDd5T5/TuQHcJH7M6kq/BUgTzDJgRXdQEPxISfZGCRj7NckF5zXAgMBAAGjgcswgcgwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjAUBgpghkgBhvhFAQYHBAYWBE5vbmUwMwYDVR0fBCwwKjAooCagJIYi aHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQUFAAOBgQBT 5VLp42EyzXxqDBuVNmtAkVqt6U3GOY9gWKUUzBSRtlepDPiR3yF+I+GfeEZ8087H9QKcBrrU eXQlQ68hFm/nH1XVTVGdQ3wZOSnC/6JrZUvlurzw9bjjXXaUx2xKI/vH7PFBoa2bfMAxSfGO UEBY2wBeWT4QhxxV3TuDSI3NgzCCBK8wggQYoAMCAQICEFsGSvEntexpo94qqcjJuhAwDQYJ KoZIhvcNAQEFBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwHhcNMDUwOTE4MDAwMDAwWhcNMDYwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxU RChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0 YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBS b3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDZBFhLbROJ3gBYIeuP8+vR6G9dT4K3lXeeK+a9TO0qfqkxm6B3RDcX yhjd000rAUjGGRvVkyBX6EjXkqCILRMAkbU5Zvk8nMyh0a27CzZH5JPHgw9bUutozhECZSDn /F5GRB/nwlOS3ip2Q+30AvwX7x2h/12yyjyO9op9HIZLnpKXqgJETp/fmiOgfPg7xu8OBrwc h1k9f48As0/8YCstHjka32q/jEqWboVtE40sk48ROWca6KMLXli3HfVdj/NIZkYc8UFjK6Y5 ojZ8hCYUo6H6hZanIyqdptDd5T5/TuQHcJH7M6kq/BUgTzDJgRXdQEPxISfZGCRj7NckF5zX AgMBAAGjgcswgcgwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYI KwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0G A1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAUBgpghkgBhvhFAQYHBAYWBE5vbmUwMwYD VR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkq hkiG9w0BAQUFAAOBgQBT5VLp42EyzXxqDBuVNmtAkVqt6U3GOY9gWKUUzBSRtlepDPiR3yF+ I+GfeEZ8087H9QKcBrrUeXQlQ68hFm/nH1XVTVGdQ3wZOSnC/6JrZUvlurzw9bjjXXaUx2xK I/vH7PFBoa2bfMAxSfGOUEBY2wBeWT4QhxxV3TuDSI3NgzGCBKowggSmAgEBMIHhMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBbBkrxJ7XsaaPeKqnI yboQMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA1MTExNTAzNDMxM1owIwYJKoZIhvcNAQkEMRYEFDicINndMYrZq/m4v9M8pv4H 81wGMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQxgeQwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFsGSvEntexp o94qqcjJuhAwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZl cmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5 ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXIt UGVyc29uYSBOb3QgVmFsaWRhdGVkAhBbBkrxJ7XsaaPeKqnIyboQMA0GCSqGSIb3DQEBAQUA BIIBABRoJH1elLFU/MkFh9V5Q0yCNADHRR1Fx/+TGQyIPhZeRcpKRQBH1n5hv+ZtLhtvAU76 KELV3bf/g+QnqiDFHomVY47A+R9tYi+3ky78abyab7PEKIiVj2KtyipVelEm7yKOGc4QGgGk Jo3rvuy4+plL8vynDHtFfazzZf11FaGHIZ/9oblz8Goog6gwy8tZDVqdi6B9Hi8gC9ZC7p/w sCr9C8vW6BnVY224zYVnyOxnIqaDXYFy95SJdWt4nyj/nQ8GDF0GXPCtvhVPKo13HO8XpCcE kYaB8rWBtxE5w9du7ZMPhJM+myLTjNXqzOPjVmhfcSHjPm5Q2wEOA2rJyTcAAAAAAAA= --------------ms090201030806080809070109-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 715C07F53E for ; Mon, 14 Nov 2005 18:30:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6399414228E for ; Mon, 14 Nov 2005 18:30:47 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10707-05; Mon, 14 Nov 2005 18:30:47 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 81A17142281; Mon, 14 Nov 2005 18:30:46 -0800 (PST) In-Reply-To: References: <43727541.8080501@Royer.com> <4378DEBE.1000004@oracle.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <0354a46b3687d70b6cdc0fd41112e208@osafoundation.org> Content-Transfer-Encoding: quoted-printable From: Lisa Dusseault Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML Date: Mon, 14 Nov 2005 18:30:43 -0800 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2005 02:30:47 -0000 On Nov 14, 2005, at 11:38 AM, Wilfredo S=E1nchez Vega wrote: > On Nov 14, 2005, at 11:00 AM, Bernard Desruisseaux wrote: >> >> > VERSION:2.0 >> BEGIN:VEVENT >> SUMMARY:Seminar on Java & >> ... >> END:VEVENT >> END:VCALENDAR >> ]]> >> >> I don't believe it is necessary to escape 0x0A and 0x0D. > > I assume you mean that CDATA will preserve 0x0A and 0x0D? Not sure=20= > that's true, actually, but even so, that may solve the parser side of=20= > the problem, but then we have an XML generator problem. There doesn't=20= > appear to be any way in DOM to specify that it should emit a CDATA=20 > section when rendering XML output. There may not be a way in DOM to require that, but there is a way in=20 English: "Servers MUST encapsulate iCalendar data in CDATA when=20 building CalDAV REPORT responses". The question is, would that be the right requirement? > > Sounds like we can get away with normalized newlines and leave it up=20= > to the XML receiver to either convert to CRLF if needed or use a=20 > tolerant iCalendar library. CalDAV just needs to clarify that this is=20= > necessary and appropriate. > Lisa Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E392E7F545 for ; Mon, 14 Nov 2005 15:23:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id EBE0414228D for ; Mon, 14 Nov 2005 15:23:06 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08705-05 for ; Mon, 14 Nov 2005 15:23:06 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id 2DAB6142289 for ; Mon, 14 Nov 2005 15:23:06 -0800 (PST) Received: (qmail invoked by alias); 14 Nov 2005 23:23:04 -0000 Received: from p508FBD37.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.189.55] by mail.gmx.net (mp021) with SMTP; 15 Nov 2005 00:23:04 +0100 X-Authenticated: #1915285 Message-ID: <43791C26.8060408@gmx.de> Date: Tue, 15 Nov 2005 00:22:14 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Scott Carr Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML References: <43727541.8080501@Royer.com> <4378DEBE.1000004@oracle.com> <4378ECB3.1040103@oracle.com> <3E26B6D4-9B6F-4552-A981-832718062AEC@wsanchez.net> <332B7645-47A4-4F98-B5FA-EAEE2821977F@opengroupware.org> <43790CDC.100@progbits.com> In-Reply-To: <43790CDC.100@progbits.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2005 23:23:07 -0000 Scott Carr wrote: > It seems to be a combination of terms in 2.2 and the 2.7 area. > > 2.7 States: "Within a CDATA section, only the CDEnd string is > recognized as markup, so that left angle brackets and ampersands may > occur in their literal form; they need not (and cannot) be escaped using > "<" and "&". CDATA sections cannot nest." > > So the parser is to return everything up to the ]]> without looking at it. > > In the 2.2 section it states that Valid Character data is Line Feed, > Carriage Return. So these items will be returned without being parsed. I just tried a test document testcdatacr.xml: (where the line end was encoded as \r\n) with the following XSLT: Of three XSLT engines I tried (MSXSL/Saxon/procxslt), *all* reported a string length of 1. Yes, applying XSLT may have distorted the result, but anyhow I think you're wrong. Did you *try*? Best regards, Julian Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 4C7677F4F9 for ; Mon, 14 Nov 2005 14:16:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4C7A814227E for ; Mon, 14 Nov 2005 14:16:36 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06760-01 for ; Mon, 14 Nov 2005 14:16:36 -0800 (PST) Received: from exchange01.corp.dccusa.com (dccmailam.dccusa.com [12.107.242.101]) by laweleka.osafoundation.org (Postfix) with ESMTP id E5095142279 for ; Mon, 14 Nov 2005 14:16:35 -0800 (PST) Received: from [10.2.1.108] ([10.2.1.108]) by exchange01.corp.dccusa.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 14 Nov 2005 16:17:00 -0600 Message-ID: <43790CDC.100@progbits.com> Date: Mon, 14 Nov 2005 16:17:00 -0600 From: Scott Carr User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: CalDAV DevList Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML References: <43727541.8080501@Royer.com> <4378DEBE.1000004@oracle.com> <4378ECB3.1040103@oracle.com> <3E26B6D4-9B6F-4552-A981-832718062AEC@wsanchez.net> <332B7645-47A4-4F98-B5FA-EAEE2821977F@opengroupware.org> In-Reply-To: <332B7645-47A4-4F98-B5FA-EAEE2821977F@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 14 Nov 2005 22:17:00.0968 (UTC) FILETIME=[22818A80:01C5E969] X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2005 22:16:36 -0000 Helge Hess wrote: > On 14. Nov 2005, at 22:20 Uhr, Wilfredo Sánchez Vega wrote: >> 4. All non-escaped line breaks (carriage returns line feeds, >> carriage return-line feed pairs, and, in XML 1.1, NEL and line >> separator) are converted to line feeds. > > Now thats interesting. So we just need to escape the line endings with > either CDATA or . > > Though I can't actually find the claim that EOL handling is special for > escaped values in the XML spec. (really, I would like to know!) > It seems to be a combination of terms in 2.2 and the 2.7 area. 2.7 States: "Within a CDATA section, only the CDEnd string is recognized as markup, so that left angle brackets and ampersands may occur in their literal form; they need not (and cannot) be escaped using "<" and "&". CDATA sections cannot nest." So the parser is to return everything up to the ]]> without looking at it. In the 2.2 section it states that Valid Character data is Line Feed, Carriage Return. So these items will be returned without being parsed. -- Scott Carr OpenOffice.org Documentation Co-Lead http://documentation.openoffice.org Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 322B17F514 for ; Mon, 14 Nov 2005 13:32:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2BA7914227E for ; Mon, 14 Nov 2005 13:32:38 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20875-08 for ; Mon, 14 Nov 2005 13:32:37 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id C235E142279 for ; Mon, 14 Nov 2005 13:32:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id F2E3A353213 for ; Mon, 14 Nov 2005 22:31:26 +0100 (CET) Received: from [192.168.0.233] (port-ip-213-211-241-152.reverse.mdcc-fun.de [213.211.241.152]) by mail.mdlink.net (Postfix) with ESMTP id 9C13A353207 for ; Mon, 14 Nov 2005 22:31:26 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <3E26B6D4-9B6F-4552-A981-832718062AEC@wsanchez.net> References: <43727541.8080501@Royer.com> <4378DEBE.1000004@oracle.com> <4378ECB3.1040103@oracle.com> <3E26B6D4-9B6F-4552-A981-832718062AEC@wsanchez.net> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <332B7645-47A4-4F98-B5FA-EAEE2821977F@opengroupware.org> Content-Transfer-Encoding: quoted-printable From: Helge Hess Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML Date: Mon, 14 Nov 2005 22:32:36 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2005 21:32:38 -0000 On 14. Nov 2005, at 22:20 Uhr, Wilfredo S=E1nchez Vega wrote: > 4. All non-escaped line breaks (carriage returns line feeds, =20 > carriage return-line feed pairs, and, in XML 1.1, NEL and line =20 > separator) are converted to line feeds. Now thats interesting. So we just need to escape the line endings =20 with either CDATA or . Though I can't actually find the claim that EOL handling is special =20 for escaped values in the XML spec. (really, I would like to know!) Greets, Helge --=20 http://docs.opengroupware.org/Members/helge/ OpenGroupware.org Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 062617F553 for ; Mon, 14 Nov 2005 13:24:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id F406714227E for ; Mon, 14 Nov 2005 13:24:24 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16254-07 for ; Mon, 14 Nov 2005 13:24:24 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C1FAF142279 for ; Mon, 14 Nov 2005 13:24:24 -0800 (PST) Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id jAELONSQ008355; Mon, 14 Nov 2005 13:24:23 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay5.apple.com (Apple SCV relay) with ESMTP id 90DEB324015; Mon, 14 Nov 2005 13:24:23 -0800 (PST) In-Reply-To: <4378ECB3.1040103@oracle.com> References: <43727541.8080501@Royer.com> <4378DEBE.1000004@oracle.com> <4378ECB3.1040103@oracle.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3E26B6D4-9B6F-4552-A981-832718062AEC@wsanchez.net> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML Date: Mon, 14 Nov 2005 13:20:00 -0800 To: Bernard Desruisseaux X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2005 21:24:25 -0000 On Nov 14, 2005, at 11:59 AM, Bernard Desruisseaux wrote: > I meant in general. With or without CDATA I don't believe > it is necessary to escape 0x0A and 0x0D. O'Reilly, "XML in a Nutshell", page 317, under "Whitespace": How parsers treat whitespace is one of the most commonly misunderstood areas of XML processing. There are four basic rules you need to remember: ... 4. All non-escaped line breaks (carriage returns line feeds, carriage return-line feed pairs, and, in XML 1.1, NEL and line separator) are converted to line feeds. -wsv Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 93AB37F561 for ; Mon, 14 Nov 2005 13:20:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8456E142281 for ; Mon, 14 Nov 2005 13:20:03 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19189-05 for ; Mon, 14 Nov 2005 13:20:03 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 55AB114227E for ; Mon, 14 Nov 2005 13:20:03 -0800 (PST) Received: from relay6.apple.com (a17-128-113-36.apple.com [17.128.113.36]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id jAELK1fp019749; Mon, 14 Nov 2005 13:20:01 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay6.apple.com (Apple SCV relay) with ESMTP id 2F845744; Mon, 14 Nov 2005 13:20:01 -0800 (PST) In-Reply-To: <4378ECB3.1040103@oracle.com> References: <43727541.8080501@Royer.com> <4378DEBE.1000004@oracle.com> <4378ECB3.1040103@oracle.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3E26B6D4-9B6F-4552-A981-832718062AEC@wsanchez.net> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML Date: Mon, 14 Nov 2005 13:20:00 -0800 To: Bernard Desruisseaux X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2005 21:20:03 -0000 On Nov 14, 2005, at 11:59 AM, Bernard Desruisseaux wrote: > I meant in general. With or without CDATA I don't believe > it is necessary to escape 0x0A and 0x0D. O'Reilly, "XML in a Nutshell", page 317, under "Whitespace": How parsers treat whitespace is one of the most commonly misunderstood areas of XML processing. There are four basic rules you need to remember: ... 4. All non-escaped line breaks (carriage returns line feeds, carriage return-line feed pairs, and, in XML 1.1, NEL and line separator) are converted to line feeds. -wsv Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A22A47F561 for ; Mon, 14 Nov 2005 13:19:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9FCF7142281 for ; Mon, 14 Nov 2005 13:19:33 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01331-07 for ; Mon, 14 Nov 2005 13:19:33 -0800 (PST) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id E387114227E for ; Mon, 14 Nov 2005 13:19:32 -0800 (PST) Received: (qmail invoked by alias); 14 Nov 2005 21:19:30 -0000 Received: from p508FBD37.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.189.55] by mail.gmx.net (mp019) with SMTP; 14 Nov 2005 22:19:30 +0100 X-Authenticated: #1915285 Message-ID: <4378FF38.8030704@gmx.de> Date: Mon, 14 Nov 2005 22:18:48 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Scott Carr Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML References: <43727541.8080501@Royer.com> <4378DEBE.1000004@oracle.com> <372299A2-40BC-4C4E-95E6-D1C72184C8A0@opengroupware.org> <4378F15D.8030604@progbits.com> <4BA101BD-307E-4BEC-B745-7156786554C8@opengroupware.org> <4378F7D8.6030006@progbits.com> In-Reply-To: <4378F7D8.6030006@progbits.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2005 21:19:33 -0000 Scott Carr wrote: > Under section 2.2 (http://www.w3.org/TR/2004/REC-xml-20040204/#charsets): > > It states: "Legal characters are tab, carriage return, line feed, and > the legal characters of Unicode and ISO/IEC 10646." > > So in affect everything between the tags are > considered ignored by the parser and must be returned. Yes. But that doesn't change the legal character set (not binary), and the line end handling (see ). > ... Best regards, Julian Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D3EF77F503 for ; Mon, 14 Nov 2005 12:46:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C486014227E for ; Mon, 14 Nov 2005 12:46:55 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14622-07 for ; Mon, 14 Nov 2005 12:46:55 -0800 (PST) Received: from exchange01.corp.dccusa.com (dccmailam.dccusa.com [12.107.242.101]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5B6F1142279 for ; Mon, 14 Nov 2005 12:46:55 -0800 (PST) Received: from [10.2.1.108] ([10.2.1.108]) by exchange01.corp.dccusa.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 14 Nov 2005 14:47:20 -0600 Message-ID: <4378F7D8.6030006@progbits.com> Date: Mon, 14 Nov 2005 14:47:20 -0600 From: Scott Carr User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: CalDAV DevList Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML References: <43727541.8080501@Royer.com> <4378DEBE.1000004@oracle.com> <372299A2-40BC-4C4E-95E6-D1C72184C8A0@opengroupware.org> <4378F15D.8030604@progbits.com> <4BA101BD-307E-4BEC-B745-7156786554C8@opengroupware.org> In-Reply-To: <4BA101BD-307E-4BEC-B745-7156786554C8@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Nov 2005 20:47:20.0577 (UTC) FILETIME=[9B8B0710:01C5E95C] X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2005 20:46:55 -0000 Helge Hess wrote: > On 14. Nov 2005, at 21:19 Uhr, Scott Carr wrote: >> CDATA is supposed to return exactly as represented between the CDATA >> tags, with NO parsing by the DOM, or XML engine being used. AFAICT, >> CDATA can even include Binary data, not sure that you would want to >> though. > > Could please point me to the section in the XML spec which explains > that? Section 2.7 says nothing like that but just outlines the > differences wrt escaping and explicitly mentions that the content is > character data. > Under section 2.2 (http://www.w3.org/TR/2004/REC-xml-20040204/#charsets): It states: "Legal characters are tab, carriage return, line feed, and the legal characters of Unicode and ISO/IEC 10646." So in affect everything between the tags are considered ignored by the parser and must be returned. At least that is how I read the spec. > For binary data you would need references to unparsed external entities, > you cannot embed binary data in any parsed XML entity (section 2.2). > True, the implementation of this I have seen was converted to HEX or Octal before being placed in the XML doc. Sorry. > Greets, > Helge > --http://docs.opengroupware.org/Members/helge/ > OpenGroupware.org > > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav > -- Scott Carr OpenOffice.org Documentation Co-Lead http://documentation.openoffice.org Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 98C9C7F565 for ; Mon, 14 Nov 2005 12:31:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8932B142281 for ; Mon, 14 Nov 2005 12:31:37 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16254-02 for ; Mon, 14 Nov 2005 12:31:37 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2F6A414227E for ; Mon, 14 Nov 2005 12:31:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 25AA4353165 for ; Mon, 14 Nov 2005 21:30:26 +0100 (CET) Received: from [192.168.0.233] (port-ip-213-211-241-152.reverse.mdcc-fun.de [213.211.241.152]) by mail.mdlink.net (Postfix) with ESMTP id BD03B353163 for ; Mon, 14 Nov 2005 21:30:25 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <4378F15D.8030604@progbits.com> References: <43727541.8080501@Royer.com> <4378DEBE.1000004@oracle.com> <372299A2-40BC-4C4E-95E6-D1C72184C8A0@opengroupware.org> <4378F15D.8030604@progbits.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4BA101BD-307E-4BEC-B745-7156786554C8@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML Date: Mon, 14 Nov 2005 21:31:28 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2005 20:31:37 -0000 On 14. Nov 2005, at 21:19 Uhr, Scott Carr wrote: > CDATA is supposed to return exactly as represented between the > CDATA tags, with NO parsing by the DOM, or XML engine being used. > AFAICT, CDATA can even include Binary data, not sure that you would > want to though. Could please point me to the section in the XML spec which explains that? Section 2.7 says nothing like that but just outlines the differences wrt escaping and explicitly mentions that the content is character data. For binary data you would need references to unparsed external entities, you cannot embed binary data in any parsed XML entity (section 2.2). Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D110D7F590 for ; Mon, 14 Nov 2005 12:19:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8E72514227E for ; Mon, 14 Nov 2005 12:19:19 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12126-06 for ; Mon, 14 Nov 2005 12:19:19 -0800 (PST) Received: from exchange01.corp.dccusa.com (dccmailam.dccusa.com [12.107.242.101]) by laweleka.osafoundation.org (Postfix) with ESMTP id EC0E8142279 for ; Mon, 14 Nov 2005 12:19:18 -0800 (PST) Received: from [10.2.1.108] ([10.2.1.108]) by exchange01.corp.dccusa.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 14 Nov 2005 14:19:42 -0600 Message-ID: <4378F15D.8030604@progbits.com> Date: Mon, 14 Nov 2005 14:19:41 -0600 From: Scott Carr User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: CalDAV DevList Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML References: <43727541.8080501@Royer.com> <4378DEBE.1000004@oracle.com> <372299A2-40BC-4C4E-95E6-D1C72184C8A0@opengroupware.org> In-Reply-To: <372299A2-40BC-4C4E-95E6-D1C72184C8A0@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 14 Nov 2005 20:19:42.0140 (UTC) FILETIME=[BF099FC0:01C5E958] X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2005 20:19:20 -0000 Helge Hess wrote: > On 14. Nov 2005, at 20:38 Uhr, Wilfredo Sánchez Vega wrote: >> This is true, but apparently they are allowed to normalize newlines. > > As far as I understand the spec XML parsers are _required_ to normalize > newlines: > > http://www.w3.org/TR/2004/REC-xml-20040204/ > > section 2.11. > >> I assume you mean that CDATA will preserve 0x0A and 0x0D? Not sure >> that's true, actually, but even so, that may solve the parser side of >> the problem, but then we have an XML generator problem. There doesn't >> appear to be any way in DOM to specify that it should emit a CDATA >> section when rendering XML output. > > Isn't CDATA just syntactic sugar to avoid repetitive escaping? Section 2.7: > CDATA is supposed to return exactly as represented between the CDATA tags, with NO parsing by the DOM, or XML engine being used. AFAICT, CDATA can even include Binary data, not sure that you would want to though. -- Scott Carr OpenOffice.org Documentation Co-Lead http://documentation.openoffice.org Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B34E17F591 for ; Mon, 14 Nov 2005 11:59:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A3275142279 for ; Mon, 14 Nov 2005 11:59:59 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12126-04 for ; Mon, 14 Nov 2005 11:59:59 -0800 (PST) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.122.30]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 43E8414226D for ; Mon, 14 Nov 2005 11:59:59 -0800 (PST) Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id jAEJxvJY013170; Mon, 14 Nov 2005 12:59:58 -0700 Received: from localhost (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id jAEJxvlk012591; Mon, 14 Nov 2005 12:59:57 -0700 Received: from [144.23.219.186] (bdesruis-ca.ca.oracle.com [144.23.219.186]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAEJxm9i012469 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 14 Nov 2005 12:59:49 -0700 Message-ID: <4378ECB3.1040103@oracle.com> Date: Mon, 14 Nov 2005 14:59:47 -0500 From: Bernard Desruisseaux User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML References: <43727541.8080501@Royer.com> <4378DEBE.1000004@oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2005 19:59:59 -0000 Wilfredo Sánchez Vega wrote: > On Nov 14, 2005, at 11:00 AM, Bernard Desruisseaux wrote: > >> Wilfredo Sánchez Vega wrote: >> >>> XML entity escaping is OK, but if that's the answer, the CalDAV >>> spec should require that clients and servers replace '\r' with >>> ' ' in calendar-data elements so that when the receiver gets >>> the data, it's not munged by their parser. >> >> >> XML parsers are supposed to report all white space (i.e., ASCII 0x09, >> 0x0A, 0x0D, and 0x20) in the element content to the client application. >> >> content >> >> is not the same as >> >> >> content >> > > > This is true, but apparently they are allowed to normalize newlines. XML parsers are allowed to normalize attribute value, but not element's content. > >> That being said, I'll update the draft with examples that escapes >> '<', '>' and '&' or uses CDATA sections. For instance: >> >> > VERSION:2.0 >> BEGIN:VEVENT >> SUMMARY:Seminar on Java & <XML> >> ... >> END:VEVENT >> END:VCALENDAR >> ]]> Oops... the example above should have read: BEGIN:VCALENDAR VERSION:2.0 BEGIN:VEVENT SUMMARY:Seminar on Java & <XML> ... END:VEVENT END:VCALENDAR That is with no CDATA... >> >> >> > VERSION:2.0 >> BEGIN:VEVENT >> SUMMARY:Seminar on Java & >> ... >> END:VEVENT >> END:VCALENDAR >> ]]> >> >> I don't believe it is necessary to escape 0x0A and 0x0D. > > > I assume you mean that CDATA will preserve 0x0A and 0x0D? I meant in general. With or without CDATA I don't believe it is necessary to escape 0x0A and 0x0D. Cheers, Bernard > Not sure > that's true, actually, but even so, that may solve the parser side of > the problem, but then we have an XML generator problem. There doesn't > appear to be any way in DOM to specify that it should emit a CDATA > section when rendering XML output. > > Sounds like we can get away with normalized newlines and leave it up > to the XML receiver to either convert to CRLF if needed or use a > tolerant iCalendar library. CalDAV just needs to clarify that this is > necessary and appropriate. > > -wsv > Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 9416B7F572 for ; Mon, 14 Nov 2005 11:54:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7DC53142281 for ; Mon, 14 Nov 2005 11:54:52 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20900-02 for ; Mon, 14 Nov 2005 11:54:52 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1D820142279 for ; Mon, 14 Nov 2005 11:54:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 347D03530CF for ; Mon, 14 Nov 2005 20:53:40 +0100 (CET) Received: from [192.168.0.233] (port-ip-213-211-241-152.reverse.mdcc-fun.de [213.211.241.152]) by mail.mdlink.net (Postfix) with ESMTP id A5A033530BE for ; Mon, 14 Nov 2005 20:53:39 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: <43727541.8080501@Royer.com> <4378DEBE.1000004@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <372299A2-40BC-4C4E-95E6-D1C72184C8A0@opengroupware.org> Content-Transfer-Encoding: quoted-printable From: Helge Hess Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML Date: Mon, 14 Nov 2005 20:54:43 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.5 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2005 19:54:52 -0000 On 14. Nov 2005, at 20:38 Uhr, Wilfredo S=E1nchez Vega wrote: > This is true, but apparently they are allowed to normalize newlines. As far as I understand the spec XML parsers are _required_ to =20 normalize newlines: http://www.w3.org/TR/2004/REC-xml-20040204/ section 2.11. > I assume you mean that CDATA will preserve 0x0A and 0x0D? Not =20 > sure that's true, actually, but even so, that may solve the parser =20 > side of the problem, but then we have an XML generator problem. =20 > There doesn't appear to be any way in DOM to specify that it should =20= > emit a CDATA section when rendering XML output. Isn't CDATA just syntactic sugar to avoid repetitive escaping? =20 Section 2.7: "An example of a CDATA section, in which "" and "" are recognized as character data, not markup" Both, textual content and CDATA are reported as regular character =20 data, there is no runtime difference? Greets, Helge --=20 http://docs.opengroupware.org/Members/helge/ OpenGroupware.org Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 24A5A7F564 for ; Mon, 14 Nov 2005 11:38:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1425F142279 for ; Mon, 14 Nov 2005 11:38:14 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14592-02 for ; Mon, 14 Nov 2005 11:38:13 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C20A9142276 for ; Mon, 14 Nov 2005 11:38:13 -0800 (PST) Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id jAEJcC3D024112; Mon, 14 Nov 2005 11:38:12 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay5.apple.com (Apple SCV relay) with ESMTP id 6DF51324013; Mon, 14 Nov 2005 11:38:12 -0800 (PST) In-Reply-To: <4378DEBE.1000004@oracle.com> References: <43727541.8080501@Royer.com> <4378DEBE.1000004@oracle.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML Date: Mon, 14 Nov 2005 11:38:11 -0800 To: Bernard Desruisseaux X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2005 19:38:14 -0000 On Nov 14, 2005, at 11:00 AM, Bernard Desruisseaux wrote: > Wilfredo S=E1nchez Vega wrote: >> XML entity escaping is OK, but if that's the answer, the CalDAV =20= >> spec should require that clients and servers replace '\r' with =20 >> ' ' in calendar-data elements so that when the receiver gets =20 >> the data, it's not munged by their parser. > > XML parsers are supposed to report all white space (i.e., ASCII 0x09, > 0x0A, 0x0D, and 0x20) in the element content to the client =20 > application. > > content > > is not the same as > > > content > This is true, but apparently they are allowed to normalize newlines. > That being said, I'll update the draft with examples that escapes > '<', '>' and '&' or uses CDATA sections. For instance: > > VERSION:2.0 > BEGIN:VEVENT > SUMMARY:Seminar on Java & <XML> > ... > END:VEVENT > END:VCALENDAR > ]]> > > > VERSION:2.0 > BEGIN:VEVENT > SUMMARY:Seminar on Java & > ... > END:VEVENT > END:VCALENDAR > ]]> > > I don't believe it is necessary to escape 0x0A and 0x0D. I assume you mean that CDATA will preserve 0x0A and 0x0D? Not =20 sure that's true, actually, but even so, that may solve the parser =20 side of the problem, but then we have an XML generator problem. =20 There doesn't appear to be any way in DOM to specify that it should =20 emit a CDATA section when rendering XML output. Sounds like we can get away with normalized newlines and leave it =20 up to the XML receiver to either convert to CRLF if needed or use a =20 tolerant iCalendar library. CalDAV just needs to clarify that this =20 is necessary and appropriate. -wsv Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 9E4AF7F55D for ; Mon, 14 Nov 2005 11:00:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8E3DC142281 for ; Mon, 14 Nov 2005 11:00:33 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09310-06 for ; Mon, 14 Nov 2005 11:00:33 -0800 (PST) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.122.30]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 4590F142279 for ; Mon, 14 Nov 2005 11:00:33 -0800 (PST) Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id jAEJ0T69026534; Mon, 14 Nov 2005 12:00:29 -0700 Received: from localhost (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id jAEJ0TpQ031303; Mon, 14 Nov 2005 12:00:29 -0700 Received: from [144.23.219.186] (bdesruis-ca.ca.oracle.com [144.23.219.186]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAEJ0FEO031225 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 14 Nov 2005 12:00:19 -0700 Message-ID: <4378DEBE.1000004@oracle.com> Date: Mon, 14 Nov 2005 14:00:14 -0500 From: Bernard Desruisseaux User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML References: <43727541.8080501@Royer.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL, UPPERCASE_25_50 X-Spam-Level: Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2005 19:00:33 -0000 Wilfredo Sánchez Vega wrote: > XML entity escaping is OK, but if that's the answer, the CalDAV spec > should require that clients and servers replace '\r' with ' ' in > calendar-data elements so that when the receiver gets the data, it's > not munged by their parser. XML parsers are supposed to report all white space (i.e., ASCII 0x09, 0x0A, 0x0D, and 0x20) in the element content to the client application. content is not the same as content That being said, I'll update the draft with examples that escapes '<', '>' and '&' or uses CDATA sections. For instance: ... END:VEVENT END:VCALENDAR ]]> I don't believe it is necessary to escape 0x0A and 0x0D. Cheers, Bernard Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 4B4777F539; Sun, 13 Nov 2005 10:17:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3B848142287; Sun, 13 Nov 2005 10:17:38 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18738-06; Sun, 13 Nov 2005 10:17:38 -0800 (PST) Received: from mail.links.org (mail.links.org [217.155.92.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B9E10142284; Sun, 13 Nov 2005 10:17:37 -0800 (PST) Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 34AD033C1C; Sun, 13 Nov 2005 18:17:36 +0000 (GMT) Message-ID: <43778340.4070401@algroup.co.uk> Date: Sun, 13 Nov 2005 18:17:36 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: RL 'Bob' Morgan References: <195278d1b8b711283f6c7fdb93107e40@osafoundation.org> <43776934.6030105@algroup.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.6 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-Mailman-Approved-At: Thu, 17 Nov 2005 10:08:10 -0800 Cc: Cyrus Daboo , WebDav WG , Mike Shaver , Scott Lawrence , HTTP working group , Alexey Melnikov , Sam Hartman , CalDAV DevList Subject: [Ietf-caldav] Re: HTTP authentication X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2005 18:17:38 -0000 RL 'Bob' Morgan wrote: > >> I'm way behind on email ... there was a non-bof on identity management >> at IETF 64, under the name DIX. The plan is to propose a BoF for IETF >> 65, leading, hopefully, to a WG. Pity I didn't notice this beforehand. > > Note that the ietf-dix list/pre-bof/technology is entirely independent > from the ietf-http-auth list/bar-bof/technology, though of course > Everything Is Related in some fashion. I'm not sure I agree with that at all, since several, if not many, identity management solutions include HTTP auth in their problem space. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ ** ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ ** "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 928527F539; Sun, 13 Nov 2005 10:08:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7CFB9142287; Sun, 13 Nov 2005 10:08:09 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01757-06; Sun, 13 Nov 2005 10:08:09 -0800 (PST) Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 3DA19142284; Sun, 13 Nov 2005 10:08:09 -0800 (PST) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout3.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id jADI7XwS024119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 13 Nov 2005 10:07:33 -0800 X-Auth-Received: from [192.168.0.6] (c-67-183-136-75.hsd1.wa.comcast.net [67.183.136.75]) (authenticated authid=rlmorgan) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id jADI7TXU012308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 13 Nov 2005 10:07:32 -0800 Date: Sun, 13 Nov 2005 10:07:58 -0800 (PST) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perf.cac.washington.edu To: Ben Laurie In-Reply-To: <43776934.6030105@algroup.co.uk> Message-ID: References: <195278d1b8b711283f6c7fdb93107e40@osafoundation.org> <43776934.6030105@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.5 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-Mailman-Approved-At: Thu, 17 Nov 2005 10:08:09 -0800 Cc: Cyrus Daboo , WebDav WG , Mike Shaver , Scott Lawrence , HTTP working group , Alexey Melnikov , Sam Hartman , CalDAV DevList Subject: [Ietf-caldav] Re: HTTP authentication X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2005 18:08:09 -0000 > I'm way behind on email ... there was a non-bof on identity management > at IETF 64, under the name DIX. The plan is to propose a BoF for IETF > 65, leading, hopefully, to a WG. Pity I didn't notice this beforehand. Note that the ietf-dix list/pre-bof/technology is entirely independent from the ietf-http-auth list/bar-bof/technology, though of course Everything Is Related in some fashion. - RL "Bob" Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 033437F53E; Sun, 13 Nov 2005 08:26:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E84BE142287; Sun, 13 Nov 2005 08:26:30 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24205-04; Sun, 13 Nov 2005 08:26:30 -0800 (PST) Received: from mail.links.org (mail.links.org [217.155.92.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 769C9142284; Sun, 13 Nov 2005 08:26:30 -0800 (PST) Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 356CA33C1C; Sun, 13 Nov 2005 16:26:28 +0000 (GMT) Message-ID: <43776934.6030105@algroup.co.uk> Date: Sun, 13 Nov 2005 16:26:28 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Sam Hartman References: <195278d1b8b711283f6c7fdb93107e40@osafoundation.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.8 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-Mailman-Approved-At: Thu, 17 Nov 2005 10:08:10 -0800 Cc: Cyrus Daboo , WebDav WG , Mike Shaver , Scott Lawrence , HTTP working group , Alexey Melnikov , CalDAV DevList Subject: [Ietf-caldav] Re: HTTP authentication X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2005 16:26:31 -0000 Lisa Dusseault wrote: > Talking with various potential CalDAV deployers lately, there's a > perceived need for better HTTP authentication mechanisms: ones which > can deal with federated identity and single sign-on. Sam Hartman wrote: > > > > May I forward this to other interested parties? > > I think it is too late to get a BOF for IETF 64, but would be happy > to work on it for the next IETF. We could definitely have a bar bof. > I'm way behind on email ... there was a non-bof on identity management at IETF 64, under the name DIX. The plan is to propose a BoF for IETF 65, leading, hopefully, to a WG. Pity I didn't notice this beforehand. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ ** ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ ** "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 1980A7F52F for ; Fri, 11 Nov 2005 11:58:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 09C611422AC for ; Fri, 11 Nov 2005 11:58:59 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32173-02 for ; Fri, 11 Nov 2005 11:58:58 -0800 (PST) Received: from S4.cableone.net (s4.cableone.net [24.116.0.230]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8BF281422A2 for ; Fri, 11 Nov 2005 11:58:58 -0800 (PST) Received: from [192.168.168.10] (unverified [69.92.70.67]) by S4.cableone.net (CableOne SMTP Service S4) with ESMTP id 36615468 for multiple; Fri, 11 Nov 2005 13:16:25 -0700 Message-ID: <4374F7FF.1030702@Royer.com> Date: Fri, 11 Nov 2005 12:58:55 -0700 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Hare , ietf-caldav@osafoundation.org Subject: Re: Some comments Re: [Ietf-caldav] icalendar vs. CRLF vs. XML References: <43727541.8080501@Royer.com> <58BE2800-2263-43A4-85D2-1B9C95011EC8@wsanchez.net> <6.2.1.2.0.20051111120239.03c20c30@mail.comcast.net> In-Reply-To: <6.2.1.2.0.20051111120239.03c20c30@mail.comcast.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050004060506040700020801" X-SpamDetect: *: 1.250000 NakedCR=2.0,Aspam=-0.8 X-NakedCr: Body contained naked cr characters X-NotAscii: charset=us-ascii; X-IP-stats: Incoming Outgoing Last 1, First 93, in=128, out=124, spam=0 Known=true X-External-IP: 69.92.70.67 X-Abuse-Info: Send abuse complaints to abuse@cableone.net X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf-caldav@osafoundation.org List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2005 19:58:59 -0000 This is a cryptographically signed message in MIME format. --------------ms050004060506040700020801 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Tim Hare wrote: > ,,, I just re-skimmed Doug Royer's xCal draft > (http://www.ietf.org/internet-drafts/draft-royer-calsch-xcal-03.txt) and > I don't see the line ending problem addressed there either. iCal object hard code the two character \ followed by N in their data as defended in 2445 so iCal data represented in xCal does not need to worry about newlines embedded in property or parameter values. Hard coded newlines and carriage returns in iCal data are for line wrap only, they are not part of the data and can be ignored, per 2445. My XSLT -> iCal code DOES terminate each iCal line with \r\n when it translates the code back to iCal format. So yes, xCal does address the problem. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------ms050004060506040700020801 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMzDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBK8wggQYoAMCAQICEFsGSvEntexpo94qqcjJuhAwDQYJKoZIhvcNAQEFBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDUwOTE4MDAw MDAwWhcNMDYwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDZ BFhLbROJ3gBYIeuP8+vR6G9dT4K3lXeeK+a9TO0qfqkxm6B3RDcXyhjd000rAUjGGRvVkyBX 6EjXkqCILRMAkbU5Zvk8nMyh0a27CzZH5JPHgw9bUutozhECZSDn/F5GRB/nwlOS3ip2Q+30 AvwX7x2h/12yyjyO9op9HIZLnpKXqgJETp/fmiOgfPg7xu8OBrwch1k9f48As0/8YCstHjka 32q/jEqWboVtE40sk48ROWca6KMLXli3HfVdj/NIZkYc8UFjK6Y5ojZ8hCYUo6H6hZanIyqd ptDd5T5/TuQHcJH7M6kq/BUgTzDJgRXdQEPxISfZGCRj7NckF5zXAgMBAAGjgcswgcgwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjAUBgpghkgBhvhFAQYHBAYWBE5vbmUwMwYDVR0fBCwwKjAooCagJIYi aHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQUFAAOBgQBT 5VLp42EyzXxqDBuVNmtAkVqt6U3GOY9gWKUUzBSRtlepDPiR3yF+I+GfeEZ8087H9QKcBrrU eXQlQ68hFm/nH1XVTVGdQ3wZOSnC/6JrZUvlurzw9bjjXXaUx2xKI/vH7PFBoa2bfMAxSfGO UEBY2wBeWT4QhxxV3TuDSI3NgzCCBK8wggQYoAMCAQICEFsGSvEntexpo94qqcjJuhAwDQYJ KoZIhvcNAQEFBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwHhcNMDUwOTE4MDAwMDAwWhcNMDYwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxU RChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0 YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBS b3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDZBFhLbROJ3gBYIeuP8+vR6G9dT4K3lXeeK+a9TO0qfqkxm6B3RDcX yhjd000rAUjGGRvVkyBX6EjXkqCILRMAkbU5Zvk8nMyh0a27CzZH5JPHgw9bUutozhECZSDn /F5GRB/nwlOS3ip2Q+30AvwX7x2h/12yyjyO9op9HIZLnpKXqgJETp/fmiOgfPg7xu8OBrwc h1k9f48As0/8YCstHjka32q/jEqWboVtE40sk48ROWca6KMLXli3HfVdj/NIZkYc8UFjK6Y5 ojZ8hCYUo6H6hZanIyqdptDd5T5/TuQHcJH7M6kq/BUgTzDJgRXdQEPxISfZGCRj7NckF5zX AgMBAAGjgcswgcgwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYI KwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0G A1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAUBgpghkgBhvhFAQYHBAYWBE5vbmUwMwYD VR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkq hkiG9w0BAQUFAAOBgQBT5VLp42EyzXxqDBuVNmtAkVqt6U3GOY9gWKUUzBSRtlepDPiR3yF+ I+GfeEZ8087H9QKcBrrUeXQlQ68hFm/nH1XVTVGdQ3wZOSnC/6JrZUvlurzw9bjjXXaUx2xK I/vH7PFBoa2bfMAxSfGOUEBY2wBeWT4QhxxV3TuDSI3NgzGCBKowggSmAgEBMIHhMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBbBkrxJ7XsaaPeKqnI yboQMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA1MTExMTE5NTg1NVowIwYJKoZIhvcNAQkEMRYEFMoZtiH4dOpI3zpZOwvtEicA qpZwMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQxgeQwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFsGSvEntexp o94qqcjJuhAwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZl cmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5 ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXIt UGVyc29uYSBOb3QgVmFsaWRhdGVkAhBbBkrxJ7XsaaPeKqnIyboQMA0GCSqGSIb3DQEBAQUA BIIBAFj9QBc52WTXMd+ah7CJhvHX7JqweLDdgwPnMX1wrnYEAYysHa9Ygs97hU6QFKzFgx15 Mv/quWdn6j/89T/I16us1AxplenY/VMff7qERoqwgI2tdSJB6jbRfoeHbDABDbejLyQNNKLn EqL6hhXl4nafmsQHFQm00JG+i+/i3xTuPGrZ1Tn2nLDWaz8znmX0tdefkaQ9e2PFa9WypdT7 Y5coRF0cLc/UuRRJb+HxL0EnheYT6WROLzY663NFZOIDZ5GpCI5FVmlBsPqXnRHERCy3iaaM kNxWX2hVRIP+tW/wUq4Luj0iIApnN9YxGdZKstnvToecxAu22RZ0Azl1PWIAAAAAAAA= --------------ms050004060506040700020801-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id BAC0C7F52F for ; Fri, 11 Nov 2005 11:58:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id AAD161422AC for ; Fri, 11 Nov 2005 11:58:39 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31267-06 for ; Fri, 11 Nov 2005 11:58:39 -0800 (PST) Received: from S3.cableone.net (s3.cableone.net [24.116.0.229]) by laweleka.osafoundation.org (Postfix) with ESMTP id 353ED1422A2 for ; Fri, 11 Nov 2005 11:58:39 -0800 (PST) Received: from [192.168.168.10] (unverified [69.92.70.67]) by S3.cableone.net (CableOne SMTP Service S3) with ESMTP id 36863218 for multiple; Fri, 11 Nov 2005 13:10:53 -0700 Message-ID: <4374F7EC.9070300@Royer.com> Date: Fri, 11 Nov 2005 12:58:36 -0700 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Hare , ietf-caldav@osafoundation.org Subject: Re: Some comments Re: [Ietf-caldav] icalendar vs. CRLF vs. XML References: <43727541.8080501@Royer.com> <58BE2800-2263-43A4-85D2-1B9C95011EC8@wsanchez.net> <6.2.1.2.0.20051111120239.03c20c30@mail.comcast.net> In-Reply-To: <6.2.1.2.0.20051111120239.03c20c30@mail.comcast.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020708070609000406080106" X-SpamDetect: *: 1.250000 NakedCR=2.0,Aspam=-0.8 X-NakedCr: Body contained naked cr characters X-NotAscii: charset=us-ascii; X-IP-stats: Incoming Outgoing Last 1, First 91, in=184, out=176, spam=0 Known=true X-External-IP: 69.92.70.67 X-Abuse-Info: Send abuse complaints to abuse@cableone.net X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf-caldav@osafoundation.org List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2005 19:58:39 -0000 This is a cryptographically signed message in MIME format. --------------ms020708070609000406080106 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Tim Hare wrote: > ,,, I just re-skimmed Doug Royer's xCal draft > (http://www.ietf.org/internet-drafts/draft-royer-calsch-xcal-03.txt) and > I don't see the line ending problem addressed there either. iCal object hard code the two character \ followed by N in their data as defended in 2445 so iCal data represented in xCal does not need to worry about newlines embedded in property or parameter values. Hard coded newlines and carriage returns in iCal data are for line wrap only, they are not part of the data and can be ignored, per 2445. My XSLT -> iCal code DOES terminate each iCal line with \r\n when it translates the code back to iCal format. So yes, it does address the problem. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------ms020708070609000406080106 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMzDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBK8wggQYoAMCAQICEFsGSvEntexpo94qqcjJuhAwDQYJKoZIhvcNAQEFBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDUwOTE4MDAw MDAwWhcNMDYwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDZ BFhLbROJ3gBYIeuP8+vR6G9dT4K3lXeeK+a9TO0qfqkxm6B3RDcXyhjd000rAUjGGRvVkyBX 6EjXkqCILRMAkbU5Zvk8nMyh0a27CzZH5JPHgw9bUutozhECZSDn/F5GRB/nwlOS3ip2Q+30 AvwX7x2h/12yyjyO9op9HIZLnpKXqgJETp/fmiOgfPg7xu8OBrwch1k9f48As0/8YCstHjka 32q/jEqWboVtE40sk48ROWca6KMLXli3HfVdj/NIZkYc8UFjK6Y5ojZ8hCYUo6H6hZanIyqd ptDd5T5/TuQHcJH7M6kq/BUgTzDJgRXdQEPxISfZGCRj7NckF5zXAgMBAAGjgcswgcgwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjAUBgpghkgBhvhFAQYHBAYWBE5vbmUwMwYDVR0fBCwwKjAooCagJIYi aHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQUFAAOBgQBT 5VLp42EyzXxqDBuVNmtAkVqt6U3GOY9gWKUUzBSRtlepDPiR3yF+I+GfeEZ8087H9QKcBrrU eXQlQ68hFm/nH1XVTVGdQ3wZOSnC/6JrZUvlurzw9bjjXXaUx2xKI/vH7PFBoa2bfMAxSfGO UEBY2wBeWT4QhxxV3TuDSI3NgzCCBK8wggQYoAMCAQICEFsGSvEntexpo94qqcjJuhAwDQYJ KoZIhvcNAQEFBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwHhcNMDUwOTE4MDAwMDAwWhcNMDYwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxU RChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0 YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBS b3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDZBFhLbROJ3gBYIeuP8+vR6G9dT4K3lXeeK+a9TO0qfqkxm6B3RDcX yhjd000rAUjGGRvVkyBX6EjXkqCILRMAkbU5Zvk8nMyh0a27CzZH5JPHgw9bUutozhECZSDn /F5GRB/nwlOS3ip2Q+30AvwX7x2h/12yyjyO9op9HIZLnpKXqgJETp/fmiOgfPg7xu8OBrwc h1k9f48As0/8YCstHjka32q/jEqWboVtE40sk48ROWca6KMLXli3HfVdj/NIZkYc8UFjK6Y5 ojZ8hCYUo6H6hZanIyqdptDd5T5/TuQHcJH7M6kq/BUgTzDJgRXdQEPxISfZGCRj7NckF5zX AgMBAAGjgcswgcgwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYI KwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0G A1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAUBgpghkgBhvhFAQYHBAYWBE5vbmUwMwYD VR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkq hkiG9w0BAQUFAAOBgQBT5VLp42EyzXxqDBuVNmtAkVqt6U3GOY9gWKUUzBSRtlepDPiR3yF+ I+GfeEZ8087H9QKcBrrUeXQlQ68hFm/nH1XVTVGdQ3wZOSnC/6JrZUvlurzw9bjjXXaUx2xK I/vH7PFBoa2bfMAxSfGOUEBY2wBeWT4QhxxV3TuDSI3NgzGCBKowggSmAgEBMIHhMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBbBkrxJ7XsaaPeKqnI yboQMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA1MTExMTE5NTgzNlowIwYJKoZIhvcNAQkEMRYEFPshHhy72qWLAjdkqv1y6CEt NjxqMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQxgeQwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFsGSvEntexp o94qqcjJuhAwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZl cmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5 ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXIt UGVyc29uYSBOb3QgVmFsaWRhdGVkAhBbBkrxJ7XsaaPeKqnIyboQMA0GCSqGSIb3DQEBAQUA BIIBAK7p003IdceJEKNeozWrR9Il6tLhhvNHrE888eCgb2Uzm+j8XerOCgwfRMbtHOvJAtl6 dNCF9WUktlHLAHvGxSdK+Bb3oNfxH58T6wGksIcg9rbHa1RDan5LDbdV7luDdg7bePntv/Z4 MmcdUhTyT42QFwqjnGS9v6aQygfVYp9xQK9CgWQySivC7yECyOnx5H/zIt8otMae6L01Evq8 LKehNt5Ew9RLUrGDbviECKQG42ovoeHZtmuEz3fEvN3lZ7UosW4cpOtt3HSdhcFHQZZ/dZ5s oisGgj16RvX4IjFyiTxizZCiTQdxEbB0c4D4DOSZMkp4SBau5A3frjEC+YsAAAAAAAA= --------------ms020708070609000406080106-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 931D97F553 for ; Fri, 11 Nov 2005 10:45:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 83C211422AC for ; Fri, 11 Nov 2005 10:45:53 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21892-05 for ; Fri, 11 Nov 2005 10:45:53 -0800 (PST) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by laweleka.osafoundation.org (Postfix) with ESMTP id 208F31422AA for ; Fri, 11 Nov 2005 10:45:53 -0800 (PST) Received: from thare.comcast.net (pcp03614075pcs.micske01.fl.comcast.net[68.84.31.33]) by comcast.net (sccrmhc13) with SMTP id <20051111184536013003a6ure>; Fri, 11 Nov 2005 18:45:41 +0000 Message-Id: <6.2.1.2.0.20051111120239.03c20c30@mail.comcast.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 11 Nov 2005 13:45:33 -0500 To: ietf-caldav@osafoundation.org From: Tim Hare Subject: Some comments Re: [Ietf-caldav] icalendar vs. CRLF vs. XML In-Reply-To: <58BE2800-2263-43A4-85D2-1B9C95011EC8@wsanchez.net> References: <43727541.8080501@Royer.com> <58BE2800-2263-43A4-85D2-1B9C95011EC8@wsanchez.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.5 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2005 18:45:53 -0000 RFC2445 was not designed for XML and therein lies the problem. I didn't=20 address this in my individual draft guideline for using calendar data in=20 XML, because my draft was focused on one direction - providing translation= =20 from arbitrary XML to iCalendar where this problem doesn't really exist. I= =20 just re-skimmed Doug Royer's xCal draft=20 (http://www.ietf.org/internet-drafts/draft-royer-calsch-xcal-03.txt) and I= =20 don't see the line ending problem addressed there either. At 12:57 AM 11/11/2005, Wilfredo S=E1nchez Vega wrote: > I agree with the sentiment, but my concern is that iCalendar (I >think) does not, and I'm not sure HTTP gets to blindly override >iCalendar. I can fix (though one could say break) the iCalendar >library I'm using, but I'm not sure everyone gets to do that. > > I just think we should be careful to make sure that the protocol >doesn't force people into a situation where they can't use a >conforming iCalendar parser. > > If the following logic: > > if calendar-data does not contain "\r\n" then > replace "\n" in calendar-data with "\r\n" > >is guaranteed to work for all iCalendar data with "\r\n" replaced >with "\n", then I guess we're OK; the server can apply that logic >before passing the data along to the iCalendar parser. As long as >"\n" isn't allowed within a iCalendar content line, that should be >true... > > -wsv > > >On Nov 10, 2005, at 5:05 PM, Cyrus Daboo wrote: > >>I would really like to be able to say that CalDAV clients/servers >>should expect to handle and parse iCalendar data with arbitrary >>line end conventions. HTTP actually states that text content-types >>transmitted by the server could have any of the three standard line >>end formats so that is a little at odds with requiring text/ calendar=20 >>objects (or iCalendar embedded in XML) to always use CRLF. > >_______________________________________________ >Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org >See http://ietf.webdav.org/caldav/ for more CalDAV resources >http://lists.osafoundation.org/mailman/listinfo/ietf-caldav Tim Hare Interested Bystander, Non-Inc.=20 Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id C17527F52F for ; Thu, 10 Nov 2005 21:57:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B23261422AD for ; Thu, 10 Nov 2005 21:57:23 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03902-02 for ; Thu, 10 Nov 2005 21:57:23 -0800 (PST) Received: from joliet-jake.wsanchez.net (adsl-68-126-173-45.dsl.snfc21.pacbell.net [68.126.173.45]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4C7CD1422AC for ; Thu, 10 Nov 2005 21:57:23 -0800 (PST) Received: from [68.126.173.43] (adsl-68-126-173-43.dsl.snfc21.pacbell.net [68.126.173.43]) by joliet-jake.wsanchez.net (Postfix) with ESMTP id 1E19519B461; Thu, 10 Nov 2005 21:57:22 -0800 (PST) In-Reply-To: References: <43727541.8080501@Royer.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <58BE2800-2263-43A4-85D2-1B9C95011EC8@wsanchez.net> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML Date: Thu, 10 Nov 2005 21:57:20 -0800 To: Cyrus Daboo X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.0 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2005 05:57:23 -0000 I agree with the sentiment, but my concern is that iCalendar (I think) does not, and I'm not sure HTTP gets to blindly override iCalendar. I can fix (though one could say break) the iCalendar library I'm using, but I'm not sure everyone gets to do that. I just think we should be careful to make sure that the protocol doesn't force people into a situation where they can't use a conforming iCalendar parser. If the following logic: if calendar-data does not contain "\r\n" then replace "\n" in calendar-data with "\r\n" is guaranteed to work for all iCalendar data with "\r\n" replaced with "\n", then I guess we're OK; the server can apply that logic before passing the data along to the iCalendar parser. As long as "\n" isn't allowed within a iCalendar content line, that should be true... -wsv On Nov 10, 2005, at 5:05 PM, Cyrus Daboo wrote: > I would really like to be able to say that CalDAV clients/servers > should expect to handle and parse iCalendar data with arbitrary > line end conventions. HTTP actually states that text content-types > transmitted by the server could have any of the three standard line > end formats so that is a little at odds with requiring text/ > calendar objects (or iCalendar embedded in XML) to always use CRLF. Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 39CDC7F52D for ; Thu, 10 Nov 2005 17:05:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2A9F5142293 for ; Thu, 10 Nov 2005 17:05:55 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00381-07 for ; Thu, 10 Nov 2005 17:05:54 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id BC19A142260 for ; Thu, 10 Nov 2005 17:05:54 -0800 (PST) Received: from [10.0.1.2] (pool-71-240-26-158.pitt.east.verizon.net [71.240.26.158]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id jAB1ebUV003726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Nov 2005 20:40:39 -0500 Date: Thu, 10 Nov 2005 20:05:49 -0500 From: Cyrus Daboo To: =?UTF-8?Q?Wilfredo_S=C3=A1nchez_Vega?= , ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML Message-ID: In-Reply-To: References: <43727541.8080501@Royer.com> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.1 tagged_above=-50.0 required=4.0 tests=AWL, MIME_QP_LONG_LINE X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2005 01:05:55 -0000 Hi Wilfredo, --On November 10, 2005 3:57:19 PM -0800 Wilfredo S=C3=A1nchez Vega=20 wrote: >> Use XML CDATA or XML entity escaping. > > I don't know how to tell the parser that an element is CDATA without > giving it a DTD, and WebDAV XML is non-validating and has no DTD, so I > don't know that this will help me. > > XML entity escaping is OK, but if that's the answer, the CalDAV spec > should require that clients and servers replace '\r' with ' ' in > calendar-data elements so that when the receiver gets the data, it's not > munged by their parser. I would really like to be able to say that CalDAV clients/servers should=20 expect to handle and parse iCalendar data with arbitrary line end=20 conventions. HTTP actually states that text content-types transmitted by=20 the server could have any of the three standard line end formats so that is = a little at odds with requiring text/calendar objects (or iCalendar=20 embedded in XML) to always use CRLF. --=20 Cyrus Daboo Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2CD5E7F50B for ; Thu, 10 Nov 2005 15:57:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1D6BD14228B for ; Thu, 10 Nov 2005 15:57:22 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32624-03 for ; Thu, 10 Nov 2005 15:57:21 -0800 (PST) Received: from joliet-jake.wsanchez.net (adsl-68-126-173-45.dsl.snfc21.pacbell.net [68.126.173.45]) by laweleka.osafoundation.org (Postfix) with ESMTP id CCC7614228F for ; Thu, 10 Nov 2005 15:57:21 -0800 (PST) Received: from [68.126.173.43] (adsl-68-126-173-43.dsl.snfc21.pacbell.net [68.126.173.43]) by joliet-jake.wsanchez.net (Postfix) with ESMTP id 6A5D319B29F for ; Thu, 10 Nov 2005 15:57:20 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43727541.8080501@Royer.com> References: <43727541.8080501@Royer.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML Date: Thu, 10 Nov 2005 15:57:19 -0800 To: ietf-caldav@osafoundation.org X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2005 23:57:22 -0000 On Nov 9, 2005, at 2:16 PM, Doug Royer wrote: > Use XML CDATA or XML entity escaping. I don't know how to tell the parser that an element is CDATA without giving it a DTD, and WebDAV XML is non-validating and has no DTD, so I don't know that this will help me. XML entity escaping is OK, but if that's the answer, the CalDAV spec should require that clients and servers replace '\r' with ' ' in calendar-data elements so that when the receiver gets the data, it's not munged by their parser. -wsv Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 826C87F523 for ; Wed, 9 Nov 2005 14:24:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 734B414229F for ; Wed, 9 Nov 2005 14:24:40 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22602-01 for ; Wed, 9 Nov 2005 14:24:40 -0800 (PST) Received: from S3.cableone.net (s3.cableone.net [24.116.0.229]) by laweleka.osafoundation.org (Postfix) with ESMTP id EA65D14229C for ; Wed, 9 Nov 2005 14:24:39 -0800 (PST) Received: from [192.168.168.10] (unverified [69.92.70.67]) by S3.cableone.net (CableOne SMTP Service S3) with ESMTP id 36656051 for multiple; Wed, 09 Nov 2005 15:36:32 -0700 Message-ID: <43727725.6020201@Royer.com> Date: Wed, 09 Nov 2005 15:24:37 -0700 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= , ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070308090703010400080803" X-SpamDetect: *: 1.250000 NakedCR=2.0,Aspam=-0.8 X-NakedCr: Body contained naked cr characters X-NotAscii: charset=us-ascii; X-IP-stats: Incoming Outgoing Last 1, First 89, in=178, out=171, spam=0 Known=true X-External-IP: 69.92.70.67 X-Abuse-Info: Send abuse complaints to abuse@cableone.net X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf-caldav@osafoundation.org List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2005 22:24:40 -0000 This is a cryptographically signed message in MIME format. --------------ms070308090703010400080803 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > 2- It's possible (and in fact doesn't look unlikely) for an icalendar > component to contain \n in its data (eg. LOCATION is "100 S. Van > Ness\nSan Francisco, CA\nU.S.A."), so you'd have to figure out how not > to replace those. In iCal, inline \n and \r are already escaped: ESCAPED-CHAR = "\\" / "\;" / "\," / "\N" / "\n") ; \\ encodes \, \N or \n encodes newline ; \; encodes ;, \, encodes , So a DESCRIPTION property VALUE with a \r\n would have that two character sequence replaced with the TWO characters: '\' 'N' or '\' 'n' -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------ms070308090703010400080803 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMzDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBK8wggQYoAMCAQICEFsGSvEntexpo94qqcjJuhAwDQYJKoZIhvcNAQEFBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDUwOTE4MDAw MDAwWhcNMDYwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDZ BFhLbROJ3gBYIeuP8+vR6G9dT4K3lXeeK+a9TO0qfqkxm6B3RDcXyhjd000rAUjGGRvVkyBX 6EjXkqCILRMAkbU5Zvk8nMyh0a27CzZH5JPHgw9bUutozhECZSDn/F5GRB/nwlOS3ip2Q+30 AvwX7x2h/12yyjyO9op9HIZLnpKXqgJETp/fmiOgfPg7xu8OBrwch1k9f48As0/8YCstHjka 32q/jEqWboVtE40sk48ROWca6KMLXli3HfVdj/NIZkYc8UFjK6Y5ojZ8hCYUo6H6hZanIyqd ptDd5T5/TuQHcJH7M6kq/BUgTzDJgRXdQEPxISfZGCRj7NckF5zXAgMBAAGjgcswgcgwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjAUBgpghkgBhvhFAQYHBAYWBE5vbmUwMwYDVR0fBCwwKjAooCagJIYi aHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQUFAAOBgQBT 5VLp42EyzXxqDBuVNmtAkVqt6U3GOY9gWKUUzBSRtlepDPiR3yF+I+GfeEZ8087H9QKcBrrU eXQlQ68hFm/nH1XVTVGdQ3wZOSnC/6JrZUvlurzw9bjjXXaUx2xKI/vH7PFBoa2bfMAxSfGO UEBY2wBeWT4QhxxV3TuDSI3NgzCCBK8wggQYoAMCAQICEFsGSvEntexpo94qqcjJuhAwDQYJ KoZIhvcNAQEFBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwHhcNMDUwOTE4MDAwMDAwWhcNMDYwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxU RChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0 YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBS b3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDZBFhLbROJ3gBYIeuP8+vR6G9dT4K3lXeeK+a9TO0qfqkxm6B3RDcX yhjd000rAUjGGRvVkyBX6EjXkqCILRMAkbU5Zvk8nMyh0a27CzZH5JPHgw9bUutozhECZSDn /F5GRB/nwlOS3ip2Q+30AvwX7x2h/12yyjyO9op9HIZLnpKXqgJETp/fmiOgfPg7xu8OBrwc h1k9f48As0/8YCstHjka32q/jEqWboVtE40sk48ROWca6KMLXli3HfVdj/NIZkYc8UFjK6Y5 ojZ8hCYUo6H6hZanIyqdptDd5T5/TuQHcJH7M6kq/BUgTzDJgRXdQEPxISfZGCRj7NckF5zX AgMBAAGjgcswgcgwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYI KwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0G A1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAUBgpghkgBhvhFAQYHBAYWBE5vbmUwMwYD VR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkq hkiG9w0BAQUFAAOBgQBT5VLp42EyzXxqDBuVNmtAkVqt6U3GOY9gWKUUzBSRtlepDPiR3yF+ I+GfeEZ8087H9QKcBrrUeXQlQ68hFm/nH1XVTVGdQ3wZOSnC/6JrZUvlurzw9bjjXXaUx2xK I/vH7PFBoa2bfMAxSfGOUEBY2wBeWT4QhxxV3TuDSI3NgzGCBKowggSmAgEBMIHhMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBbBkrxJ7XsaaPeKqnI yboQMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA1MTEwOTIyMjQzN1owIwYJKoZIhvcNAQkEMRYEFGd6dyXu78p3PWHmswi/mGaA 5yrkMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQxgeQwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFsGSvEntexp o94qqcjJuhAwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZl cmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5 ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXIt UGVyc29uYSBOb3QgVmFsaWRhdGVkAhBbBkrxJ7XsaaPeKqnIyboQMA0GCSqGSIb3DQEBAQUA BIIBAGDyHfT4EGnX7wzRI72Yy+141F0/z6/A45ql7Uf4IYIXzr5ZM5hsqxpjJsf2imVGtPow cRoAumy5exiPod15m+JzrbjgYoBadu9wgCGqswbdZTccLCC1On57t9OqQeZL25Y+Zq5sqWab lMSTOCDseuWl3biItlZyY7jIJpi7cKffQVtfmr0UlgvH0WlwExil4PnWGaR6JUmTkqwMLKT3 gxEl8ktjdwQ8grZGde+FHi24zEFL9R1bJSvp4PSvbrKUsuIbdkq7mYmbWkU8f2gi1Euzo48r bLCZmBs1592FC3J8dKvcEObPNpmDHCKPAVmniFYEiIIQQ8xuFRxD2mllpjIAAAAAAAA= --------------ms070308090703010400080803-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 019A27F530 for ; Wed, 9 Nov 2005 14:16:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E58F61422A2 for ; Wed, 9 Nov 2005 14:16:36 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21790-02 for ; Wed, 9 Nov 2005 14:16:36 -0800 (PST) Received: from S1.cableone.net (s1.cableone.net [24.116.0.227]) by laweleka.osafoundation.org (Postfix) with ESMTP id 50E2F14229F for ; Wed, 9 Nov 2005 14:16:36 -0800 (PST) Received: from [192.168.168.10] (unverified [69.92.70.67]) by S1.cableone.net (CableOne SMTP Service S1) with ESMTP id 36751605 for multiple; Wed, 09 Nov 2005 15:16:57 -0700 Message-ID: <43727541.8080501@Royer.com> Date: Wed, 09 Nov 2005 15:16:33 -0700 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= , ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050202070805030900070304" X-SpamDetect: *: 1.250000 NakedCR=2.0,Aspam=-0.8 X-Aspam: For explanation see http://netwinsite.com/surgemail/aspaminfo.htm X-Aspam: Words 0.0 -561-5848 -562-2131 -gagel -caledonia -theres -iis -generate -warned -scanning X-Aspam: URLS scored 0.8 verisign.com cnc.bc.ca X-Aspam: Best match was sample c:\good\1051592149.251_651.ball X-Aspam: Total 0.8 X-NakedCr: Body contained naked cr characters X-IP-stats: Incoming Outgoing Last 1, First 92, in=145, out=145, spam=0 Known=true X-External-IP: 69.92.70.67 X-Abuse-Info: Send abuse complaints to abuse@cableone.net X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf-caldav@osafoundation.org List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2005 22:16:37 -0000 This is a cryptographically signed message in MIME format. --------------ms050202070805030900070304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Use XML CDATA or XML entity escaping. Wilfredo S=E1nchez Vega wrote: > I'm noticing what looks like an inherent problem with the calendar-=20 > data element. One of the uses of calendar-data is to inline icalendar= =20 > data. The problem is that icalendar requires that lines be terminated= =20 > with \r\n (CRLF), but XML parsers seem to be allowed to normalize=20 > newlines. For example (python): >=20 > >>> data =3D '\nHELLO\r\nWORLD' > >>> doc =3D xml.dom.minidom.parseString(data) > >>> doc.toxml() > u'\nHELLO\nWORLD' >=20 > Notice that the \r in the input XML was removed in the output. =20 > Depending on how I construct the XML document, the \r can be lost whil= e=20 > parsing the document into a DOM or which emitting a DOM as XML. >=20 > My concern here is that if XML parsers/generators are allowed to =20 > monkey with EOL strings, the icalendar data will get munged. I can =20 > probably fiddle with my XML code until I plug all of the paths in whic= h=20 > this is happening, but it doesn't seem easy, which means that CalDAV=20 > implementors are likely to screw it up at least some of the time, sinc= e=20 > most people don't want to write there own XML parsers and generators, = > that being the whole point of XML. >=20 > I don't think we can get away with allowing XML that normalizes \r \n= =20 > to \n... the problem there is that it's no longer valid icalendar data= =20 > and while it's generally easy enough to replace \n with \r\n, that=20 > solution will be bug-ridden: >=20 > 1- You don't want to replace \n with \r\n if it's already using \r \n= ,=20 > so you have to to detect it. >=20 > 2- It's possible (and in fact doesn't look unlikely) for an icalenda= r=20 > component to contain \n in its data (eg. LOCATION is "100 S. Van=20 > Ness\nSan Francisco, CA\nU.S.A."), so you'd have to figure out how not= =20 > to replace those. >=20 > ...so it might be necessary to encode the icalendar data in the XML, =20 > but the spec would have to specify that. >=20 > -wsv >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav --=20 Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------ms050202070805030900070304 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMzDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBK8wggQYoAMCAQICEFsGSvEntexpo94qqcjJuhAwDQYJKoZIhvcNAQEFBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDUwOTE4MDAw MDAwWhcNMDYwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDZ BFhLbROJ3gBYIeuP8+vR6G9dT4K3lXeeK+a9TO0qfqkxm6B3RDcXyhjd000rAUjGGRvVkyBX 6EjXkqCILRMAkbU5Zvk8nMyh0a27CzZH5JPHgw9bUutozhECZSDn/F5GRB/nwlOS3ip2Q+30 AvwX7x2h/12yyjyO9op9HIZLnpKXqgJETp/fmiOgfPg7xu8OBrwch1k9f48As0/8YCstHjka 32q/jEqWboVtE40sk48ROWca6KMLXli3HfVdj/NIZkYc8UFjK6Y5ojZ8hCYUo6H6hZanIyqd ptDd5T5/TuQHcJH7M6kq/BUgTzDJgRXdQEPxISfZGCRj7NckF5zXAgMBAAGjgcswgcgwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjAUBgpghkgBhvhFAQYHBAYWBE5vbmUwMwYDVR0fBCwwKjAooCagJIYi aHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQUFAAOBgQBT 5VLp42EyzXxqDBuVNmtAkVqt6U3GOY9gWKUUzBSRtlepDPiR3yF+I+GfeEZ8087H9QKcBrrU eXQlQ68hFm/nH1XVTVGdQ3wZOSnC/6JrZUvlurzw9bjjXXaUx2xKI/vH7PFBoa2bfMAxSfGO UEBY2wBeWT4QhxxV3TuDSI3NgzCCBK8wggQYoAMCAQICEFsGSvEntexpo94qqcjJuhAwDQYJ KoZIhvcNAQEFBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwHhcNMDUwOTE4MDAwMDAwWhcNMDYwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxU RChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0 YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBS b3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDZBFhLbROJ3gBYIeuP8+vR6G9dT4K3lXeeK+a9TO0qfqkxm6B3RDcX yhjd000rAUjGGRvVkyBX6EjXkqCILRMAkbU5Zvk8nMyh0a27CzZH5JPHgw9bUutozhECZSDn /F5GRB/nwlOS3ip2Q+30AvwX7x2h/12yyjyO9op9HIZLnpKXqgJETp/fmiOgfPg7xu8OBrwc h1k9f48As0/8YCstHjka32q/jEqWboVtE40sk48ROWca6KMLXli3HfVdj/NIZkYc8UFjK6Y5 ojZ8hCYUo6H6hZanIyqdptDd5T5/TuQHcJH7M6kq/BUgTzDJgRXdQEPxISfZGCRj7NckF5zX AgMBAAGjgcswgcgwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYI KwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0G A1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAUBgpghkgBhvhFAQYHBAYWBE5vbmUwMwYD VR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkq hkiG9w0BAQUFAAOBgQBT5VLp42EyzXxqDBuVNmtAkVqt6U3GOY9gWKUUzBSRtlepDPiR3yF+ I+GfeEZ8087H9QKcBrrUeXQlQ68hFm/nH1XVTVGdQ3wZOSnC/6JrZUvlurzw9bjjXXaUx2xK I/vH7PFBoa2bfMAxSfGOUEBY2wBeWT4QhxxV3TuDSI3NgzGCBKowggSmAgEBMIHhMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBbBkrxJ7XsaaPeKqnI yboQMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA1MTEwOTIyMTYzM1owIwYJKoZIhvcNAQkEMRYEFAzx30TXyEmJwVgBKkmn0l0s 2dMnMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQxgeQwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFsGSvEntexp o94qqcjJuhAwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZl cmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5 ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXIt UGVyc29uYSBOb3QgVmFsaWRhdGVkAhBbBkrxJ7XsaaPeKqnIyboQMA0GCSqGSIb3DQEBAQUA BIIBAL1iqbq2YtkmvW5xVuF4xclwgFZV8rqYz5PsUAHdmCTQ9sJdm9QXrWpWfL6Z1HdCAMcG 5KJZGP72hmrZ1Jr9/CbEe+fi5j4hcCezckHsYoOsu2gjCwTBb+icNgtE7gowhFzdsXPlhEiZ DhBg9qDA1tkuW+lUZgTBVgWYjgSEwHWDwaNEnBNdU0sVesOnue3OHdumrcOu9ubfqN6mc9jp fUG2z9IYl+tjsCgHHEcKCJRG4GHhhJLpzpN50ImSNeIyvz4QL3GfdbdevQfOHIjsbFwJU+iv Rf7ebEOudYL0XGQfHrlSR/NpJmS3qHAw+UQgAooJlNrNdpEJmLlGAk9nXgAAAAAAAAA= --------------ms050202070805030900070304-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D94CD7F523 for ; Wed, 9 Nov 2005 14:15:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CA2B81422A2 for ; Wed, 9 Nov 2005 14:15:33 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21611-01 for ; Wed, 9 Nov 2005 14:15:33 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 72BA614229F for ; Wed, 9 Nov 2005 14:15:33 -0800 (PST) Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id jA9MFXES009625 for ; Wed, 9 Nov 2005 14:15:33 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay5.apple.com (Apple SCV relay) with ESMTP id 1B262324013 for ; Wed, 9 Nov 2005 14:15:33 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) To: ietf-caldav@osafoundation.org Message-Id: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3-795635071; protocol="application/pkcs7-signature" From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Date: Wed, 9 Nov 2005 14:09:33 -0800 X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Subject: [Ietf-caldav] icalendar vs. CRLF vs. XML X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2005 22:15:34 -0000 --Apple-Mail-3-795635071 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I'm noticing what looks like an inherent problem with the calendar- data element. One of the uses of calendar-data is to inline icalendar data. The problem is that icalendar requires that lines be terminated with \r\n (CRLF), but XML parsers seem to be allowed to normalize newlines. For example (python): >>> data = '\nHELLO\r\nWORLD' >>> doc = xml.dom.minidom.parseString(data) >>> doc.toxml() u'\nHELLO\nWORLD' Notice that the \r in the input XML was removed in the output. Depending on how I construct the XML document, the \r can be lost while parsing the document into a DOM or which emitting a DOM as XML. My concern here is that if XML parsers/generators are allowed to monkey with EOL strings, the icalendar data will get munged. I can probably fiddle with my XML code until I plug all of the paths in which this is happening, but it doesn't seem easy, which means that CalDAV implementors are likely to screw it up at least some of the time, since most people don't want to write there own XML parsers and generators, that being the whole point of XML. I don't think we can get away with allowing XML that normalizes \r \n to \n... the problem there is that it's no longer valid icalendar data and while it's generally easy enough to replace \n with \r\n, that solution will be bug-ridden: 1- You don't want to replace \n with \r\n if it's already using \r \n, so you have to to detect it. 2- It's possible (and in fact doesn't look unlikely) for an icalendar component to contain \n in its data (eg. LOCATION is "100 S. Van Ness\nSan Francisco, CA\nU.S.A."), so you'd have to figure out how not to replace those. ...so it might be necessary to encode the icalendar data in the XML, but the spec would have to specify that. -wsv --Apple-Mail-3-795635071 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIzDCCAz8w ggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0 ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxA dGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7d yfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDow OKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgw DQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A 9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYI Tq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggWFMIIE7qADAgECAgMNZZAwDQYJKoZI hvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkp IEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0 MTExMDAyMjkyN1oXDTA1MTExMDAyMjkyN1owggH/MRUwEwYDVQQEEwxTYW5jaGV6IFZlZ2ExETAP BgNVBCoTCFdpbGZyZWRvMR4wHAYDVQQDExVXaWxmcmVkbyBTYW5jaGV6IFZlZ2ExJDAiBgkqhkiG 9w0BCQEWFXdzYW5jaGV6QHdzYW5jaGV6Lm5ldDEhMB8GCSqGSIb3DQEJARYSd3NhbmNoZXpAYXBw bGUuY29tMSIwIAYJKoZIhvcNAQkBFhN3c2FuY2hlekBhcGFjaGUub3JnMR8wHQYJKoZIhvcNAQkB FhB3c2FuY2hlekBtaXQuZWR1MSQwIgYJKoZIhvcNAQkBFhV3c2FuY2hlekBhbHVtLm1pdC5lZHUx IzAhBgkqhkiG9w0BCQEWFHdzYW5jaGV6QGZyZWVic2Qub3JnMSIwIAYJKoZIhvcNAQkBFhN3c2Fu Y2hlekBuZXRic2Qub3JnMR0wGwYJKoZIhvcNAQkBFg50cml0YW5AbWl0LmVkdTEsMCoGCSqGSIb3 DQEJARYdd3NhbmNoZXpAcHJldHR5Z29vZHBsYW5lcy5jb20xJzAlBgkqhkiG9w0BCQEWGHdzYW5j aGV6QGZyZWVtZXRob2RzLm9yZzEfMB0GCSqGSIb3DQEJARYQdG9vbEByYW5nZXJzLm9yZzEfMB0G CSqGSIb3DQEJARYQd3NhbmNoZXpAbWFjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAMdR8Xdk0klE2zVpa5NJPNI1rz1kTWtpPqCz0/h9oI5cdpw8OiJpfD/7npvxTKQk564YwikW wIZ9zkE1Nu9twStukxQb6D8QdAKk+4SVgkDZm62rHBJBoLoBpW9O5qTkHtvuWMVCRuCZW4lAJYdp vZ9FkGrLssn+rBV99LYZPc2D7Y0y4XoAoqvGu1rjkRNXftm49PXXHth/wlgzSiaC7f27M8s7IhuC fcvp04iMok3id03+blIKwmcH7Nb1L7X3wok+5JMhTa1txGds1m9AqN9nb3zav30GEO0LXU2Y7PMV 8De6TYU3cJD95BfATGEx7JhxrPXwKBCbiJDc5dsMPhcCAwEAAaOCASQwggEgMIIBDgYDVR0RBIIB BTCCAQGBFXdzYW5jaGV6QHdzYW5jaGV6Lm5ldIESd3NhbmNoZXpAYXBwbGUuY29tgRN3c2FuY2hl ekBhcGFjaGUub3JngRB3c2FuY2hlekBtaXQuZWR1gRV3c2FuY2hlekBhbHVtLm1pdC5lZHWBFHdz YW5jaGV6QGZyZWVic2Qub3JngRN3c2FuY2hlekBuZXRic2Qub3JngQ50cml0YW5AbWl0LmVkdYEd d3NhbmNoZXpAcHJldHR5Z29vZHBsYW5lcy5jb22BGHdzYW5jaGV6QGZyZWVtZXRob2RzLm9yZ4EQ dG9vbEByYW5nZXJzLm9yZ4EQd3NhbmNoZXpAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBAGtqmsTpUyTIYFCMtTwEM0wg/l0Ul/EOTzfSx9CUni9i32m2DF8h5801L+64LOl8 XawvtrVmE7HCFF3d33/lNd9nmLrGAdEvG7yr++FJ1059puTTgqUChZBL+xkHZp8Yu9d5yPtGxeHZ E3Ke+6t+UuSS9OV8pt2VmzjKwTGjJtJLMYIC5zCCAuMCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw1lkDAJBgUrDgMCGgUAoIIBUzAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTExMDkyMjA5MzRaMCMGCSqGSIb3DQEJBDEW BBT69vbf9ixViZQ/YChV+SoYmxwdGDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDWWQMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMj VGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw1lkDANBgkqhkiG9w0BAQEFAASC AQBCGHsisTOZe8Z6o8EbAIVrbd4oyIRQFsEn0Jbs7ETp8dbTX+uYvlk/cu0PldifNrCyIRHZmcZ+ 8p29WjyAPG+SoUoufpDz5WXwrGTFT1oO60e+vcUC4mWor0vMb1syeesnH/LUGVQ/GvxmmgcW5X7F EbD4QjwefDrdQWrBnjxSt2BFBMPyq90sXhMsqyAW002m3Wku1hwiXdJXwCCJUHDdKnVtVNiV7lOm 664VzVeze4ZvSADb9cnE/duB2oLQBr+bOEsuazwbuQZuKVxfPj1ALIpmO4q0JJ7QBWKunbH2orW0 G0+30PZXwEj36dVKmoDwLEEu6tBTDcDyCtl2AA3CAAAAAAAA --Apple-Mail-3-795635071-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 828927F52C for ; Wed, 9 Nov 2005 14:10:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3F3BB14229F for ; Wed, 9 Nov 2005 14:10:23 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07612-07 for ; Wed, 9 Nov 2005 14:10:22 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id DF5F614229C for ; Wed, 9 Nov 2005 14:10:22 -0800 (PST) Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id jA9MAK6G025272 for ; Wed, 9 Nov 2005 14:10:22 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay5.apple.com (Apple SCV relay) with ESMTP id 44D14324013 for ; Wed, 9 Nov 2005 14:10:20 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) To: ietf-caldav@osafoundation.org Message-Id: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3-795635071; protocol="application/pkcs7-signature" From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Date: Wed, 9 Nov 2005 14:09:33 -0800 X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.5 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Subject: [Ietf-caldav] icalendar vs. CRLF vs. XML X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2005 22:10:23 -0000 --Apple-Mail-3-795635071 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I'm noticing what looks like an inherent problem with the calendar- data element. One of the uses of calendar-data is to inline icalendar data. The problem is that icalendar requires that lines be terminated with \r\n (CRLF), but XML parsers seem to be allowed to normalize newlines. For example (python): >>> data = '\nHELLO\r\nWORLD' >>> doc = xml.dom.minidom.parseString(data) >>> doc.toxml() u'\nHELLO\nWORLD' Notice that the \r in the input XML was removed in the output. Depending on how I construct the XML document, the \r can be lost while parsing the document into a DOM or which emitting a DOM as XML. My concern here is that if XML parsers/generators are allowed to monkey with EOL strings, the icalendar data will get munged. I can probably fiddle with my XML code until I plug all of the paths in which this is happening, but it doesn't seem easy, which means that CalDAV implementors are likely to screw it up at least some of the time, since most people don't want to write there own XML parsers and generators, that being the whole point of XML. I don't think we can get away with allowing XML that normalizes \r \n to \n... the problem there is that it's no longer valid icalendar data and while it's generally easy enough to replace \n with \r\n, that solution will be bug-ridden: 1- You don't want to replace \n with \r\n if it's already using \r \n, so you have to to detect it. 2- It's possible (and in fact doesn't look unlikely) for an icalendar component to contain \n in its data (eg. LOCATION is "100 S. Van Ness\nSan Francisco, CA\nU.S.A."), so you'd have to figure out how not to replace those. ...so it might be necessary to encode the icalendar data in the XML, but the spec would have to specify that. -wsv --Apple-Mail-3-795635071 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIzDCCAz8w ggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0 ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxA dGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7d yfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDow OKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgw DQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A 9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYI Tq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggWFMIIE7qADAgECAgMNZZAwDQYJKoZI hvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkp IEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0 MTExMDAyMjkyN1oXDTA1MTExMDAyMjkyN1owggH/MRUwEwYDVQQEEwxTYW5jaGV6IFZlZ2ExETAP BgNVBCoTCFdpbGZyZWRvMR4wHAYDVQQDExVXaWxmcmVkbyBTYW5jaGV6IFZlZ2ExJDAiBgkqhkiG 9w0BCQEWFXdzYW5jaGV6QHdzYW5jaGV6Lm5ldDEhMB8GCSqGSIb3DQEJARYSd3NhbmNoZXpAYXBw bGUuY29tMSIwIAYJKoZIhvcNAQkBFhN3c2FuY2hlekBhcGFjaGUub3JnMR8wHQYJKoZIhvcNAQkB FhB3c2FuY2hlekBtaXQuZWR1MSQwIgYJKoZIhvcNAQkBFhV3c2FuY2hlekBhbHVtLm1pdC5lZHUx IzAhBgkqhkiG9w0BCQEWFHdzYW5jaGV6QGZyZWVic2Qub3JnMSIwIAYJKoZIhvcNAQkBFhN3c2Fu Y2hlekBuZXRic2Qub3JnMR0wGwYJKoZIhvcNAQkBFg50cml0YW5AbWl0LmVkdTEsMCoGCSqGSIb3 DQEJARYdd3NhbmNoZXpAcHJldHR5Z29vZHBsYW5lcy5jb20xJzAlBgkqhkiG9w0BCQEWGHdzYW5j aGV6QGZyZWVtZXRob2RzLm9yZzEfMB0GCSqGSIb3DQEJARYQdG9vbEByYW5nZXJzLm9yZzEfMB0G CSqGSIb3DQEJARYQd3NhbmNoZXpAbWFjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAMdR8Xdk0klE2zVpa5NJPNI1rz1kTWtpPqCz0/h9oI5cdpw8OiJpfD/7npvxTKQk564YwikW wIZ9zkE1Nu9twStukxQb6D8QdAKk+4SVgkDZm62rHBJBoLoBpW9O5qTkHtvuWMVCRuCZW4lAJYdp vZ9FkGrLssn+rBV99LYZPc2D7Y0y4XoAoqvGu1rjkRNXftm49PXXHth/wlgzSiaC7f27M8s7IhuC fcvp04iMok3id03+blIKwmcH7Nb1L7X3wok+5JMhTa1txGds1m9AqN9nb3zav30GEO0LXU2Y7PMV 8De6TYU3cJD95BfATGEx7JhxrPXwKBCbiJDc5dsMPhcCAwEAAaOCASQwggEgMIIBDgYDVR0RBIIB BTCCAQGBFXdzYW5jaGV6QHdzYW5jaGV6Lm5ldIESd3NhbmNoZXpAYXBwbGUuY29tgRN3c2FuY2hl ekBhcGFjaGUub3JngRB3c2FuY2hlekBtaXQuZWR1gRV3c2FuY2hlekBhbHVtLm1pdC5lZHWBFHdz YW5jaGV6QGZyZWVic2Qub3JngRN3c2FuY2hlekBuZXRic2Qub3JngQ50cml0YW5AbWl0LmVkdYEd d3NhbmNoZXpAcHJldHR5Z29vZHBsYW5lcy5jb22BGHdzYW5jaGV6QGZyZWVtZXRob2RzLm9yZ4EQ dG9vbEByYW5nZXJzLm9yZ4EQd3NhbmNoZXpAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBAGtqmsTpUyTIYFCMtTwEM0wg/l0Ul/EOTzfSx9CUni9i32m2DF8h5801L+64LOl8 XawvtrVmE7HCFF3d33/lNd9nmLrGAdEvG7yr++FJ1059puTTgqUChZBL+xkHZp8Yu9d5yPtGxeHZ E3Ke+6t+UuSS9OV8pt2VmzjKwTGjJtJLMYIC5zCCAuMCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw1lkDAJBgUrDgMCGgUAoIIBUzAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTExMDkyMjA5MzRaMCMGCSqGSIb3DQEJBDEW BBT69vbf9ixViZQ/YChV+SoYmxwdGDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDWWQMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMj VGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw1lkDANBgkqhkiG9w0BAQEFAASC AQBCGHsisTOZe8Z6o8EbAIVrbd4oyIRQFsEn0Jbs7ETp8dbTX+uYvlk/cu0PldifNrCyIRHZmcZ+ 8p29WjyAPG+SoUoufpDz5WXwrGTFT1oO60e+vcUC4mWor0vMb1syeesnH/LUGVQ/GvxmmgcW5X7F EbD4QjwefDrdQWrBnjxSt2BFBMPyq90sXhMsqyAW002m3Wku1hwiXdJXwCCJUHDdKnVtVNiV7lOm 664VzVeze4ZvSADb9cnE/duB2oLQBr+bOEsuazwbuQZuKVxfPj1ALIpmO4q0JJ7QBWKunbH2orW0 G0+30PZXwEj36dVKmoDwLEEu6tBTDcDyCtl2AA3CAAAAAAAA --Apple-Mail-3-795635071-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6E3457F523 for ; Wed, 9 Nov 2005 14:09:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5A8F91422A2 for ; Wed, 9 Nov 2005 14:09:37 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11198-07 for ; Wed, 9 Nov 2005 14:09:37 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id F3BD314229F for ; Wed, 9 Nov 2005 14:09:36 -0800 (PST) Received: from relay6.apple.com (a17-128-113-36.apple.com [17.128.113.36]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id jA9M9YU0008719 for ; Wed, 9 Nov 2005 14:09:36 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay6.apple.com (Apple SCV relay) with ESMTP id 73E0B172 for ; Wed, 9 Nov 2005 14:09:34 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) To: ietf-caldav@osafoundation.org Message-Id: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3-795635071; protocol="application/pkcs7-signature" From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Date: Wed, 9 Nov 2005 14:09:33 -0800 X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.5 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Subject: [Ietf-caldav] icalendar vs. CRLF vs. XML X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2005 22:09:37 -0000 --Apple-Mail-3-795635071 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I'm noticing what looks like an inherent problem with the calendar- data element. One of the uses of calendar-data is to inline icalendar data. The problem is that icalendar requires that lines be terminated with \r\n (CRLF), but XML parsers seem to be allowed to normalize newlines. For example (python): >>> data = '\nHELLO\r\nWORLD' >>> doc = xml.dom.minidom.parseString(data) >>> doc.toxml() u'\nHELLO\nWORLD' Notice that the \r in the input XML was removed in the output. Depending on how I construct the XML document, the \r can be lost while parsing the document into a DOM or which emitting a DOM as XML. My concern here is that if XML parsers/generators are allowed to monkey with EOL strings, the icalendar data will get munged. I can probably fiddle with my XML code until I plug all of the paths in which this is happening, but it doesn't seem easy, which means that CalDAV implementors are likely to screw it up at least some of the time, since most people don't want to write there own XML parsers and generators, that being the whole point of XML. I don't think we can get away with allowing XML that normalizes \r \n to \n... the problem there is that it's no longer valid icalendar data and while it's generally easy enough to replace \n with \r\n, that solution will be bug-ridden: 1- You don't want to replace \n with \r\n if it's already using \r \n, so you have to to detect it. 2- It's possible (and in fact doesn't look unlikely) for an icalendar component to contain \n in its data (eg. LOCATION is "100 S. Van Ness\nSan Francisco, CA\nU.S.A."), so you'd have to figure out how not to replace those. ...so it might be necessary to encode the icalendar data in the XML, but the spec would have to specify that. -wsv --Apple-Mail-3-795635071 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIzDCCAz8w ggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0 ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxA dGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7d yfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDow OKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgw DQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A 9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYI Tq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggWFMIIE7qADAgECAgMNZZAwDQYJKoZI hvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkp IEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0 MTExMDAyMjkyN1oXDTA1MTExMDAyMjkyN1owggH/MRUwEwYDVQQEEwxTYW5jaGV6IFZlZ2ExETAP BgNVBCoTCFdpbGZyZWRvMR4wHAYDVQQDExVXaWxmcmVkbyBTYW5jaGV6IFZlZ2ExJDAiBgkqhkiG 9w0BCQEWFXdzYW5jaGV6QHdzYW5jaGV6Lm5ldDEhMB8GCSqGSIb3DQEJARYSd3NhbmNoZXpAYXBw bGUuY29tMSIwIAYJKoZIhvcNAQkBFhN3c2FuY2hlekBhcGFjaGUub3JnMR8wHQYJKoZIhvcNAQkB FhB3c2FuY2hlekBtaXQuZWR1MSQwIgYJKoZIhvcNAQkBFhV3c2FuY2hlekBhbHVtLm1pdC5lZHUx IzAhBgkqhkiG9w0BCQEWFHdzYW5jaGV6QGZyZWVic2Qub3JnMSIwIAYJKoZIhvcNAQkBFhN3c2Fu Y2hlekBuZXRic2Qub3JnMR0wGwYJKoZIhvcNAQkBFg50cml0YW5AbWl0LmVkdTEsMCoGCSqGSIb3 DQEJARYdd3NhbmNoZXpAcHJldHR5Z29vZHBsYW5lcy5jb20xJzAlBgkqhkiG9w0BCQEWGHdzYW5j aGV6QGZyZWVtZXRob2RzLm9yZzEfMB0GCSqGSIb3DQEJARYQdG9vbEByYW5nZXJzLm9yZzEfMB0G CSqGSIb3DQEJARYQd3NhbmNoZXpAbWFjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAMdR8Xdk0klE2zVpa5NJPNI1rz1kTWtpPqCz0/h9oI5cdpw8OiJpfD/7npvxTKQk564YwikW wIZ9zkE1Nu9twStukxQb6D8QdAKk+4SVgkDZm62rHBJBoLoBpW9O5qTkHtvuWMVCRuCZW4lAJYdp vZ9FkGrLssn+rBV99LYZPc2D7Y0y4XoAoqvGu1rjkRNXftm49PXXHth/wlgzSiaC7f27M8s7IhuC fcvp04iMok3id03+blIKwmcH7Nb1L7X3wok+5JMhTa1txGds1m9AqN9nb3zav30GEO0LXU2Y7PMV 8De6TYU3cJD95BfATGEx7JhxrPXwKBCbiJDc5dsMPhcCAwEAAaOCASQwggEgMIIBDgYDVR0RBIIB BTCCAQGBFXdzYW5jaGV6QHdzYW5jaGV6Lm5ldIESd3NhbmNoZXpAYXBwbGUuY29tgRN3c2FuY2hl ekBhcGFjaGUub3JngRB3c2FuY2hlekBtaXQuZWR1gRV3c2FuY2hlekBhbHVtLm1pdC5lZHWBFHdz YW5jaGV6QGZyZWVic2Qub3JngRN3c2FuY2hlekBuZXRic2Qub3JngQ50cml0YW5AbWl0LmVkdYEd d3NhbmNoZXpAcHJldHR5Z29vZHBsYW5lcy5jb22BGHdzYW5jaGV6QGZyZWVtZXRob2RzLm9yZ4EQ dG9vbEByYW5nZXJzLm9yZ4EQd3NhbmNoZXpAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBAGtqmsTpUyTIYFCMtTwEM0wg/l0Ul/EOTzfSx9CUni9i32m2DF8h5801L+64LOl8 XawvtrVmE7HCFF3d33/lNd9nmLrGAdEvG7yr++FJ1059puTTgqUChZBL+xkHZp8Yu9d5yPtGxeHZ E3Ke+6t+UuSS9OV8pt2VmzjKwTGjJtJLMYIC5zCCAuMCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw1lkDAJBgUrDgMCGgUAoIIBUzAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTExMDkyMjA5MzRaMCMGCSqGSIb3DQEJBDEW BBT69vbf9ixViZQ/YChV+SoYmxwdGDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDWWQMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMj VGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw1lkDANBgkqhkiG9w0BAQEFAASC AQBCGHsisTOZe8Z6o8EbAIVrbd4oyIRQFsEn0Jbs7ETp8dbTX+uYvlk/cu0PldifNrCyIRHZmcZ+ 8p29WjyAPG+SoUoufpDz5WXwrGTFT1oO60e+vcUC4mWor0vMb1syeesnH/LUGVQ/GvxmmgcW5X7F EbD4QjwefDrdQWrBnjxSt2BFBMPyq90sXhMsqyAW002m3Wku1hwiXdJXwCCJUHDdKnVtVNiV7lOm 664VzVeze4ZvSADb9cnE/duB2oLQBr+bOEsuazwbuQZuKVxfPj1ALIpmO4q0JJ7QBWKunbH2orW0 G0+30PZXwEj36dVKmoDwLEEu6tBTDcDyCtl2AA3CAAAAAAAA --Apple-Mail-3-795635071-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 802457F545 for ; Fri, 4 Nov 2005 08:51:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6879314228A for ; Fri, 4 Nov 2005 08:51:47 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20534-10 for ; Fri, 4 Nov 2005 08:51:47 -0800 (PST) Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 038F6142289 for ; Fri, 4 Nov 2005 08:51:46 -0800 (PST) Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jA4H1mEP018479; Fri, 4 Nov 2005 11:01:48 -0600 Received: from localhost (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id jA4Gph44027540; Fri, 4 Nov 2005 09:51:44 -0700 Received: from [144.23.219.186] (bdesruis-ca.ca.oracle.com [144.23.219.186]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jA4GpZdb027502 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 4 Nov 2005 09:51:40 -0700 Message-ID: <436B918D.50206@oracle.com> Date: Fri, 04 Nov 2005 11:51:25 -0500 From: Bernard Desruisseaux User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] Confused about calendar query filters References: <4366C6ED.4070709@oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2005 16:51:47 -0000 Wilfredo, The original intent was that for a component, or a property or a parameter to match, one of the following condition would need to be true: is-defined, time-range, text-match. Clearly not all conditions apply to components, to all properties and all parameters. The "is-defined" XML elements was there for the sake of completeness more than anything else. The idea was that one of the above condition would be required in every filter. That being said, you are quite correct that the DTD snippet in draft is broken... You are not the first implementer to wonder about the existence of the "is-defined" XML element and I'm tempted to remove it now. The next draft will address this issue one way or the other. Thanks! Bernard Wilfredo Sánchez Vega wrote: > Ew, right. So my example with the missing if-defined would match all > resources? If so, I think this little bit of extra XML complicates > 8.3.1 significantly. > > 8.3.1 should add a qualifier that the filter doesn't match if the > component type doesn't match the name attribute. That's somewhat > obvious, but it should be stated explicitly in the spec. > > But that's not quite enough because of the element... it > doesn't match if the component type doesn't match the name attribute > *unless* the comp-filter is empty *or* all of its children (or, > recursively all of their children) are empty. Right? > > I wonder what the value of having this element around is, rather than > making the present of comp-filter simply imply that it should be defined. > > Or is the empty EVENT filter illegal? That would be simpler again, > but it's not stated as illegal in the spec. The DTD snippet in 8.3.1 > would need to be something more like: > > (is-defined | time-range | comp-filter | prop-filter) > comp-filter* prop-filter*> > > But I would still wonder why is-defined exists at all... > > -wsv > > > On Oct 31, 2005, at 5:37 PM, Bernard Desruisseaux wrote: > >>> So if I had this instead: >>> >>> >>> >>> >>> >>> I'd interpret it as "give me all data for any resource which >>> contains an event." and going t the extreme: >> >> >> Right, but you forgot the "is-defined" XML element. >> >> >> >> >> >> >> >> > > Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7BA5D7F546 for ; Wed, 2 Nov 2005 20:48:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6B9B11422CA for ; Wed, 2 Nov 2005 20:48:29 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28581-04 for ; Wed, 2 Nov 2005 20:48:29 -0800 (PST) Received: from fed1rmmtao02.cox.net (fed1rmmtao02.cox.net [68.230.241.37]) by laweleka.osafoundation.org (Postfix) with ESMTP id 22B431422A7 for ; Wed, 2 Nov 2005 20:48:29 -0800 (PST) Received: from [127.0.0.1] (really [70.191.49.25]) by fed1rmmtao02.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20051103044750.PEAY29216.fed1rmmtao02.cox.net@[127.0.0.1]>; Wed, 2 Nov 2005 23:47:50 -0500 Message-ID: <43699697.10202@dcta.com> Date: Wed, 02 Nov 2005 20:48:23 -0800 From: "David C. Thewlis" Organization: DCTA Inc. User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Brandis Subject: Re: [Ietf-caldav] CalDAV Testing References: <43696944.7090007@quantum-logic.net> In-Reply-To: <43696944.7090007@quantum-logic.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: X-Mailman-Approved-At: Fri, 04 Nov 2005 08:40:17 -0800 Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dthewlis@dcta.com List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2005 04:48:29 -0000 Robert, You guys REALLY should have gotten involved in Calconnect. We've been doing CalDAV interop testing since January with multiple servers and clients. Of course, it's not too late... :-) Dave Thewlis Robert Brandis wrote: > Hi, > > We will be developing a CalDAV server. Our plan is to take mod_dav and > extend it for CalDAV use. > > I was wondering if there are any clients that implement enough of > CalDAV to use for testing. Or, is there a test suite? > > Any help would be greatly appreciated. Thank you. > > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav > > Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2030F7F511 for ; Wed, 2 Nov 2005 17:35:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0D1A51422D0 for ; Wed, 2 Nov 2005 17:35:11 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14338-10 for ; Wed, 2 Nov 2005 17:35:10 -0800 (PST) Received: from mta9.srv.hcvlny.cv.net (mta9.srv.hcvlny.cv.net [167.206.4.204]) by laweleka.osafoundation.org (Postfix) with ESMTP id C78031422CC for ; Wed, 2 Nov 2005 17:35:10 -0800 (PST) Received: from carbone.cc (ool-44c27137.dyn.optonline.net [68.194.113.55]) by mta9.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-2.06 (built May 11 2005)) with ESMTP id <0IPC00B5PV2EVY19@mta9.srv.hcvlny.cv.net> for ietf-caldav@osafoundation.org; Wed, 02 Nov 2005 20:35:04 -0500 (EST) Received: from [127.0.0.1] (hurricane.carbone.cc [192.168.0.204]) by carbone.cc (8.11.3/8.11.3) with ESMTP id jA30JZ312319 for ; Wed, 02 Nov 2005 19:19:36 -0500 (EST) Date: Wed, 02 Nov 2005 20:35:00 -0500 From: Robert Brandis To: ietf-caldav@osafoundation.org Message-id: <43696944.7090007@quantum-logic.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-Antivirus: avast! (VPS 0544-4, 11/02/2005), Outbound message X-Antivirus-Status: Clean User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.3 tagged_above=-50.0 required=4.0 tests=FORGED_RCVD_HELO X-Spam-Level: Subject: [Ietf-caldav] CalDAV Testing X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2005 01:35:11 -0000 Hi, We will be developing a CalDAV server. Our plan is to take mod_dav and extend it for CalDAV use. I was wondering if there are any clients that implement enough of CalDAV to use for testing. Or, is there a test suite? Any help would be greatly appreciated. Thank you. Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A56D77F547 for ; Wed, 2 Nov 2005 09:14:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 974351422BC for ; Wed, 2 Nov 2005 09:14:39 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04579-02 for ; Wed, 2 Nov 2005 09:14:39 -0800 (PST) Received: from mta5.srv.hcvlny.cv.net (mta5.srv.hcvlny.cv.net [167.206.4.200]) by laweleka.osafoundation.org (Postfix) with ESMTP id 66ACE1422BA for ; Wed, 2 Nov 2005 09:14:39 -0800 (PST) Received: from carbone.cc (ool-44c27137.dyn.optonline.net [68.194.113.55]) by mta5.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-2.06 (built May 11 2005)) with ESMTP id <0IPC00MB07VK6XLK@mta5.srv.hcvlny.cv.net> for ietf-caldav@osafoundation.org; Wed, 02 Nov 2005 12:14:09 -0500 (EST) Received: from [127.0.0.1] (hurricane.carbone.cc [192.168.0.204]) by carbone.cc (8.11.3/8.11.3) with ESMTP id jA2Fwi320964 for ; Wed, 02 Nov 2005 10:58:45 -0500 (EST) Date: Wed, 02 Nov 2005 12:14:05 -0500 From: Robert Brandis To: ietf-caldav@osafoundation.org Message-id: <4368F3DD.2020303@quantum-logic.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-Antivirus: avast! (VPS 0544-4, 11/02/2005), Outbound message X-Antivirus-Status: Clean User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.8 tagged_above=-50.0 required=4.0 tests=FORGED_RCVD_HELO, FROM_ENDS_IN_NUMS X-Spam-Level: X-Mailman-Approved-At: Fri, 04 Nov 2005 08:40:17 -0800 Subject: [Ietf-caldav] Testing a CalDAV server. X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2005 17:14:39 -0000 Hi, We will be developing a CalDAV server. Our plan is to take mod_dav and extend it for CalDAV use. The idea is to produce a server that is much like the Cyrus IMAP server: scalable and reliable. I was wondering if there are any clients that implement enough of CalDAV to use for testing. Or, is there a test suite? Any help would be greatly appreacited. Thank you. Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B03067F52E for ; Tue, 1 Nov 2005 11:50:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9D0861422B5 for ; Tue, 1 Nov 2005 11:50:58 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24995-07 for ; Tue, 1 Nov 2005 11:50:58 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 4BE131422B4 for ; Tue, 1 Nov 2005 11:50:58 -0800 (PST) Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id jA1Jor5x014144; Tue, 1 Nov 2005 11:50:53 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay5.apple.com (Apple SCV relay) with ESMTP id 12E27324017; Tue, 1 Nov 2005 11:50:53 -0800 (PST) In-Reply-To: <4366C6ED.4070709@oracle.com> References: <4366C6ED.4070709@oracle.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1-96113837; protocol="application/pkcs7-signature" Message-Id: From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] Confused about calendar query filters Date: Tue, 1 Nov 2005 11:50:52 -0800 To: Bernard Desruisseaux X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.6 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2005 19:50:58 -0000 --Apple-Mail-1-96113837 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Ew, right. So my example with the missing if-defined would match all resources? If so, I think this little bit of extra XML complicates 8.3.1 significantly. 8.3.1 should add a qualifier that the filter doesn't match if the component type doesn't match the name attribute. That's somewhat obvious, but it should be stated explicitly in the spec. But that's not quite enough because of the element... it doesn't match if the component type doesn't match the name attribute *unless* the comp-filter is empty *or* all of its children (or, recursively all of their children) are empty. Right? I wonder what the value of having this element around is, rather than making the present of comp-filter simply imply that it should be defined. Or is the empty EVENT filter illegal? That would be simpler again, but it's not stated as illegal in the spec. The DTD snippet in 8.3.1 would need to be something more like: But I would still wonder why is-defined exists at all... -wsv On Oct 31, 2005, at 5:37 PM, Bernard Desruisseaux wrote: >> So if I had this instead: >> >> >> >> >> >> I'd interpret it as "give me all data for any resource which >> contains an event." and going t the extreme: > > Right, but you forgot the "is-defined" XML element. > > > > > > > > --Apple-Mail-1-96113837 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIzDCCAz8w ggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0 ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxA dGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7d yfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDow OKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgw DQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A 9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYI Tq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggWFMIIE7qADAgECAgMNZZAwDQYJKoZI hvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkp IEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0 MTExMDAyMjkyN1oXDTA1MTExMDAyMjkyN1owggH/MRUwEwYDVQQEEwxTYW5jaGV6IFZlZ2ExETAP BgNVBCoTCFdpbGZyZWRvMR4wHAYDVQQDExVXaWxmcmVkbyBTYW5jaGV6IFZlZ2ExJDAiBgkqhkiG 9w0BCQEWFXdzYW5jaGV6QHdzYW5jaGV6Lm5ldDEhMB8GCSqGSIb3DQEJARYSd3NhbmNoZXpAYXBw bGUuY29tMSIwIAYJKoZIhvcNAQkBFhN3c2FuY2hlekBhcGFjaGUub3JnMR8wHQYJKoZIhvcNAQkB FhB3c2FuY2hlekBtaXQuZWR1MSQwIgYJKoZIhvcNAQkBFhV3c2FuY2hlekBhbHVtLm1pdC5lZHUx IzAhBgkqhkiG9w0BCQEWFHdzYW5jaGV6QGZyZWVic2Qub3JnMSIwIAYJKoZIhvcNAQkBFhN3c2Fu Y2hlekBuZXRic2Qub3JnMR0wGwYJKoZIhvcNAQkBFg50cml0YW5AbWl0LmVkdTEsMCoGCSqGSIb3 DQEJARYdd3NhbmNoZXpAcHJldHR5Z29vZHBsYW5lcy5jb20xJzAlBgkqhkiG9w0BCQEWGHdzYW5j aGV6QGZyZWVtZXRob2RzLm9yZzEfMB0GCSqGSIb3DQEJARYQdG9vbEByYW5nZXJzLm9yZzEfMB0G CSqGSIb3DQEJARYQd3NhbmNoZXpAbWFjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAMdR8Xdk0klE2zVpa5NJPNI1rz1kTWtpPqCz0/h9oI5cdpw8OiJpfD/7npvxTKQk564YwikW wIZ9zkE1Nu9twStukxQb6D8QdAKk+4SVgkDZm62rHBJBoLoBpW9O5qTkHtvuWMVCRuCZW4lAJYdp vZ9FkGrLssn+rBV99LYZPc2D7Y0y4XoAoqvGu1rjkRNXftm49PXXHth/wlgzSiaC7f27M8s7IhuC fcvp04iMok3id03+blIKwmcH7Nb1L7X3wok+5JMhTa1txGds1m9AqN9nb3zav30GEO0LXU2Y7PMV 8De6TYU3cJD95BfATGEx7JhxrPXwKBCbiJDc5dsMPhcCAwEAAaOCASQwggEgMIIBDgYDVR0RBIIB BTCCAQGBFXdzYW5jaGV6QHdzYW5jaGV6Lm5ldIESd3NhbmNoZXpAYXBwbGUuY29tgRN3c2FuY2hl ekBhcGFjaGUub3JngRB3c2FuY2hlekBtaXQuZWR1gRV3c2FuY2hlekBhbHVtLm1pdC5lZHWBFHdz YW5jaGV6QGZyZWVic2Qub3JngRN3c2FuY2hlekBuZXRic2Qub3JngQ50cml0YW5AbWl0LmVkdYEd d3NhbmNoZXpAcHJldHR5Z29vZHBsYW5lcy5jb22BGHdzYW5jaGV6QGZyZWVtZXRob2RzLm9yZ4EQ dG9vbEByYW5nZXJzLm9yZ4EQd3NhbmNoZXpAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBAGtqmsTpUyTIYFCMtTwEM0wg/l0Ul/EOTzfSx9CUni9i32m2DF8h5801L+64LOl8 XawvtrVmE7HCFF3d33/lNd9nmLrGAdEvG7yr++FJ1059puTTgqUChZBL+xkHZp8Yu9d5yPtGxeHZ E3Ke+6t+UuSS9OV8pt2VmzjKwTGjJtJLMYIC5zCCAuMCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw1lkDAJBgUrDgMCGgUAoIIBUzAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTExMDExOTUwNTNaMCMGCSqGSIb3DQEJBDEW BBSiV/5GH8U0TWWiI6GB5rCzakzFNjB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDWWQMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMj VGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw1lkDANBgkqhkiG9w0BAQEFAASC AQB2QP2Qedgob6aOAJMFYQ/BTFwcsvtboJkSzA34DcOBETBiwy/AIUK3wchB/WaR+VhVbAyfoUf4 +2kX05UGS8tF+O6xxy+QTUwveeNS+yZ8FXWRElOi/43nPKOVGaNM+rZA2yUb9ZqTGVmWFnC/s2Wi Qpl5Ce6fxNWQgjFuSm02Y8wzrPuuG0lVdpVxP2PYasdwj7ydpV2mKk/H4tS1gyU6esVXYQiqosOD ZHgauqK5FNSPWd39Oryc7Y2Kjzkm+907NSZ78UZ5PyS6LA+qoIIVcaz1GA/P+KC0hEgnDOjk+1Bm vj1FfvD+srhSLbr9+Xt4TBo/WcBXAKTQ7qcs7wErAAAAAAAA --Apple-Mail-1-96113837--