Subject: [Ietf-caldav] comments on -02
From: Dan Winship <[email-masked]>
To: [email-masked]
Date: Wed, 29 Sep 2004 12:41:06 -0400
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>

Simple typos: "calenadr" in 4.1, "calendards" in 5.2, "apper" in 14.3

> 4.2  Recurrence and the Data Model

How/where are "detached" instances of a recurrence represented? Eg, if I
change the SUMMARY of one instance of a meeting, does that require
creating a new resource (with the same UID as an existing resource)?

> 4.3  CalDAV and timezones

This feels like it presupposes a certain calsify outcome...

> 4.4  Scheduling, Fanout and the Data model

> The Inbox contains inbound iTIP messages long after they are
> handled/seen by the user

OK. How long?

> CalDAV defines an iTIP Outbox collection...

In email clients and real life, an outbox/"out box" is for things that
are on their way out. The CalDAV Outbox stores things that have
*already* gone out. Seems weird, but I don't know if this is going to
annoy anyone but me. :)

> Two users coordinating scheduling with one calendar (e.g.  a calendar
> user and her assistant) can see what scheduling messages the other
> user has sent.

But does that actually tell them what they want to know? Wouldn't it
would be better to look in the calendar folder instead?

      * If some invitees have already responded to the invite, the copy
        of the event in the calendar will show updated PARTSTATs, but
        the copy in the Outbox won't.
      * If the other user made changes to the event after first
        scheduling it (eg, added an attendee who was forgotten in the
        original invite), that will be reflected all in one place in the
        calendar folder, but the information would be split across
        multiple separate Outbox messages.
      * If a meeting was scheduled entirely via iMIP (perhaps because it
        was received as a REQUEST from a non-CalDAV user), then it will
        appear in the calendar, but not in the Outbox.

Another problem is that the Outbox doesn't record the responses to the
SCHEDULE request. So you might see an invite that appears to have been
sent to several people, when in fact the server returned a 502 for every
Recipient.

> However, the server MAY be configured (how is not defined here) to 
> auto-accept or auto-reject invitations, and if the server
> auto-accepts invitations then the server is responsible for creating
> VEVENT resources in the user's calendar.

("VEVENT" is wrong here, it might be automatically accepting VTODOs
too.)

If the spec is going to explicitly allow servers to do this, it should
specify how the client is expected to behave in such a situation. How
does a client determine if the server has already processed an
invitation? And is the server allowed (or REQUIRED) to process it
*before* putting it in the Inbox, to avoid a race condition?

> 5.2  Calendars Collection

> A WebDAV collection which corresponds to a single calendar or VAGENDA 
> is a Calendar.

VAGENDA is a CAP-ism. RFC 2445 has only VCALENDARs.

> It MUST contain one event collection

Any reason for that? What if a system wants to support just todo data?
(Eg, a bug-tracking system could export your bugs as tasks.)

> and one alarm collection.

That's wrong now, right?

> 5.3  Event Collection

> and each one contains exactly one VEVENT or VFREEBUSY object.

Do we really want static VFREEBUSY objects?

> 5.7  iTIP Outbox Collection

> Every non-collection resource in the scheduling collection is
> considered to be a REQUEST or REPLY.

No COUNTER, DECLINE-COUNTER, etc?

> 6.  Creating Resources

Why not just say that the client should use POST (to the collection URL)
rather than PUT, and let the server generate an object URL?

> 7.  Users and Groups 
>
> The WebDAV ACL specification requires that any principal to whom
> permissions can be represented via a WebDAV resource (complete with
> WebDAV properties and a HTTP URL).

Something is missing in that sentence. (s/can be represented/can be
granted can be represented/ ?)

> 9.  Scheduling and Fanout

> In other words, the server MUST handle fanout if requested

I think that sentence predates the calendar-schedule capability... the
section probably needs a little rewriting

> CalDAV servers that return the value "calendar-schedule" in the DAV 
> response header MUST support iTIP to send and receive scheduling
> requests as well as reply to scheduling request.  Outgoing iTIP
> messages MUST be submitted to an iTIP Outbox collection.

Who is being MUSTed in the second sentence? The paragraph starts out
talking about servers, but servers don't submit things to Outboxes. And
if it means "Clients MUST submit outgoing iTIP messages to an iTIP
Outbox collection", that would imply they weren't allowed to do iMIP,
which also sounds wrong.

> Incoming iTIP messages MUST be delivered to an iTIP Inbox collection.

Another dangling MUST.

> 9.1  SCHEDULE Method for WebDAV

> The list of attendees and the organizer information in this request
> body might well be redundant with the values of the Recipient and
> Originator headers.  This is intentional, so that the client can have
> more control over who receives invitations and who sends them:

I think each of the three examples you give is redundant with existing
iCalendar/iTIP functionality:

> o  The client may send invitations to calendar users not on the
>    attendee list (for example, to an assistant, caterer, observer,
>    etc).

They could also be listed as ATTENDEEs with ROLE=NON-PARTICIPANT.

> o  The client may choose not to send invitations to calendar users
>    who are on the attendee list (for example, attendees who have been
>    scheduled through an out-of-band mechanism).

Maybe they could just be listed with PARTSTAT=ACCEPTED? (Maybe not...)

> o  The originator may be different than the organizer, for example an
>    assistant who has calendar-bind privileges on the organizer's
>    calendar.

You can specify that with the SENT-BY property on the ORGANIZER.

> 9.1.1  Status Codes for use with 207 (Multi-Status)

Tying back to the Outbox comments earlier, does every successful
SCHEDULE result in a message being appended to Outbox, even when every
Recipient fails?

Need a little more discussion of the exact scheduling flow. Section 9
mentions "(c) a new method requests fanout of a resource that has
already been uploaded", but the description of SCHEDULE itself doesn't
mention ordering at all, which it probably should. (If you do SCHEDULE
first, then PUT, there's a race condition in that someone else's REPLY
could come in before you PUT the event they're REPLYing to, especially
if there are auto-accepting/rejecting resources on the system.)

OTOH, what's the advantage in doing a PUT to the calendar followed by a
SCHEDULE to the Outbox, rather than just doing a SCHEDULE to the
calendar?

> 202 (Accepted) - The request was accepted, but the server has not
> performed any action with it yet.

What happens if the server returns a 202 and is then unable to complete
the transaction? (Presumably if it *knew* it was going to be able to
succeed, it would have just returned a 200 instead.) Eg, it might return
a 202 if it forwards the request to a remote user via iMIP, but then
what happens if the iMIP message bounces? There doesn't seem to be any
way for the server to inform the client of that.

> 507 (Insufficient Storage) - The server did not have sufficient space
> to record the iTIP message.

"in the Recipient's iTIP Inbox". Presumably if the Originator is over
quota, the SCHEDULE would get back a top-level 507 rather than a 207.

> 9.2.1  Example - Retrieve incoming iTIP Message

The example has an "Originator" header in the response. Is that a bug?
If not, something needs to say explicitly somewhere that that
information is preserved. (And that the Recipient information isn't?
What about in the copy in Outbox?)

> 13.  CalDAV Principal Properties

Many of these properties would be useful (or maybe even necessary) for
resource-type calendars as well, which (according to section 12)
wouldn't have any principal associated with them. Is there any reason
these couldn't be defined on the Calendar or Calendar Container instead
of the Principal?

> 13.3  itip-inbox-URL Property
> 13.4  itip-outbox-URL Property

Both of these are multi-valued... is there any particular behavior
expected of clients in the presence of multiple Inboxes or Outboxes? (If
not, then why can you have more than one?)

> 14.3  calendar-bind Privilege

> Recipient header.  The SCHEDULE request If the server's calendar-bind
> privilege check fails for a given inbox, the rest of the SCHEDULE

I think the "The SCHEDULE request " there is a cut+pasto.

> 15.1  calendar-time-range Report

Need to clarify how free/busy works in CalDAV (probably with an explicit
example). Do you have to request the Vfreebusy component-filter? What
does the response data look like? The text sort of implies that view-
free-busy gives you the ability to ask for and see the dtstart and dtend
of VEVENTs, as opposed to just asking for a time range and getting back
a VFREEBUSY object containing anonymous time ranges.

If the response uses VFREEBUSY, are BUSY-TENTATIVE and BUSY-UNAVAILABLE
periods ever used? (Perhaps the server MAY return BUSY-TENTATIVE periods
corresponding to unprocessed invites, and MAY allow the user to mark a
time period BUSY-UNAVAILABLE?)

> 15.1.2  Response to 'calendar-time-range'

> The response to this report is a WebDAV Multi-Status response,
> containing one <response> element for each event AND for each
> recurrence.  This differs from the PROPFIND response to an event
> collection only in that the relevant recurrences each have their own
> <response> element, not just the master event.

That's sort of ambiguous about whether or not the master event is
returned.

-- Dan

Date: Wed, 29 Sep 2004 10:50:45 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked], Lisa Dusseault <[email-masked]>, CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] Questions on use cases
Cc: 

Hi [email-masked],

--On Tuesday, September 28, 2004 8:16 PM -0400 [email-masked] wrote:

> My favorite candidate for 'helper application', which I once wrote on
> OfficeVision/MVS, a mainframe e-mail/calendaring system, is 'NEXT'. All
> this helper does is look at your calendar and tell you either your next
> event, or the meeting you are currently supposed to be in, if the current
> time is within a certain amount of the start time. This would be helped
> by having DTSTART, at the least, be something searchable.

The question is whether you would want to get that info via webdav 
properties or via a webdav REPORT. There will be a 'time-range' report in 
caldav that you could use to get the same information.

> Alarms without VEVENTs or VTODOs might as well be relegated to cron jobs
> in my opinion - what would be the point of an alarm that goes off just
> because it's "that time"? If you want a reminder without revealing what
> it is ("time to check Ebay!")  leave the text out of the VTODO/VEVENT.

We are not talking about alarms that operate without any reference to a 
VEVENT, but rather the ability to store alarms separately from VEVENTs, but 
have them linked backed to the VEVENT in some way (e.g. via a webdav 
property containing the URL to the event(s)). Lisa's example of having a 
'library' of standard alarms is one case where that would be useful. The 
other is being able to provide per-user private alarms on shared events 
(e.g. user A wants an alarm 5 minutes before, user B wants one 10 minutes 
before). That is hard to do when the alarm data is embedded in the event 
data or when users don't have write access to the event but still want to 
have an alarm for it.

So what are the expected use cases for alarms, particularly in the shared 
calendar case? Do we want to allow per-user private alarms?

-- 
Cyrus Daboo

Date: Tue, 28 Sep 2004 20:16:38 -0400
To: Lisa Dusseault <[email-masked]>, CalDAV DevList <[email-masked]>
From: [email-masked]
Subject: Re: [Ietf-caldav] Questions on use cases
Cc: 

My favorite candidate for 'helper application', which I once wrote on 
OfficeVision/MVS, a mainframe e-mail/calendaring system, is 'NEXT'. All 
this helper does is look at your calendar and tell you either your next 
event, or the meeting you are currently supposed to be in, if the current 
time is within a certain amount of the start time. This would be helped by 
having DTSTART, at the least, be something searchable.

Alarms without VEVENTs or VTODOs might as well be relegated to cron jobs in 
my opinion - what would be the point of an alarm that goes off just because 
it's "that time"? If you want a reminder without revealing what it is 
("time to check Ebay!")  leave the text out of the VTODO/VEVENT.

At 05:20 PM 9/28/04, Lisa Dusseault wrote:
>Bernard, Cyrus & I have had a chance to discuss alarms, property promotion 
>and scheduling some more, and while we have some opinions based on our own 
>respective products, it would be nice to get a wider set of use cases.
>
>Alarms:  The use cases around alarms should help us decide whether each 
>VALARM is "hidden" inside the body of a VEVENT resource, or if alarms are 
>available as properties on VEVENT resources, or as standalone resources.
>   - What are the ways clients want to use alarms?
>   - Is an alarm always treated as part of an event?
>   - Are there clients (actual, planned or envisioned) which would use 
> alarms and not use the rest of the event/todo?
>   - Do clients conceptually "reuse" alarms?  E.g. practically all my 
> alarms could be factored down to one alarm "produce alert and basso sound 
> 15 min before event start".  In other words, most of my VEVENTs could all 
> link to the same VALARM if it were not a subcomponent, but I'm not sure 
> that would be useful.
>
>Property Promotion:  My original design for property promotion assumed 
>that there would be clients that relied on properties heavily or 
>exclusively.  Clients could browse via properties before going to the step 
>of downloading the iCalendar body, or perhaps even do without the body 
>entirely.  However, it's become clear that making the iCalendar body fully 
>redundant is hard.  We'd have to deal with custom iCalendar properties, 
>with alarm sub-components, with multi-valued properties like attendees, 
>and with large properties like attachments.  How worthwhile is it? Should 
>we head towards full property promotion, or towards zero property 
>promotion, or is there some middle ground that actually improves life for 
>clients?  Some of the questions to feed into this:
>   - Are any clients planning to use WebDAV properties for anything 
> besides getting the ETag to do synchronization?  How would you use properties?
>   - Does every client plan to have a full iCalendar parser?  I know that 
> traditional full "calendar client" software will probably have a full 
> iCalendar parser anyway, but are there helper applications that could do 
> features with only a subset of the iCalendar information?
>E.g. a helper application that only cares about start/end times?
>   - Use cases for WebDAV custom properties?
>
>Scheduling:  The content in the draft -02 describing scheduling isn't 
>complete, yet it is probably fairly illustrative of one possible 
>approach.  What are your initial thoughts?  Does anybody have very 
>important use cases that this approach completely fails to address?
>
>Thanks for your input and help in advance,
>
>Lisa
>_______________________________________________
>Ietf-caldav mailing list
>[email-masked]
>http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Tim Hare
Interested Bystander, Non-Inc. 

To: CalDAV DevList <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Date: Tue, 28 Sep 2004 14:20:57 -0700
Subject: [Ietf-caldav] Questions on use cases

Bernard, Cyrus & I have had a chance to discuss alarms, property 
promotion and scheduling some more, and while we have some opinions 
based on our own respective products, it would be nice to get a wider 
set of use cases.

Alarms:  The use cases around alarms should help us decide whether each 
VALARM is "hidden" inside the body of a VEVENT resource, or if alarms 
are available as properties on VEVENT resources, or as standalone 
resources.
   - What are the ways clients want to use alarms?
   - Is an alarm always treated as part of an event?
   - Are there clients (actual, planned or envisioned) which would use 
alarms and not use the rest of the event/todo?
   - Do clients conceptually "reuse" alarms?  E.g. practically all my 
alarms could be factored down to one alarm "produce alert and basso 
sound 15 min before event start".  In other words, most of my VEVENTs 
could all link to the same VALARM if it were not a subcomponent, but 
I'm not sure that would be useful.

Property Promotion:  My original design for property promotion assumed 
that there would be clients that relied on properties heavily or 
exclusively.  Clients could browse via properties before going to the 
step of downloading the iCalendar body, or perhaps even do without the 
body entirely.  However, it's become clear that making the iCalendar 
body fully redundant is hard.  We'd have to deal with custom iCalendar 
properties, with alarm sub-components, with multi-valued properties 
like attendees, and with large properties like attachments.  How 
worthwhile is it? Should we head towards full property promotion, or 
towards zero property promotion, or is there some middle ground that 
actually improves life for clients?  Some of the questions to feed into 
this:
   - Are any clients planning to use WebDAV properties for anything 
besides getting the ETag to do synchronization?  How would you use 
properties?
   - Does every client plan to have a full iCalendar parser?  I know 
that traditional full "calendar client" software will probably have a 
full iCalendar parser anyway, but are there helper applications that 
could do features with only a subset of the iCalendar information?  
E.g. a helper application that only cares about start/end times?
   - Use cases for WebDAV custom properties?

Scheduling:  The content in the draft -02 describing scheduling isn't 
complete, yet it is probably fairly illustrative of one possible 
approach.  What are your initial thoughts?  Does anybody have very 
important use cases that this approach completely fails to address?

Thanks for your input and help in advance,

Lisa 

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Question on caldav-02.txt
Date: Mon, 27 Sep 2004 14:24:36 -0700
To: [email-masked]
Cc: [email-masked]

--Apple-Mail-1--98523782
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed

Thanks, I propose clearing this up for now by removing the offending=20
sentence in 5.3.

The model assumption, for now, is that putting all events in the same=20
collection should make it easier for clients to figure out what's on=20
somebody else's calendar.

Lisa

On Sep 21, 2004, at 7:32 PM, [email-masked] wrote:

>  In 5.2 it says a calendar should contain no more than one events=20
> collection:
>
>  >
>
> > It MUST NOT contain more than one of any
> >=A0=A0 of these specific collections, although
>
> >
>
>  In 5.3 it says a client must be able to handle multiple events=20
> collections:
>
>  >
>
> > Clients MUST be
> >=A0=A0 prepared to identify and navigate multiple event
> collections within a
> >=A0=A0 Calendar
>
> >
>
>  This seems contradictory to me, and possibly needs clearing up?
>
>
>  Tim Hare
>  Interested Bystander, Non-Inc.
> _______________________________________________
> Ietf-caldav mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

--Apple-Mail-1--98523782
Content-Transfer-Encoding: quoted-printable
Content-Type: text/enriched;
	charset=ISO-8859-1

Thanks, I propose clearing this up for now by removing the offending
sentence in 5.3.

The model assumption, for now, is that putting all events in the same
collection should make it easier for clients to figure out what's on
somebody else's calendar.

Lisa

On Sep 21, 2004, at 7:32 PM, [email-masked] wrote:

<excerpt> In 5.2 it says a calendar should contain no more than one
events collection:

 >

<fixed>> It MUST NOT contain more than one of any

>=A0=A0 of these specific collections, although

</fixed>

>

 In 5.3 it says a client must be able to handle multiple events
collections:

 >

<fixed>> Clients MUST be

>=A0=A0 prepared to identify and navigate multiple event

collections within a

>=A0=A0 Calendar

</fixed>

>

 This seems contradictory to me, and possibly needs clearing up?

 Tim Hare

 Interested Bystander, Non-Inc.=20

_______________________________________________

Ietf-caldav mailing list

[email-masked]

http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

</excerpt>=

--Apple-Mail-1--98523782--

Date: Tue, 21 Sep 2004 22:32:21 -0400
To: [email-masked]
From: [email-masked]
Subject: [Ietf-caldav] Question on caldav-02.txt

<html>
<body>
In 5.2 it says a calendar should contain no more than one events
collection:<br><br>
&gt;<br>
<pre>&gt; It MUST NOT contain more than one of any
&gt;&nbsp;&nbsp; of these specific collections, although
</pre>&gt;<br><br>
In 5.3 it says a client must be able to handle multiple events
collections:<br><br>
&gt;<br>
<pre>&gt; Clients MUST be
&gt;&nbsp;&nbsp; prepared to identify and navigate multiple event
collections within a
&gt;&nbsp;&nbsp; Calendar
</pre>&gt;<br><br>
This seems contradictory to me, and possibly needs clearing up?<br>
<x-sigsep><p></x-sigsep>
Tim Hare<br>
Interested Bystander, Non-Inc.</body>
</html>

Date: Tue, 21 Sep 2004 16:27:04 -0400
From: Bernard Desruisseaux <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: [Ietf-caldav] [Fwd: I-D ACTION:draft-dusseault-caldav-02.txt]

This is a multi-part message in MIME format.
--------------010109000808010008060100
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

FYI

-------- Original Message --------
Subject: I-D ACTION:draft-dusseault-caldav-02.txt
Date: Tue, 21 Sep 2004 15:38:09 -0400
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: Calendar Server Extensions for WebDAV (CalDAV)
	Author(s)	: L. Dusseault, et al.
	Filename	: draft-dusseault-caldav-02.txt
	Pages		: 55
	Date		: 2004-9-21
	
In the five years since WebDAV [3] was standardized, at least three
    groups have used WebDAV as a basis to provide Internet calendar
    access with a minimum of development effort.  However, each group
    decided independently how the calendaring data model would map to the
    WebDAV data model and how to deal with features such as recurrance
    and queries for free-busy times.  This draft proposes a standard data
    model mapping and a few extensions to WebDAV that make
    WebDAV-server-based calendaring work well for clients while requiring
    a minimum of new work (particularly on clients).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-dusseault-caldav-02.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-dusseault-caldav-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-dusseault-caldav-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--------------010109000808010008060100
Content-Type: Message/External-body;
 name="draft-dusseault-caldav-02.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-dusseault-caldav-02.txt"

Content-Type: text/plain
Content-ID: <[email-masked]>

--------------010109000808010008060100
Content-Type: text/plain;
	name="file:///C|/DOCUME%7E1/BDESRU%7E1.STE/LOCALS%7E1/TEMP/nsmail.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
	filename="file:///C|/DOCUME%7E1/BDESRU%7E1.STE/LOCALS%7E1/TEMP/nsmail.txt"

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--------------010109000808010008060100--

Date: Wed, 15 Sep 2004 09:08:22 +0200
From: Harrie Hazewinkel <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Requirement for text/calendar to contain BEGIN/END VCALENDAR
Cc: CalDAV DevList <[email-masked]>

Lisa Dusseault wrote:
> Some broader input would be nice on an issue I've been looking at out of 
> band...
> 
>  - If the CalDAV VEVENT resources (the resource that corresponds to a 
> simple event) is of type "text/calendar", then it has to have 
> BEGIN:VCALENDAR and END:VCALENDAR as a wrapper.
>  - If that wrapper exists on every single CalDAV resource it's a bit of 
> constant redundant overhead.

I agree her that it would be redundant. I have build here in I.Net a
prototype of a SyncML -based synchronization server for our calendar
server (CAP-based) and all mobile devices wrap for synchronization the
VEVENT in a VCALENDAR. On its won no real problem, it is required by
mime-type.
 From a synchronization server implementation I handle internally only
the VEVENTs. I do this for conversion/comparison. SyncML is 'item'
oriented and most mobile devices do not combine multiple VEVENTs as
a single item. From the CAP side I can get a number of VEVENTS in a
single request.
Therefore, I had the choice patch up all (multiple enclosed VEVENTS from
the CAP side of strip the 'wrapping' of the 'item' in the SYncML side.
As you say it seems redundant and so the chcoie was made.

> 
> It's not that much overhead, so if we have to keep it to be 
> backward-compatible I think we ought.  The question is, do iCalendar 
> parsers today handle something that is text/calendar and doesn't begin 
> with BEGIN:VCALENDAR? Instead it would just start with BEGIN:VEVENT and
> contain only one VEVENT.  In other words, how forgiving are existing 
> iCalendar parsers in this respect?

It depends I guess, we use the freeassociation/libical from sourceforge.
That library is able to make directly VEVENTS from strings. Honestly,
I believe that many implementation can do that. It sounds to me 
reasonable, because the applications must be able to manipulate the
VEVENT.

However, you have to realize the amount of devices out there that handle
calendar parts. That grows quickly, since almost every mobile telephone 
has a calendar nowadays.

Harrie

Date: Tue, 14 Sep 2004 22:40:32 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked], Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Requirement for text/calendar to contain	BEGIN/END VCALENDAR
Cc: CalDAV DevList <[email-masked]>

Hi Tim,

--On Tuesday, September 14, 2004 9:17 PM -0400 [email-masked] wrote:

> Hmm perhaps there should be a collection for each type of METHOD - one
> collection for PUBLISH items, another for scheduling REQUESTs, etc.

I think that's dividing things too far. What we need is a single collection 
(Inbox) for all incoming iTIP requests - there would be a WebDAV property 
on the actual resources in the collection that exposes the method.

-- 
Cyrus Daboo

Date: Tue, 14 Sep 2004 21:17:14 -0400
To: Lisa Dusseault <[email-masked]>
From: [email-masked]
Subject: Re: [Ietf-caldav] Requirement for text/calendar to contain BEGIN/END VCALENDAR
Cc: CalDAV DevList <[email-masked]>

Hmm perhaps there should be a collection for each type of METHOD - one 
collection for PUBLISH items, another for scheduling REQUESTs, etc.

At 08:37 PM 9/14/04, Lisa Dusseault wrote:
>See, the thing is, there wouldn't be a method.  These are being stored 
>somewhere, they're not requests.    Will existing iCalendar parsers choke 
>if there's no method?
>
>I suppose if there had to be a method it would be PUBLISH, for events 
>stored in the user's calendar.  Even if the event isn't being very widely 
>published, still that's the closest concept.
>
>Lisa
>
>
>On Sep 14, 2004, at 5:29 PM, [email-masked] wrote:
>
>>I don't know how other parsers do it.. but the METHOD property in the 
>>BEGIN: VCALENDAR is an important piece of information: it tells you 
>>whether the object is PUBLISHed or is a REQUEST, REPLY, etc. METHOD only 
>>exists in the VCALENDAR component. If there is a way to "nest" objects 
>>within CalDAV then you can make do with only one VCALENDAR pair per 
>>grouping but otherwise I think you need it.
>>
>>At 06:40 PM 9/14/04, you wrote:
>>>Some broader input would be nice on an issue I've been looking at out of 
>>>band...
>>>
>>>  - If the CalDAV VEVENT resources (the resource that corresponds to a 
>>> simple event) is of type "text/calendar", then it has to have 
>>> BEGIN:VCALENDAR and END:VCALENDAR as a wrapper.
>>>  - If that wrapper exists on every single CalDAV resource it's a bit of 
>>> constant redundant overhead.
>>>
>>>It's not that much overhead, so if we have to keep it to be 
>>>backward-compatible I think we ought.  The question is, do iCalendar 
>>>parsers today handle something that is text/calendar and doesn't begin 
>>>with BEGIN:VCALENDAR?  Instead it would just start with BEGIN:VEVENT and 
>>>contain only one VEVENT.  In other words, how forgiving are existing 
>>>iCalendar parsers in this respect?
>>>
>>>Lisa
>>>
>>>_______________________________________________
>>>Ietf-caldav mailing list
>>>[email-masked]
>>>http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>>
>>Tim Hare
>>Interested Bystander, Non-Inc.

Tim Hare
Interested Bystander, Non-Inc. 

Date: Tue, 14 Sep 2004 20:43:09 -0400
To: [email-masked]
From: [email-masked]
Subject: Fwd: Re: [Ietf-caldav] Requirement for text/calendar to contain BEGIN/END VCALENDAR

>Date: Tue, 14 Sep 2004 20:29:25 -0400
>To: Lisa Dusseault <[email-masked]>
>From: [email-masked]
>Subject: Re: [Ietf-caldav] Requirement for text/calendar to contain 
>BEGIN/END VCALENDAR
>
>I don't know how other parsers do it.. but the METHOD property in the 
>BEGIN: VCALENDAR is an important piece of information: it tells you 
>whether the object is PUBLISHed or is a REQUEST, REPLY, etc. METHOD only 
>exists in the VCALENDAR component. If there is a way to "nest" objects 
>within CalDAV then you can make do with only one VCALENDAR pair per 
>grouping but otherwise I think you need it.
>
>At 06:40 PM 9/14/04, you wrote:
>>Some broader input would be nice on an issue I've been looking at out of 
>>band...
>>
>>  - If the CalDAV VEVENT resources (the resource that corresponds to a 
>> simple event) is of type "text/calendar", then it has to have 
>> BEGIN:VCALENDAR and END:VCALENDAR as a wrapper.
>>  - If that wrapper exists on every single CalDAV resource it's a bit of 
>> constant redundant overhead.
>>
>>It's not that much overhead, so if we have to keep it to be 
>>backward-compatible I think we ought.  The question is, do iCalendar 
>>parsers today handle something that is text/calendar and doesn't begin 
>>with BEGIN:VCALENDAR?  Instead it would just start with BEGIN:VEVENT and 
>>contain only one VEVENT.  In other words, how forgiving are existing 
>>iCalendar parsers in this respect?
>>
>>Lisa
>>
>>_______________________________________________
>>Ietf-caldav mailing list
>>[email-masked]
>>http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>
>Tim Hare
>Interested Bystander, Non-Inc.

Tim Hare
Interested Bystander, Non-Inc. 

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Requirement for text/calendar to contain BEGIN/END VCALENDAR
Date: Tue, 14 Sep 2004 17:37:24 -0700
To: [email-masked]
Cc: CalDAV DevList <[email-masked]>

See, the thing is, there wouldn't be a method.  These are being stored 
somewhere, they're not requests.    Will existing iCalendar parsers 
choke if there's no method?

I suppose if there had to be a method it would be PUBLISH, for events 
stored in the user's calendar.  Even if the event isn't being very 
widely published, still that's the closest concept.

Lisa

On Sep 14, 2004, at 5:29 PM, [email-masked] wrote:

> I don't know how other parsers do it.. but the METHOD property in the 
> BEGIN: VCALENDAR is an important piece of information: it tells you 
> whether the object is PUBLISHed or is a REQUEST, REPLY, etc. METHOD 
> only exists in the VCALENDAR component. If there is a way to "nest" 
> objects within CalDAV then you can make do with only one VCALENDAR 
> pair per grouping but otherwise I think you need it.
>
> At 06:40 PM 9/14/04, you wrote:
>> Some broader input would be nice on an issue I've been looking at out 
>> of band...
>>
>>  - If the CalDAV VEVENT resources (the resource that corresponds to a 
>> simple event) is of type "text/calendar", then it has to have 
>> BEGIN:VCALENDAR and END:VCALENDAR as a wrapper.
>>  - If that wrapper exists on every single CalDAV resource it's a bit 
>> of constant redundant overhead.
>>
>> It's not that much overhead, so if we have to keep it to be 
>> backward-compatible I think we ought.  The question is, do iCalendar 
>> parsers today handle something that is text/calendar and doesn't 
>> begin with BEGIN:VCALENDAR?  Instead it would just start with 
>> BEGIN:VEVENT and contain only one VEVENT.  In other words, how 
>> forgiving are existing iCalendar parsers in this respect?
>>
>> Lisa
>>
>> _______________________________________________
>> Ietf-caldav mailing list
>> [email-masked]
>> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>
> Tim Hare
> Interested Bystander, Non-Inc.
>

Date: Tue, 14 Sep 2004 18:36:40 -0600
From: Doug Royer <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] Requirement for text/calendar to contain BEGIN/END VCALENDAR
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: CalDAV DevList <[email-masked]>
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-caldav>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Wed, 15 Sep 2004 00:37:00 -0000

This is a cryptographically signed message in MIME format.

--------------ms040307020808070503060904
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Lisa Dusseault wrote:

> Some broader input would be nice on an issue I've been looking at out 
> of band...
>
>  - If the CalDAV VEVENT resources (the resource that corresponds to a 
> simple event) is of type "text/calendar", then it has to have 
> BEGIN:VCALENDAR and END:VCALENDAR as a wrapper.
>  - If that wrapper exists on every single CalDAV resource it's a bit 
> of constant redundant overhead.
>
> It's not that much overhead, so if we have to keep it to be 
> backward-compatible I think we ought.  The question is, do iCalendar 
> parsers today handle something that is text/calendar and doesn't begin 
> with BEGIN:VCALENDAR?  Instead it would just start with BEGIN:VEVENT 
> and contain only one VEVENT.  In other words, how forgiving are 
> existing iCalendar parsers in this respect?

This in a slightly different format came up on the CALSIFY mailing list.

Some of the properties (METHOD  for example ) exist only outside
of a VEVENT.  When needed it would force the BEGIN/END VCALENDAR
tags. Sometimes or not sometimes would be a little flaky.

Many implementions toss data before a BEGIN VCALENDAR
and after a END VCALENDAR assuming it is MIME noise.
Its kind of a poor mans ical/mime parser.

At least one vendor wrapps each and every VEVENT with a BEGIN/END VCALENDAR.
Another vendor only allows one BEGIN/END VCALENDAR per mime object.

I would recomment that this list not re-invent iCAL or CALSIFY except
when unique to CALDAV, else we are going to have multiple was to
do the same thing again.

I am not sure which way CALSIFY is going.  I am hoping one BEGIN/END 
VCALENDAR
per unique METHOD  so that existing parsers work and are reusable for iMIP.

And in keeping with iMIP only ONE BEGIN/END VCALENDAR per unique METHOD .
Which is the same as one and only one BEGIN/END VCALENDAR per MIME object.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)520-4044
http://Royer.com/People/Doug   | Fax:    (866)594-8574
                               | Cell:   (208)520-4044

              We Do Standards - You Need Standards

--------------ms040307020808070503060904
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms040307020808070503060904--

To: CalDAV DevList <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Date: Tue, 14 Sep 2004 15:40:25 -0700
Subject: [Ietf-caldav] Requirement for text/calendar to contain BEGIN/END VCALENDAR

Some broader input would be nice on an issue I've been looking at out 
of band...

  - If the CalDAV VEVENT resources (the resource that corresponds to a 
simple event) is of type "text/calendar", then it has to have 
BEGIN:VCALENDAR and END:VCALENDAR as a wrapper.
  - If that wrapper exists on every single CalDAV resource it's a bit of 
constant redundant overhead.

It's not that much overhead, so if we have to keep it to be 
backward-compatible I think we ought.  The question is, do iCalendar 
parsers today handle something that is text/calendar and doesn't begin 
with BEGIN:VCALENDAR?  Instead it would just start with BEGIN:VEVENT 
and contain only one VEVENT.  In other words, how forgiving are 
existing iCalendar parsers in this respect?

Lisa

Date: Tue, 07 Sep 2004 13:02:36 -0400
From: Bernard Desruisseaux <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] Creating a calendar

Tim,

You must be talking of "Calendar Attributes for vCard and LDAP":

http://www.ietf.org/rfc/rfc2739.txt

Cheers,
Bernard

[email-masked] wrote:

> I think, myself, that this should be a property in a user's directory 
> entry in some directory accessible via LDAP. I believe one of the 
> iCalendar RFCs referenced doing this, although a cursory search of RFC 
> 2445 only references using LDAP in a component property, rather than 
> using LDAP to locate user calendars. In any case, it is very desirable 
> to be able to use directory search to find the user's calendar.
> 
> 
> 
> At 12:49 PM 8/27/04, Elias Sinderson wrote:
> 
>> Lisa Dusseault wrote:
>>
>>> I also like the idea of looking at the principal resource to find out 
>>> more information like where the user's calendar is homed, where the 
>>> user's other file sharing space can be found, etc.  CalDAV would only 
>>> have to define a property on the principal resource for this to work 
>>> [...]
>>
>>
>> +1 - simple and elegant.
>>
>> Cyrus Daboo wrote:
>>
>>> Lisa Dusseault wrote:
>>>
>>>> When a user logs in, the ACL standard defines a REPORT to ask "who 
>>>> am I".
>>>> With that report the client gets the mapping from the user's login 
>>>> ID to
>>>> a principal URL.
>>>
>>>
>>> But that does not help locating calendars for resources that are not 
>>> associated with a principal e.g. public calendars, calendars for 
>>> meeting rooms etc One could argue that you could use DASL to find 
>>> those things, but I think having a NAMESPACE report would be better.
>>
>>
>> Presumably these resources could also be located via other means 
>> (links from a corporate intranet web site, group homepage, etc.). As 
>> long as a client provides a way for a user to enter in the location of 
>> a calendar the issue is somewhat moot. I do support the notion of 
>> automatic / programmatic location of calendar resources, however I 
>> don't believe that it necessarily entails the creation of a new report 
>> type.
>>
>> You are completely correct in that DASL is general enough to support 
>> this use case - can you explain why you believe that the report 
>> approach is somehow better? IMHO, using DASL for calendar resource 
>> discovery makes perfect sense and wouldn't put an inordinate amount of 
>> load on a server, considering that the discovery process would only 
>> happen infrequently at worst and only a few times per user / client at 
>> best (on a given server).
>>
>>
>> Cheers,
>> Elias
>> _______________________________________________
>> Ietf-caldav mailing list
>> [email-masked]
>> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
> 
> 
> Tim Hare
> Interested Bystander, Non-Inc.
> 
> _______________________________________________
> Ietf-caldav mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Creating a calendar
Date: Tue, 7 Sep 2004 09:55:58 -0700
To: [email-masked]
Cc: CalDAV DevList <[email-masked]>

Typically the WebDAV "principal resources" are actually reflections of 
LDAP data.  For example, if you have Xythos WebFile Server, when a 
query to a principal resource like 
"http://example.org/users/ldusseault" is handled by the WebDAV server, 
it can actually make a live request to the LDAP server to get the 
user's display name or other information, before responding to the HTTP 
request.

The reasoning behind the design of "principal resources" in the first 
place was to keep HTTP/WebDAV clients from having to implement LDAP in 
order to find users to set access control; also to keep from requiring 
sites that use WebDAV from necessarily having to include LDAP in the 
architecture.  The existence of principal resources means that a site 
that doesn't use LDAP can get the user data from another source without 
having to change HTTP/WebDAV client implementations.

All this is not mutually exclusive with using LDAP to locate user 
calendars, but it does make LDAP less of a requirement.

Lisa

On Sep 7, 2004, at 7:38 AM, [email-masked] wrote:

> I think, myself, that this should be a property in a user's directory 
> entry in some directory accessible via LDAP. I believe one of the 
> iCalendar RFCs referenced doing this, although a cursory search of RFC 
> 2445 only references using LDAP in a component property, rather than 
> using LDAP to locate user calendars. In any case, it is very desirable 
> to be able to use directory search to find the user's calendar.
>
>
>
> At 12:49 PM 8/27/04, Elias Sinderson wrote:
>> Lisa Dusseault wrote:
>>
>>> I also like the idea of looking at the principal resource to find 
>>> out more information like where the user's calendar is homed, where 
>>> the user's other file sharing space can be found, etc.  CalDAV would 
>>> only have to define a property on the principal resource for this to 
>>> work [...]
>>
>> +1 - simple and elegant.
>>
>> Cyrus Daboo wrote:
>>
>>> Lisa Dusseault wrote:
>>>
>>>> When a user logs in, the ACL standard defines a REPORT to ask "who 
>>>> am I".
>>>> With that report the client gets the mapping from the user's login 
>>>> ID to
>>>> a principal URL.
>>>
>>> But that does not help locating calendars for resources that are not 
>>> associated with a principal e.g. public calendars, calendars for 
>>> meeting rooms etc One could argue that you could use DASL to find 
>>> those things, but I think having a NAMESPACE report would be better.
>>
>> Presumably these resources could also be located via other means 
>> (links from a corporate intranet web site, group homepage, etc.). As 
>> long as a client provides a way for a user to enter in the location 
>> of a calendar the issue is somewhat moot. I do support the notion of 
>> automatic / programmatic location of calendar resources, however I 
>> don't believe that it necessarily entails the creation of a new 
>> report type.
>>
>> You are completely correct in that DASL is general enough to support 
>> this use case - can you explain why you believe that the report 
>> approach is somehow better? IMHO, using DASL for calendar resource 
>> discovery makes perfect sense and wouldn't put an inordinate amount 
>> of load on a server, considering that the discovery process would 
>> only happen infrequently at worst and only a few times per user / 
>> client at best (on a given server).
>>
>>
>> Cheers,
>> Elias
>> _______________________________________________
>> Ietf-caldav mailing list
>> [email-masked]
>> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>
> Tim Hare
> Interested Bystander, Non-Inc.
>
> _______________________________________________
> Ietf-caldav mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Tue, 07 Sep 2004 10:38:10 -0400
To: CalDAV DevList <[email-masked]>
From: [email-masked]
Subject: Re: [Ietf-caldav] Creating a calendar

I think, myself, that this should be a property in a user's directory entry 
in some directory accessible via LDAP. I believe one of the iCalendar RFCs 
referenced doing this, although a cursory search of RFC 2445 only 
references using LDAP in a component property, rather than using LDAP to 
locate user calendars. In any case, it is very desirable to be able to use 
directory search to find the user's calendar.

At 12:49 PM 8/27/04, Elias Sinderson wrote:
>Lisa Dusseault wrote:
>
>>I also like the idea of looking at the principal resource to find out 
>>more information like where the user's calendar is homed, where the 
>>user's other file sharing space can be found, etc.  CalDAV would only 
>>have to define a property on the principal resource for this to work [...]
>
>+1 - simple and elegant.
>
>Cyrus Daboo wrote:
>
>>Lisa Dusseault wrote:
>>
>>>When a user logs in, the ACL standard defines a REPORT to ask "who am I".
>>>With that report the client gets the mapping from the user's login ID to
>>>a principal URL.
>>
>>But that does not help locating calendars for resources that are not 
>>associated with a principal e.g. public calendars, calendars for meeting 
>>rooms etc One could argue that you could use DASL to find those things, 
>>but I think having a NAMESPACE report would be better.
>
>Presumably these resources could also be located via other means (links 
>from a corporate intranet web site, group homepage, etc.). As long as a 
>client provides a way for a user to enter in the location of a calendar 
>the issue is somewhat moot. I do support the notion of automatic / 
>programmatic location of calendar resources, however I don't believe that 
>it necessarily entails the creation of a new report type.
>
>You are completely correct in that DASL is general enough to support this 
>use case - can you explain why you believe that the report approach is 
>somehow better? IMHO, using DASL for calendar resource discovery makes 
>perfect sense and wouldn't put an inordinate amount of load on a server, 
>considering that the discovery process would only happen infrequently at 
>worst and only a few times per user / client at best (on a given server).
>
>
>Cheers,
>Elias
>_______________________________________________
>Ietf-caldav mailing list
>[email-masked]
>http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Tim Hare
Interested Bystander, Non-Inc.