Subject: [Ietf-caldav] [Fwd: Re: PUT vs strong ETags]
From: Bernard Desruisseaux <[email-masked]>
To: [email-masked]
Date: Tue, 29 Nov 2005 20:56:53 -0500
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>

-------- Original Message --------
Subject: Re: PUT vs strong ETags
Resent-Date: Tue, 29 Nov 2005 21:26:37 +0000
Resent-From: [email-masked]
Date: Tue, 29 Nov 2005 22:19:41 +0100
From: Julian Reschke <[email-masked]>
To: Scott Lawrence <[email-masked]>
CC: HTTP Working Group <[email-masked]>
References: <[email-masked]> 
<[email-masked]>

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

To: CalDAV DevList <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Date: Wed, 23 Nov 2005 12:29:56 -0800
Subject: [Ietf-caldav] Fwd: Question on bug 15

--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

    <error><uid-is-unique/></error>

With the way we have it now, the error explains the error, rather than 
the success condition, so the draft currently would require

   <error><uid-already-exists/></error>

So if you care about how this looks, speak up on the WebDAV list.

Lisa

Begin forwarded message:

> Resent-From: [email-masked]
> From: Cullen Jennings <[email-masked]>
> Date: November 23, 2005 10:05:12 AM PST
> To: WebDav <[email-masked]>
> 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

   <<error><<uid-is-unique/><</error>

With the way we have it now, the error explains the error, rather than
the success condition, so the draft currently would require

  <<error><<uid-already-exists/><</error>

So if you care about how this looks, speak up on the WebDAV list.

Lisa

Begin forwarded message:

<excerpt><bold><color><param>0000,0000,0000</param>Resent-From:
</color></bold>[email-masked]

<bold><color><param>0000,0000,0000</param>From: </color></bold>Cullen
Jennings <<[email-masked]>

<bold><color><param>0000,0000,0000</param>Date:
</color></bold>November 23, 2005 10:05:12 AM PST

<bold><color><param>0000,0000,0000</param>To: </color></bold>WebDav
<<[email-masked]>

<bold><color><param>0000,0000,0000</param>Subject: </color>Question on
bug 15

</bold>

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.

</excerpt>
--Apple-Mail-1--148225853--

Date: Mon, 21 Nov 2005 11:26:11 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Kai Pan <[email-masked]>
Subject: Re: [Ietf-caldav] Some questions with respect to the CalDAV	specification draft 6
Cc: [email-masked]

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
>      <C:calendar-data>
>        <C:comp name="VCALENDAR">
>          <C:allprop/>
>          <C:comp name="VEVENT">
>            <C:prop name="X-ABC-GUID"/>
>            <C:prop name="UID"/>
>            ......
>     
>      As shown above, the <C:allprop/> element comes before the <C:comp 
> 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:
>   <!ELEMENT comp ((allcomp, (allprop | prop*)) |
>                     (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,

  <!ELEMENT comp (((allprop | prop*), allcomp) |
                  ((allprop | prop*), comp*))>

> 2. In Section 10.1, Page 44, the calendar-query element is defined as below:
>    <!ELEMENT calendar-query (DAV:allprop | DAV:propname | DAV:prop)?
>                             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:

<!ELEMENT calendar-query ((DAV:allprop | DAV:propname | DAV:prop)?,
                          filter, timezone?)>

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
>    <!ELEMENT calendar-data ((comp?, expand-recurrence-set?) |
>                  #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:

<!ELEMENT calendar-data ((comp?, (expand-recurrence-set |
                                  limit-recurrence-set  |
                                  limit-freebusy-set)?) |
                          #PCDATA)?>

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 -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Mon, 21 Nov 2005 11:07:07 -0500
From: Bernard Desruisseaux <[email-masked]>
To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>
Subject: Re: [Ietf-caldav] Confused about calendar query filters
Cc: [email-masked]

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 <is-defined> 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:
>>
>>   <!ELEMENT comp-filter
>>       (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:
>>>>     <filter>
>>>>       <comp-filter name="VCALENDAR">
>>>>         <comp-filter name="VEVENT"/>
>>>>       </comp-filter>
>>>>     </filter>
>>>>   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.
>>>
>>>      <filter>
>>>        <comp-filter name="VCALENDAR">
>>>          <comp-filter name="VEVENT">
>>>            <is-defined/>
>>>          </comp-filter>
>>>        </comp-filter>
>>>      </filter>
>>
>>
>>
> 
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Mon, 21 Nov 2005 10:18:48 -0500
From: Bernard Desruisseaux <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML

+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 -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Tue, 15 Nov 2005 21:07:16 -0500
To: [email-masked]
From: Tim Hare <[email-masked]>
Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML

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 -- [email-masked]
>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

From: Helge Hess <[email-masked]>
Date: Tue, 15 Nov 2005 23:45:28 +0100
To: CalDAV DevList <[email-masked]>
Cc: [email-masked], =?ISO-8859-1?Q?=C1lvaro_del_Castillo?= <[email-masked]>, Cornelius Schumacher <[email-masked]>, Till Adam <[email-masked]>
Subject: [Ietf-caldav] FOSDEM 2006

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

Date: Tue, 15 Nov 2005 12:36:10 -0800
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-caldav list <[email-masked]>
Subject: [Ietf-caldav] Registration open for Calconnect Roundtable and Interop Testing Event,  January 2006 - The Calendaring and Scheduling Consortium
Reply-To: [email-masked]

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" <[email-masked]>, "ietf-caldav 
reflector" <[email-masked]>, "IETF CALSCH" 
<[email-masked]>, "ietf-calsify reflector" 
<[email-masked]>, "www-rdf-calendar reflector" 
<[email-masked]>

* Copy:*

	

	 "Robert Tolmach - WellGood Group" <[email-masked]>, "Brian 
Dear" <[email-masked]>, "John Carbone" <[email-masked]>, 
[email-masked], [email-masked]

* 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 
<[email-masked]> 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 
<[email-masked]> 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 [email-masked] 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: <[email-masked]>
References: <[email-masked]>
X-Mailer: Calypso Version 3.30.00.00 (4)
Date: Thu, 02 Dec 2004 07:48:00 -0800
Reply-To: [email-masked]
From: "David C. Thewlis" <[email-masked]>
To: "calconnect-l reflector" <[email-masked]>, "ietf-caldav 
reflector" <[email-masked]>, "IETF CALSCH" 
<[email-masked]>, "ietf-calsify reflector" 
<[email-masked]>, "www-rdf-calendar reflector" 
<[email-masked]>
Cc: "Robert Tolmach - WellGood Group" <[email-masked]>, 
"Brian Dear" <[email-masked]>, "John Carbone" 
<[email-masked]>, [email-masked], [email-masked]
Subject: Call for Participantion -- Second Calconnect Interop - 11-12 
January 2005 - Seattle, Washington
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====_11020024806334=_"
Sender: [email-masked]
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 <[email-masked]> 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. 
<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. 
<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. 
<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. 
<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 · [email-masked] 
<mailto:[email-masked]>

--------------060907090401000004070303
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<!-- Inserted by Calypso -->
<table id="_CalyPrintHeader_" style="display: none; color: black;"
 border="0" cellpadding="0" cellspacing="2" rules="none" width="100%">
  <tbody>
    <tr>
      <td colspan="3">
      <hr color="black" noshade="noshade" size="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr align="left" valign="top">
      <td nowrap="nowrap" width="1"><b>&nbsp;Date:</b><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td width="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td>&nbsp;12/2/2004 07:52<br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr align="left" valign="top">
      <td nowrap="nowrap" width="1"><b>&nbsp;From:</b><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td width="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td>&nbsp;David C. Thewlis<br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr align="left" valign="top">
      <td nowrap="nowrap" width="1"><b>&nbsp;To:</b><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td width="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td>&nbsp;"calconnect-l reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"ietf-caldav reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"IETF CALSCH" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"ietf-calsify reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"www-rdf-calendar reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr align="left" valign="top">
      <td nowrap="nowrap" width="1"><b>&nbsp;Copy:</b><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td width="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td>&nbsp;"Robert Tolmach - WellGood Group" <a
 class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"Brian Dear" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"John Carbone" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
      <a class="moz-txt-link-abbreviated"
 href="mailto:[email-masked]">[email-masked]</a>, <a
 class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr align="left" valign="top">
      <td nowrap="nowrap" width="1"><b>&nbsp;Subject:</b><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td width="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td>&nbsp;Call for Participantion -- Second Calconnect Interop - 11-12
January 2005 - Seattle, Washington<br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr>
      <td colspan="3">
      <hr color="black" noshade="noshade" size="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
  </tbody>
</table>
<!-- End Calypso --><!-- Inserted by Calypso -->
<table id="_CalyMsgHeader_" style="display: none; color: rgb(0, 0, 0);"
 bgcolor="#c0c0c0" border="1" cellpadding="2" cellspacing="2"
 rules="none" width="100%">
  <tbody>
    <tr bgcolor="#c0c0c0">
      <td><font color="#000000" face="VERDANA,ARIAL,HELVETICA" size="-2">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 <a
 class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
Thu, 2 Dec 2004 07:52:03 -0800 (PST)<br>
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<br>
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 <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
Thu, 2 Dec 2004
10:47:57 -0500<br>
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<br>
X-Authentication-Warning: aix2.egenconsulting.com: majordom set sender
to <a class="moz-txt-link-abbreviated"
 href="mailto:[email-masked]">[email-masked]</a>
using -f<br>
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<br>
Received: from davet23 ([24.254.88.112]) by fed1rmmtao04.cox.net
(InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id
&lt;20041202154833.YTO5357.fed1rmmtao04.cox.net@davet23&gt; Thu, 2 Dec
2004 10:48:33 -0500<br>
Message-ID: <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
References: <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
X-Mailer: Calypso Version 3.30.00.00 (4)<br>
Date: Thu, 02 Dec 2004 07:48:00 -0800<br>
Reply-To: <a class="moz-txt-link-abbreviated"
 href="mailto:[email-masked]">[email-masked]</a><br>
From: "David C. Thewlis" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
To: "calconnect-l reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"ietf-caldav reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"IETF
CALSCH" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"ietf-calsify reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"www-rdf-calendar reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
Cc: "Robert Tolmach - WellGood Group" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"Brian Dear" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"John Carbone" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
      <a class="moz-txt-link-abbreviated"
 href="mailto:[email-masked]">[email-masked]</a>, <a
 class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a><br>
Subject: Call for Participantion -- Second Calconnect Interop - 11-12
January 2005 - Seattle, Washington<br>
Mime-Version: 1.0<br>
Content-Type: multipart/alternative; boundary="=====_11020024806334=_"<br>
Sender: <a class="moz-txt-link-abbreviated"
 href="mailto:[email-masked]">[email-masked]</a><br>
Precedence: bulk<br>
X-pstn-levels: (S:99.90000/99.90000 R:95.9108 P:95.9108 M:94.8624
C:98.9754 )<br>
X-pstn-settings: 5 (2.0000:2.0000) s gt3 gt2 gt1 r p m c <br>
X-pstn-addresses: from <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
forward
(user good) [2395/93] <br>
      </font><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
  </tbody>
</table>
<!-- End Calypso -->
<div><em>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.&nbsp; Our apologies if you
receive multiple copies.<br>
<br>
</em></div>
<div><em></em><strong>CALCONNECT INTEROP TESTING EVENT -&nbsp;
09-10 January 2006</strong><br>
<br>
<strong>CALCONNECT ROUNDTABLE V - 10-12 January 2006</strong><br>
</div>
<div>&nbsp;<strong><br>
</strong></div>
<div>&nbsp;<br>
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.<br>
<br>
<u>Registration is now open for these events as of 15 November 2005.</u><br>
</div>
<br>
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.&nbsp; <br>
<br>
The <b>Interop</b> will take place 09-10 January, all day the 9th and
until lunch on the 10th.&nbsp; It will offer
multiple Interop Testing Scenarios including <br>
<ul>
  <li>extensive CalDAV testing, <br>
  </li>
  <li>RFC (iCalendar, iMIP, iTIP) interoperability and RFC conformance
testing</li>
  <li>CALSIFY minimum interoperability testing.&nbsp; <br>
  </li>
</ul>
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.&nbsp; <br>
<br>
Interop participation is <u>open to all</u> interested organizations
that wish to test calendaring and scheduling implementations, and <u>is
not limited to members of the Consortium </u>(although members receive
a significant discount on the Interop participation fee). <br>
<br>
More information about the Interop is available at <a
 href="http://www.calconnect.org/iopjan2006.html">http://www.calconnect.org/iopjan2006.html.</a><br>
<br>
The <b>Roundtable</b> 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).&nbsp; It will feature Technical
Committee meetings, ad hoc meetings, and a full Plenary of the
Consortium.&nbsp; You must represent a member of CalConnect to attend the
Roundtable <u>unless</u> your organization chooses to participate as
an Observer (a non-member who wishes to attend a Roundtable to evaluate
participation in the Consortium).<br>
<br>
More information about the Roundtable is available at <a
 href="http://www.calconnect.org/roundtable5.html">http://www.calconnect.org/roundtable5.html.</a><br>
<br>
<div><strong><br>
REGISTRATION FEES<br>
<br>
</strong><b>Interop:</b> $1500 for Consortium
members and $2500 for non-members.&nbsp; The registration fee covers two
individuals; additional individuals are $150 each for members or
non-members.&nbsp; (If you are planning to participate in more than one
Interop scenario, you may need
additional people.)&nbsp; <strong></strong><br>
&nbsp;<br>
<b>Roundtable:</b>&nbsp; $275 per individual until 01 January and $325
thereafter.&nbsp; 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). &nbsp; <i><br>
<br>
A combined registration fee for both the Interop and Roundtable is
available; please see <a href="http://www.calconnect.org/iopfees.html">http://www.calconnect.org/iopfees.html.</a><br>
</i>&nbsp;</div>
<div><b><br>
</b></div>
<div>&nbsp;<br>
</div>
<div><b>ADDITIONAL DETAILS AND REGISTRATION INFORMATION</b><br>
<br>
Information on the Roundtable, including logistics, current
schedule and agenda planning, and registration information is available
on the Consortium website at <a
 href="http://www.calconnect.org/roundtable5.html">http://www.calconnect.org/roundtable5.html</a>.&nbsp;
More information on the Interop including logistics, planning, and
registration information is available on the Consortium website at <a
 href="http://www.calconnect.org/iopjan2006.html">http://www.calconnect.org/iopjan2006.html.</a><br>
<br>
You may also go to Consortium site at <a
 href="http://www.calconnect.org">http://www.calconnect.org</a>
and select "Coming Events" from the sidebar to find logistics,
planning and registration information for both the Roundtable and the
Interop.<br>
</div>
<br>
For questions and additional information please contact the
Consortium's Executive Director, Dave Thewlis, via the contact
information listed below. <br>
<div><br>
Space will be limited, so register as soon as possible. <br>
<br>
</div>
<div>Best Regards,</div>
<br>
Dave Thewlis<br>
<br>
<div class="moz-signature">-- <br>
<b>Dave Thewlis, Executive Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile) &middot; +1 415 946 3454
(fax)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a>
&middot; <a href="mailto:[email-masked]">[email-masked]</a><br>
<br>
</div>
</body>
</html>

--------------060907090401000004070303--

Date: Tue, 15 Nov 2005 20:20:39 +0100
From: Julian Reschke <[email-masked]>
To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>
Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML
Cc: [email-masked]

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

From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>
Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML
Date: Tue, 15 Nov 2005 10:09:49 -0800
To: Lisa Dusseault <[email-masked]>
Cc: [email-masked]

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 (&#13;) 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

Date: Tue, 15 Nov 2005 10:15:10 +0100
From: Julian Reschke <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML
Cc: [email-masked]

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

Date: Mon, 14 Nov 2005 20:43:13 -0700
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML
Reply-To: [email-masked]

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

--------------ms090201030806080809070109--

From: Lisa Dusseault <[email-masked]>
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?= <[email-masked]>
Cc: [email-masked]

On Nov 14, 2005, at 11:38 AM, Wilfredo S=E1nchez Vega wrote:

> On Nov 14, 2005, at 11:00 AM, Bernard Desruisseaux wrote:
>>
>> <C:calendar-data><![CDATA[BEGIN:VCALENDAR
>> VERSION:2.0
>> BEGIN:VEVENT
>> SUMMARY:Seminar on Java & <XML>
>> ...
>> END:VEVENT
>> END:VCALENDAR
>> ]]></C:calendar-data>
>>
>> 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

Date: Tue, 15 Nov 2005 00:22:14 +0100
From: Julian Reschke <[email-masked]>
To: Scott Carr <[email-masked]>
Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML
Cc: CalDAV DevList <[email-masked]>

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 
> "&lt;" and "&amp;". 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:

<foo><![CDATA[
]]></foo>

(where the line end was encoded as \r\n) with the following XSLT:

<xsl:transform xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                 version="1.0"
 >

<xsl:output method="html"/>

<xsl:template match="/">
	<xsl:value-of select="string-length(/foo)"/>
</xsl:template>

</xsl:transform>

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

Date: Mon, 14 Nov 2005 16:17:00 -0600
From: Scott Carr <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML

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 &#13;&#10;.
> 
> 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 
"&lt;" and "&amp;". 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

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML
Date: Mon, 14 Nov 2005 22:32:36 +0100
To: CalDAV DevList <[email-masked]>

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 &#13;&#10;.

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

From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>
Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML
Date: Mon, 14 Nov 2005 13:20:00 -0800
To: Bernard Desruisseaux <[email-masked]>
Cc: [email-masked]

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

From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>
Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML
Date: Mon, 14 Nov 2005 13:20:00 -0800
To: Bernard Desruisseaux <[email-masked]>
Cc: [email-masked]

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

Date: Mon, 14 Nov 2005 22:18:48 +0100
From: Julian Reschke <[email-masked]>
To: Scott Carr <[email-masked]>
Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML
Cc: CalDAV DevList <[email-masked]>

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 <![CDATA[ and ]]> 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 
<http://www.w3.org/TR/2004/REC-xml-20040204/#sec-line-ends>).

> ...

Best regards, Julian

Date: Mon, 14 Nov 2005 14:47:20 -0600
From: Scott Carr <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML

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 <![CDATA[ and ]]> 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 -- [email-masked]
> 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

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML
Date: Mon, 14 Nov 2005 21:31:28 +0100
To: CalDAV DevList <[email-masked]>

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

Date: Mon, 14 Nov 2005 14:19:41 -0600
From: Scott Carr <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML

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

Date: Mon, 14 Nov 2005 14:59:47 -0500
From: Bernard Desruisseaux <[email-masked]>
To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>
Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML
Cc: [email-masked]

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   
>>> '&#13;' 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.
>>
>>   <element>content</element>
>>
>> is not the same as
>>
>>   <element>
>>     content
>>   </element>
> 
> 
>   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:
>>
>> <C:calendar-data><![CDATA[BEGIN:VCALENDAR
>> VERSION:2.0
>> BEGIN:VEVENT
>> SUMMARY:Seminar on Java &amp; &lt;XML&gt;
>> ...
>> END:VEVENT
>> END:VCALENDAR
>> ]]></C:calendar-data>

Oops... the example above should have read:

<C:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
BEGIN:VEVENT
SUMMARY:Seminar on Java &amp; &lt;XML&gt;
...
END:VEVENT
END:VCALENDAR
</C:calendar-data>

That is with no CDATA...

>>
>>
>> <C:calendar-data><![CDATA[BEGIN:VCALENDAR
>> VERSION:2.0
>> BEGIN:VEVENT
>> SUMMARY:Seminar on Java & <XML>
>> ...
>> END:VEVENT
>> END:VCALENDAR
>> ]]></C:calendar-data>
>>
>> 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
> 

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML
Date: Mon, 14 Nov 2005 20:54:43 +0100
To: CalDAV DevList <[email-masked]>

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 "<greeting>" and "</=20
greeting>"
    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

From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>
Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML
Date: Mon, 14 Nov 2005 11:38:11 -0800
To: Bernard Desruisseaux <[email-masked]>
Cc: [email-masked]

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
>> '&#13;' 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.
>
>   <element>content</element>
>
> is not the same as
>
>   <element>
>     content
>   </element>

   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:
>
> <C:calendar-data><![CDATA[BEGIN:VCALENDAR
> VERSION:2.0
> BEGIN:VEVENT
> SUMMARY:Seminar on Java &amp; &lt;XML&gt;
> ...
> END:VEVENT
> END:VCALENDAR
> ]]></C:calendar-data>
>
>
> <C:calendar-data><![CDATA[BEGIN:VCALENDAR
> VERSION:2.0
> BEGIN:VEVENT
> SUMMARY:Seminar on Java & <XML>
> ...
> END:VEVENT
> END:VCALENDAR
> ]]></C:calendar-data>
>
> 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

Date: Mon, 14 Nov 2005 14:00:14 -0500
From: Bernard Desruisseaux <[email-masked]>
To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>
Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML
Cc: [email-masked]

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  '&#13;' 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.

   <element>content</element>

is not the same as

   <element>
     content
   </element>

That being said, I'll update the draft with examples that escapes
'<', '>' and '&' or uses CDATA sections.  For instance:

<C:calendar-data><![CDATA[BEGIN:VCALENDAR
VERSION:2.0
BEGIN:VEVENT
SUMMARY:Seminar on Java &amp; &lt;XML&gt;
...
END:VEVENT
END:VCALENDAR
]]></C:calendar-data>

<C:calendar-data><![CDATA[BEGIN:VCALENDAR
VERSION:2.0
BEGIN:VEVENT
SUMMARY:Seminar on Java & <XML>
...
END:VEVENT
END:VCALENDAR
]]></C:calendar-data>

I don't believe it is necessary to escape 0x0A and 0x0D.

Cheers,
Bernard

Date: Sun, 13 Nov 2005 18:17:36 +0000
From: Ben Laurie <[email-masked]>
To: RL 'Bob' Morgan <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, WebDav WG <[email-masked]>, Mike Shaver <[email-masked]>, Scott Lawrence <[email-masked]>, HTTP working group <[email-masked]>, Alexey Melnikov <[email-masked]>, Sam Hartman <[email-masked]>, CalDAV DevList <[email-masked]>
Subject: [Ietf-caldav] Re: HTTP authentication

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

Date: Sun, 13 Nov 2005 10:07:58 -0800 (PST)
From: "RL 'Bob' Morgan" <[email-masked]>
To: Ben Laurie <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, WebDav WG <[email-masked]>, Mike Shaver <[email-masked]>, Scott Lawrence <[email-masked]>, HTTP working group <[email-masked]>, Alexey Melnikov <[email-masked]>, Sam Hartman <[email-masked]>, CalDAV DevList <[email-masked]>
Subject: [Ietf-caldav] Re: HTTP authentication

> 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"

Date: Sun, 13 Nov 2005 16:26:28 +0000
From: Ben Laurie <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, WebDav WG <[email-masked]>, Mike Shaver <[email-masked]>, Scott Lawrence <[email-masked]>, HTTP working group <[email-masked]>, Alexey Melnikov <[email-masked]>, CalDAV DevList <[email-masked]>
Subject: [Ietf-caldav] Re: HTTP authentication

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

Date: Fri, 11 Nov 2005 12:58:55 -0700
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Tim Hare <[email-masked]>, [email-masked]
Subject: Re: Some comments Re: [Ietf-caldav] icalendar vs. CRLF vs. XML
Reply-To: [email-masked]

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

--------------ms050004060506040700020801--

Date: Fri, 11 Nov 2005 12:58:36 -0700
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Tim Hare <[email-masked]>, [email-masked]
Subject: Re: Some comments Re: [Ietf-caldav] icalendar vs. CRLF vs. XML
Reply-To: [email-masked]

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

--------------ms020708070609000406080106--

Date: Fri, 11 Nov 2005 13:45:33 -0500
To: [email-masked]
From: Tim Hare <[email-masked]>
Subject: Some comments Re: [Ietf-caldav] icalendar vs. CRLF vs. XML

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 -- [email-masked]
>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

From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>
Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML
Date: Thu, 10 Nov 2005 21:57:20 -0800
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked]

   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.

Date: Thu, 10 Nov 2005 20:05:49 -0500
From: Cyrus Daboo <[email-masked]>
To: =?UTF-8?Q?Wilfredo_S=C3=A1nchez_Vega?= <[email-masked]>, [email-masked]
Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML

Hi Wilfredo,

--On November 10, 2005 3:57:19 PM -0800 Wilfredo S=C3=A1nchez Vega=20
<[email-masked]> 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  '&#13;' 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

From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>
Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML
Date: Thu, 10 Nov 2005 15:57:19 -0800
To: [email-masked]

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  
'&#13;' in calendar-data elements so that when the receiver gets the  
data, it's not munged by their parser.

	-wsv

Date: Wed, 09 Nov 2005 15:24:37 -0700
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>, [email-masked]
Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML
Reply-To: [email-masked]

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

--------------ms070308090703010400080803--

Date: Wed, 09 Nov 2005 15:16:33 -0700
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>, [email-masked]
Subject: Re: [Ietf-caldav] icalendar vs. CRLF vs. XML
Reply-To: [email-masked]

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 '<?xml version=3D"1.0" ?>\n<foobar>HELLO\r\nWORLD</ fo=
obar>'
>     >>> doc =3D xml.dom.minidom.parseString(data)
>     >>> doc.toxml()
>     u'<?xml version=3D"1.0" ?>\n<foobar>HELLO\nWORLD</foobar>'
>=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 -- [email-masked]
> 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

--------------ms050202070805030900070304--

To: [email-masked]
From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>
Date: Wed, 9 Nov 2005 14:09:33 -0800
Subject: [Ietf-caldav] icalendar vs. CRLF vs. XML

--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 = '<?xml version="1.0" ?>\n<foobar>HELLO\r\nWORLD</ 
foobar>'
     >>> doc = xml.dom.minidom.parseString(data)
     >>> doc.toxml()
     u'<?xml version="1.0" ?>\n<foobar>HELLO\nWORLD</foobar>'

   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

--Apple-Mail-3-795635071--

To: [email-masked]
From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>
Date: Wed, 9 Nov 2005 14:09:33 -0800
Subject: [Ietf-caldav] icalendar vs. CRLF vs. XML

--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 = '<?xml version="1.0" ?>\n<foobar>HELLO\r\nWORLD</ 
foobar>'
     >>> doc = xml.dom.minidom.parseString(data)
     >>> doc.toxml()
     u'<?xml version="1.0" ?>\n<foobar>HELLO\nWORLD</foobar>'

   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

--Apple-Mail-3-795635071--

To: [email-masked]
From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>
Date: Wed, 9 Nov 2005 14:09:33 -0800
Subject: [Ietf-caldav] icalendar vs. CRLF vs. XML

--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 = '<?xml version="1.0" ?>\n<foobar>HELLO\r\nWORLD</ 
foobar>'
     >>> doc = xml.dom.minidom.parseString(data)
     >>> doc.toxml()
     u'<?xml version="1.0" ?>\n<foobar>HELLO\nWORLD</foobar>'

   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

--Apple-Mail-3-795635071--

Date: Fri, 04 Nov 2005 11:51:25 -0500
From: Bernard Desruisseaux <[email-masked]>
To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>
Subject: Re: [Ietf-caldav] Confused about calendar query filters
Cc: [email-masked]

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 <is-defined> 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:
> 
>   <!ELEMENT comp-filter
>       (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:
>>>     <filter>
>>>       <comp-filter name="VCALENDAR">
>>>         <comp-filter name="VEVENT"/>
>>>       </comp-filter>
>>>     </filter>
>>>   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.
>>
>>      <filter>
>>        <comp-filter name="VCALENDAR">
>>          <comp-filter name="VEVENT">
>>            <is-defined/>
>>          </comp-filter>
>>        </comp-filter>
>>      </filter>
> 
> 

Date: Wed, 02 Nov 2005 20:48:23 -0800
From: "David C. Thewlis" <[email-masked]>
Organization: DCTA Inc.
To: Robert Brandis <[email-masked]>
Subject: Re: [Ietf-caldav] CalDAV Testing
Cc: [email-masked]
Reply-To: [email-masked]

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 -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>
>

Date: Wed, 02 Nov 2005 20:35:00 -0500
From: Robert Brandis <[email-masked]>
To: [email-masked]
Subject: [Ietf-caldav] CalDAV Testing

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.

Date: Wed, 02 Nov 2005 12:14:05 -0500
From: Robert Brandis <[email-masked]>
To: [email-masked]
Subject: [Ietf-caldav] Testing a CalDAV server.

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.

From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>
Subject: Re: [Ietf-caldav] Confused about calendar query filters
Date: Tue, 1 Nov 2005 11:50:52 -0800
To: Bernard Desruisseaux <[email-masked]>
Cc: [email-masked]

--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 <is-defined> 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:

   <!ELEMENT comp-filter
       (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:
>>     <filter>
>>       <comp-filter name="VCALENDAR">
>>         <comp-filter name="VEVENT"/>
>>       </comp-filter>
>>     </filter>
>>   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.
>
>      <filter>
>        <comp-filter name="VCALENDAR">
>          <comp-filter name="VEVENT">
>            <is-defined/>
>          </comp-filter>
>        </comp-filter>
>      </filter>

--Apple-Mail-1-96113837
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

--Apple-Mail-1-96113837--