Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections
From: "Brian Moseley" <[email-masked]>
To: "CalDAV DevList" <[email-masked]>
Date: Fri, 31 Mar 2006 16:29:32 -0800
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>

On 3/31/06, Wilfredo Sánchez Vega <[email-masked]> wrote:
> On Mar 30, 2006, at 11:33 AM, Brian Moseley wrote:
>
> > 1) point my client at the parent collection to publish updates
> > 2) tell his friends who use my client the url of the parent collection
> > 3) tell his friends who use vanilla caldav clients  the url of the
> > calendar subcollection
> > 4) tell his friends who use vanilla carddav clients the url of the
> > contact subcollection
>
>    Just like he'd tells since friends with a generic PDF viewer that
> happens to know how to do HTTP GET (Open URL...) to point them at the
> PDF document in this collection.  Yeah.  Or the client will have to
> know that if it gets a collection, to search for PDF documents in the
> collection and do something useful like offer up a list, etc.
>
>    What you don't do is insist that the PDF document must be able to
> store any resources in it that you want and whatnot.  Why pretend
> that the PDF and the collection that contain the PDF are the same thing?

sorry, i'm not even close to getting your point. but the section of my
original message that you quoted is specifically what i DON'T want to
have to do. i want to avoid a world like that at all costs. it's
pretty much what the existing limitations of caldav force on me,
though, if i stay rigidly compliant and still try to still include
mixed content within one logical "shared content bundle".

From: =?ISO-8859-1?Q?Wilfredo_Sánchez_Vega?= <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections
Date: Fri, 31 Mar 2006 15:53:56 -0800
To: Brian Moseley <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

On Mar 30, 2006, at 11:33 AM, Brian Moseley wrote:

> 1) point my client at the parent collection to publish updates
> 2) tell his friends who use my client the url of the parent collection
> 3) tell his friends who use vanilla caldav clients  the url of the
> calendar subcollection
> 4) tell his friends who use vanilla carddav clients the url of the
> contact subcollection

   Just like he'd tells since friends with a generic PDF viewer that  
happens to know how to do HTTP GET (Open URL...) to point them at the  
PDF document in this collection.  Yeah.  Or the client will have to  
know that if it gets a collection, to search for PDF documents in the  
collection and do something useful like offer up a list, etc.

   What you don't do is insist that the PDF document must be able to  
store any resources in it that you want and whatnot.  Why pretend  
that the PDF and the collection that contain the PDF are the same thing?

	-wsv

Date: Thu, 30 Mar 2006 12:18:19 -0800
From: "Brian Moseley" <[email-masked]>
Sender: [email-masked]
To: "CalDAV DevList" <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections

On 3/30/06, Cyrus Daboo <[email-masked]> wrote:

> Lets be clear about this: the main reason for this constraint is to allow
> support of legacy calendar systems with CalDAV. In order to promote
> adoption of CalDAV we want to see CalDAV 'adapters' for the existing large
> deployments of such calendaring systems, and crucially make it easy for
> CalDAV to sit on top of those. Often such systems ONLY allow calendar data
> to be stored, and there is no satisfactory way to store arbitrary data.

understood :)

> So the bottom line is there will always be some CalDAV servers that cannot
> support non-calendar data in calendar collections. The question then
> becomes whether we mandate this behaviour or make it optional so that other
> less constrained servers can store arbitrary data. And there in lies the
> problem of making a potentially important feature a 'MAY' - it means that
> clients cannot rely on it to be present and so have to have two or more
> code paths to achieve the same goals. I think history has shown with IMAP
> that when that occurs, the client authors nearly always choose to implement
> a single code path - the one that will work with all servers irrespective
> of constraints (i.e. in our case be able to work with CalDAV constraints as
> they stand now).

and that's fine for most clients. adding the MAY feature allows a
(probably small) subset of clients and servers to remain fully
interoperable with the rest of the clients and servers out there while
adding important new features that are also interoperable, albeit with
that same small subset.

> I think the examples you give are interesting cases, but they can be solved
> in a whole variety of different ways whilst still living with the current
> constraints on the data model.

but nothing satisfactory has been proposed yet. you could certainly
make the case that it's my job to use my brain to come up with a good
solution for my software, but if we don't all collaborate on a
standard solution that's acceptable to most or all of us, then either
my software is not going to be of the quality i want, or it's not
going to inteoperate with everyone else's.

> I think part of the problem here is trying to impose a user's
> 'visualization' of the data on the data store. Its my belief that there
> really ought to be a separate 'virtual visualization' layer between the end
> user and the data such that they can choose their own arbitrary groupings
> based on what makes sense for them. That way constraints on either side can
> be hidden.

how could such a visualization be implemented interoperably? do you
think there is an opportunity for an extension to caldav, perhaps,
instead of a MAY feature?

Date: Thu, 30 Mar 2006 15:09:05 -0500
From: Cyrus Daboo <[email-masked]>
To: Brian Moseley <[email-masked]>, CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections

Hi Brian,

--On March 30, 2006 11:33:08 AM -0800 Brian Moseley <[email-masked]> 
wrote:

> 2) caldav doesn't allow non-calendar resources in calendar collections.

Lets be clear about this: the main reason for this constraint is to allow 
support of legacy calendar systems with CalDAV. In order to promote 
adoption of CalDAV we want to see CalDAV 'adapters' for the existing large 
deployments of such calendaring systems, and crucially make it easy for 
CalDAV to sit on top of those. Often such systems ONLY allow calendar data 
to be stored, and there is no satisfactory way to store arbitrary data.

So the bottom line is there will always be some CalDAV servers that cannot 
support non-calendar data in calendar collections. The question then 
becomes whether we mandate this behaviour or make it optional so that other 
less constrained servers can store arbitrary data. And there in lies the 
problem of making a potentially important feature a 'MAY' - it means that 
clients cannot rely on it to be present and so have to have two or more 
code paths to achieve the same goals. I think history has shown with IMAP 
that when that occurs, the client authors nearly always choose to implement 
a single code path - the one that will work with all servers irrespective 
of constraints (i.e. in our case be able to work with CalDAV constraints as 
they stand now).

I think the examples you give are interesting cases, but they can be solved 
in a whole variety of different ways whilst still living with the current 
constraints on the data model.

I think part of the problem here is trying to impose a user's 
'visualization' of the data on the data store. Its my belief that there 
really ought to be a separate 'virtual visualization' layer between the end 
user and the data such that they can choose their own arbitrary groupings 
based on what makes sense for them. That way constraints on either side can 
be hidden.

-- 
Cyrus Daboo

Date: Thu, 30 Mar 2006 11:33:08 -0800
From: "Brian Moseley" <[email-masked]>
Sender: [email-masked]
To: "CalDAV DevList" <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections

On 3/30/06, Wilfredo Sánchez Vega <[email-masked]> wrote:

>    Right, but the downside here is that this seems like a funny
> little dance.  It's extra "magic" complexity that the server is
> taking care of, and I don't like the idea of building that into a
> spec.  Where I'm going is that neither option for hiding data seems
> palatable.

and as julian pointed out, it's not the expected behavior of a generic
webdav collection. yeah, none of the proposed solutions have been
great, but i'm hoping they stimulate further ideas - or at least cause
people to reconsider whether caldav clients should be expected to
recognize and discard non-calendar resources returned from PROPFINDs.

>    My point is that if you want a spiffy collection with mixed
> content, treat the calendar collection as one resource in that
> collection, rather than trying to force the calendar collection to be
> that collection itself.  Or put the mixed data in a subcollection.
> The "ew" objection is understandable, but not all that compelling.
>
>    Put simply, I don't see why you can't accomplish what I understand
> your goal to be without living in the bounds of the current spec.  I
> realize, though, that I probably don't understand what you are trying
> to do well enough.

let's imagine that my client can publish events, tasks, contacts,
email messages, and photos to my server. my client also allows other
people who are also using my client to subcribe to all of these things
as one big mess.

imagine further that my server allows people using any vanilla caldav
client to subscribe directly to the calendar subcollection, and those
using any vanilla carddav client to subscribe directly to the contact
subcollection.

my client could certainly make a parent collection containing a
subcollection for each distinct content type. but then the user would
have to remember to:

1) point my client at the parent collection to publish updates
2) tell his friends who use my client the url of the parent collection
3) tell his friends who use vanilla caldav clients  the url of the
calendar subcollection
4) tell his friends who use vanilla carddav clients the url of the
contact subcollection

that is not a very compelling interoperability story. the ideal
scenario is that the user can tell all of his friends a single url
without regard to what client they might be using. do you agree that
is a worthy interop goal?

i could theoretically put some magic into my server to examine
requests for the parent collection and determine whether they come
from 1) my client, 2) vanilla caldav client, or 3) vanilla carddav
client. this would let me serve content from one of the subcollections
in response to a request made for the parent collection and just might
suffice (except the protocols don't give us any mechanism for these
clients to distinguish what kind of content they want).

but there's also the problem that in my client, a particular content
item can be an event, a task, an email message, a content and a photo
all at the same time. i'd rather not have to store a copy of the item
in each of these four subcollections if i could store a single item in
the parent collection. if i could do that, then my server could
respond to a request with a view of that item appropriate to the
protocol used to request it:

1) webdav - the "uber item'
2) caldav - an icalendar object containing a vevent and a vtodo
3) carddav - a vcard (i assume that's the correct resource type)

the parent collection, then, would act as a caldav collection for
caldav clients, a carddav collection (if such a thing exists) for
carddav clients, and a regular webdav collection for webdav clilents.

there are only two things holding us back from this ideal content
negotiation situation in which users and clients only ever have to
know about one url and the server can store one resource but serve
multiple views of it.

1) clients don't have any way to ask for specific content types with
PROPFIND or otherwise indicate that they are anything other than a
generic webdav client interested in all resource types.

2) caldav doesn't allow non-calendar resources in calendar collections.

does this make sense? does anybody else other than me see any value in
shaping the webdav-based protocols so that they allow for (not assume,
simply allow for) this negotiated-content world to exist?

From: =?ISO-8859-1?Q?Wilfredo_Sánchez_Vega?= <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections
Date: Thu, 30 Mar 2006 10:58:42 -0800
To: Brian Moseley <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

On Mar 28, 2006, at 11:58 AM, Brian Moseley wrote:

>>    Having to add a custom header to not get unexpected data is
>> undesirable.  Not all clients will know of this custom header.
>> Better to have a custom header to show you the data, and have the
>> server default to hiding it.
>
> agree! that's what i proposed earlier in the thread. if a client used
> MKCALENDAR to create the collection, then consider "calendar" the
> primary resource type for that collection and return only resources of
> that type for PROPFINDS, unless the client explicitly asks for
> more/different types with the custom header.

   Right, but the downside here is that this seems like a funny  
little dance.  It's extra "magic" complexity that the server is  
taking care of, and I don't like the idea of building that into a  
spec.  Where I'm going is that neither option for hiding data seems  
palatable.

>>    I really don't see the practical problem that you face here.  If
>> you treat the calendar collection as a compound document, you can put
>> that collection in your logic collection along with whatever other
>> resources you like.
>
> not really getting your point here.

   My point is that if you want a spiffy collection with mixed  
content, treat the calendar collection as one resource in that  
collection, rather than trying to force the calendar collection to be  
that collection itself.  Or put the mixed data in a subcollection.   
The "ew" objection is understandable, but not all that compelling.

   Put simply, I don't see why you can't accomplish what I understand  
your goal to be without living in the bounds of the current spec.  I  
realize, though, that I probably don't understand what you are trying  
to do well enough.

	-wsv

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections
Date: Wed, 29 Mar 2006 00:14:33 +0200
To: CalDAV DevList <[email-masked]>

On 28. Mrz 2006, at 22:26 Uhr, Julian Reschke wrote:
> Just for the record: methinks that mixed content should be fine; so  
> CalDAV should allow that, and clients would need to deal with it  
> upon PROPFIND.

I tend to agree.

CalDAV is so complicated that it won't be fully supported by legacy  
servers which can't deal with the mixed content requirement anyway.  
In fact I think the far majority of fully compliant CalDAV servers  
will be done from scratch and most existing servers will just support  
a subset which is enough to connect the important clients.

Personally I do not see a major difference between supporting  
subcollections and supporting mixed content. The level of difficulty  
for legacy RDBMS servers should be roughly the same.

So I suggest that a statement is added that clients MUST be prepared  
to receive content which is not iCalendar. They can filter that using  
the content-type or just use REPORTs if they don't want to be bothered.

I think there is no explicit need for a MAY on the server side, just  
keep the WebDAV semantics (which allows the server to reject content  
if it doesn't want it / can't store it ...).

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

Date: Tue, 28 Mar 2006 12:33:57 -0800
From: "Brian Moseley" <[email-masked]>
Sender: [email-masked]
To: "CalDAV DevList" <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections

On 3/28/06, Julian Reschke <[email-masked]> wrote:

> Just for the record: methinks that mixed content should be fine; so
> CalDAV should allow that, and clients would need to deal with it upon
> PROPFIND.

i am sympathetic to those who argue that a simple calendar client
should not have to download and discard non-calendar resources.

i would just like to find a way for those "basic" caldav cilents to
distinguish themselves from "even more basic" webdav clients (which do
want all member resources) and "mixed content aware" clients that
should be able to ask for specifically what they want.

Date: Tue, 28 Mar 2006 22:26:36 +0200
From: Julian Reschke <[email-masked]>
To: Brian Moseley <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections
Cc: CalDAV DevList <[email-masked]>

Brian Moseley wrote:
> On 3/28/06, Julian Reschke <[email-masked]> wrote:
> 
>> That would break the PROPFIND semantics defined by RFC2518. If a
>> calendar collection is a WebDAV collection, it has to follow the
>> semantics defined by RFC2518.
> 
> logjam!
> 
> ok, well, i give up. if nobody has a better suggestion, then we will
> have to find a way to be as non-uncompliant as possible if we do
> decide to support mixed content. it certainly doesn't seem like we can
> be all things to all people.

Just for the record: methinks that mixed content should be fine; so 
CalDAV should allow that, and clients would need to deal with it upon 
PROPFIND.

Just my 2 cents,

Julian

Date: Tue, 28 Mar 2006 12:23:13 -0800
From: "Brian Moseley" <[email-masked]>
Sender: [email-masked]
To: "CalDAV DevList" <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections

On 3/28/06, Julian Reschke <[email-masked]> wrote:

> That would break the PROPFIND semantics defined by RFC2518. If a
> calendar collection is a WebDAV collection, it has to follow the
> semantics defined by RFC2518.

logjam!

ok, well, i give up. if nobody has a better suggestion, then we will
have to find a way to be as non-uncompliant as possible if we do
decide to support mixed content. it certainly doesn't seem like we can
be all things to all people.

Date: Tue, 28 Mar 2006 22:06:42 +0200
From: Julian Reschke <[email-masked]>
To: Brian Moseley <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections
Cc: CalDAV DevList <[email-masked]>

Brian Moseley wrote:
> On 3/28/06, Wilfredo Sánchez Vega <[email-masked]> wrote:
> 
>>    Since when do users universally avoid doing silly things?
> 
> yea but we are talking more about clients here. i can't imagine users
> will be getting into the gritty details of telling their clients to
> put event attachments into subcollections and so forth. i expect
> clients will hide all this behind "publish your calendar to location
> xyz".
> 
>>    Having to add a custom header to not get unexpected data is
>> undesirable.  Not all clients will know of this custom header.
>> Better to have a custom header to show you the data, and have the
>> server default to hiding it.
> 
> agree! that's what i proposed earlier in the thread. if a client used
> MKCALENDAR to create the collection, then consider "calendar" the
> primary resource type for that collection and return only resources of
> that type for PROPFINDS, unless the client explicitly asks for
> more/different types with the custom header.

That would break the PROPFIND semantics defined by RFC2518. If a 
calendar collection is a WebDAV collection, it has to follow the 
semantics defined by RFC2518.

 > ...

Best regards, Julian

Date: Tue, 28 Mar 2006 11:58:26 -0800
From: "Brian Moseley" <[email-masked]>
Sender: [email-masked]
To: "CalDAV DevList" <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections

On 3/28/06, Wilfredo Sánchez Vega <[email-masked]> wrote:

>    Since when do users universally avoid doing silly things?

yea but we are talking more about clients here. i can't imagine users
will be getting into the gritty details of telling their clients to
put event attachments into subcollections and so forth. i expect
clients will hide all this behind "publish your calendar to location
xyz".

>    Having to add a custom header to not get unexpected data is
> undesirable.  Not all clients will know of this custom header.
> Better to have a custom header to show you the data, and have the
> server default to hiding it.

agree! that's what i proposed earlier in the thread. if a client used
MKCALENDAR to create the collection, then consider "calendar" the
primary resource type for that collection and return only resources of
that type for PROPFINDS, unless the client explicitly asks for
more/different types with the custom header.

>    I really don't see the practical problem that you face here.  If
> you treat the calendar collection as a compound document, you can put
> that collection in your logic collection along with whatever other
> resources you like.

not really getting your point here.

this

From: =?ISO-8859-1?Q?Wilfredo_Sánchez_Vega?= <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections
Date: Tue, 28 Mar 2006 11:45:12 -0800
To: Brian Moseley <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

On Mar 28, 2006, at 10:17 AM, Brian Moseley wrote:

> On 3/27/06, Lisa Dusseault <[email-masked]> wrote:
>
>>         - If an external attachment to a calendar item is itself a  
>> calendar
>> item, where does it get stored?  If in the calendar collection, how
>> would we disable the REPORT acting on that and deal with the possible
>> duplication of IDs?
>
> isn't this a case of "don't do the obviously silly thing"? if you
> don't want a calendar item to actually show up on your calendar, don't
> put it in your calendar collection.

   Since when do users universally avoid doing silly things?

>>   - Even clients that don't want to make use of the feature, would
>> have to be able to deal with extra resources appearing in a calendar
>> collection, and how to interpret or display or ignore
>
> this, i think, is the main problem with my request, but it can't be an
> unsolvable problem. a custom request header would do the trick -
> "X-CALENDAR-ACCEPT: text/calendar" or some such.

   Having to add a custom header to not get unexpected data is  
undesirable.  Not all clients will know of this custom header.   
Better to have a custom header to show you the data, and have the  
server default to hiding it.

>> If we take as given that not all servers are going to support storing
>> resources of arbitrary types, then I for one am in favour of limiting
>> what clients have to deal with, and keeping the spec simpler, by
>> isolating these various resources in a sub-collection.   I don't see
>> sufficient benefit in the more flexible but more complicated
>> approach, in fact I'm unaware of any use cases that can't equally be
>> satisfied with a sub-collection, and I can see some use cases that
>> are better served with a sub-collection (e.g. synchronizing
>> attachments in off-cycles).
>
> just as some servers "don't wanna" support arbitrary resource types,
> some clients "don't wanna" have to deal with subcollections. choosing
> whether or not to put a particular resource in the main collection
> rather than a subcollection might be simple now, but what happens when
> additional sharing protocols come out that each expect their single
> resource type to be the one true resource type in a collection?
> suddenly you force clients to create a bunch of peer collections, each
> for a different resource type, to represent a single "logical"
> collection. bleh.

   Not supporting arbitrary resource types is a matter of necessity  
for some servers, and a matter of simplicity for others.  Dealing  
with subcollections, on the other hand, is something a client has to  
know how to do anyway, and is hardly a significant complication.  You  
seem to be putting a cosmetic priority above practical ones.

   I really don't see the practical problem that you face here.  If  
you treat the calendar collection as a compound document, you can put  
that collection in your logic collection along with whatever other  
resources you like.  Complaining that you can't store arbitrary  
content in a server-managed collection feels like complaining that  
you can't store random data in whatever file format you encounter for  
a resource.

	-wsv

Date: Tue, 28 Mar 2006 10:17:48 -0800
From: "Brian Moseley" <[email-masked]>
Sender: [email-masked]
To: "CalDAV DevList" <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections

On 3/27/06, Lisa Dusseault <[email-masked]> wrote:

> At any rate, I don't see a clear consensus on this list to REQUIRE
> all servers to support arbitrary types in calendar collections.  If
> people think I'm wrong about the consensus they should voice their
> opinions here unless they've already voiced it here.

just to be clear, i would have never suggested this as a requirement.

>   - The spec would probably have to consider the following:
>         - are these objects attachments, or can be anything at all?
>         - If an external attachment to a calendar item is itself a calendar
> item, where does it get stored?  If in the calendar collection, how
> would we disable the REPORT acting on that and deal with the possible
> duplication of IDs?

isn't this a case of "don't do the obviously silly thing"? if you
don't want a calendar item to actually show up on your calendar, don't
put it in your calendar collection.

attachments are a case where using a different collection actually
makes sense. i'm okay with that, since it's not the use case i'm
addressing.

>   - Clients that might want to make use of the feature have to see if
> the server supports it, or not, and have conditional actions for both
> cases.

well, sure. isn't that always the case when choosing to implement an
optional feature? if a client wants to have extended functionality and
still be useful with servers that don't provide the option, the client
is going to be more complicated, by definition. i don't see why
anybody would be afraid of that.

>   - Even clients that don't want to make use of the feature, would
> have to be able to deal with extra resources appearing in a calendar
> collection, and how to interpret or display or ignore

this, i think, is the main problem with my request, but it can't be an
unsolvable problem. a custom request header would do the trick -
"X-CALENDAR-ACCEPT: text/calendar" or some such.

> If we take as given that not all servers are going to support storing
> resources of arbitrary types, then I for one am in favour of limiting
> what clients have to deal with, and keeping the spec simpler, by
> isolating these various resources in a sub-collection.   I don't see
> sufficient benefit in the more flexible but more complicated
> approach, in fact I'm unaware of any use cases that can't equally be
> satisfied with a sub-collection, and I can see some use cases that
> are better served with a sub-collection (e.g. synchronizing
> attachments in off-cycles).

just as some servers "don't wanna" support arbitrary resource types,
some clients "don't wanna" have to deal with subcollections. choosing
whether or not to put a particular resource in the main collection
rather than a subcollection might be simple now, but what happens when
additional sharing protocols come out that each expect their single
resource type to be the one true resource type in a collection?
suddenly you force clients to create a bunch of peer collections, each
for a different resource type, to represent a single "logical"
collection. bleh.

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections
Date: Mon, 27 Mar 2006 18:23:18 -0800
To: Brian Moseley <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

On Mar 16, 2006, at 4:24 PM, Brian Moseley wrote:
> On 3/16/06, Bernard Desruisseaux <[email-masked]>  
> wrote:
>
>> If you insist to have your collection accessible by a single URL
>> you could request the Cosmo-aware clients to specify a proprietary
>> request-header (e.g., X-OSAF-Something) in each of their requests.
>> Cosmo would enable its CalDAV proprietary extension that allows
>> resources of arbitrary media type in calendar collections only when
>> this proprietary request-header is specified in a request.

> I get the impression that you are
> blowing off what i and at least a couple of others seem to think is a
> valid use case. there has been no comment on my assertion that caldav
> is written from a perspective that assumes calendar data is of primary
> importance to a server, giving short shrift to servers where calendar
> is just one of many data types that can be freely interspersed. can
> you and/or lisa and/or cyrus address this? thanks.

In my extended personal experience, Bernard doesn't blow these kinds  
of things off :)  In fact he brought this up tonight in our phone  
call asking if we could resolve the issue.  We discussed this at  
length perhaps as long as a year ago, and have revisited it now, but  
he  simply remains of the strong opinion that we can't require  
servers to store arbitrary types.  He's got a perspective which is  
different from yours and mine, on how an existing calendar repository  
is likely to be implemented, what restrictions it has and what kind  
of features it can implement easily or with difficulty.

We actually tried hard to balance concerns of calendar-only servers,  
with those of a sharing server with more freely-interspersed data.   
We believe the use case is handled with a different mechanism -- that  
of sub-collections, primarily.  Alternatively, calendar and non- 
calendar items can be mixed in any collection that doesn't advertise  
that it is a CalDAV calendar collection (and it can still even  
support calendar REPORTs)

At any rate, I don't see a clear consensus on this list to REQUIRE  
all servers to support arbitrary types in calendar collections.  If  
people think I'm wrong about the consensus they should voice their  
opinions here unless they've already voiced it here.

Let's suppose that's a given.  If servers aren't required to allow  
this, then MAY they?  If some servers can, but other servers don't,  
then this makes the spec and client implementations both more  
complicated
  - The spec would probably have to consider the following:
	- are these objects attachments, or can be anything at all?
	- If an external attachment to a calendar item is itself a calendar  
item, where does it get stored?  If in the calendar collection, how  
would we disable the REPORT acting on that and deal with the possible  
duplication of IDs?
  - Clients that might want to make use of the feature have to see if  
the server supports it, or not, and have conditional actions for both  
cases.
  - Even clients that don't want to make use of the feature, would  
have to be able to deal with extra resources appearing in a calendar  
collection, and how to interpret or display or ignore

If we take as given that not all servers are going to support storing  
resources of arbitrary types, then I for one am in favour of limiting  
what clients have to deal with, and keeping the spec simpler, by  
isolating these various resources in a sub-collection.   I don't see  
sufficient benefit in the more flexible but more complicated  
approach, in fact I'm unaware of any use cases that can't equally be  
satisfied with a sub-collection, and I can see some use cases that  
are better served with a sub-collection (e.g. synchronizing  
attachments in off-cycles).

Lisa

Date: Mon, 27 Mar 2006 13:34:56 -0800
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-caldav list <[email-masked]>
Subject: [Ietf-caldav] Registration is now open for May 2005 CalConnect Roundtable and IOP Testing
Reply-To: [email-masked]

This is a multi-part message in MIME format.
--------------000406090204090900070906
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Registration is now open for the May 22-25 CalConnect Roundtable VI and 
Interoperability Testing events.  These events will be hosted by IBM in 
Cambridge, Massachusetts.  The IOP testing will occur on May 22nd and 
the morning of May 23rd.  The Roundtable will take place on the 
afternoon of the 23rd, all day on the 24th and the morning of the 25th.

Information on Roundtable VI and on the IOP testing event can be found 
at http://www.calconnect.org/roundtable6.html and 
http://www.calconnect.org/iopmay2006.html respectively, including travel 
and logistics information.

A general schedule for the Roundtable is posted on the Roundtable VI 
page mentioned agove; more detailed information will be posted to that 
page as it becomes available.

The Consortium is planning to offer an introductory Practicum on 
iCalendar (RFC 2445) and on CalDAV, the new Calendar Access protocol, on 
Tuesday morning the 23rd for anyone who is not involved in the IOP 
testing and wishes to come early.  The Practicum is available without to 
anyone registered for Roundtable VI as an member representative or as an 
observer.

Due to the hotel pressures in the Boston area in May, I encourage 
everyone to make their travel and hotel arrangements 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)
http://www.calconnect.org · [email-masked] 
<mailto:[email-masked]>

--------------000406090204090900070906
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">
<br>
<br>
Registration is now open for the May 22-25 CalConnect Roundtable VI and
Interoperability Testing events.&nbsp; These events will be hosted by IBM in
Cambridge, Massachusetts.&nbsp; The IOP testing will occur on May 22nd and
the morning of May 23rd.&nbsp; The Roundtable will take place on the
afternoon of the 23rd, all day on the 24th and the morning of the 25th.<br>
<br>
Information on Roundtable VI and on the IOP testing event can be found
at <a href="http://www.calconnect.org/roundtable6.html">http://www.calconnect.org/roundtable6.html</a>
and <a href="http://www.calconnect.org/iopmay2006.html">http://www.calconnect.org/iopmay2006.html</a>
respectively, including travel and logistics information.<br>
<br>
A general schedule for the Roundtable is posted on the Roundtable VI
page mentioned agove; more detailed information will be posted to that
page as it becomes available.<br>
<br>
The Consortium is planning to offer an introductory Practicum on
iCalendar (RFC 2445) and on CalDAV, the new Calendar Access protocol,
on Tuesday morning the 23rd for anyone who is not involved in the IOP
testing and wishes to come early.&nbsp; The Practicum is available without
to anyone registered for Roundtable VI as an member representative or
as an observer.<br>
<br>
Due to the hotel pressures in the Boston area in May, I encourage
everyone to make their travel and hotel arrangements as soon as
possible.<br>
<br>
Best Regards,<br>
<br>
Dave Thewlis<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)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a> &middot; <a
 href="mailto:[email-masked]">[email-masked]</a>
</div>
</body>
</html>

--------------000406090204090900070906--

Date: Fri, 24 Mar 2006 08:53:36 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Jari Urpalainen <[email-masked]>
Subject: Re: [Ietf-caldav] ical within xml text nodes
Cc: [email-masked]

Hi Jari,

- I guess it wouldn't hurt to add a comment about XML escaping
   (i.e., the use of character and entity references as well as
   CDATA sections) in section 9.5 CALDAV:calendar-data XML Element.

- We'll change all the examples with trailing whitespaces. That is,

     END:VCALENDAR
          </C:calendar-data>

   should be changed to:

     END:VCALENDAR
     </C:calendar-data>

- We'll fix the typo in section 7.7.1.

Thanks for the feedback!

Cheers,
Bernard

Jari Urpalainen wrote:
> Hi all!
> 
> This is just a ping of discussion with Lisa. While XML is not that good 
> at embedding other markup it should imo expressed clearly that 
> applications must either encode at least & and < characters or embed 
> ical within CDATA sections. With CDATA it is worth mentioning that that 
> ]]> (or new start of CDATA) string may not appear within ical strings 
> (although very rare situation i agree/assume). CRLF mangling seems to be 
> taken care of. What I don't know at all, does ical allow appended 
> whitespaces at the end of document as many examples have it ? In Section 
> 7.7.1 there's a typo </C:calendar-data/>. I'm still a newbie regarding 
> caldav, so I don't have real comments on the content of this i-d, sorry.
> br,
> Jari
> _______________________________________________
> 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: Fri, 24 Mar 2006 10:20:50 +0100
From: Julian Reschke <[email-masked]>
To: Jari Urpalainen <[email-masked]>
Subject: Re: [Ietf-caldav] ical within xml text nodes
Cc: [email-masked]

Jari Urpalainen wrote:
> Hi all!
> 
> This is just a ping of discussion with Lisa. While XML is not that good 
> at embedding other markup it should imo expressed clearly that 
> applications must either encode at least & and < characters or embed 
> ical within CDATA sections. With CDATA it is worth mentioning that that 
> ...

Well, if somebody gets this wrong, no recipient using a regular XML 
parser would be able to interoperate. So I guess that kind of bug would 
get noticed very soon :-)

Best regards, Julian

From: "Tim Hare" <[email-masked]>
To: <[email-masked]>
Subject: RE: [Ietf-caldav] ical within xml text nodes
Date: Fri, 24 Mar 2006 00:02:14 -0500

I don't think there's any express document regarding embedding iCalendar
(RCF2445) in XML as a piece of text. iCalendar is not markup-like, or at
least not well-formed markup, having for most components only a beginning
"tag" (for example DTSTART:) with no end tag.

There are IETF individual draft documents on "xcal" which try to describe an
XML representation of iCalendar data

As far as appended whitespace goes, if have been reading the RFC correctly,
trailing whitespace MAY be ignored in the value of a component or property;
however a blank immediately following x'0D0A' is part of line wrapping of a
component value larger than 75 characters and cannot be ignored. 

Remember that iCalendar files don't have the same properties as XML
documents.

Also, since you are at Nokia, unless things have changed one of the original
iCalendar authors worked there (F. Dawson) and could be a source of
information if he's not busy on other things.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jari Urpalainen
Sent: Thursday, March 23, 2006 9:14 PM
To: [email-masked]
Subject: [Ietf-caldav] ical within xml text nodes

Hi all!

This is just a ping of discussion with Lisa. While XML is not that good 
at embedding other markup it should imo expressed clearly that 
applications must either encode at least & and < characters or embed 
ical within CDATA sections. With CDATA it is worth mentioning that that 
]]> (or new start of CDATA) string may not appear within ical strings 
(although very rare situation i agree/assume). CRLF mangling seems to be 
taken care of. What I don't know at all, does ical allow appended 
whitespaces at the end of document as many examples have it ? In Section 
7.7.1 there's a typo </C:calendar-data/>. I'm still a newbie regarding 
caldav, so I don't have real comments on the content of this i-d, sorry.
br,
Jari
_______________________________________________
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: Fri, 24 Mar 2006 04:14:16 +0200
From: Jari Urpalainen <[email-masked]>
To: [email-masked]
Subject: [Ietf-caldav] ical within xml text nodes

Hi all!

This is just a ping of discussion with Lisa. While XML is not that good 
at embedding other markup it should imo expressed clearly that 
applications must either encode at least & and < characters or embed 
ical within CDATA sections. With CDATA it is worth mentioning that that 
]]> (or new start of CDATA) string may not appear within ical strings 
(although very rare situation i agree/assume). CRLF mangling seems to be 
taken care of. What I don't know at all, does ical allow appended 
whitespaces at the end of document as many examples have it ? In Section 
7.7.1 there's a typo </C:calendar-data/>. I'm still a newbie regarding 
caldav, so I don't have real comments on the content of this i-d, sorry.
br,
Jari

From: "Tim Hare" <[email-masked]>
To: "'Calsify WG'" <[email-masked]>, "'CalDAV DevList'" <[email-masked]>, "'WebDAV WG'" <[email-masked]>
Subject: RE: [Ietf-calsify] Re: [Ietf-caldav] Re: CalDAV draft Informal Last-Call
Date: Sat, 18 Mar 2006 14:49:06 -0500

Cross-posted to Calsify, CalDAV, and WebDAV because that's how it came in,
which is relevant to this post. 

Would it be possible to not cross-post CalDAV/WebDAV discussion to the
Calsify list, please?  The two are different efforts, albeit related, and
receiving CalDAV postings twice only serves to make it harder to follow
Calsify discussions.

Thanks, 
Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Julian Reschke
Sent: Saturday, March 18, 2006 12:42 PM
To: Bernard Desruisseaux
Cc: Calsify WG; CalDAV DevList; WebDAV WG
Subject: [Ietf-calsify] Re: [Ietf-caldav] Re: CalDAV draft Informal
Last-Call

Bernard Desruisseaux wrote:
> 
> I thought it would be worthwhile to update everybody on the
> changes we are planning to make in draft -11 based on the
> issues that have been brought up so far:
> 
> - Added new preconditions:
>    * CALDAV:number-of-recurrences-within-limits for PUT;
>    * CALDAV:calendar-collection-location-ok for MOVE and COPY.
> - Redefined the CALDAV:no-uid-conflict precondition.
> - Minor editorial changes.
> - Update to references.
> - Added element CALDAV:is-not-defined.
> - Added new attribute "negate-condition" to the
>   CALDAV:text-match element.
> 
> The last two changes were required to be able to query the to-dos
> that are *not* completed and *not* cancelled. The issue is that
> the CALDAV:calendar-query REPORT does not provide support for a
> "not" operator. To be able to address the above use case without
> increasing the complexity of the CALDAV:calendar-query REPORT
> significantly we have decided to add a new condition "is-not-defined" 
> and to add a "negate-condition" attribute to be able to negate the
> "text-match" condition.
> ...

Bernard,

so did you consider whether CalDAV is going to be based on RFC2518 or on 
RFC2518bis? That is, would a CalDAV client be able to rely on 
RFC2518bis, or would they need to interact with both kinds of servers?

Are CalDAV server implementors implementing RFC2518bis (or are they 
planning to)?

Best regards, Julian
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Sat, 18 Mar 2006 18:55:23 +0100
From: Julian Reschke <[email-masked]>
To: Brian Moseley <[email-masked]>
Subject: Re: [Ietf-caldav] Re: CalDAV draft Informal Last-Call
Cc: CalDAV DevList <[email-masked]>

Brian Moseley wrote:
> On 3/18/06, Julian Reschke <[email-masked]> wrote:
> 
>> Are CalDAV server implementors implementing RFC2518bis (or are they
>> planning to)?
> 
> i haven't looked at it in detail, so i don't have an adquate
> understanding of how much effort it would take to implement, but i'm
> unlikely to do it soon unless caldav requires it.

Well.

RFC2518bis introduces some incompatible changes compared to RFC2518. 
Some are easy to handle, but at least one is not.

Should CalDAV avoid to build on top of RFC2518bis, both CalDAV clients 
and servers will have to deal with that interoperability issue.

On the other hand, it's not too late to throw that change out, see 
WebDAV mailing list at 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2006JanMar/0670.html> 
and 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2006JanMar/0693.html>.

Best regards, Julian

Date: Sat, 18 Mar 2006 09:46:28 -0800
From: "Brian Moseley" <[email-masked]>
Sender: [email-masked]
To: "CalDAV DevList" <[email-masked]>
Subject: Re: [Ietf-caldav] Re: CalDAV draft Informal Last-Call

On 3/18/06, Julian Reschke <[email-masked]> wrote:

> Are CalDAV server implementors implementing RFC2518bis (or are they
> planning to)?

i haven't looked at it in detail, so i don't have an adquate
understanding of how much effort it would take to implement, but i'm
unlikely to do it soon unless caldav requires it.

Date: Sat, 18 Mar 2006 18:42:14 +0100
From: Julian Reschke <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-caldav] Re: CalDAV draft Informal Last-Call
Cc: Ted Hardie <[email-masked]>, Calsify WG <[email-masked]>, CalDAV DevList <[email-masked]>, WebDAV WG <[email-masked]>

Bernard Desruisseaux wrote:
> 
> I thought it would be worthwhile to update everybody on the
> changes we are planning to make in draft -11 based on the
> issues that have been brought up so far:
> 
> - Added new preconditions:
>    * CALDAV:number-of-recurrences-within-limits for PUT;
>    * CALDAV:calendar-collection-location-ok for MOVE and COPY.
> - Redefined the CALDAV:no-uid-conflict precondition.
> - Minor editorial changes.
> - Update to references.
> - Added element CALDAV:is-not-defined.
> - Added new attribute "negate-condition" to the
>   CALDAV:text-match element.
> 
> The last two changes were required to be able to query the to-dos
> that are *not* completed and *not* cancelled. The issue is that
> the CALDAV:calendar-query REPORT does not provide support for a
> "not" operator. To be able to address the above use case without
> increasing the complexity of the CALDAV:calendar-query REPORT
> significantly we have decided to add a new condition "is-not-defined" 
> and to add a "negate-condition" attribute to be able to negate the
> "text-match" condition.
> ...

Bernard,

so did you consider whether CalDAV is going to be based on RFC2518 or on 
RFC2518bis? That is, would a CalDAV client be able to rely on 
RFC2518bis, or would they need to interact with both kinds of servers?

Are CalDAV server implementors implementing RFC2518bis (or are they 
planning to)?

Best regards, Julian

Date: Thu, 16 Mar 2006 16:24:34 -0800
From: "Brian Moseley" <[email-masked]>
Sender: [email-masked]
To: "CalDAV DevList" <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections

On 3/16/06, Bernard Desruisseaux <[email-masked]> wrote:

> The Accept request-header field can be used to specify certain
> media types which are acceptable for the response. I believe
> PROPFIND can only return responses of media type "text/xml"
> and "application/xml". The Accept request-header does not impact
> which resources are reported by PROPFIND.

ah, good point. the Accept header is basically rendered useless with
webdav by the xml envelope. great.

> If you insist to have your collection accessible by a single URL
> you could request the Cosmo-aware clients to specify a proprietary
> request-header (e.g., X-OSAF-Something) in each of their requests.
> Cosmo would enable its CalDAV proprietary extension that allows
> resources of arbitrary media type in calendar collections only when
> this proprietary request-header is specified in a request.

thanks for the suggestion, but i get the impression that you are
blowing off what i and at least a couple of others seem to think is a
valid use case. there has been no comment on my assertion that caldav
is written from a perspective that assumes calendar data is of primary
importance to a server, giving short shrift to servers where calendar
is just one of many data types that can be freely interspersed. can
you and/or lisa and/or cyrus address this? thanks.

Date: Thu, 16 Mar 2006 19:14:26 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Brian Moseley <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections
Cc: CalDAV DevList <[email-masked]>

Brian,

The Accept request-header field can be used to specify certain
media types which are acceptable for the response. I believe
PROPFIND can only return responses of media type "text/xml"
and "application/xml". The Accept request-header does not impact
which resources are reported by PROPFIND.

If you insist to have your collection accessible by a single URL
you could request the Cosmo-aware clients to specify a proprietary
request-header (e.g., X-OSAF-Something) in each of their requests.
Cosmo would enable its CalDAV proprietary extension that allows
resources of arbitrary media type in calendar collections only when
this proprietary request-header is specified in a request.

Cheers,
Bernard

Brian Moseley wrote:
> On 3/16/06, Bernard Desruisseaux <[email-masked]> wrote:
> 
> 
>>A calendar object resource would be accessible via two URLs:
>>
>>    /home/brian/generic/mtg123.ics   -- regular collection
>>    /home/brian/calendar/mtg123.ics  -- calendar collection
>>
>>and these two URLs would be mapped to the same resource in your
>>internal store (you don't want to duplicate data).
> 
> 
> that is technically possible, but it doesn't meet our requirement for
> having a collection accessible by a single url :)
> 
> here's the "maximum interop, user friendly" chandler/cosmo sharing scenario:
> 
> 1) user A shares a collection of data containing resource of many
> types, including some of multiple types (for example, "all of my work
> stuff") to cosmo, which responds with the url to the shared collection
> 
> 2) user A sends that url to user B, another chandler user, who
> subscribes to the shared collection using chandler's "smart"
> capabilities, receiving all of the resources in the collection,
> regardless of type
> 
> 3) user A sends the same url to user C, an evolution user, who
> subscribes to the shared collection using caldav, receiving just the
> calendar resources (and multitype resources stamped as calendar
> objects)
> 
> 4) user A sends the same url to user D, an ical user, who subscribes
> to the shared collection using "webcal", receiving a monolithic
> icalendar object containing icalendar representations of all of the
> calendar resources (and multitype resources stamped as calendar
> objects)
> 
> we want a single cosmo collection to masquerade as a caldav calendar
> collection for user  and as a webcal-style monolithic calendar
> resource for user D, as well as operating as a "smart" collection for
> chandler.
> 
> the caldav scenario is the only problematic one, since the caldav
> client has no way to ask for just the calendar resources from the
> collection. we have no way of distinguishing between a caldav client
> and a "smart" client. using the Accept header would solve this
> problem, no?
> _______________________________________________
> 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: Thu, 16 Mar 2006 15:08:34 -0800
From: "Brian Moseley" <[email-masked]>
Sender: [email-masked]
To: "CalDAV DevList" <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections

On 3/16/06, Helge Hess <[email-masked]> wrote:

> This is mostly irrelevant to the discussion, but of course the client
> has a way. It just needs to use a REPORT to retrieve the events. But
> thats beside the point.

right, that's why i didn't address it :)

> > using the Accept header would solve this problem, no?
>
> Not the actual problem, no. The problem is that it makes the servers
> more complicated if the client is allowed to PUT arbitary content
> into a calendar collection. And that every MAY makes conforming to
> the standard harder.

but it's the server implementors' choice whether or not they want to
make their server more complicated or not, not the standards body's.

please explain how MAY makes compliance harder. if you don't want to
implement the optional feature, on either the client or server end,
then don't. what's hard about that? do you have a specific example of
MAY leading to increased complexity or difficulty?

> You basically explain how Chandler won't be a conforming CalDAV
> client but only works with Cosmo (because it relies on that feature
> instead of honoring the MAY)?

i explained how chandler and cosmo operate together, and how clients
that implement today's caldav draft work with cosmo. chandler has a
"vanilla" caldav compatibility mode as well. i didn't see the need to
go into that.

> It does not seem to support this use case:
> 5) a user using a server w/o PUT / PROPPATCH / abc support sends a
> URL to a
>     Chandler user. The Chandler user won't be able to use the collection
>     because it doesn't support required features.

in this case, chandler acts just as a standard caldav client.

> Well and thats really against a standardization effort, no? And
> proves my concern that there will be clients which will most likely
> ignore a MAY and will work with just 50% of the servers :-|

there may be, but those are lazy clients. the solution is not to dumb
the spec down to encourage their laziness but rather to let the
community and competition weed out those clients (or conversely for
the community to signal its overwhelming desire for the client that
only works with half of the servers).

> Summary: *if* this feature is considered crucial for a working
> calendaring standard, it IMHO should be a MUST.

since your assumption is that i consider it crucial is invalid, then
so is this statement. i still hold that servers ought to have the
choice to support arbitrary content in a calendar collection and, if
they do, they should be required to be fully compatible with clients
that do not support arbitrary content in a calendar collection.

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections
Date: Thu, 16 Mar 2006 23:20:58 +0100
To: CalDAV DevList <[email-masked]>

On 16. Mrz 2006, at 22:51 Uhr, Brian Moseley wrote:
> the caldav scenario is the only problematic one, since the caldav
> client has no way to ask for just the calendar resources from the
> collection.

This is mostly irrelevant to the discussion, but of course the client  
has a way. It just needs to use a REPORT to retrieve the events. But  
thats beside the point.

> using the Accept header would solve this problem, no?

Not the actual problem, no. The problem is that it makes the servers  
more complicated if the client is allowed to PUT arbitary content  
into a calendar collection. And that every MAY makes conforming to  
the standard harder.

(Of course it always makes sense to send a proper Accept. But if the  
client needs to deal with that, it can also just check the content- 
type property/header prior attempting a GET.)

You basically explain how Chandler won't be a conforming CalDAV  
client but only works with Cosmo (because it relies on that feature  
instead of honoring the MAY)?
It does not seem to support this use case:
5) a user using a server w/o PUT / PROPPATCH / abc support sends a  
URL to a
    Chandler user. The Chandler user won't be able to use the collection
    because it doesn't support required features.

Well and thats really against a standardization effort, no? And  
proves my concern that there will be clients which will most likely  
ignore a MAY and will work with just 50% of the servers :-|

Summary: *if* this feature is considered crucial for a working  
calendaring standard, it IMHO should be a MUST.

Same thing for PROPPATCH, iCal X-* properties and iCal VATTACH  
components (we had the discussion ...).
The RFC should give definite directions on what MUST be available and  
highlight that MAY features may not be used (w/o proper fallback) in  
a conforming client.

regards,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

Date: Thu, 16 Mar 2006 13:51:46 -0800
From: "Brian Moseley" <[email-masked]>
Sender: [email-masked]
To: "CalDAV DevList" <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections

On 3/16/06, Bernard Desruisseaux <[email-masked]> wrote:

> A calendar object resource would be accessible via two URLs:
>
>     /home/brian/generic/mtg123.ics   -- regular collection
>     /home/brian/calendar/mtg123.ics  -- calendar collection
>
> and these two URLs would be mapped to the same resource in your
> internal store (you don't want to duplicate data).

that is technically possible, but it doesn't meet our requirement for
having a collection accessible by a single url :)

here's the "maximum interop, user friendly" chandler/cosmo sharing scenario:

1) user A shares a collection of data containing resource of many
types, including some of multiple types (for example, "all of my work
stuff") to cosmo, which responds with the url to the shared collection

2) user A sends that url to user B, another chandler user, who
subscribes to the shared collection using chandler's "smart"
capabilities, receiving all of the resources in the collection,
regardless of type

3) user A sends the same url to user C, an evolution user, who
subscribes to the shared collection using caldav, receiving just the
calendar resources (and multitype resources stamped as calendar
objects)

4) user A sends the same url to user D, an ical user, who subscribes
to the shared collection using "webcal", receiving a monolithic
icalendar object containing icalendar representations of all of the
calendar resources (and multitype resources stamped as calendar
objects)

we want a single cosmo collection to masquerade as a caldav calendar
collection for user  and as a webcal-style monolithic calendar
resource for user D, as well as operating as a "smart" collection for
chandler.

the caldav scenario is the only problematic one, since the caldav
client has no way to ask for just the calendar resources from the
collection. we have no way of distinguishing between a caldav client
and a "smart" client. using the Accept header would solve this
problem, no?

Date: Thu, 16 Mar 2006 16:24:00 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Brian Moseley <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections
Cc: CalDAV DevList <[email-masked]>

I understand the internal data model of Cosmo allows resources
of arbitrary media type to co-exist in the same container.

For each container you could have a regular WebDAV collection
that would give access to all the resources in the container,
and a calendar collection that would only give access to the
calendar object resources contained in the container.

A calendar object resource would be accessible via two URLs:

    /home/brian/generic/mtg123.ics   -- regular collection
    /home/brian/calendar/mtg123.ics  -- calendar collection

and these two URLs would be mapped to the same resource in your
internal store (you don't want to duplicate data).

Cheers,
Bernard

Brian Moseley wrote:
> On 3/16/06, Helge Hess <[email-masked]> wrote:
> 
> 
>>Whats the use case for storing additional content in a calendar?
> 
> 
> cosmo is a generic content repository that happens to allow caldav
> access. it supports content that is "stamped" as various types -
> imagine a resource that is simultaneously an event, a task, and an
> email message.
> 
> i want to support caldav access to a collection filled with resources
> with arbitrary media types. one such media type might be something
> like "text/x-multitype" for a resource that encloses icalendar and
> mime representations of the same data item.
> 
> caldav clients should be able to send reports to these collections and
> get back just calendar resources as they'd expect, including the
> icalendar representations of these special multitype resources. other
> "smart" clients should be able to put and get resources of arbitrary
> types, including multitype as mentioned above.
> 
> it is certainly true that i can implement cosmo to allow smart clients
> to put whatever they want into cosmo's collections. however, if cosmo
> allows a caldav client to behave this way, then it is contradicting
> the caldav spec as written. of course most caldav clients won't try,
> but still.
> 
> i think the issue might be one of perspective. the draft is written
> such that storing calendar resources is the primary job of a calendar
> collection. from my point of view, a collection should only be thought
> of as a calendar collection when it's time to service a caldav report.
> 
> i understand the issue where a caldav client propfinds a calendar
> collection and finds resources with media types it can't handle.
> couldn't we specify that a client may send the Accept header limiting
> the returned resources to just those that the client can handle? i'd
> be satisfied if the default server behavior does not provide an Accept
> header, is to include only text/calendar resources in the response.
> providing an Accept header certainly seems to be the responsibility of
> a "smart" client.
> _______________________________________________
> 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: Thu, 16 Mar 2006 12:14:06 -0800
From: "Brian Moseley" <[email-masked]>
Sender: [email-masked]
To: "CalDAV DevList" <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections

On 3/16/06, Julian Reschke <[email-masked]> wrote:

> If your server is a generic server where a calendar just happens to be a
> special case, it really doesn't make sense requiring the server to
> reject other content. Thinking of it, server implementors aren't likely
> to implement that constraint if it doesn't make sense to them (no matter
> what the spec says...).

unfortunately that is exactly the position i'm in at the moment with
cosmo, if i choose not to place non-calendar content in
subcollections.

again, serving calendar data is not the be-all and end-all of my
software. calendar is just one of the many content types cosmo
supports. i'd like to be able to masquerade cosmo's collections as
calendar collections when it serves my purpose (mainly allowing caldav
clients to run reports), but i don't want caldav dictating my content
model, which is (rather, will be) much more expansive than just events
and tasks.

Date: Thu, 16 Mar 2006 12:10:43 -0800
From: "Brian Moseley" <[email-masked]>
Sender: [email-masked]
To: "CalDAV DevList" <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections

On 3/16/06, Helge Hess <[email-masked]> wrote:

> Whats the use case for storing additional content in a calendar?

cosmo is a generic content repository that happens to allow caldav
access. it supports content that is "stamped" as various types -
imagine a resource that is simultaneously an event, a task, and an
email message.

i want to support caldav access to a collection filled with resources
with arbitrary media types. one such media type might be something
like "text/x-multitype" for a resource that encloses icalendar and
mime representations of the same data item.

caldav clients should be able to send reports to these collections and
get back just calendar resources as they'd expect, including the
icalendar representations of these special multitype resources. other
"smart" clients should be able to put and get resources of arbitrary
types, including multitype as mentioned above.

it is certainly true that i can implement cosmo to allow smart clients
to put whatever they want into cosmo's collections. however, if cosmo
allows a caldav client to behave this way, then it is contradicting
the caldav spec as written. of course most caldav clients won't try,
but still.

i think the issue might be one of perspective. the draft is written
such that storing calendar resources is the primary job of a calendar
collection. from my point of view, a collection should only be thought
of as a calendar collection when it's time to service a caldav report.

i understand the issue where a caldav client propfinds a calendar
collection and finds resources with media types it can't handle.
couldn't we specify that a client may send the Accept header limiting
the returned resources to just those that the client can handle? i'd
be satisfied if the default server behavior does not provide an Accept
header, is to include only text/calendar resources in the response.
providing an Accept header certainly seems to be the responsibility of
a "smart" client.

From: =?ISO-8859-1?Q?Wilfredo_Sánchez_Vega?= <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections
Date: Thu, 16 Mar 2006 11:41:01 -0800
To: Julian Reschke <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

   This isn't exactly true.  In a CalDAV server, a calendar  
collection is never generic; it _must_ be managed by the server.  For  
example, when you PUT a calendar resource, it has to verify that the  
UID of the resource isn't already in use by another.

	-wsv

On Mar 16, 2006, at 5:41 AM, Julian Reschke wrote:

> If your server is a generic server where a calendar just happens to  
> be a special case, it really doesn't make sense requiring the  
> server to reject other content.

Date: Thu, 16 Mar 2006 10:08:55 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Brian Moseley <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections
Cc: CalDAV DevList <[email-masked]>

Hi Brian,

Servers may allow clients to create regular collections in calendar
collections for this purpose. Clients can store any kind of resources
in those regular sub-collection including calendar resources that don't
obey the restrictions of calendar collection. Sub-collections and their
content is simply ignored by the calendaring reports.

Servers may provide support for calendar resources of different media
type (e.g., text/calendar for iCalendar, text/x-vCalendar for vCalendar).
So, a resource might be considered as a non-calendar resource by one
CalDAV server and as a calendar resource by another CalDAV server.

If you could store a calendar resource in a media type not supported
by the CalDAV server in a calendar collection (i.e., a non-calendar
resource as far as this server can tell), you'll be stuck with an ugly
problem the day the CalDAV server will be upgraded to support calendar
resource of this media type. After the upgrade either some calendar
resources that never appeared in your calendar will now show up or
some calendar resources in your calendar collections will be considered
invalid as they won't obey the restriction of calendar collections.

Cheers,
Bernard

Brian Moseley wrote:
> i'd like to re-examine the decision to blanket disallow non-calendar
> resources within calendar collections.
> 
> i recognize that for some servers it may not be possible to allow
> anything other than an event or task to be put into a calendar
> collection, but surely some would like to be able to support this
> without contradicting the spec
> 
> why not state that servers MAY allow non-calendar resources in
> calendar collections, and that PUTs containing resources that are not
> supported will return 415 responses?
> _______________________________________________
> 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: Thu, 16 Mar 2006 09:44:03 -0500
From: Cyrus Daboo <[email-masked]>
To: Brian Moseley <[email-masked]>, CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections

Hi Cyrus,

--On March 16, 2006 9:31:32 AM -0500 Cyrus Daboo <[email-masked]> wrote:

>> i'd like to re-examine the decision to blanket disallow non-calendar
>> resources within calendar collections.
>>
>> i recognize that for some servers it may not be possible to allow
>> anything other than an event or task to be put into a calendar
>> collection, but surely some would like to be able to support this
>> without contradicting the spec
>>
>> why not state that servers MAY allow non-calendar resources in
>> calendar collections, and that PUTs containing resources that are not
>> supported will return 415 responses?

One other thing I wanted to point out relating to interoperability: if 
client A creates ancillary resources for a calendar object resource, and 
client B does not, then when client B copies/moves a calendar object 
between calendar collections, the ancillary data will likely not be moved 
(unless the server was somehow aware of it and moved it as well). That 
would likely 'upset' client A! Also, how would client B modifying the 
calendar data know to update the ancillary data? Whilst use of WebDAVC 
properties or X- items embedded in the iCal data solve the problem of 
moving/copying, they don't address the data consistency issue.

So careful thought needs to be given to the use cases for such resources to 
ensure interoperability at at least the basic iCal level can always be 
maintained.

-- 
Cyrus Daboo

Date: Thu, 16 Mar 2006 09:34:20 -0500
From: Cyrus Daboo <[email-masked]>
To: "Kervin L. Pierre" <[email-masked]>, Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections
Cc: CalDAV DevList <[email-masked]>

Hi Kervin,

--On March 16, 2006 9:04:24 AM -0500 "Kervin L. Pierre" 
<[email-masked]> wrote:

> Client specific resources necessary to render the
> calendar, or otherwise tie events to client specific
> features.  Eg. Additional MAPI properties if your
> client uses that API, icons, etc.

Could data like that be stored as a WebDAV property on the calendar object 
resource? Obviously large chunks of data would not be suitable as WebDAV 
properties, but small bits of 'meta-data' would.

> I don't have a strong opinion on this, personally
> we haven't needed to do this as yet.  And if it
> became necessary a 'shadow' regular WebDAV folder
> would work just as well, though requiring an
> additional piece of information.

Obviously a WebDAV property could be used to 'point' to the location of 
such a 'shadow' collection or resources.

-- 
Cyrus Daboo

Date: Thu, 16 Mar 2006 09:31:32 -0500
From: Cyrus Daboo <[email-masked]>
To: Brian Moseley <[email-masked]>, CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections

Hi Brian,

--On March 15, 2006 8:47:52 PM -0800 Brian Moseley <[email-masked]> 
wrote:

> i'd like to re-examine the decision to blanket disallow non-calendar
> resources within calendar collections.
>
> i recognize that for some servers it may not be possible to allow
> anything other than an event or task to be put into a calendar
> collection, but surely some would like to be able to support this
> without contradicting the spec
>
> why not state that servers MAY allow non-calendar resources in
> calendar collections, and that PUTs containing resources that are not
> supported will return 415 responses?

Note that the current spec does allow regular collections inside of a 
calendar collection (c.f. Section 4.2). So there is nothing to stop a 
client creating its own private collection inside a calendar and storing 
whatever it wants in there. Yes that does mean non-calendar resources at 
Depth:1 in a calendar collection are disallowed, but you can have that at 
'lower' depths than that if needs be. The benefit of keeping non-calendar 
resources out of the top-level of the calendar is that clients and servers 
can easily ignore such data by simply doing Depth:1 PROPFINDs etc. Thus 
clients that don't use the extra 'meta' data resources don't pay the 
penalty of 'seeing' them in PROPFINDs. Yes they will see the regular 
collections - but hopefully those will be fewer than the resources they 
might contain.

-- 
Cyrus Daboo

Date: Thu, 16 Mar 2006 09:23:19 -0500
From: Mike Douglass <[email-masked]>
Cc: CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections

It makes sense in that it helps to ensure dependencies on non-caldav 
resources don't become a requirement.

I don't think that stops implementors adding features outside of caldav 
if they wish but I believe the protocol should specify only what is 
required for caldav interoperability.

If it's the case that interoperability with exchange say, requires some 
extra information, then maybe we should build that in

Julian Reschke wrote:

> Helge Hess wrote:
>
>> On 16. Mrz 2006, at 05:47 Uhr, Brian Moseley wrote:
>>
>>> why not state that servers MAY allow non-calendar resources in
>>> calendar collections, and that PUTs containing resources that are not
>>> supported will return 415 responses?
>>
>>
>> Whats the use case for storing additional content in a calendar?
>>
>> I think the danger is that some clients will ignore the MAY in the 
>> spec and will just not work (properly) with servers not supporting 
>> arbitary content.
>
>
> Depends on where you come from.
>
> If your server is a generic server where a calendar just happens to be 
> a special case, it really doesn't make sense requiring the server to 
> reject other content. Thinking of it, server implementors aren't 
> likely to implement that constraint if it doesn't make sense to them 
> (no matter what the spec says...).
>
> Best regards, Julian
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections
Date: Thu, 16 Mar 2006 15:18:08 +0100
To: CalDAV DevList <[email-masked]>

On 16. Mrz 2006, at 15:04 Uhr, Kervin L. Pierre wrote:
> Eg. Additional MAPI properties if your
> client uses that API, icons, etc.

For exactly this a MAY would not be sufficient. Either CalDAV  
requires the server to support additional resources, then this can be  
used by a MAPI plugin to store additional stuff directly in the  
calendar OR it doesn't. In the latter case it must store the  
additional info somewhere else anyway (or opt to be incompatible with  
certain CalDAV servers, which is my concern).

I'm not so much against the feature itself but I'm against having to  
many MAYs, this just increases complexity for everyone :-)

BTW: for MAPI properties one would preferably either use WebDAV  
properties on the resource or iCalendar X- fields. However MAPI  
messages can also contain attachments which could be stored as  
separate resources (probably better for performance than storing them  
inside a VATTACH section ...)

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

Date: Thu, 16 Mar 2006 09:04:24 -0500
From: "Kervin L. Pierre" <[email-masked]>
To: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections
Cc: CalDAV DevList <[email-masked]>

Helge Hess wrote:
> Whats the use case for storing additional content in a calendar?
> 

Client specific resources necessary to render the
calendar, or otherwise tie events to client specific
features.  Eg. Additional MAPI properties if your
client uses that API, icons, etc.

I don't have a strong opinion on this, personally
we haven't needed to do this as yet.  And if it
became necessary a 'shadow' regular WebDAV folder
would work just as well, though requiring an
additional piece of information.

Best Regards,
Kervin

Date: Thu, 16 Mar 2006 14:41:57 +0100
From: Julian Reschke <[email-masked]>
To: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections
Cc: CalDAV DevList <[email-masked]>

Helge Hess wrote:
> On 16. Mrz 2006, at 05:47 Uhr, Brian Moseley wrote:
>> why not state that servers MAY allow non-calendar resources in
>> calendar collections, and that PUTs containing resources that are not
>> supported will return 415 responses?
> 
> Whats the use case for storing additional content in a calendar?
> 
> I think the danger is that some clients will ignore the MAY in the spec 
> and will just not work (properly) with servers not supporting arbitary 
> content.

Depends on where you come from.

If your server is a generic server where a calendar just happens to be a 
special case, it really doesn't make sense requiring the server to 
reject other content. Thinking of it, server implementors aren't likely 
to implement that constraint if it doesn't make sense to them (no matter 
what the spec says...).

Best regards, Julian

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections
Date: Thu, 16 Mar 2006 14:30:33 +0100
To: CalDAV DevList <[email-masked]>

On 16. Mrz 2006, at 05:47 Uhr, Brian Moseley wrote:
> why not state that servers MAY allow non-calendar resources in
> calendar collections, and that PUTs containing resources that are not
> supported will return 415 responses?

Whats the use case for storing additional content in a calendar?

I think the danger is that some clients will ignore the MAY in the  
spec and will just not work (properly) with servers not supporting  
arbitary content.

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

Date: Thu, 16 Mar 2006 09:23:04 +0100
From: Julian Reschke <[email-masked]>
To: Brian Moseley <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections
Cc: CalDAV DevList <[email-masked]>

Brian Moseley wrote:
> i'd like to re-examine the decision to blanket disallow non-calendar
> resources within calendar collections.
> 
> i recognize that for some servers it may not be possible to allow
> anything other than an event or task to be put into a calendar
> collection, but surely some would like to be able to support this
> without contradicting the spec
> 
> why not state that servers MAY allow non-calendar resources in
> calendar collections, and that PUTs containing resources that are not
> supported will return 415 responses?

That sounds like the right approach to me.

Julian

Date: Wed, 15 Mar 2006 20:47:52 -0800
From: "Brian Moseley" <[email-masked]>
Sender: [email-masked]
To: "CalDAV DevList" <[email-masked]>
Subject: [Ietf-caldav] non-calendar resources in calendar collections

i'd like to re-examine the decision to blanket disallow non-calendar
resources within calendar collections.

i recognize that for some servers it may not be possible to allow
anything other than an event or task to be put into a calendar
collection, but surely some would like to be able to support this
without contradicting the spec

why not state that servers MAY allow non-calendar resources in
calendar collections, and that PUTs containing resources that are not
supported will return 415 responses?

Date: Wed, 15 Mar 2006 21:35:52 -0500
From: Bernard Desruisseaux <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] Re: CalDAV draft Informal Last-Call
Cc: Ted Hardie <[email-masked]>, Calsify WG <[email-masked]>, WebDAV WG <[email-masked]>

I thought it would be worthwhile to update everybody on the
changes we are planning to make in draft -11 based on the
issues that have been brought up so far:

- Added new preconditions:
    * CALDAV:number-of-recurrences-within-limits for PUT;
    * CALDAV:calendar-collection-location-ok for MOVE and COPY.
- Redefined the CALDAV:no-uid-conflict precondition.
- Minor editorial changes.
- Update to references.
- Added element CALDAV:is-not-defined.
- Added new attribute "negate-condition" to the
   CALDAV:text-match element.

The last two changes were required to be able to query the to-dos
that are *not* completed and *not* cancelled. The issue is that
the CALDAV:calendar-query REPORT does not provide support for a
"not" operator. To be able to address the above use case without
increasing the complexity of the CALDAV:calendar-query REPORT
significantly we have decided to add a new condition "is-not-defined" 
and to add a "negate-condition" attribute to be able to negate the
"text-match" condition.

Here's the DTD declarations that will be added to the draft:

   <!ELEMENT is-not-defined EMPTY>

   <!ATTLIST text-match negate-condition (yes | no) #IMPLIED "no">

Here's an example for the to-dos use case:

    REPORT /bernard/work/ HTTP/1.1
    Host: cal.example.com
    Depth: 1
    Content-Type: application/xml; charset="utf-8"
    Content-Length: xxxx

    <?xml version="1.0" encoding="utf-8" ?>
    <C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
      <D:prop xmlns:D="DAV:">
        <D:getetag/>
        <C:calendar-data/>
      </D:prop>
      <C:filter>
        <C:comp-filter name="VCALENDAR">
          <C:comp-filter name="VTODO">
            <C:prop-filter name="COMPLETED">
              <C:is-not-defined/>
            </C:prop-filter>
            <C:prop-filter name="STATUS">
              <C:text-match
                 negate-condition="yes">CANCELLED</c:text-match>
            </C:prop-filter>
          </C:comp-filter>
        </C:comp-filter>
      </C:filter>
    </C:calendar-query>

Please continue to send us feedback/questions/comments.

Thanks,
Bernard

Bernard Desruisseaux wrote:
> Quick update.  We will submit the CalDAV draft for Last Call when
> Internet-Draft posting will resume after the next IETF meeting.
> That will give more time to people to review the draft.
> 
> Cheers,
> Bernard
> 
> Bernard Desruisseaux wrote:
> 
>>
>> We submitted CalDAV draft -10 to the IETF yesterday. The draft has
>> not been officially announced yet, but it is already available for
>> you to review at the following URL:
>>
>> http://ietf.webdav.org/caldav/draft-dusseault-caldav-10.txt
>>
>> We would like to submit the CalDAV draft for Last Call in time for
>> the 65th IETF Meeting in Dallas (i.e., really soon!). Before we do
>> so, we would like to get as much feedback as possible from the
>> participants of the "ietf-caldav" mailing list as well as from the
>> members of the WebDAV and Calsify Working Groups.
>>
>> Once officially announced the draft should be available at:
>>
>>   http://www.ietf.org/internet-drafts/draft-dusseault-caldav-10.txt
>>
>> Previous versions of the draft are available at:
>>
>>   http://ietfreport.isoc.org/idref/draft-dusseault-caldav/
>>
>> Discussion on CalDAV is taking place on the "ietf-caldav" mailing list:
>>
>>   mailto:[email-masked]
>>
>> which is archived at:
>>
>>   http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>>
>> Reports on the 4 CalDAV Interoperability Events organized by the
>> Calendaring and Scheduling Consortium (CalConnect) can be found at:
>>
>>   http://www.calconnect.org/ioppast.html
>>
>> Finally, additional information on CalDAV can also be found at:
>>
>>   http://ietf.webdav.org/caldav/
>>
>> Please review draft -10 and send us feedback/questions/comments.
>>
>> Thanks for you help!
>>
>> Cheers,
>> Bernard
>>
>> -- 
>>
>> C.1.  Changes in -10
>>
>>    a.  Added new section about support for X- items when storing data.
>>
>>    b.  Added new precondition to allow servers to reject queries on
>>        unsupported X- items, and a new example.
>>
>>    c.  Added new text about always supporting X- in calendar-data.
>>
>>    d.  Created new section for PUT, COPY and MOVE preconditions.
>>
>>    e.  Report examples re-done with full listing of calendar data in
>>        Appendix.
>>
>>    f.  Removed description of using UID, SUMMARY etc as resource name.
>>
>>    g.  Indicate that calendar object resource may contain only
>>        overridden components.
>>
>>    h.  Add security consideration about not expose details in resource
>>        names.
>>
>>    i.  Add constraint that free-busy-query can only be run on a
>>        collection.
>>
>>    j.  Add preconditions for calendar-timezone property/elements in
>>        MKCALENDAR, PROPPATCH and calendar-query REPORT.
>>
>>    k.  Fix principal-match example.
>>
>>
>>
> 
> _______________________________________________
> 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, 07 Mar 2006 08:39:08 -0500
From: Bernard Desruisseaux <[email-masked]>
To: CalDAV DevList <[email-masked]>, Calsify WG <[email-masked]>, WebDAV WG <[email-masked]>
Cc: Ted Hardie <[email-masked]>
Subject: [Ietf-caldav] Re: CalDAV draft Informal Last-Call

Quick update.  We will submit the CalDAV draft for Last Call when
Internet-Draft posting will resume after the next IETF meeting.
That will give more time to people to review the draft.

Cheers,
Bernard

Bernard Desruisseaux wrote:
> 
> We submitted CalDAV draft -10 to the IETF yesterday. The draft has
> not been officially announced yet, but it is already available for
> you to review at the following URL:
> 
> http://ietf.webdav.org/caldav/draft-dusseault-caldav-10.txt
> 
> We would like to submit the CalDAV draft for Last Call in time for
> the 65th IETF Meeting in Dallas (i.e., really soon!). Before we do
> so, we would like to get as much feedback as possible from the
> participants of the "ietf-caldav" mailing list as well as from the
> members of the WebDAV and Calsify Working Groups.
> 
> Once officially announced the draft should be available at:
> 
>   http://www.ietf.org/internet-drafts/draft-dusseault-caldav-10.txt
> 
> Previous versions of the draft are available at:
> 
>   http://ietfreport.isoc.org/idref/draft-dusseault-caldav/
> 
> Discussion on CalDAV is taking place on the "ietf-caldav" mailing list:
> 
>   mailto:[email-masked]
> 
> which is archived at:
> 
>   http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
> 
> Reports on the 4 CalDAV Interoperability Events organized by the
> Calendaring and Scheduling Consortium (CalConnect) can be found at:
> 
>   http://www.calconnect.org/ioppast.html
> 
> Finally, additional information on CalDAV can also be found at:
> 
>   http://ietf.webdav.org/caldav/
> 
> Please review draft -10 and send us feedback/questions/comments.
> 
> Thanks for you help!
> 
> Cheers,
> Bernard
> 
> -- 
> 
> C.1.  Changes in -10
> 
>    a.  Added new section about support for X- items when storing data.
> 
>    b.  Added new precondition to allow servers to reject queries on
>        unsupported X- items, and a new example.
> 
>    c.  Added new text about always supporting X- in calendar-data.
> 
>    d.  Created new section for PUT, COPY and MOVE preconditions.
> 
>    e.  Report examples re-done with full listing of calendar data in
>        Appendix.
> 
>    f.  Removed description of using UID, SUMMARY etc as resource name.
> 
>    g.  Indicate that calendar object resource may contain only
>        overridden components.
> 
>    h.  Add security consideration about not expose details in resource
>        names.
> 
>    i.  Add constraint that free-busy-query can only be run on a
>        collection.
> 
>    j.  Add preconditions for calendar-timezone property/elements in
>        MKCALENDAR, PROPPATCH and calendar-query REPORT.
> 
>    k.  Fix principal-match example.
> 
> 
> 

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Re: CalDAV draft Informal Last-Call
Date: Thu, 2 Mar 2006 00:36:58 +0100
To: CalDAV DevList <[email-masked]>

On 2. Mrz 2006, at 00:31 Uhr, Lisa Dusseault wrote:
> Not sure what you want a summary of.  If you want to know the  
> practical differences between RFC2518 and RFC2518bis, there's a  
> section for that at the bottom of the RFC2518bis doc, sorted  
> roughly according to whether an implementor is likely to have to  
> make changes as a result of the spec change.

Ah thanks, that is what I was looking for. For reference:
   http://tools.ietf.org/html/draft-ietf-webdav- 
rfc2518bis-14.txt#page-135

Thanks,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Re: CalDAV draft Informal Last-Call
Date: Wed, 1 Mar 2006 15:31:26 -0800
To: Helge Hess <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

Not sure what you want a summary of.  If you want to know the  
practical differences between RFC2518 and RFC2518bis, there's a  
section for that at the bottom of the RFC2518bis doc, sorted roughly  
according to whether an implementor is likely to have to make changes  
as a result of the spec change.

Lisa

On Mar 1, 2006, at 3:27 PM, Helge Hess wrote:

> On 2. Mrz 2006, at 00:19 Uhr, Lisa Dusseault wrote:
>> CalDAV would presumably require support for class 1 and class 3,  
>> but not class 2.  This would mean that the server is compliant  
>> with RFC2518bis requirements (the class 3 part), that it is  
>> backward compatible with RFC2518 clients (the class 1 part)
>
> Being lazy reading specs :-), so - Could you summarize the  
> practical differences between class 1 and 3? I've never heard about  
> class-3 before ;-|
>
> Thanks,
>   Helge
> -- 
> http://docs.opengroupware.org/Members/helge/
> OpenGroupware.org

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Re: CalDAV draft Informal Last-Call
Date: Thu, 2 Mar 2006 00:27:11 +0100
To: Lisa Dusseault <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

On 2. Mrz 2006, at 00:19 Uhr, Lisa Dusseault wrote:
> CalDAV would presumably require support for class 1 and class 3,  
> but not class 2.  This would mean that the server is compliant with  
> RFC2518bis requirements (the class 3 part), that it is backward  
> compatible with RFC2518 clients (the class 1 part)

Being lazy reading specs :-), so - Could you summarize the practical  
differences between class 1 and 3? I've never heard about class-3  
before ;-|

Thanks,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Re: CalDAV draft Informal Last-Call
Date: Wed, 1 Mar 2006 15:19:09 -0800
To: Helge Hess <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

Heh, we worried this would be a point of confusion.

CalDAV would presumably require support for class 1 and class 3, but  
not class 2.  This would mean that the server is compliant with  
RFC2518bis requirements (the class 3 part), that it is backward  
compatible with RFC2518 clients (the class 1 part), and it may or may  
not support locking (depending on whether class 2 is advertised).

Lisa

On Mar 1, 2006, at 3:12 PM, Helge Hess wrote:

> On 1. Mrz 2006, at 15:46 Uhr, Julian Reschke wrote:
>> one important question here is whether CalDav servers can rely on  
>> their clients speaking WebDAV class 3, and whether CalDav clients  
>> can rely on CalDAV servers being class 3 compliant. If this is not  
>> the case, both sides will be harder to implement, because of  
>> incompatible changes in RFC2518bis (see <http://lists.w3.org/ 
>> Archives/Public/w3c-dist-auth/2006JanMar/0670.html>).
>
> Sorry if this is a stupid question, but the link you give talks  
> about LOCKs. Does this mean that "just" class-2 has changed and  
> class-1 is as is? I would assume that most CalDAV clients talk  
> class-1 (actually thats all which is required by CalDAV), so this  
> shouldn't be an issue?
>
> Thanks,
>   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

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Re: CalDAV draft Informal Last-Call
Date: Thu, 2 Mar 2006 00:12:19 +0100
To: Julian Reschke <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

On 1. Mrz 2006, at 15:46 Uhr, Julian Reschke wrote:
> one important question here is whether CalDav servers can rely on  
> their clients speaking WebDAV class 3, and whether CalDav clients  
> can rely on CalDAV servers being class 3 compliant. If this is not  
> the case, both sides will be harder to implement, because of  
> incompatible changes in RFC2518bis (see <http://lists.w3.org/ 
> Archives/Public/w3c-dist-auth/2006JanMar/0670.html>).

Sorry if this is a stupid question, but the link you give talks about  
LOCKs. Does this mean that "just" class-2 has changed and class-1 is  
as is? I would assume that most CalDAV clients talk class-1 (actually  
thats all which is required by CalDAV), so this shouldn't be an issue?

Thanks,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Re: CalDAV draft Informal Last-Call
Date: Wed, 1 Mar 2006 08:37:46 -0800
To: Julian Reschke <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

I think Julian's proposing that CalDAV build on RFC2518bis, not  
RFC2518, and I agree.  The improvements are all very carefully  
considered for improving interoperability and maintaining backward- 
compatibility, and many are applicable to CalDAV. It's not a big cost  
for existing servers or clients to upgrade from RFC2518 compliance to  
RFC2518bis compliance (in particular existing clients should incur  
zero or very small costs), and there's a sizable benefit to those  
implementing WebDAV for the first time.  In the long run existing  
servers or clients also derive benefit from less ambiguous  
interoperability with new entrants.

Lisa

On Mar 1, 2006, at 6:46 AM, Julian Reschke wrote:

> Bernard Desruisseaux wrote:
>> ...
>> Lisa, Cyrus and I already discussed about the possibility of making
>> reference to RFC2518bis. We will consider your feedback on this  
>> issue.
>> ...
>
> Bernard,
>
> one important question here is whether CalDav servers can rely on  
> their clients speaking WebDAV class 3, and whether CalDav clients  
> can rely on CalDAV servers being class 3 compliant. If this is not  
> the case, both sides will be harder to implement, because of  
> incompatible changes in RFC2518bis (see <http://lists.w3.org/ 
> Archives/Public/w3c-dist-auth/2006JanMar/0670.html>).
>
> Best regards, Julian
> _______________________________________________
> 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, 01 Mar 2006 15:46:51 +0100
From: Julian Reschke <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Cc: CalDAV DevList <[email-masked]>
Subject: [Ietf-caldav] Re: CalDAV draft Informal Last-Call

Bernard Desruisseaux wrote:
> ...
> Lisa, Cyrus and I already discussed about the possibility of making
> reference to RFC2518bis. We will consider your feedback on this issue.
> ...

Bernard,

one important question here is whether CalDav servers can rely on their 
clients speaking WebDAV class 3, and whether CalDav clients can rely on 
CalDAV servers being class 3 compliant. If this is not the case, both 
sides will be harder to implement, because of incompatible changes in 
RFC2518bis (see 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2006JanMar/0670.html>).

Best regards, Julian