Subject: [Ietf-caldav] Meeting in Washingon, DC?
From: Lisa Dusseault <[email-masked]>
To: CalDAV DevList <[email-masked]>
Date: Fri, 22 Oct 2004 12:32:43 -0700
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>

I'm going to be in Washington, DC at the IETF this year, doing WebDAV 
and IMAPEXT among other things.  Who else is going to be there, and who 
else wants to get together to see if we can nail out any issues in 
CalDAV?  Reply to me with preferred times or anti-preferred times and 
I'll try to coordinate....

Lisa

To: CalDAV DevList <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Date: Tue, 19 Oct 2004 09:59:34 -0700
Subject: [Ietf-caldav] Fwd: CalDAV implementations

--Apple-Mail-9--361109398
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

I thought I'd forward this to the CalDAV list as it has a bunch of 
useful comments.  One of the next things I plan to work on his how to 
create calendar collections and whether or not one can delete them.

Lisa

Begin forwarded message:

> From: James Mason <[email-masked]>
> Date: October 19, 2004 12:09:31 AM PDT
> To: Slide Developers Mailing List <[email-masked]>
> Subject: Re: CalDAV implementations
> Reply-To: "Slide Developers Mailing List" 
> <[email-masked]>
>
> Lisa,
>
> Here's some feedback on what I think it would take to build a CalDAV
> server on top of Slide. I'll be referencing parts of the spec here.
>
>
>
> "5 - CalDAV defines the following new resource types for use in 
> calendar
> repositories"
>
> Some of these will take more work than others. None seem too hard, but
> some have some rather odd requirements that need clarification. For
> instance, should itip-inbox collections inside calendars that are not
> inside of calendar-collections be deleteable?
>
> "5.7 - CalDAV server is responsible for parsing incoming REPLY messages
> and adding attendee information to events."
>
> This should be doable. Slide has a nice event framework that should
> simplify this type of requirement.
>
> "7 - In addition, certain properties are required on calendars to link
> to principal resources."
> -and-
> "13 - All these properties SHOULD exist on every principal if the 
> server
> supports CalDAV anywhere in its namespace."
>
> This one could be a problem. Slide doesn't treat user stores any
> different from file stores, so the properties available for a 
> particular
> resource are dependent on the capabilities of the backend Store. For
> instance, Slide can use LDAP for storing users, so to be CalDAV
> compliant the LDAP repository would have to be modified to expose the
> necessary properties to Slide. Since this isn't something Slide can
> guarantee, this could be an issue.
>
> "8 - Since a calendar resource of type text/calendar has properties
> which duplicate some of its internal state, it's the server's
> responsibility to keep those consistent somehow."
>
> Again, the event framework should help with this, and Slide already has
> some support for parsing internal properties of uploaded documents. 
> What
> would be really helpful is an iCal library written in Java with a
> license that's useable by the ASF. That would save a lot of time,
> especially if Slide implements a CalDAV client API.
>
> "9.1 - SCHEDULE Method for WebDAV"
>
> The only really complicated thing here is fanout, I think. There's a 
> lot
> to scheduling, though, so this is a big chunk to handle.
>
> "14 - A CalDAV server MUST also support the set of calendar-specific
> privileges defined in this section."
>
> Slide's security implementation is extensible, so I don't see any big
> barrier to this other than the work required to support more 
> complicated
> privileges (such as view-free-busy).
>
> "15 - This section defines the reports which a CalDAV server MUST
> support."
>
> Other than handling recurrences this isn't particularly bad, it's just
> going to be a bit of work.
>
>
>
> That's about it. Sorry it took so long to get this reply out (that's a
> rather long document you've put together ;) ). Here are a few things
> that I think would help encourage a Slide CalDAV server:
>
> 1. A working client, especially a test suite. It's going to be hard to
> verify functionality otherwise. On a personal note, I use Evolution at
> home and Groupwise at work, so if you can get Novell to support this
> (especially with Groupwise) I'd be much more inspired to work on it :).
>
> 2. An iCal library. A lot of the functionality required by the spec
> involves parsing and modifying iCal files, so it would speed things if
> there was an existing piece of work here.
>
> 3. Another developer or two. I'm interested in this because I like the
> topic and I think it's a good thing to do, however I don't have an itch
> to scratch here. Unless someone else can pick this up too I doubt I'll
> have the time to implement anything useful.
>
> -James
>
> On Fri, 2004-10-15 at 16:01, Lisa Dusseault wrote:
>> I'm doing some investigation of possible open source server
>> implementations of CalDAV
>> <http://www.ietf.org/internet-drafts/draft-dusseault-caldav-02.txt>.
>>
>>    - In the commercial area we've seen implementations started by 
>> Oracle
>> and definite interest by IBM.
>>    - In open source, Redhat is considering working on it sometime 
>> soon,
>> as is University of Washington, but as far as I know they haven't
>> started yet.
>>
>> Has anybody thought of adding this to Slide? It's a natural fit since
>> the biggest requirement for CalDAV is support for WebDAV  + ACL.
>>
>> Lisa
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email-masked]
> For additional commands, e-mail: [email-masked]
>

--Apple-Mail-9--361109398
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

I thought I'd forward this to the CalDAV list as it has a bunch of
useful comments.  One of the next things I plan to work on his how to
create calendar collections and whether or not one can delete them.

Lisa

Begin forwarded message:

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

<bold><color><param>0000,0000,0000</param>Date: </color></bold>October
19, 2004 12:09:31 AM PDT

<bold><color><param>0000,0000,0000</param>To: </color></bold>Slide
Developers Mailing List <<[email-masked]>

<bold><color><param>0000,0000,0000</param>Subject: </color>Re: CalDAV
implementations

<color><param>0000,0000,0000</param>Reply-To: </color></bold>"Slide
Developers Mailing List" <<[email-masked]>

Lisa,

Here's some feedback on what I think it would take to build a CalDAV

server on top of Slide. I'll be referencing parts of the spec here.

"5 - CalDAV defines the following new resource types for use in
calendar

repositories"

Some of these will take more work than others. None seem too hard, but

some have some rather odd requirements that need clarification. For

instance, should itip-inbox collections inside calendars that are not

inside of calendar-collections be deleteable?

"5.7 - CalDAV server is responsible for parsing incoming REPLY messages

and adding attendee information to events."

This should be doable. Slide has a nice event framework that should

simplify this type of requirement.

"7 - In addition, certain properties are required on calendars to link

to principal resources."

-and-

"13 - All these properties SHOULD exist on every principal if the
server

supports CalDAV anywhere in its namespace."

This one could be a problem. Slide doesn't treat user stores any

different from file stores, so the properties available for a
particular

resource are dependent on the capabilities of the backend Store. For

instance, Slide can use LDAP for storing users, so to be CalDAV

compliant the LDAP repository would have to be modified to expose the

necessary properties to Slide. Since this isn't something Slide can

guarantee, this could be an issue.

"8 - Since a calendar resource of type text/calendar has properties

which duplicate some of its internal state, it's the server's

responsibility to keep those consistent somehow."

Again, the event framework should help with this, and Slide already has

some support for parsing internal properties of uploaded documents.
What

would be really helpful is an iCal library written in Java with a

license that's useable by the ASF. That would save a lot of time,

especially if Slide implements a CalDAV client API.

"9.1 - SCHEDULE Method for WebDAV"

The only really complicated thing here is fanout, I think. There's a
lot

to scheduling, though, so this is a big chunk to handle.

"14 - A CalDAV server MUST also support the set of calendar-specific

privileges defined in this section."

Slide's security implementation is extensible, so I don't see any big

barrier to this other than the work required to support more
complicated

privileges (such as view-free-busy).

"15 - This section defines the reports which a CalDAV server MUST

support."

Other than handling recurrences this isn't particularly bad, it's just

going to be a bit of work.

That's about it. Sorry it took so long to get this reply out (that's a

rather long document you've put together ;) ). Here are a few things

that I think would help encourage a Slide CalDAV server:

1. A working client, especially a test suite. It's going to be hard to

verify functionality otherwise. On a personal note, I use Evolution at

home and Groupwise at work, so if you can get Novell to support this

(especially with Groupwise) I'd be much more inspired to work on it :).

2. An iCal library. A lot of the functionality required by the spec

involves parsing and modifying iCal files, so it would speed things if

there was an existing piece of work here.

3. Another developer or two. I'm interested in this because I like the

topic and I think it's a good thing to do, however I don't have an itch

to scratch here. Unless someone else can pick this up too I doubt I'll

have the time to implement anything useful.

-James

On Fri, 2004-10-15 at 16:01, Lisa Dusseault wrote:

<excerpt>I'm doing some investigation of possible open source server

implementations of CalDAV

<<http://www.ietf.org/internet-drafts/draft-dusseault-caldav-02.txt>.

   - In the commercial area we've seen implementations started by
Oracle

and definite interest by IBM.

   - In open source, Redhat is considering working on it sometime soon,

as is University of Washington, but as far as I know they haven't

started yet.

Has anybody thought of adding this to Slide? It's a natural fit since

the biggest requirement for CalDAV is support for WebDAV  + ACL.

Lisa

</excerpt>

---------------------------------------------------------------------

To unsubscribe, e-mail: [email-masked]

For additional commands, e-mail: [email-masked]

</excerpt>
--Apple-Mail-9--361109398--

From: Michael R Gettes <[email-masked]>
Subject: Re: [Ietf-calsify] RE: [Ietf-caldav] comments on -02
Date: Mon, 11 Oct 2004 19:54:24 -0400
To: "Cameron Stillion" <[email-masked]>
Cc: [email-masked], [email-masked]

Is it reasonable to suggest community based ical or task
oriented ical?  People oriented systems might be able to
limit one set of abilities within the spec whereas others,
such as computing clusters and other areas, could use
forms of ical that allow them to their jobs as well.
Creating namespaces for ical specifications would seem
to be a logical thing to do.  Well known namespaces have
well defined specs and uses -- this allows for local
namespaces to implement other aspects of ical.

Just a thought...

/mrg

On Oct 11, 2004, at 19:30, Cameron Stillion wrote:

>
> I respectfully disagree.  Leaving a standard "as open as possible" can
> easily lead to such difficulties in interoperability as we have all
> witnessed over the past several years.  The idea for calsify, I 
> believe,
> is to actually curb the open-ended nature of iCal in favor of the more
> practical bottom line: something that works for a subset that we really
> really care about.
>
> This is not uncommon in software development, it's just that iCal is
> long due for such a refocus and simplification.  It's not so much a
> matter of Social Restrictions - it's just that the kinds of systems we
> are creating have a general purpose to them, and it is centered around
> creating calendars, sharing calendars, scheduling meetings, and other
> simple day-to-day things.  Aligning stellar cartography hardware and
> synchronizing atomic clocks are most definitely on the ragged outer 
> edge
> of our target.
>
> This is not to say we should paint ourselves into a corner in the most
> fundamental ways, but it does mean we need to start small, get 
> something
> basic that we all can agree to, grow some real interoperability, and
> THEN we can start tinkering with how to extend the standard to the
> zillion other applications and possibilities.
>
> As for your specific example -- "granularity", I can easily see a
> property emerge in a future version of iCal that specified 
> sub-15-minute
> granularity.  This would not break clients who didn't care (most of
> them, IMHO) and would be easily read and interpreted by those who did.
>
> Let's avoid getting wrapped around the axle of creating "the perfect
> calendaring standard" - I'm just hoping we can get something simple 
> that
> kind of works without too much pain and suffering.
>
>
> Cameron
>
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Lyndon
> Nerenberg
> Sent: Saturday, October 09, 2004 9:57 PM
> To: [email-masked]; [email-masked];
> [email-masked]
> Subject: [Ietf-calsify] RE: [Ietf-caldav] comments on -02
>
> --On 2004-10-6 10:25 PM -0400 [email-masked] wrote:
>
>> my view is that we ought to establish a standard for the granularity
>> of a free/busy time map (15 minutes would be my choice)
>
> I disagree with this. Calendaring is much more than just scheduling
> meetings (with people). I can see using iCal and friends to schedule
> runtime on computing clusters, or access to radio astronomy telescopes,
> or many other resources where fine-grained access times are 
> appropriate.
> We should not be placing any form of social restrictions on the
> protocols like this. They must be left as open ended as possible so as
> to preclude us having to revisit the specifications in the near term
> because we didn't anticipate a use for them.
>
> --lyndon
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
> _______________________________________________
> Ietf-caldav mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] RE: [Ietf-caldav] comments on -02
Date: Mon, 11 Oct 2004 16:30:10 -0700
From: "Cameron Stillion" <[email-masked]>
To: "Lyndon Nerenberg" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: 

I respectfully disagree.  Leaving a standard "as open as possible" can
easily lead to such difficulties in interoperability as we have all
witnessed over the past several years.  The idea for calsify, I believe,
is to actually curb the open-ended nature of iCal in favor of the more
practical bottom line: something that works for a subset that we really
really care about.

This is not uncommon in software development, it's just that iCal is
long due for such a refocus and simplification.  It's not so much a
matter of Social Restrictions - it's just that the kinds of systems we
are creating have a general purpose to them, and it is centered around
creating calendars, sharing calendars, scheduling meetings, and other
simple day-to-day things.  Aligning stellar cartography hardware and
synchronizing atomic clocks are most definitely on the ragged outer edge
of our target.   

This is not to say we should paint ourselves into a corner in the most
fundamental ways, but it does mean we need to start small, get something
basic that we all can agree to, grow some real interoperability, and
THEN we can start tinkering with how to extend the standard to the
zillion other applications and possibilities.

As for your specific example -- "granularity", I can easily see a
property emerge in a future version of iCal that specified sub-15-minute
granularity.  This would not break clients who didn't care (most of
them, IMHO) and would be easily read and interpreted by those who did.  

Let's avoid getting wrapped around the axle of creating "the perfect
calendaring standard" - I'm just hoping we can get something simple that
kind of works without too much pain and suffering.

Cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Lyndon
Nerenberg
Sent: Saturday, October 09, 2004 9:57 PM
To: [email-masked]; [email-masked];
[email-masked]
Subject: [Ietf-calsify] RE: [Ietf-caldav] comments on -02

--On 2004-10-6 10:25 PM -0400 [email-masked] wrote:

> my view is that we ought to establish a standard for the granularity 
> of a free/busy time map (15 minutes would be my choice)

I disagree with this. Calendaring is much more than just scheduling
meetings (with people). I can see using iCal and friends to schedule
runtime on computing clusters, or access to radio astronomy telescopes,
or many other resources where fine-grained access times are appropriate.
We should not be placing any form of social restrictions on the
protocols like this. They must be left as open ended as possible so as
to preclude us having to revisit the specifications in the near term
because we didn't anticipate a use for them.

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

Date: Sun, 10 Oct 2004 08:50:55 -0400
To: Lyndon Nerenberg <[email-masked]>, [email-masked], [email-masked]
From: [email-masked]
Subject: RE: [Ietf-caldav] comments on -02
Cc: 

After several comments, I can see that exchanging a "bit map" of free/busy 
time has definite downsides,  so let's drop that idea.
Also, rather than continuing to cross-post I will put further discussion of 
how to simplify free/busy work  on the calsify list rather than caldav.

Tim Hare
Interested Bystander, Non-Inc. 

Date: Sat, 09 Oct 2004 21:57:02 -0700
From: Lyndon Nerenberg <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: RE: [Ietf-caldav] comments on -02
Cc: 

--On 2004-10-6 10:25 PM -0400 [email-masked] wrote:

> my view is that we ought to establish a standard for the granularity
> of a free/busy time map (15 minutes would be my choice)

I disagree with this. Calendaring is much more than just scheduling 
meetings (with people). I can see using iCal and friends to schedule 
runtime on computing clusters, or access to radio astronomy telescopes, 
or many other resources where fine-grained access times are 
appropriate. We should not be placing any form of social restrictions 
on the protocols like this. They must be left as open ended as possible 
so as to preclude us having to revisit the specifications in the near 
term because we didn't anticipate a use for them.

--lyndon

Date: Thu, 07 Oct 2004 11:36:10 -0600
From: Doug Royer <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [Ietf-caldav] comments on -02
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.45
Cc: 
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [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: Thu, 07 Oct 2004 17:36:17 -0000

This is a cryptographically signed message in MIME format.

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

Lisa Dusseault wrote:

> I don't see why a bit map has any advantages over a free busy summary 
> with begin/end times for each busy blocks.  And the begin/end 
> timestamps have some advantages: they're human-readable (or at least 
> developer/debugger readable), and don't require us to choose an 
> arbitrary maximum granularity (why fifteen minutes? why not five? 
> one?  Can I negotiate granularity?).

I agree. VFREEBUSY is already in effect a bit map represented in ASCII.

>
> ...

-- 

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

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

--------------ms070409010101090702000600--

Date: Thu, 07 Oct 2004 08:40:00 +0200
From: Julian Reschke <[email-masked]>
To: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] comments on -02 (creating items)
Cc: CalDAV DevList <[email-masked]>

Helge Hess wrote:
> ...
> Yes, I know. This wasn't my point. I expect that CalDAV will be used to 
> expose legacy systems which implies that it needs to deal with the above 
> situation (object naming done by the server).
> I wanted to know whether a regular WebDAV client is supposed to be able 
> to deal with the above sequence (and in turn, CalDAV).

In this case, a regular WebDAV client is just an HTTP client (PUT is 
defined in RFC2616, and WebDAV doesn't modify it's semantics). A 
properly written client *should* go back to the user, display the 
redirect target and ask whether (s)he wants to write to that URL 
instead. I'm not sure anybody is doing that, though.

Another approach may be to actually allow the PUT, but to return a 
Location header in the response that contains the actual URL. Again, I 
doubt many clients will expect this.

If this is a scenario that needs to be taken care, it seems there should 
be a specific protocol extension for it (possibly in a separate spec).

> Eg one example Dan already brought up (and which I always wanted to 
> implement ;-), is the Bugzilla/WebDAV gateway. You certainly want to 
> have the bug ids as the "filenames".

(sounds interesting)

> ...

Best regards, Julian

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

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] comments on -02
Date: Wed, 6 Oct 2004 20:44:18 -0700
To: [email-masked]
Cc: [email-masked], [email-masked]

I don't see why a bit map has any advantages over a free busy summary 
with begin/end times for each busy blocks.  And the begin/end 
timestamps have some advantages: they're human-readable (or at least 
developer/debugger readable), and don't require us to choose an 
arbitrary maximum granularity (why fifteen minutes? why not five? one?  
Can I negotiate granularity?).

The calendar agent can always translate begin/end times into a bitmap 
for summarization -- that's implementation-dependent.

I have a prejudice against binary formats, too :)

Lisa

On Oct 6, 2004, at 7:25 PM, [email-masked] wrote:

> Free/Busy is a property of the user/owner of the calendar more than 
> anything else; in essence I really want a logical AND of all of my 
> free/busy time so that none of my events, personal or business, get 
> overbooked. In iCalendar, however, we have to represent those at the 
> VCALENDAR level.  I am cross-posting this to the calsify list, because 
> it really belongs there - my view is that we ought to establish a 
> standard for the granularity of a free/busy time map (15 minutes would 
> be my choice), and then just exchange a "bit map" of the time between 
> two dates that are requested as the endpoints - call it a VBUSYMAP 
> deliverable as other binary objects are, in Base64.  Then, scheduling 
> a meeting might go something like this:
>
> Organizer to each attendee: Show me your free/busy map between date X 
> and date Y.
> Each attendee: here is the VBUSYMAP of my time
> Organizer then finds (hopefully) a time when all are free, and sends 
> out meeting requests for that time;or, finding no acceptable time, 
> picks two different dates and tries again.
>
> This, to me, simplifies and shortens the scheduling process. Your code 
> doesn't have to parse all of the VFREEBUSY items. In fact, an 
> implementation can choose to maintain the map in whatever backing 
> store it uses, and keep it updated as VEVENTS are added or removed.
>
> At 08:36 PM 10/6/04, Cameron Stillion wrote:
>> But if you don't want to be scheduled, that means you want the time to
>> appear as if you are "scheduled" already... Right?  You can do this 
>> now
>> by putting an appointment on your calendar marked as "OOF" - and the
>> free/busy view of this event will clearly mark this as already taken.
>>
>> Having someone schedule you on Saturday or Sunday is really a social
>> problem though. If it is your wife, it makes sense.  If it's your
>> co-worker, then there are social checks and balances that say this 
>> won't
>> happen if it isn't appropriate.  The protocol is not meant to solve 
>> the
>> social aspect.  Clearly good software would keep this in mind and help
>> you do the right thing, but it can't know all the human 
>> implications...
>>
>> I still stand by the fact that free/busy is merely a translation of
>> events, and that anything else is unnecessarily complex with really no
>> benefit - to the standard most especially, but even more to 
>> applications
>> and systems.
>>
>>
>> cameron
>>
>>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of G. Barnes
>> Sent: Wednesday, October 06, 2004 10:26 AM
>> To: [email-masked]
>> Subject: Re: [Ietf-caldav] comments on -02
>>
>> On Wed, 6 Oct 2004, Lisa Dusseault wrote:
>>
>> > I could go either way on allowing users to store standalone 
>> VFREEBUSY
>> > components.  Keeping it is a small feature/flexibility; removing it 
>> is
>>
>> > a small simplification.  Who else has use cases or problems with
>> > keeping or removing that feature?
>>
>> I have a problem with removing it.  I want to be able to say, 'no one
>> can schedule me on Saturday or Sunday' (among other times).  Othewise,
>> some jerk is going to schedule a mandatory meeting at 7am Saturday.
>> Creating a VEVENT would presumably mean something shows up in my
>> calendar.
>> But I don't necessarily have an event scheduled; I just want to be 
>> left
>> alone.  The most obvious way to do this is to create a standalone
>> VFREEBUSY.
>>
>>                    Greg Barnes
>>                    Computing and Communications, University of
>> Washington
>>                    [email-masked]
>>                    (206) 685-3295
>> _______________________________________________
>> Ietf-caldav mailing list
>> [email-masked]
>> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>>
>> _______________________________________________
>> 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: Wed, 06 Oct 2004 22:25:15 -0400
To: <[email-masked]>, [email-masked]
From: [email-masked]
Subject: RE: [Ietf-caldav] comments on -02
Cc: 

Free/Busy is a property of the user/owner of the calendar more than 
anything else; in essence I really want a logical AND of all of my 
free/busy time so that none of my events, personal or business, get 
overbooked. In iCalendar, however, we have to represent those at the 
VCALENDAR level.  I am cross-posting this to the calsify list, because it 
really belongs there - my view is that we ought to establish a standard for 
the granularity of a free/busy time map (15 minutes would be my choice), 
and then just exchange a "bit map" of the time between two dates that are 
requested as the endpoints - call it a VBUSYMAP deliverable as other binary 
objects are, in Base64.  Then, scheduling a meeting might go something like 
this:

Organizer to each attendee: Show me your free/busy map between date X and 
date Y.
Each attendee: here is the VBUSYMAP of my time
Organizer then finds (hopefully) a time when all are free, and sends out 
meeting requests for that time;or, finding no acceptable time, picks two 
different dates and tries again.

This, to me, simplifies and shortens the scheduling process. Your code 
doesn't have to parse all of the VFREEBUSY items. In fact, an 
implementation can choose to maintain the map in whatever backing store it 
uses, and keep it updated as VEVENTS are added or removed.

At 08:36 PM 10/6/04, Cameron Stillion wrote:
>But if you don't want to be scheduled, that means you want the time to
>appear as if you are "scheduled" already... Right?  You can do this now
>by putting an appointment on your calendar marked as "OOF" - and the
>free/busy view of this event will clearly mark this as already taken.
>
>Having someone schedule you on Saturday or Sunday is really a social
>problem though. If it is your wife, it makes sense.  If it's your
>co-worker, then there are social checks and balances that say this won't
>happen if it isn't appropriate.  The protocol is not meant to solve the
>social aspect.  Clearly good software would keep this in mind and help
>you do the right thing, but it can't know all the human implications...
>
>I still stand by the fact that free/busy is merely a translation of
>events, and that anything else is unnecessarily complex with really no
>benefit - to the standard most especially, but even more to applications
>and systems.
>
>
>cameron
>
>
>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]] On Behalf Of G. Barnes
>Sent: Wednesday, October 06, 2004 10:26 AM
>To: [email-masked]
>Subject: Re: [Ietf-caldav] comments on -02
>
>On Wed, 6 Oct 2004, Lisa Dusseault wrote:
>
> > I could go either way on allowing users to store standalone VFREEBUSY
> > components.  Keeping it is a small feature/flexibility; removing it is
>
> > a small simplification.  Who else has use cases or problems with
> > keeping or removing that feature?
>
>I have a problem with removing it.  I want to be able to say, 'no one
>can schedule me on Saturday or Sunday' (among other times).  Othewise,
>some jerk is going to schedule a mandatory meeting at 7am Saturday.
>Creating a VEVENT would presumably mean something shows up in my
>calendar.
>But I don't necessarily have an event scheduled; I just want to be left
>alone.  The most obvious way to do this is to create a standalone
>VFREEBUSY.
>
>                    Greg Barnes
>                    Computing and Communications, University of
>Washington
>                    [email-masked]
>                    (206) 685-3295
>_______________________________________________
>Ietf-caldav mailing list
>[email-masked]
>http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>
>_______________________________________________
>Ietf-caldav mailing list
>[email-masked]
>http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Tim Hare
Interested Bystander, Non-Inc. 

Content-class: urn:content-classes:message
Subject: RE: [Ietf-caldav] comments on -02
Date: Wed, 6 Oct 2004 17:36:42 -0700
From: "Cameron Stillion" <[email-masked]>
To: "G. Barnes" <[email-masked]>, <[email-masked]>
Cc: 

But if you don't want to be scheduled, that means you want the time to
appear as if you are "scheduled" already... Right?  You can do this now
by putting an appointment on your calendar marked as "OOF" - and the
free/busy view of this event will clearly mark this as already taken.

Having someone schedule you on Saturday or Sunday is really a social
problem though. If it is your wife, it makes sense.  If it's your
co-worker, then there are social checks and balances that say this won't
happen if it isn't appropriate.  The protocol is not meant to solve the
social aspect.  Clearly good software would keep this in mind and help
you do the right thing, but it can't know all the human implications...

I still stand by the fact that free/busy is merely a translation of
events, and that anything else is unnecessarily complex with really no
benefit - to the standard most especially, but even more to applications
and systems.

cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of G. Barnes
Sent: Wednesday, October 06, 2004 10:26 AM
To: [email-masked]
Subject: Re: [Ietf-caldav] comments on -02

On Wed, 6 Oct 2004, Lisa Dusseault wrote:

> I could go either way on allowing users to store standalone VFREEBUSY 
> components.  Keeping it is a small feature/flexibility; removing it is

> a small simplification.  Who else has use cases or problems with 
> keeping or removing that feature?

I have a problem with removing it.  I want to be able to say, 'no one
can schedule me on Saturday or Sunday' (among other times).  Othewise,
some jerk is going to schedule a mandatory meeting at 7am Saturday.
Creating a VEVENT would presumably mean something shows up in my
calendar. 
But I don't necessarily have an event scheduled; I just want to be left
alone.  The most obvious way to do this is to create a standalone
VFREEBUSY.

                   Greg Barnes
                   Computing and Communications, University of
Washington
                   [email-masked]
                   (206) 685-3295
_______________________________________________
Ietf-caldav mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] comments on -02 (creating items)
Date: Wed, 6 Oct 2004 23:05:33 +0200
To: CalDAV DevList <[email-masked]>

On Oct 6, 2004, at 18:27, Cyrus Daboo wrote:
>> Question: in WebDAV, would that be viable:
>> a) PUT on /1234.ics
>> b) server detects as a new item (1234 not available)
>> c) server creates new item name (54321)
>> d) server redirects client to /54321.ics
>> e) client will reattempt PUT on /54321.ics
>> Is this acceptable WebDAV? (I know that almost no HTTP client properly
>> supports redirects ...)
> First of all there are ways in HTTP & WebDAV to ensure that a new 
> resource is created when doing a PUT - e.g. use of 'If-None-Match: *' 
> header and/or lock-nulls.

Yes, I know. This wasn't my point. I expect that CalDAV will be used to 
expose legacy systems which implies that it needs to deal with the 
above situation (object naming done by the server).
I wanted to know whether a regular WebDAV client is supposed to be able 
to deal with the above sequence (and in turn, CalDAV).

Eg one example Dan already brought up (and which I always wanted to 
implement ;-), is the Bugzilla/WebDAV gateway. You certainly want to 
have the bug ids as the "filenames".

BTW: letting the server create the uid isn't the worst idea either 
since it reduces locking (you would need to lock the whole folder?!) 
and neither requires looping to find an available name. (though this 
isn't my main motivation, see above)

> I believe the choice of URL naming should be left to the client, 
> rather than having some kind of special POST or redirect approach.

Maybe POST/redirect might be too difficult. But if support for the 
redirect as outlined above is already required for a conforming 
WebDAV/HTTP client anyway, then we get the functionality for free. This 
is something I would like to get an OK for ;-)

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

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] comments on -02
Date: Wed, 6 Oct 2004 22:54:23 +0200
To: CalDAV DevList <[email-masked]>

On Oct 6, 2004, at 17:16, Lisa Dusseault wrote:
> I could go either way on allowing users to store standalone VFREEBUSY 
> components.  Keeping it is a small feature/flexibility; removing it is 
> a small simplification.  Who else has use cases or problems with 
> keeping or removing that feature?

I agree with Dan here. VFREEBUSY is just a stripped external 
representation of VEVENTs. Its natural for the OGo storage which 
doesn't dinstinguish between and event and conflict information (its 
just one SQL table type queried for everything).

On the other side supporting VFREEBUSY PUTs in the protocol server is 
relatively easy. It would just create a fullfledged appointment on the 
server with a read access configuration which only allows for startdate 
and enddate read access.
The difficult or unnatural thing here is to remember that an 
appointment created by a freebusy PUT and return the event as exactly 
that in subsequent requests.

Summary: I would prefer to see that an event collection can only 
contain events. Having to deal with two different things only makes it 
more complicated and requires more explanation.

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

Date: Wed, 6 Oct 2004 10:25:54 -0700 (PDT)
From: "G. Barnes" <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-caldav] comments on -02

On Wed, 6 Oct 2004, Lisa Dusseault wrote:

> I could go either way on allowing users to store standalone VFREEBUSY 
> components.  Keeping it is a small feature/flexibility; removing it is a 
> small simplification.  Who else has use cases or problems with keeping or 
> removing that feature?

I have a problem with removing it.  I want to be able to say, 'no one
can schedule me on Saturday or Sunday' (among other times).  Othewise, some 
jerk is going to schedule a mandatory meeting at 7am Saturday.  Creating
a VEVENT would presumably mean something shows up in my calendar. 
But I don't necessarily have an event scheduled; I just want to be left 
alone.  The most obvious way to do this is to create a standalone VFREEBUSY.

                   Greg Barnes
                   Computing and Communications, University of Washington
                   [email-masked]
                   (206) 685-3295

Date: Wed, 06 Oct 2004 12:27:03 -0400
From: Cyrus Daboo <[email-masked]>
To: Helge Hess <[email-masked]>, CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] comments on -02 (creating items)
Cc: 

Hi Helge,

--On Tuesday, October 5, 2004 2:15 AM +0200 Helge Hess 
<[email-masked]> wrote:

> Question: in WebDAV, would that be viable:
> a) PUT on /1234.ics
> b) server detects as a new item (1234 not available)
> c) server creates new item name (54321)
> d) server redirects client to /54321.ics
> e) client will reattempt PUT on /54321.ics
> Is this acceptable WebDAV? (I know that almost no HTTP client properly
> supports redirects ...)

First of all there are ways in HTTP & WebDAV to ensure that a new resource 
is created when doing a PUT - e.g. use of 'If-None-Match: *' header and/or 
lock-nulls.

I believe the choice of URL naming should be left to the client, rather 
than having some kind of special POST or redirect approach. CalDAV should 
recommend a suitable naming scheme (e.g. a lightweight hash of (UID, SEQ, 
RECURRENCE-ID, LAST_MODIFIED), as well as ensure clients use the proper 
HTTP/WebDAV approach for ensuring creation of new resources.

-- 
Cyrus Daboo

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] comments on -02
Date: Wed, 6 Oct 2004 08:16:10 -0700
To: Dan Winship <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

I could go either way on allowing users to store standalone VFREEBUSY 
components.  Keeping it is a small feature/flexibility; removing it is 
a small simplification.  Who else has use cases or problems with 
keeping or removing that feature?

lisa

On Oct 6, 2004, at 8:10 AM, Dan Winship wrote:

> On Tue, 2004-10-05 at 20:00 -0400, [email-masked] wrote:
>> This is a response to a VFREBUSY request (from RFC 2445)
> ...
>> As you can perhaps see, it's a pretty compact method of representing 
>> busy
>> time over the requested period,  the requestor doesn't have to 
>> retrieve and
>> parse all of the VEVENTS  in the period
>
> Sure, the server should definitely return VFREEBUSY objects in response
> to a free-busy-time request, but that doesn't mean the user needs to be
> able to create arbitrary VFREEBUSY objects. The server can construct an
> appropriate VFREEBUSY response automatically from the VEVENTs.
>
>> and as Doug Royer pointed out,
>> your busy time could be longer than the event time (or shorter, but I 
>> can't
>> think of a use case for that)
>
> The use case for shorter would be "I only care about the first half of
> the agenda, so I'm going to leave early". But both of these are 
> examples
> of constructing use cases based on what happens to be possible 
> according
> to the wording of the spec. I don't think anything in the RFCs suggests
> that VFREEBUSY was supposed to be able to address either of these 
> cases.
>
> (If we did want to implement something like this, it would make more
> sense to add a property or parameter to the VEVENT itself, maybe using
> syntax similar to the VALARM TRIGGER parameter, to add or remove busy
> time from either end of the event. That way, if the event was
> rescheduled, the freebusy hack would move along with it. Not that I'm
> suggesting we do that any time before calsify finishes :-)
>
> -- Dan
>
>
> _______________________________________________
> Ietf-caldav mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Subject: RE: [Ietf-caldav] comments on -02
From: Dan Winship <[email-masked]>
To: [email-masked]
Date: Wed, 06 Oct 2004 11:10:40 -0400
Cc: CalDAV DevList <[email-masked]>

On Tue, 2004-10-05 at 20:00 -0400, [email-masked] wrote:
> This is a response to a VFREBUSY request (from RFC 2445)
...
> As you can perhaps see, it's a pretty compact method of representing busy 
> time over the requested period,  the requestor doesn't have to retrieve and 
> parse all of the VEVENTS  in the period

Sure, the server should definitely return VFREEBUSY objects in response
to a free-busy-time request, but that doesn't mean the user needs to be
able to create arbitrary VFREEBUSY objects. The server can construct an
appropriate VFREEBUSY response automatically from the VEVENTs.

> and as Doug Royer pointed out, 
> your busy time could be longer than the event time (or shorter, but I can't 
> think of a use case for that)

The use case for shorter would be "I only care about the first half of
the agenda, so I'm going to leave early". But both of these are examples
of constructing use cases based on what happens to be possible according
to the wording of the spec. I don't think anything in the RFCs suggests
that VFREEBUSY was supposed to be able to address either of these cases.

(If we did want to implement something like this, it would make more
sense to add a property or parameter to the VEVENT itself, maybe using
syntax similar to the VALARM TRIGGER parameter, to add or remove busy
time from either end of the event. That way, if the event was
rescheduled, the freebusy hack would move along with it. Not that I'm
suggesting we do that any time before calsify finishes :-)

-- Dan

Date: Tue, 05 Oct 2004 20:00:35 -0400
To: "CalDAV DevList" <[email-masked]>
From: [email-masked]
Subject: RE: [Ietf-caldav] comments on -02

This is a response to a VFREBUSY request (from RFC 2445)

      BEGIN:VFREEBUSY
      ORGANIZER:[email-masked]
      DTSTART:19980313T141711Z
      DTEND:19980410T141711Z
      FREEBUSY:19980314T233000Z/19980315T003000Z
      FREEBUSY:19980316T153000Z/19980316T163000Z
      FREEBUSY:19980318T030000Z/19980318T040000Z
      URL:http://www.host.com/calendar/busytime/jsmith.ifb
      END:VFREEBUSY

As you can perhaps see, it's a pretty compact method of representing busy 
time over the requested period,  the requestor doesn't have to retrieve and 
parse all of the VEVENTS  in the period,  and as Doug Royer pointed out, 
your busy time could be longer than the event time (or shorter, but I can't 
think of a use case for that).  The shortest representation of free/busy 
time I've seen implemented was a binary bit-map of every 15 minutes in a 
month  - 31 x (24 x 4 bits = 96 bits = 12 octets) = 372 octets for a whole 
month!, with 0=free 1=busy.

T15At 11:41 PM 10/4/04, Cameron Stillion wrote:
>I've always been confused by the difference between VFREEBUSY and the
>VEVENT with precisely the same attributes...
>
>You seem to be arguing here that VFB's are useful as a scaled down
>version for those with reduced permissions.  However, I can, using
>VEVENTS, accomplish the same thing.  In fact, I can impose a far more
>granular set of permissions applied to any subset of the calendar.
>Free/Busy, IMHO is simply a version of VEVENT listings that does not
>contain the "full" enchilada.  Free/Busy and other scaled down versions
>of VEVENTS will always be calculated from the full source VEVENTS
>anyway.  Why do we need a different schematic representation?
>
>Perhaps this argument would better appear on calsify, but we've already
>opened the box...
>
>
>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]] On Behalf Of
>[email-masked]
>Sent: Monday, October 04, 2004 8:18 PM
>To: CalDAV DevList
>Subject: Re: [Ietf-caldav] comments on -02
>
>VFREEBUSY  is used for query/retrieval of busy time - sometimes a client
>is authorized to know free and busy times and nothing else - no details
>of events, no summary description of events, nothing  but "the time is
>blocked from 8 to 9".  Scheduling is also potentially faster when you
>just inquire into VFREEBUSY, not retrieve every event over a time range
>and construct a free/busy time map.
>
>   At 08:10 PM 10/4/04, Helge Hess wrote:
> >On Oct 5, 2004, at 1:41, Lisa Dusseault wrote:
> >>>>and each one contains exactly one VEVENT or VFREEBUSY object.
> >>>Do we really want static VFREEBUSY objects?
> >>yes- these don't duplicate VEVENT data, they supplement it with
> >>blocked out time.
> >
> >Hm, this will probably complicate things? I would see a vfreebusy as a
> >stripped representation of an vevent. If you want to block a time,
> >create a proper event (and attach information why this is blocked).
> >
> >A more interesting case is free time. But not to complicate things I
> >tend to suggest that those are implemented as some rrule property on
> >the event collection.
> >
> >For conflict detection a server would probably do:
> >a) calculate busy time based on existing events
> >b) restrict the remaining free time by freetime data (eg the work hours
>at the
> >    office)
> >If we really want to support VFREEBUSY objects in an event collection,
> >most servers probably will convert them to real events (with no
> >additional
> >info) on the fly. I would like to avoid this.
> >
> >Greets,
> >   Helge
> >--
> >http://docs.opengroupware.org/Members/helge/
> >OpenGroupware.org
> >
> >_______________________________________________
> >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

Tim Hare
Interested Bystander, Non-Inc. 

Date: Tue, 05 Oct 2004 21:37:08 +0200
From: Julian Reschke <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: [Ietf-caldav] Comments on draft 02

Hi,

below are some comments on the -02 draft, primarily from a WebDAV p.o.v. 
(so little to no Calendaring knowledge involved here :-).

02-C01 Section 1.1.1

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-02.html#rfc.section.1.1.1.p.2>

"Specifying new URL formats..." -- is this about new URI schemes (I 
think so)? In this case, the text should use the proper IETF terminology.

02-C02 Section 1.1.3+4

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-02.html#rfc.section.1.1.3>
<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-02.html#rfc.section.1.1.4>

This makes it sound as if Locking is a mandatory WebDAV feature, which 
is incorrect.

02-C03 Section 1.1.6

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-02.html#rfc.section.1.1.6.p.2>

Looking at the IETF status of the SASL draft it seems that it needs to 
be revised (also it's at draft 11 in the meantime). At some point of 
time this (calDav) spec needs to decide whether it wants to refer to 
work-in-progress or not...

02-C04 Section 2

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-02.html#rfc.section.2>

Why are the following features required?

- Locking
- WebDAV SEARCH

I suspect there's some desire to promote certain WebDAV 
features/extensions (to which I'm sympathetic). However, just requiring 
lots of (IMHO orthogonal) stuff will just raise the entry barrier, thus 
affect acceptance (because people do not embrace CalDAV) or interop 
(because people will subset anyway) negatively. IMHO it's better to keep 
the required WebDAV feature set minimal, and then explain who certain 
extensions optionall can make things even better.

Similar thoughts apply to requiring RFC3744. I can easily imagine a 
server that has a custom ACL system that for some reason doesn't get 
exposed as WebDAV ACLs. As far as I can tell, that system would still be 
fully functional with the restriction that a calendaring client wouldn't 
be able to display ACLs or author them.

Also, saying that a server "may" support DeltaV doesn't say anything 
useful. It may also support any other HTTP extension (such as ordered 
collections, bindings or redirects). Please remove that paragraph.

02-C05 Section 3

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-02.html#rfc.section.3>

I'm not sure we need new DAV: header tokens. It seems that both 
scenarios can already be addressed using supported-live-property-set and 
supported-method-set (and of course also the Allow header returned upon 
OPTIONS).

02-C06, Section 6

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-02.html#rfc.section.6.p.5>

It's ok to recommend a certain file extension, but requiring it is 
against HTTP and the overall Web architecture. The content type of a 
resource served via HTTP is defined by the Content-Type response 
parameter, nothing else. Even IE get's this right in XPSP2.

Editorial

02-E01

Document needs to refer to RFC3667 in the boilerplate.

02-E02, Section 5.1

starting in 
<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-02.html#rfc.section.5.1>

there are several examples using a namespace name of "DAV" instead of 
"DAV:".

02-E03, Section 6

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-02.html#rfc.section.6.p.6>

Non-ASCII (in this case Chinese) characters are not allowed in IETF spec 
text content.

02-E04, References

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-02.html#rfc.references>

The reference to WebDAV SEARCH has an incorrect date; anyway, in the 
meantime the draft has been updated, see 
<http://www.ietf.org/internet-drafts/draft-reschke-webdav-search-07>.

02-E05, Section 4.1, typo

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-02.html#rfc.section.4.1.p.3>

s/calenadr/calendar/

Best regards,

Julian

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

Date: Tue, 05 Oct 2004 11:48:43 -0600
From: Doug Royer <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] comments on -02
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.45
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: Tue, 05 Oct 2004 17:48:55 -0000

This is a cryptographically signed message in MIME format.

--------------ms040805050200070800040201
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

There is no rule that says the your BUSY time == your VEVENT time.
They are not quite the same thing.

I could say that +/- 15 to every VEVENT - tag as busy.
I could say that weekends and 5pm - 8am tag as busy all of the time.

Cameron Stillion wrote:

>I've always been confused by the difference between VFREEBUSY and the
>VEVENT with precisely the same attributes... 
>
>You seem to be arguing here that VFB's are useful as a scaled down
>version for those with reduced permissions.  However, I can, using
>VEVENTS, accomplish the same thing.  In fact, I can impose a far more
>granular set of permissions applied to any subset of the calendar.
>Free/Busy, IMHO is simply a version of VEVENT listings that does not
>contain the "full" enchilada.  Free/Busy and other scaled down versions
>of VEVENTS will always be calculated from the full source VEVENTS
>anyway.  Why do we need a different schematic representation?
>
>Perhaps this argument would better appear on calsify, but we've already
>opened the box...
>  
>

-- 

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

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

--------------ms040805050200070800040201--

Date: Tue, 05 Oct 2004 18:50:07 +0200
From: Julian Reschke <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] comments on -02
Cc: [email-masked]

Lisa Dusseault wrote:
> I'd always thought of a principal resource as a WebDAV resource because 
> it MUST have certain properties.  In what way is it not a WebDAV 
> resource if it has properties?  Sure, MOVE and COPY and DELETE and 
> PROPPATCH and LOCK may all be forbidden, but those could all be 
> forbidden on any read-only WebDAV resource.

This leads us into the fuzzy area of what a "WebDAV resource" is. As 
WebDAV level 1 for instance requires supports for PROPPATCH, I would 
expect a "WebDAV" resource to never ever return 405, something which is 
explicitly allowed for a principal resource in RFC3744.

As you note, in practice this doesn't make a big difference (for 
instance, you may get a 403 because you're missing privileges).

Anyway, I think the authors of RFC3744 intentionally did *not* say that 
  a principal is a WebDAV resource, so CalDav shouldn't claim that it's 
saying that.

Best regards, Julian

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

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] comments on -02
Date: Tue, 5 Oct 2004 09:26:01 -0700
To: Julian Reschke <[email-masked]>
Cc: [email-masked]

I'd always thought of a principal resource as a WebDAV resource because 
it MUST have certain properties.  In what way is it not a WebDAV 
resource if it has properties?  Sure, MOVE and COPY and DELETE and 
PROPPATCH and LOCK may all be forbidden, but those could all be 
forbidden on any read-only WebDAV resource.

Lisa

On Oct 5, 2004, at 12:10 AM, Julian Reschke wrote:

> Lisa Dusseault wrote:
> > ...
>> fixed text: "The WebDAV ACL specification requires that any principal 
>> to whom permissions
>>           can be granted is represented via a WebDAV resource"
>> ...
>
> Not so (<http://greenbytes.de/tech/webdav/rfc3744.html#principals>):
>
> "...However, servers implementing this specification MUST expose 
> principal resources at an http(s) URL, which is a privileged scheme 
> that points to resources that have additional properties, as described 
> in Section 4. So, a principal resource can have multiple URIs, one of 
> which has to be an http(s) scheme URL. Although an implementation 
> SHOULD support PROPFIND and MAY support PROPPATCH to access and modify 
> information about a principal, it is not required to do so."
>
> Best regards, Julian
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Date: Tue, 05 Oct 2004 09:10:06 +0200
From: Julian Reschke <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] comments on -02
Cc: [email-masked]

Lisa Dusseault wrote:
 > ...
> fixed text: "The WebDAV ACL specification requires that any principal to 
> whom permissions
>           can be granted is represented via a WebDAV resource"
> ...

Not so (<http://greenbytes.de/tech/webdav/rfc3744.html#principals>):

"...However, servers implementing this specification MUST expose 
principal resources at an http(s) URL, which is a privileged scheme that 
points to resources that have additional properties, as described in 
Section 4. So, a principal resource can have multiple URIs, one of which 
has to be an http(s) scheme URL. Although an implementation SHOULD 
support PROPFIND and MAY support PROPPATCH to access and modify 
information about a principal, it is not required to do so."

Best regards, Julian

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

Content-class: urn:content-classes:message
Subject: RE: [Ietf-caldav] comments on -02
Date: Mon, 4 Oct 2004 20:41:18 -0700
From: "Cameron Stillion" <[email-masked]>
To: <[email-masked]>, "CalDAV DevList" <[email-masked]>
Cc: 

I've always been confused by the difference between VFREEBUSY and the
VEVENT with precisely the same attributes... 

You seem to be arguing here that VFB's are useful as a scaled down
version for those with reduced permissions.  However, I can, using
VEVENTS, accomplish the same thing.  In fact, I can impose a far more
granular set of permissions applied to any subset of the calendar.
Free/Busy, IMHO is simply a version of VEVENT listings that does not
contain the "full" enchilada.  Free/Busy and other scaled down versions
of VEVENTS will always be calculated from the full source VEVENTS
anyway.  Why do we need a different schematic representation?

Perhaps this argument would better appear on calsify, but we've already
opened the box...

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, October 04, 2004 8:18 PM
To: CalDAV DevList
Subject: Re: [Ietf-caldav] comments on -02

VFREEBUSY  is used for query/retrieval of busy time - sometimes a client
is authorized to know free and busy times and nothing else - no details
of events, no summary description of events, nothing  but "the time is
blocked from 8 to 9".  Scheduling is also potentially faster when you
just inquire into VFREEBUSY, not retrieve every event over a time range
and construct a free/busy time map.

  At 08:10 PM 10/4/04, Helge Hess wrote:
>On Oct 5, 2004, at 1:41, Lisa Dusseault wrote:
>>>>and each one contains exactly one VEVENT or VFREEBUSY object.
>>>Do we really want static VFREEBUSY objects?
>>yes- these don't duplicate VEVENT data, they supplement it with 
>>blocked out time.
>
>Hm, this will probably complicate things? I would see a vfreebusy as a 
>stripped representation of an vevent. If you want to block a time, 
>create a proper event (and attach information why this is blocked).
>
>A more interesting case is free time. But not to complicate things I 
>tend to suggest that those are implemented as some rrule property on 
>the event collection.
>
>For conflict detection a server would probably do:
>a) calculate busy time based on existing events
>b) restrict the remaining free time by freetime data (eg the work hours
at the
>    office)
>If we really want to support VFREEBUSY objects in an event collection, 
>most servers probably will convert them to real events (with no 
>additional
>info) on the fly. I would like to avoid this.
>
>Greets,
>   Helge
>--
>http://docs.opengroupware.org/Members/helge/
>OpenGroupware.org
>
>_______________________________________________
>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: Mon, 04 Oct 2004 23:18:08 -0400
To: CalDAV DevList <[email-masked]>
From: [email-masked]
Subject: Re: [Ietf-caldav] comments on -02

VFREEBUSY  is used for query/retrieval of busy time - sometimes a client is 
authorized to know free and busy times and nothing else - no details of 
events, no summary description of events, nothing  but "the time is blocked 
from 8 to 9".  Scheduling is also potentially faster when you just inquire 
into VFREEBUSY, not retrieve every event over a time range and construct a 
free/busy time map.

  At 08:10 PM 10/4/04, Helge Hess wrote:
>On Oct 5, 2004, at 1:41, Lisa Dusseault wrote:
>>>>and each one contains exactly one VEVENT or VFREEBUSY object.
>>>Do we really want static VFREEBUSY objects?
>>yes- these don't duplicate VEVENT data, they supplement it with blocked 
>>out time.
>
>Hm, this will probably complicate things? I would see a vfreebusy as a 
>stripped representation of an vevent. If you want to block a time, create 
>a proper event (and attach information why this is blocked).
>
>A more interesting case is free time. But not to complicate things I tend 
>to suggest that those are implemented as some rrule property on the event 
>collection.
>
>For conflict detection a server would probably do:
>a) calculate busy time based on existing events
>b) restrict the remaining free time by freetime data (eg the work hours at the
>    office)
>If we really want to support VFREEBUSY objects in an event collection, 
>most servers probably will convert them to real events (with no additional 
>info) on the fly. I would like to avoid this.
>
>Greets,
>   Helge
>--
>http://docs.opengroupware.org/Members/helge/
>OpenGroupware.org
>
>_______________________________________________
>Ietf-caldav mailing list
>[email-masked]
>http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Tim Hare
Interested Bystander, Non-Inc. 

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] comments on -02 (creating items)
Date: Tue, 5 Oct 2004 02:15:58 +0200
To: CalDAV DevList <[email-masked]>

On Oct 5, 2004, at 1:41, Lisa Dusseault wrote:
>>> 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?
> That's not a standard part of WebDAV although as we know Exchange 
> server does that :)
>
> I'm not against that feature but it's not one that WebDAV servers 
> already do, so CalDAV servers would need to add that if we specify 
> that.

+1 for POST.

In most RDBMS based servers some kind of sequence will decide the 
identifier for new objects.

Question: in WebDAV, would that be viable:
a) PUT on /1234.ics
b) server detects as a new item (1234 not available)
c) server creates new item name (54321)
d) server redirects client to /54321.ics
e) client will reattempt PUT on /54321.ics
Is this acceptable WebDAV? (I know that almost no HTTP client properly 
supports redirects ...)

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

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] comments on -02
Date: Tue, 5 Oct 2004 02:10:56 +0200
To: CalDAV DevList <[email-masked]>

On Oct 5, 2004, at 1:41, Lisa Dusseault wrote:
>>> and each one contains exactly one VEVENT or VFREEBUSY object.
>> Do we really want static VFREEBUSY objects?
> yes- these don't duplicate VEVENT data, they supplement it with 
> blocked out time.

Hm, this will probably complicate things? I would see a vfreebusy as a 
stripped representation of an vevent. If you want to block a time, 
create a proper event (and attach information why this is blocked).

A more interesting case is free time. But not to complicate things I 
tend to suggest that those are implemented as some rrule property on 
the event collection.

For conflict detection a server would probably do:
a) calculate busy time based on existing events
b) restrict the remaining free time by freetime data (eg the work hours 
at the
    office)
If we really want to support VFREEBUSY objects in an event collection, 
most servers probably will convert them to real events (with no 
additional info) on the fly. I would like to avoid this.

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

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] comments on -02
Date: Mon, 4 Oct 2004 16:41:33 -0700
To: Dan Winship <[email-masked]>
Cc: [email-masked]

Responses to these comments inline...

On Sep 29, 2004, at 9:41 AM, Dan Winship wrote:
>> 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)?

My intent was that would create a new WebDAV resource with the same UID 
as an existing resource. Anybody else have other suggestions?

>
>> 4.3  CalDAV and timezones
>
> This feels like it presupposes a certain calsify outcome...

It supposes that either iCalendar will keep VTIMEZONES in recurring 
VEVENTS, or that even if it does change CalDAV servers will have to 
deal with RFC2445 compliant VEVENTS.  If calsify makes a bunch of 
changes we'll certainly have to rewrite this and other sections but 
it's too early to do that now.

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

How about this language, later on after the overview material?

"Servers SHOULD NOT delete messages before or after
     a client has retrieved the messages in the inbox; instead the 
server SHOULD
     leave Inbox cleanup to the client.  A server MAY apply a quota to 
the iTIP
     Inbox (limiting the number of messages, the total size, or some 
other
     measurable) and MAY bounce incoming messages if the iTIP inbox is 
full
     or some other repository or account problem has occurred."

>
>> 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. :)

I know, we realized this after putting that wording in a bunch of 
places, and haven't resolved the wording because we may still be 
debating the purpose.  If we in fact use it to store things that have 
already gone out we should rename it to "sent" or something.

Any input on the purpose of the iTIP "outbox" ? Is it useful to have a 
collection of sent invitations?

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

An event in the calendar doesn't tell you what the wording in the 
invitation has, necessarily.  Don't forget you can theoretically send 
out an invitation for a meeting which you're not an attendee of .  
Maybe we should clarify whether an invitation in the sent items folder 
necessarily has to correspond to an event in the calendar?

Also the sent items record tells you when the invitation went out, 
which could be after the event item was created.

I don't know what to do about recording the responses to the SCHEDULE 
request.  A concrete proposal would be welcome here.

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

I'm fixing that....

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

Wouldn't this be the same case as detecting whether another client has 
already processed the invitation?  It's the same problem as the 
multi-client problem -- the server is just another potential active 
client or user agent.

I do like the idea of processing it before it shows up to avoid a race 
condition.  However, that problem might also have to be solved for the 
multi-client use cases.  in fact this shows me we'll need another 
section in the scheduling/fanout section of the document, explaining 
*how* to accept/reject invitations and avoid race conditions.  (To 
avoid race conditions I'll recommend how to use locks or strong ETags).

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

Fixing...

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

Thats a pretty good idea.  so the server MAY contain one and no more 
than one event collection, just like todos.

>
>> and one alarm collection.
>
> That's wrong now, right?

Fixing...

>
>> 5.3  Event Collection
>
>> and each one contains exactly one VEVENT or VFREEBUSY object.
>
> Do we really want static VFREEBUSY objects?

yes- these don't duplicate VEVENT data, they supplement it with blocked 
out time.

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

I thought COUNTER was a REPLY?  Do you think these should also be added?

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

That's not a standard part of WebDAV although as we know Exchange 
server does that :)

I'm not against that feature but it's not one that WebDAV servers 
already do, so CalDAV servers would need to add that if we specify 
that.

>
>> 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/ ?)

fixed text: "The WebDAV ACL specification requires that any principal 
to whom permissions
           can be granted is represented via a WebDAV resource"

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

Yeah, deleted that sentence.

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

This seems better to me:
"These servers MUST
	handle outgoing iTIP messages submitted to an iTIP Outbox collection,
     and MUST deliver incoming iTIP messages to an iTIP Inbox 
collection."

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

see above
>
>> 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.

That's like a "cc", the way we outlined in the draft is more like a 
"bcc".  The difference is whether everybody else sees that they are in 
the attendee list or not.

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

I don't like that -- that seems to be overloading something to mean 
something that it doesn't mean.

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

Hmm, I recall something convincing here that made our header trick a 
neat one, but now i can't reconstruct the details...  what a four-day 
vacation can do to you!

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

I would say, yes, that's the intended model...  as I said above it 
would be even  more useful to have some way to store the results as 
well as the outgoing message.

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

The PUT and the SCHEDULE are intended to be independent because 
otherwise we tend to design them together and limit what clients can 
do.
  - PUT is the operation which stores the event on a specific calendar.
  - SCHEDULE is the operation which sends an invitation to multiple 
recipients.

What can the client do special if we keep them independent?
  - I can SCHEDULE to a single Outbox, and independently decide whether 
to PUT the event to my karate calendar or my work calendar.
  - Can SCHEDULE without doing PUT: scheduling a meeting that the 
scheduler doesn't actually attend (and I don't show up in attendee 
list).  e.g. when our HR person schedules an interview for me and a 
candidate.
  - Can PUT without SCHEDULE (any event that doesn't have attendees 
other than myself)
  - Can PUT an event that *does* have attendees, and can use another 
mechanism besides SCHEDULE to notify them (Chandler needs this use 
case).
  - Can PUT an event on my calendar long in advance, then when 
date/location are confirmed and I'm ready to write the invitation, send 
SCHEDULE.

But if we continue with this model, you're right, we do need to 
recommend that if the event is going to go on a calendar at all it 
should go before the SCHEDULE is sent.

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

Yep, Bernard & I discussed this at great length when we got together.  
No good answers yet.

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

True enough.  thx.

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

Actually the text does say "The originator of the iTIP message will be
	specified in the Originator response header."

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

Cyrus? Bernard?  I think this might be a good idea...

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

Damn, you ask too many good questions.  We should discuss the value of 
multiple inboxes/outboxes, and whether the value is worth the 
complexity.  Somebody, please respond with a new subject so we can 
discuss :)

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

Correct

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

Agreed.  For now this is a TODO in the spec.

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

Oooh,  good point.  I intended one resource for each recurrence.

>
> -- Dan
>
>
Thanks Dan!  Great review.