Dan Mosedale | 1 Feb 22:24 2005

Re: hyphens in element names problematic for XML language bindings

Helge Hess wrote:

> On 29. Jan 2005, at 00:38 Uhr, Dan Mosedale wrote:
>> In my mind, the issue is not a matter of optimization, but of 
>> readable code.
> But isn't that the same reason why dashes are used in the protocol? 
> XML is supposed to be human readable/writable for various reasons and 
> slashes help with that.

Fair enough.  However, I suspect we can come up with a list of elements 
names for the caldav context that are similarly readable to our current 
set, which is really what counts here, I think.

>>   My experience has been that less readable code tends to have more 
>> bugs.  As you point out, it's too late to fix existing cases of this 
>> in WebDAV itself, but by changing the new CalDAV-specific elements, 
>> we can at least avoid making the problem worse.  If we do this, then 
>> implementors end up having fewer code statements that need to use 
>> hard-to-read escape syntaxes.  This should lead, I suspect, to at 
>> least slightly less buggy code in the CalDAV implementations written 
>> in such environments, which is good for the community as a whole.
> It makes it easier for your specific implementation of the XML parser 
> which may or may not be a worthwhile reason (IMHO its not).
> Personally I would assume that your XML parser could be easily 
> enhanced to escape dashes with eg underlines prior calling back to the 
(Continue reading)

Doug Royer | 2 Feb 01:08 2005

Re: hyphens in element names problematic for XML anguage bindings

> I think you're misunderstanding the concept of a native-language 
> binding: the parsing for XML element names can't be separate from the 
> language parsing itself.  That is, XML element names are parsed as 
> member variable names in the context of normal code.  So in JS, for 
> example, this means that XML element names that are compatible with JS 
> property names can be addressed directly as a property on a JS object, 
> but names with (eg) a minus in them cannot.  This is likely to be true 
> of any native XML binding to almost any language: minus is an operator 
> (and therefore not part of a valid variable name) in most popular 
> languages today.

I can parse XML with C/C++/Java/PHP/Python/Perl and other languages
that also do not allow variable names to contain a dash.

In all cases you have to store your XML names you parse
in a collection that allows those names for exactly that

And every language that I have used has a SAX
or a SAX like API, you can get to all of those names and
their data.

Why is JS different? It sounds like you want to make
XML element name the JS variable names. And this debate
took place on the XML mailing lists years ago and most
considered it not a valid argument as it would restrict
XML element names to a worst case sub-set of a huge and
unknown number of programming languages. This debate
also took place on the CALSCH mailing list for parsing iCalendar
(Continue reading)

Dave Thewlis | 10 Feb 06:30 2005

Report on Calconnect Roundtable II; advance notice of Roundtable III - The Calendaring and Scheduling Consortium

This note is going to the ietf-caldav and ietf-calsify mailing lists, 
which means that many people will get it twice.  My apologies; there 
seem to be enough people on one or the other but not both to require 
separate sends.


The Calendaring and Scheduling Consortium, also known as CalConnect,
held its first formal  Roundtable event together with an Interop in
Seattle, Washington on 11-13 January, hosted by the University of

A report on Roundtable II  has been posted to the Calconnect website at
www.calconnect.org:  choose "Roundtable II" from the sidebar or go to

The public report on the Interop event has been posted on the website
under Past Interops, where you can also locate information and results
from previous Calconnect Interops.

The next Consortium Roundtable and Interop will be 1-3 June, 2005,
hosted by Duke University in Durham, North Carolina.

Please visit our website at www.calconnect.org for further information
about the Consortium including events, technical committees, and
Interops.  Please contact me with any questions or for information about
joining the Consoritum.

Best Regards,

(Continue reading)

Lisa Dusseault | 11 Feb 01:12 2005

CalDAV home page

I've put together a rough "home page" for CalDAV, pretty clearly based 
on the WebDAV resources page (I stole all the HTML, in fact)


Suggestions welcome

Bernard Desruisseaux | 11 Feb 06:08 2005


We've just submitted CalDAV draft -05 to the IETF.
It's already available at the following URL:


B.1  Changes in -05

    a.  Removed a lot of non-normative text.
    b.  Removed property promotion/demotion requirements.
    c.  Removed calendar-owner and cal-scale properties.
    d.  Removed 'ical' prefix/text from element names.
    e.  Relaxed WebDAV Class 2 (locking) requirement to a MAY.
    f.  Relaxed MKCALENDAR requirement to a SHOULD.
    g.  Moved the XML Namespace section in the Introduction.
    h.  Added CALDAV: prefix to CalDAV XML elements in the text.
    i.  Added CALDAV:calendar-multiget report.
    j.  Added CALDAV:free-busy-query report.
    k.  Added CALDAV:calendar-description property.
    l.  Changed CALDAV:calendar-query-result element name to
    m.  Added description and examples of handling timezones.
    n.  Added mandatory "start" and "end" attributes to the
        CALDAV:expand-recurrence-set element.
    o.  Added three CalDAV OPTIONS requests.
    p.  Grouped XML Element declarations in a separate section.

We are planning to submit draft-desruisseaux-caldav-sched-00.txt in
the coming weeks.

(Continue reading)

Bernard Desruisseaux | 11 Feb 06:17 2005

Re: Comments on draft-dusseault-caldav-04


Thanks for your comments!  The -05 draft addresses most of
the issues you have reported. See my comments below.

I'll keep track of the issues that are not yet addressed.


Julian Reschke wrote:

 > Hi,
 > below are my comments about the -04 draft (top-down read, focusing on
 > WebDAV/HTTP questions with little Calendaring specific checks):
 > Best regards, Julian
 > --
 > 04-C01 Section 1.1.1

 > A few terminology problems here:
(Continue reading)

Kervin L. Pierre | 15 Feb 01:17 2005

separate scheduling? - Re: Comments on draft-dusseault-caldav-04

Bernard Desruisseaux wrote:
> The scheduling part of CalDAV has been moved into a
> separate draft. Those issues will be addressed later.

Anyone care to comment on that decision a little?

I am not questioning it, but it seems like a very
big change.

What were the specific issues which led to this
decision?  Understanding those may help us better
understand the apparently revised goals and scope
of the new protocol.

Bernard Desruisseaux | 15 Feb 03:09 2005

Re: separate scheduling? - Re: Comments on draft-dusseault-caldav-04


There are no specific issues really.

Some people were concerned that the publication of CalDAV would be
delayed because the specification was trying to address both calendar
access and scheduling. Given that some people are currently only
interested in the "calendar-access" feature of CalDAV, and given
that Lisa, Cyrus and myself believe we are going to be done with
"calendar-access" soon, we have decided to split the document
and get a first CalDAV draft published.

Given that support for "calendar-schedule" was already optional,
I don't think this is a big change.

The authors are still committed to get the "calendar-schedule"
feature published. The goals and scope of CalDAV have not changed.
The authors have simply adopted a phased approach to get CalDAV
in the hands of end users as soon as possible.

I hope that address your concerns.


Kervin L. Pierre wrote:

> Bernard Desruisseaux wrote:
(Continue reading)

Julian Reschke | 15 Feb 13:00 2005

[Fwd: draft-reschke-http-addmember-00]


-------- Original Message --------
 > ...


recently different communities (caldav/groupdav, atompup (protocol
part)) have been discussing how to use HTTP to author new resources when
the URL namespace is completely server-controlled, thus PUT just doesn't
fit well.

A simple approach would be to define a new HTTP method which is *almost*
like PUT, except that the server chooses the URL to create (and returns
it in the Location header).

I've submitted a first draft as "draft-reschke-http-addmember-00". Note
that it also contains an appendix covering possible alternative approaches.

Feedback appreciated,


HTML version:
Latest edits will be at:


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
(Continue reading)

Julian Reschke | 15 Feb 13:10 2005

Re: Comments on draft-dusseault-caldav-04

Bernard Desruisseaux wrote:

> Julian,
> Thanks for your comments!  The -05 draft addresses most of
> the issues you have reported. See my comments below.
> I'll keep track of the issues that are not yet addressed.


In general, the new draft seems to be a big improvement. I currently do 
not have the time fot a in-depth review, but I noticed that you have 
started to use OPTIONS request bodies similar to RFC3253. However, that 
approach is sort-of deprecated (check out 
so you may want to consider moving to live properties instead.

Some more comments inline...

>  > The example given (resource created at a different URI) seems to violate
>  > HTTP semantics: if PUT doesn't actually create a resource at the
>  > Request-URI, a status code of 201 (actually any 2xx code) seems to be
>  > wrong.
> This issue is not addressed yet.

See draft-reschke-http-addmember-00 
for an alternate proposal...
(Continue reading)