Subject: Re: [Ietf-caldav] What happened to the CalDav website?
From: Adam Laurie <[email-masked]>
To: [email-masked]
Date: Thu, 29 Jun 2006 12:39:00 +0100
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>

For the past couple of weeks I've been trying to find a download with no 
joy... All URLS previously mentioned appear to be down:

  http://ietf.cse.ucsc.edu/caldav
  http://caldav.org/
  http://www.caldav.org/
  http://ietf.webdav.org/caldav/

Is there CVS or some other access, or is the distribution site likely to 
come back any time soon?

BTW, please copy me on replies - I'm not subscribed to this list.

cheers,
Adam
-- 
Adam Laurie                         Tel: +44 (0) 1304 814800
The Bunker Secure Hosting Ltd.      Fax: +44 (0) 1304 814899
Ash Radar Station                   http://www.thebunker.net
Marshborough Road
Sandwich                            mailto:[email-masked]
Kent
CT13 0PL
UNITED KINGDOM                      PGP key on keyservers

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] CalDAV Global Address Book
Date: Tue, 27 Jun 2006 00:16:38 +0100
To: "Kervin L. Pierre" <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

On Jun 26, 2006, at 11:23 PM, Kervin L. Pierre wrote:
>
> We did not want to introduce LDAP as a
> dependency for using the client, but would
> like to provide a global address book.

So far it sounds to me like you can rely on the WebDAV Principal  
namespace for that purpose.  That may of course not be available in  
all situations, because it can be a matter of configuration how much  
of that is readable/searchable and to whom, but in the situations  
where there's no access to the principal namespace you wouldn't be  
getting access to that information anyway.

So for good interoperability, your client would attempt to get this  
global address book through the principal namespace, but not fail  
badly if searching/listing were disallowed.

Lisa

Date: Mon, 26 Jun 2006 15:23:10 -0700 (PDT)
From: "Kervin L. Pierre" <[email-masked]>
Subject: Re: [Ietf-caldav] CalDAV Global Address Book
To: Cyrus Daboo <[email-masked]>, Julian Reschke <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

Hello Group,

--- Cyrus Daboo <[email-masked]> wrote:
> 
> What's wrong with simply putting calendar attributes
> in the organization's 
> directory? 

Nothing at all, but the organization may not
have an organizational directory or someone
who can administer one.

Keep in mind, that this issue is resolved by
adding a 'default calendar' property on the
principal.

We did not want to introduce LDAP as a
dependency for using the client, but would
like to provide a global address book.

The next option is to have the user provide
a default calendar name to try, or choose
one for them.  A bit of a hack, but seems
preferable to requiring LDAP.

Also note that a CalDAV GAB is not meant to
replace a LDAP GAB, but to provide base
functionality so that administering a LDAP
server is optional.

> when there will likely be a directory that will
> contain all the other 
> useful communication related attributes too (email,
> im, web page etc). If 
> the directory is sufficient, then RFC 2739 defines a
> set of attributes that can be used.

It's a useful dependency, I agree, but I
don't think it should be manatory for GAB
functionality.

> Well, a client could expose the calendar hierarchy
> and allow users to 
> browse that - that is what I did in Mulberry and
> matches the UI we had for 
> browsing shared mailboxes on the email side. The
> client can offer searching 
> on that if it wanted - no need to go to principals.
> 

The calendar collections for a single
organization may exist on separate servers.

Also, I think the calendar browsing scheme
is too complicated for the types of users
we run into.  But this is a judgement call.
Many people are easily confused by URLS,
folder hierarchies, etc.  

We'd like to offer them a simple list of
names in the organization; if they have
permission to view that list.

> The purpose of the SRV is to allow outside users to
> locate a CalAV server 

I understand, thanks.

At any rate, consider adding the ability
to add a 'default calendar' URL to the
principal.  That's how MAPI does it, so
there is some 'precedence' if that matters.

It would allow a principal<->calendar,
1-to-1 relationship that simple clients
can use to simplify interaction with the
CalDAV server.

Best regards,
Kervin

Date: Mon, 26 Jun 2006 11:07:14 -0400
From: Cyrus Daboo <[email-masked]>
To: "Kervin L. Pierre" <[email-masked]>, Julian Reschke <[email-masked]>
Subject: Re: [Ietf-caldav] CalDAV Global Address Book
Cc: CalDAV DevList <[email-masked]>

Hi Kervin,

--On June 26, 2006 7:51:00 AM -0700 "Kervin L. Pierre" 
<[email-masked]> wrote:

>> There are situations where access to the principal
>> hierarchy may be denied
>> entirely (whether directly or by a REPORT). For
>> example, consider an ISP
>
> That is true.  What about department or
> organizational servers?  Is denying authenticated
> users access to the principal hierarchy common?
> Is it some sought of best practise?
>
> If it is not then we can take our chances and
> simply list that permission as a prequisite for
> using the CalDAV global address book.

What's wrong with simply putting calendar attributes in the organization's 
directory? Having a 'special' address book just for CalDAV seems silly, 
when there will likely be a directory that will contain all the other 
useful communication related attributes too (email, im, web page etc). If 
the directory is sufficient, then RFC 2739 defines a set of attributes that 
can be used.

>> Question: is your intent here to have a general way
>> to find anybody's
>> calendar given some identifier?
>
> Exactly.  And to also return a list of everybody
> in the organization ( or more precisely on the
> server ), that has a calendar ( ie. Browse users ).

Again - a proper directory is a better bet.

> Basically how Microsoft Outlook shares calendars...
>
> (i) Type in a term
> (ii) Get a list of principal matches
> (iii) Click on a match to retrieve that calendar
>   Or
> (i) Browse the Global Address Book
> (ii) Select the principal you need
> (iii) Click on their row to retrieve their calendar
>
> Btw. That is probably how most clients are going
> to share calendars, I'd wager.

Well, a client could expose the calendar hierarchy and allow users to 
browse that - that is what I did in Mulberry and matches the UI we had for 
browsing shared mailboxes on the email side. The client can offer searching 
on that if it wanted - no need to go to principals.

>> Do you actually want
>> their calendar as
>> opposed to wanting to do scheduling operations with
>> them (as in free-busy
>> lookups, booking meetings etc)?
>
> We need the calendar, definitely.  This is used
> for delegating calendar duties to secretaries,
> browsing a colleague's schedule, etc.

OK.

>> gone on in Calconnect. Right now the feeling is that
>> there needs to be a
>> new 'scheduleto' URI scheme with appropriate lookup
>> rules (SRV records) to
>> find the calendar service for a particular address.
>
> This seems to be slightly different from what
> we're doing, if I am not mistaken, but please
> correct me if I am wrong...
>
> A SRV record will be useful in providing the
> appropriate CalDAV server given a principle
> or a domain.  Eg. Answering "Where is example.com's
> CalDAV server" with "It's cal.example.com".
>
> But after the client initiates the session
> with cal.example.com, it still doesn't know
> where the user's 'primary' calendar is.
> And it still can't provide the user with a
> list of available principals.  Correct?

The purpose of the SRV is to allow outside users to locate a CalAV server 
that supports the calendar-schedule feature so that they can carry out 
scheduling operations. That does not expose individual user calendars 
within the organization - merely a 'public' URL to which calendar-schedule 
requests can be sent and response returned.

Scheduling like that is more likely to be what people want to do for their 
personal calendars - i.e. not expose those to anyone on the outside but 
allow them to schedule.

Discovery of actual 'public' calendars is a slightly different issue and 
does need to be addressed in some fashion. Various possibilities for that 
have been mentioned, including use of ATOM feeds etc. Of course a similar 
type of problem exists for discovering public mailing lists - that is 
usually addressed by simply having a webpage listing them with links to 
initiate subscription etc.

-- 
Cyrus Daboo

Date: Mon, 26 Jun 2006 07:51:00 -0700 (PDT)
From: "Kervin L. Pierre" <[email-masked]>
Subject: Re: [Ietf-caldav] CalDAV Global Address Book
To: Cyrus Daboo <[email-masked]>, Julian Reschke <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

Hello,

--- Cyrus Daboo <[email-masked]> wrote:

> There are situations where access to the principal
> hierarchy may be denied 
> entirely (whether directly or by a REPORT). For
> example, consider an ISP 

That is true.  What about department or
organizational servers?  Is denying authenticated
users access to the principal hierarchy common?
Is it some sought of best practise?

If it is not then we can take our chances and
simply list that permission as a prequisite for
using the CalDAV global address book.

> Question: is your intent here to have a general way
> to find anybody's 
> calendar given some identifier? 

Exactly.  And to also return a list of everybody
in the organization ( or more precisely on the
server ), that has a calendar ( ie. Browse users ).

Basically how Microsoft Outlook shares calendars...

(i) Type in a term
(ii) Get a list of principal matches
(iii) Click on a match to retrieve that calendar
  Or
(i) Browse the Global Address Book
(ii) Select the principal you need
(iii) Click on their row to retrieve their calendar

Btw. That is probably how most clients are going
to share calendars, I'd wager.

> Do you actually want
> their calendar as 
> opposed to wanting to do scheduling operations with
> them (as in free-busy 
> lookups, booking meetings etc)? 

We need the calendar, definitely.  This is used
for delegating calendar duties to secretaries,
browsing a colleague's schedule, etc.

> gone on in Calconnect. Right now the feeling is that
> there needs to be a 
> new 'scheduleto' URI scheme with appropriate lookup
> rules (SRV records) to 
> find the calendar service for a particular address.

This seems to be slightly different from what
we're doing, if I am not mistaken, but please
correct me if I am wrong...

A SRV record will be useful in providing the
appropriate CalDAV server given a principle
or a domain.  Eg. Answering "Where is example.com's
CalDAV server" with "It's cal.example.com".

But after the client initiates the session
with cal.example.com, it still doesn't know
where the user's 'primary' calendar is.
And it still can't provide the user with a
list of available principals.  Correct?

Best regards,
Kervin

From: Sam Hartman <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] References in draft-dusseault-caldav-12
Date: Mon, 26 Jun 2006 10:01:27 -0400
Cc: The IESG <[email-masked]>, CalDAV DevList <[email-masked]>

>>>>> "Lisa" == Lisa Dusseault <[email-masked]> writes:

    Lisa> Context: whether CalDAV should mandate clients supporting
    Lisa> TLS in order to provide at least one encrypted transport
    Lisa> over which plain- text passwords might be used.

Yes or wait for a revision of HTTP.

Date: Mon, 26 Jun 2006 15:59:18 +0200
From: Julian Reschke <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-caldav] CalDAV Global Address Book
Cc: CalDAV DevList <[email-masked]>

Cyrus Daboo schrieb:
> Hi Julian,
> 
> --On June 26, 2006 3:28:28 PM +0200 Julian Reschke 
> <[email-masked]> wrote:
> 
>> Why a new *URI scheme*???????? Common (well...) wisdom IMHO is not to
>> define new URI schemes, unless none of the existing schemes would work.
>> Why wouldn't http be sufficient? Did you consider defining a MIME type
>> (holding the information in the content), or a link relation?
> 
> Yup - we did have arguments for all of this and a new scheme came out as 
> the best choice for a number of reasons. Obviously there is a high 
> barrier for defining new schemes so we will have to fully justify this 
> if we do end up doing it and writing a spec for it.

Well, there's a barrier for a reason. It would be nice if somebody could 
summarize over here what actual problem needs to be solved, and which 
alternatives have been discussed.

Best regards, Julian

Date: Mon, 26 Jun 2006 09:53:48 -0400
From: Cyrus Daboo <[email-masked]>
To: Julian Reschke <[email-masked]>
Subject: Re: [Ietf-caldav] CalDAV Global Address Book
Cc: CalDAV DevList <[email-masked]>

Hi Julian,

--On June 26, 2006 3:28:28 PM +0200 Julian Reschke <[email-masked]> 
wrote:

> Why a new *URI scheme*???????? Common (well...) wisdom IMHO is not to
> define new URI schemes, unless none of the existing schemes would work.
> Why wouldn't http be sufficient? Did you consider defining a MIME type
> (holding the information in the content), or a link relation?

Yup - we did have arguments for all of this and a new scheme came out as 
the best choice for a number of reasons. Obviously there is a high barrier 
for defining new schemes so we will have to fully justify this if we do end 
up doing it and writing a spec for it.

-- 
Cyrus Daboo

Date: Mon, 26 Jun 2006 15:28:28 +0200
From: Julian Reschke <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-caldav] CalDAV Global Address Book
Cc: CalDAV DevList <[email-masked]>

Cyrus Daboo schrieb:
> Hi Kervin,
> 
> --On June 26, 2006 9:09:03 AM +0200 Julian Reschke 
> <[email-masked]> wrote:
> 
>>> (i) Is it reasonable to assume that the principal
>>> collection would allow listing?  In my current
>>> testing this has been the case.  Ie. Are we
>>> going to incur the wrath of Sys. Admins. because
>>> we assumed that users are allowed to list this
>>> collection?  ( I am hoping someone more familiar
>>> with WebDAV ACL can clarify this )
>>
>> No, in general you can't assume that listing will work, as the
>> collections may be very (very!) big.
>>
>> But the DAV:principal-property-search REPORT may help here
>> (<http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.9.4>).
> 
> There are situations where access to the principal hierarchy may be 
> denied entirely (whether directly or by a REPORT). For example, consider 
> an ISP running a caldav server - they are very unlikely to want to 
> expose their customer list (list of users) to everyone either outsiders 
> or customers.
> 
> Question: is your intent here to have a general way to find anybody's 
> calendar given some identifier? Do you actually want their calendar as 
> opposed to wanting to do scheduling operations with them (as in 
> free-busy lookups, booking meetings etc)? If this is what you want to do 
> then there have been several discussions of 'calendar user 
> discoverability' that have gone on in Calconnect. Right now the feeling 
> is that there needs to be a new 'scheduleto' URI scheme with appropriate 
> lookup rules (SRV records) to find the calendar service for a particular 
> address.

Why a new *URI scheme*???????? Common (well...) wisdom IMHO is not to 
define new URI schemes, unless none of the existing schemes would work. 
Why wouldn't http be sufficient? Did you consider defining a MIME type 
(holding the information in the content), or a link relation?

Best regards, Julian

Date: Mon, 26 Jun 2006 09:16:13 -0400
From: Cyrus Daboo <[email-masked]>
To: Julian Reschke <[email-masked]>, "Kervin L. Pierre" <[email-masked]>
Subject: Re: [Ietf-caldav] CalDAV Global Address Book
Cc: CalDAV DevList <[email-masked]>

Hi Kervin,

--On June 26, 2006 9:09:03 AM +0200 Julian Reschke <[email-masked]> 
wrote:

>> (i) Is it reasonable to assume that the principal
>> collection would allow listing?  In my current
>> testing this has been the case.  Ie. Are we
>> going to incur the wrath of Sys. Admins. because
>> we assumed that users are allowed to list this
>> collection?  ( I am hoping someone more familiar
>> with WebDAV ACL can clarify this )
>
> No, in general you can't assume that listing will work, as the
> collections may be very (very!) big.
>
> But the DAV:principal-property-search REPORT may help here
> (<http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.9.4>).

There are situations where access to the principal hierarchy may be denied 
entirely (whether directly or by a REPORT). For example, consider an ISP 
running a caldav server - they are very unlikely to want to expose their 
customer list (list of users) to everyone either outsiders or customers.

Question: is your intent here to have a general way to find anybody's 
calendar given some identifier? Do you actually want their calendar as 
opposed to wanting to do scheduling operations with them (as in free-busy 
lookups, booking meetings etc)? If this is what you want to do then there 
have been several discussions of 'calendar user discoverability' that have 
gone on in Calconnect. Right now the feeling is that there needs to be a 
new 'scheduleto' URI scheme with appropriate lookup rules (SRV records) to 
find the calendar service for a particular address.

-- 
Cyrus Daboo

Date: Mon, 26 Jun 2006 09:09:03 +0200
From: Julian Reschke <[email-masked]>
To: "Kervin L. Pierre" <[email-masked]>
Subject: Re: [Ietf-caldav] CalDAV Global Address Book
Cc: CalDAV DevList <[email-masked]>

Kervin L. Pierre schrieb:
> Hello Group,
> 
> Has the issue of providing a Global Address Book
> for CalDAV users come up yet?
> 
> It seems that if a user provides the WebDAV ACL
> base URL. eg.
> http://cal.example.com/principals/individuals/
> 
> A CalDAV client can provide a Global Address Book
> to its user by...
>  (i) first listing the principals in that
> collection at that URL.
>  (ii) then rendering using the returned
> displayname
>  (iii) and accessing using the calendar-home-set
> property.
> 
> There are issues surrounding this though...
> 
> (i) Is it reasonable to assume that the principal
> collection would allow listing?  In my current
> testing this has been the case.  Ie. Are we
> going to incur the wrath of Sys. Admins. because
> we assumed that users are allowed to list this
> collection?  ( I am hoping someone more familiar
> with WebDAV ACL can clarify this )

No, in general you can't assume that listing will work, as the 
collections may be very (very!) big.

But the DAV:principal-property-search REPORT may help here 
(<http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.9.4>).

> ...

Best regards, Julian

Date: Sun, 25 Jun 2006 22:51:14 -0400
From: "Kervin L. Pierre" <[email-masked]>
Organization: Adevsoft Inc
To: CalDAV DevList <[email-masked]>
Subject: [Ietf-caldav] CalDAV Global Address Book

Hello Group,

Has the issue of providing a Global Address Book
for CalDAV users come up yet?

It seems that if a user provides the WebDAV ACL
base URL. eg.
http://cal.example.com/principals/individuals/

A CalDAV client can provide a Global Address Book
to its user by...
  (i) first listing the principals in that
collection at that URL.
  (ii) then rendering using the returned
displayname
  (iii) and accessing using the calendar-home-set
property.

There are issues surrounding this though...

(i) Is it reasonable to assume that the principal
collection would allow listing?  In my current
testing this has been the case.  Ie. Are we
going to incur the wrath of Sys. Admins. because
we assumed that users are allowed to list this
collection?  ( I am hoping someone more familiar
with WebDAV ACL can clarify this )

(ii) How are server developers dealing with setting
calendar-home-set ?  This property is listed as
a MAY.  The spec says this can be a calendar
collection, or a regular collection with a calendar
descendant. This is going to make clients lives a
little harder.  Maybe the spec should decide on one
approach.  Currently I see Oracle is pointing to a
calendar, this works perfectly for us because
users are going to want to put in a principal and
get a calendar in return I suspect.  Just as they
do with current calendar applications, eg. Outlook.

Hence...

(iii) I think we need a way to specify a 'default'
or 'main' calendar.  If a 'default calendar' property
is not desirable, the spec should suggest a default
calendar collection name.  Just as webservers look for
'index.html' if they are configured to do so.  So if
the client finds that calendar-home-set points to an
ordinary collection, it may ask for the 'main'
collection under that and see if that is a calendar.

The ultimate goal is, given a principle, the client
can ultimately retrieve a calendar.

Best regards,
Kervin

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] References in draft-dusseault-caldav-12
Date: Sat, 24 Jun 2006 00:19:49 +0200
To: CalDAV DevList <[email-masked]>
Cc: The IESG <[email-masked]>

On Jun 23, 2006, at 21:44, Julian Reschke wrote:
> The point I'm trying to make is that if CalDAV and WebDAV share the  
> same security requirements, they optimally should say the same  
> thing. As CalDAV already normatively refers to RFC2518bis, this  
> means it doesn't need to say anything about it all.

Definitely +1. Why should CalDAV be different to WebDAV/HTTP?

Helge

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] References in draft-dusseault-caldav-12
Date: Fri, 23 Jun 2006 14:40:03 -0700
To: Sam Hartman <[email-masked]>
Cc: The IESG <[email-masked]>, CalDAV DevList <[email-masked]>

Context:  whether CalDAV should mandate clients supporting TLS in  
order to provide at least one encrypted transport over which plain- 
text passwords might be used.

Lisa

On Jun 23, 2006, at 2:36 PM, Sam Hartman wrote:

>>>>>> "Julian" == Julian Reschke <[email-masked]> writes:
>
>     Julian> Lisa Dusseault schrieb:
>>> ...  It would indeed be better to solve it in the base spec if
>>> we had time and resources.  Mark Nottingham is holding a bar
>>> BOF in Montreal to see if there's interest in making some
>>> updates to HTTP, which might include this.  But since that's
>>> such a long-term approach, I don't think it's the right thing
>>> to wait for here, nor is it the right thing to leave decent
>>> security optional.  Thus, I don't agree with your opinion on
>>> this, but you're welcome to attempt to argue it with the IESG
>>> ([email-masked]) or the Security directorate ([email-masked]).
>>> ...
>>
> I'm missing what this is all about?  Etag?  If so, how does that have
> to do with security?
> Something else?
>

From: Sam Hartman <[email-masked]>
To: Julian Reschke <[email-masked]>
Subject: Re: [Ietf-caldav] References in draft-dusseault-caldav-12
Date: Fri, 23 Jun 2006 17:36:25 -0400
Cc: The IESG <[email-masked]>, CalDAV DevList <[email-masked]>

>>>>> "Julian" == Julian Reschke <[email-masked]> writes:

    Julian> Lisa Dusseault schrieb:
    >> ...  It would indeed be better to solve it in the base spec if
    >> we had time and resources.  Mark Nottingham is holding a bar
    >> BOF in Montreal to see if there's interest in making some
    >> updates to HTTP, which might include this.  But since that's
    >> such a long-term approach, I don't think it's the right thing
    >> to wait for here, nor is it the right thing to leave decent
    >> security optional.  Thus, I don't agree with your opinion on
    >> this, but you're welcome to attempt to argue it with the IESG
    >> ([email-masked]) or the Security directorate ([email-masked]).
    >> ...
>
I'm missing what this is all about?  Etag?  If so, how does that have
to do with security?
Something else?

Date: Fri, 23 Jun 2006 21:44:35 +0200
From: Julian Reschke <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] References in draft-dusseault-caldav-12
Cc: The IESG <[email-masked]>, CalDAV DevList <[email-masked]>

Lisa Dusseault schrieb:
> 
> On Jun 23, 2006, at 12:29 PM, Julian Reschke wrote:
> 
>> Lisa Dusseault schrieb:
>>> ...
>>> It would indeed be better to solve it in the base spec if we had time 
>>> and resources.  Mark Nottingham is holding a bar BOF in Montreal to 
>>> see if there's interest in making some updates to HTTP, which might 
>>> include this.  But since that's such a long-term approach, I don't 
>>> think it's the right thing to wait for here, nor is it the right 
>>> thing to leave decent security optional.
>>> Thus, I don't agree with your opinion on this, but you're welcome to 
>>> attempt to argue it with the IESG ([email-masked]) or the Security 
>>> directorate ([email-masked]).
>>> ...
>>
>> OK, let's try a very simple question:
>>
>> How are the security requirements for CalDAV different from those for 
>> WebDAV?
> 
> It's not.  WebDAV makes the same requirement, with the exception of not 
> making TLS the mandatory-to-implement mechanism.  CalDAV simply goes a 
> step further in ensuring interoperability, in addition to security.
> 
> Would you propose updating RFC2518bis to make TLS mandatory?

The point I'm trying to make is that if CalDAV and WebDAV share the same 
security requirements, they optimally should say the same thing. As 
CalDAV already normatively refers to RFC2518bis, this means it doesn't 
need to say anything about it all.

I'm not a security expert. But if the experts think that what RFC2518bis 
currently says isn't sufficient, then yes, it should be updated.

Best regards, Julian

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] References in draft-dusseault-caldav-12
Date: Fri, 23 Jun 2006 12:37:37 -0700
To: Julian Reschke <[email-masked]>
Cc: The IESG <[email-masked]>, CalDAV DevList <[email-masked]>

On Jun 23, 2006, at 12:29 PM, Julian Reschke wrote:

> Lisa Dusseault schrieb:
>> ...
>> It would indeed be better to solve it in the base spec if we had  
>> time and resources.  Mark Nottingham is holding a bar BOF in  
>> Montreal to see if there's interest in making some updates to  
>> HTTP, which might include this.  But since that's such a long-term  
>> approach, I don't think it's the right thing to wait for here, nor  
>> is it the right thing to leave decent security optional.
>> Thus, I don't agree with your opinion on this, but you're welcome  
>> to attempt to argue it with the IESG ([email-masked]) or the  
>> Security directorate ([email-masked]).
>> ...
>
> OK, let's try a very simple question:
>
> How are the security requirements for CalDAV different from those  
> for WebDAV?

It's not.  WebDAV makes the same requirement, with the exception of  
not making TLS the mandatory-to-implement mechanism.  CalDAV simply  
goes a step further in ensuring interoperability, in addition to  
security.

Would you propose updating RFC2518bis to make TLS mandatory?

Lisa

Date: Fri, 23 Jun 2006 21:29:35 +0200
From: Julian Reschke <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] References in draft-dusseault-caldav-12
Cc: The IESG <[email-masked]>, CalDAV DevList <[email-masked]>

Lisa Dusseault schrieb:
> ...
> It would indeed be better to solve it in the base spec if we had time 
> and resources.  Mark Nottingham is holding a bar BOF in Montreal to see 
> if there's interest in making some updates to HTTP, which might include 
> this.  But since that's such a long-term approach, I don't think it's 
> the right thing to wait for here, nor is it the right thing to leave 
> decent security optional.
> 
> Thus, I don't agree with your opinion on this, but you're welcome to 
> attempt to argue it with the IESG ([email-masked]) or the Security 
> directorate ([email-masked]).
> ...

OK, let's try a very simple question:

How are the security requirements for CalDAV different from those for 
WebDAV?

If they are the same, CalDAV should just refer to RFC2518bis.

If you think they aren't, please explain how.

Best regards, Julian

(yes, [email-masked] copied)

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] References in draft-dusseault-caldav-12
Date: Fri, 23 Jun 2006 12:08:19 -0700
To: Julian Reschke <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

On Jun 23, 2006, at 11:22 AM, Julian Reschke wrote:

> Lisa Dusseault schrieb:
>> I answered too fast and forgot one important point:  a single,  
>> mandatory-to-implement secure transport is necessary to have both  
>> interoperability and to meet the "no plain-text passwords in the  
>> clear" requirement.  If a server supported only IPSec and a client  
>> supported only TLS, that would not be interoperable.  I find TLS  
>> to be the preferable mandatory-to-implement solution.
>> It looks like our text could still do with some improvement  
>> however; something along the lines of "Servers MUST NOT offer  
>> BASIC over an unprotected channel.  Clients MUST support TLS in  
>> order to provide one channel-encryption mechanism that servers can  
>> rely on if they decide to offer BASIC."
>> ...
>
> I really think it's an extremely bad idea if each protocol that  
> happens to use HTTP as transport comes with it's own requirements  
> here. This is an issue which is common to WebDAV itself, CalDav,  
> AtomPub and so on.
>
> Are you saying that the IESG expects the authors of each of these  
> specs to come up with their own solution?
>
> If this problem really requires attention, it should be solved in a  
> base spec others can rely on. It definitively doesn't belong into  
> CalDAV (why would it have security requirements different from  
> those in WebDAV, for instance???).
>

It would indeed be better to solve it in the base spec if we had time  
and resources.  Mark Nottingham is holding a bar BOF in Montreal to  
see if there's interest in making some updates to HTTP, which might  
include this.  But since that's such a long-term approach, I don't  
think it's the right thing to wait for here, nor is it the right  
thing to leave decent security optional.

Thus, I don't agree with your opinion on this, but you're welcome to  
attempt to argue it with the IESG ([email-masked]) or the Security  
directorate ([email-masked]).

Lisa

Date: Fri, 23 Jun 2006 20:22:07 +0200
From: Julian Reschke <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] References in draft-dusseault-caldav-12
Cc: CalDAV DevList <[email-masked]>

Lisa Dusseault schrieb:
> I answered too fast and forgot one important point:  a single, 
> mandatory-to-implement secure transport is necessary to have both 
> interoperability and to meet the "no plain-text passwords in the clear" 
> requirement.  If a server supported only IPSec and a client supported 
> only TLS, that would not be interoperable.  I find TLS to be the 
> preferable mandatory-to-implement solution.
> 
> It looks like our text could still do with some improvement however; 
> something along the lines of "Servers MUST NOT offer BASIC over an 
> unprotected channel.  Clients MUST support TLS in order to provide one 
> channel-encryption mechanism that servers can rely on if they decide to 
> offer BASIC."
> 
> ...

I really think it's an extremely bad idea if each protocol that happens 
to use HTTP as transport comes with it's own requirements here. This is 
an issue which is common to WebDAV itself, CalDav, AtomPub and so on.

Are you saying that the IESG expects the authors of each of these specs 
to come up with their own solution?

If this problem really requires attention, it should be solved in a base 
spec others can rely on. It definitively doesn't belong into CalDAV (why 
would it have security requirements different from those in WebDAV, for 
instance???).

Best regards, Julian

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] References in draft-dusseault-caldav-12
Date: Fri, 23 Jun 2006 11:07:08 -0700
To: "Kervin L. Pierre" <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

I answered too fast and forgot one important point:  a single,  
mandatory-to-implement secure transport is necessary to have both  
interoperability and to meet the "no plain-text passwords in the  
clear" requirement.  If a server supported only IPSec and a client  
supported only TLS, that would not be interoperable.  I find TLS to  
be the preferable mandatory-to-implement solution.

It looks like our text could still do with some improvement however;  
something along the lines of "Servers MUST NOT offer BASIC over an  
unprotected channel.  Clients MUST support TLS in order to provide  
one channel-encryption mechanism that servers can rely on if they  
decide to offer BASIC."

lisa

On Jun 23, 2006, at 11:03 AM, Lisa Dusseault wrote:

>
> On Jun 23, 2006, at 10:57 AM, Kervin L. Pierre wrote:
>
>> Hello,
>>
>> I think it can be argued that since 4.1.1 states
>> that either TLS or IPSEC is valid to remedy the
>> situation, that the authors were suggesting that
>> the protocol's _use_ be protected and not that the
>> protocol itself has to supply protection. Ie.
>> plain-text CalDAV over an IPSEC VPN would satisfy
>> 4.1.1 in that case.
>>
>> In other words the CalDAV spec does not have to
>> mandate TLS but rather mandate that either TLS or
>> IPSEC be used when using the protocol.
>
> This is a very good point, thanks.
>
>> PS. + $0.02 :)  The Etag issue, this, and a recent
>> iCalendar issue seem to stem from CalDAV not
>> 'looking the other way' on deficiencies in
>> HTTP and iCalendar.
>>
>> This is commendable, but by doing this it forces
>> developers to investigate and modify components
>> that they otherwise would have been able to
>> utilize as 'black box' components.
>>
>> For example, clients who would simply call a HTTP
>> stack with a url, username and password will now
>> have to check the type of authorization is being
>> used and fail that connection if auth is basic.
>> Not to mention relay that to the user in a way
>> that is useful to them.  This is compounded by the
>> fact that the authorization layer may not be in
>> the developers control.  Eg. The client application
>> already supports WebDAV or some other HTTP protocol
>> and the CalDAV component or layer simply calls that
>> function with a simplified API interface.
>>
>> My point is maybe we should avoid conflicting with
>> lower level protocols if at all possible, for the
>> sake of adoption?
>
> A pragmatic approach, yes.  Philosophically I tend to agree with  
> you (there are too many cases to list, where we simply went with  
> what the underlying protocols provided, as that was our first  
> choice usually), but there are always a couple exceptions.  The  
> ETag ambiguity simply interfered too much with interoperability and  
> reliable synching.  And the secured transport (when using plain- 
> text passwords) is not only a good idea, it's important to get  
> CalDAV approved.
>
> Lisa

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] References in draft-dusseault-caldav-12
Date: Fri, 23 Jun 2006 11:03:31 -0700
To: Kervin L.Pierre <[email-masked]>
Cc: [email-masked]

On Jun 23, 2006, at 10:57 AM, Kervin L. Pierre wrote:

> Hello,
>
> I think it can be argued that since 4.1.1 states
> that either TLS or IPSEC is valid to remedy the
> situation, that the authors were suggesting that
> the protocol's _use_ be protected and not that the
> protocol itself has to supply protection. Ie.
> plain-text CalDAV over an IPSEC VPN would satisfy
> 4.1.1 in that case.
>
> In other words the CalDAV spec does not have to
> mandate TLS but rather mandate that either TLS or
> IPSEC be used when using the protocol.

This is a very good point, thanks.

> PS. + $0.02 :)  The Etag issue, this, and a recent
> iCalendar issue seem to stem from CalDAV not
> 'looking the other way' on deficiencies in
> HTTP and iCalendar.
>
> This is commendable, but by doing this it forces
> developers to investigate and modify components
> that they otherwise would have been able to
> utilize as 'black box' components.
>
> For example, clients who would simply call a HTTP
> stack with a url, username and password will now
> have to check the type of authorization is being
> used and fail that connection if auth is basic.
> Not to mention relay that to the user in a way
> that is useful to them.  This is compounded by the
> fact that the authorization layer may not be in
> the developers control.  Eg. The client application
> already supports WebDAV or some other HTTP protocol
> and the CalDAV component or layer simply calls that
> function with a simplified API interface.
>
> My point is maybe we should avoid conflicting with
> lower level protocols if at all possible, for the
> sake of adoption?

A pragmatic approach, yes.  Philosophically I tend to agree with you  
(there are too many cases to list, where we simply went with what the  
underlying protocols provided, as that was our first choice usually),  
but there are always a couple exceptions.  The ETag ambiguity simply  
interfered too much with interoperability and reliable synching.  And  
the secured transport (when using plain-text passwords) is not only a  
good idea, it's important to get CalDAV approved.

Lisa

Date: Fri, 23 Jun 2006 13:57:37 -0400
From: "Kervin L. Pierre" <[email-masked]>
Organization: Adevsoft Inc
To: [email-masked]
Subject: Re: [Ietf-caldav] References in draft-dusseault-caldav-12

Hello,

I think it can be argued that since 4.1.1 states
that either TLS or IPSEC is valid to remedy the
situation, that the authors were suggesting that
the protocol's _use_ be protected and not that the
protocol itself has to supply protection. Ie.
plain-text CalDAV over an IPSEC VPN would satisfy
4.1.1 in that case.

In other words the CalDAV spec does not have to
mandate TLS but rather mandate that either TLS or
IPSEC be used when using the protocol.

PS. + $0.02 :)  The Etag issue, this, and a recent
iCalendar issue seem to stem from CalDAV not
'looking the other way' on deficiencies in
HTTP and iCalendar.

This is commendable, but by doing this it forces
developers to investigate and modify components
that they otherwise would have been able to
utilize as 'black box' components.

For example, clients who would simply call a HTTP
stack with a url, username and password will now
have to check the type of authorization is being
used and fail that connection if auth is basic.
Not to mention relay that to the user in a way
that is useful to them.  This is compounded by the
fact that the authorization layer may not be in
the developers control.  Eg. The client application
already supports WebDAV or some other HTTP protocol
and the CalDAV component or layer simply calls that
function with a simplified API interface.

My point is maybe we should avoid conflicting with
lower level protocols if at all possible, for the
sake of adoption?

Best regards,
Kervin

Lisa Dusseault wrote:
> 
> On Jun 23, 2006, at 6:23 AM, Julian Reschke wrote:
>>
>>> Right now CalDAV effectively mandates the use of TLS (again not SSL) 
>>> when BASIC authentication is used. Is that too strong of a position?
>>
>> I would think so. It's just something that CalDAV doesn't need to make 
>> requirements about. See similar discussion for AtomPub.
> 
> That used to be true, when RFC2616 and RFC2518 were published.  It's not 
> true any more.  See also RFC3552, particularly section 4.1
> 
>    "Unprotected (plaintext)
>    username/password systems are not acceptable in IETF standards."
> 
> So, today the IESG imposes a higher standard, because the technology is 
> available to reasonably do so.  IMO, this is the right thing to do.
> 
> Lisa
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
> 

Date: Fri, 23 Jun 2006 19:17:35 +0200
From: Julian Reschke <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] References in draft-dusseault-caldav-12
Cc: [email-masked]

Lisa Dusseault schrieb:
> 
> On Jun 23, 2006, at 6:23 AM, Julian Reschke wrote:
>>
>>> Right now CalDAV effectively mandates the use of TLS (again not SSL) 
>>> when BASIC authentication is used. Is that too strong of a position?
>>
>> I would think so. It's just something that CalDAV doesn't need to make 
>> requirements about. See similar discussion for AtomPub.
> 
> That used to be true, when RFC2616 and RFC2518 were published.  It's not 
> true any more.  See also RFC3552, particularly section 4.1
> 
>    "Unprotected (plaintext)
>    username/password systems are not acceptable in IETF standards."
> 
> So, today the IESG imposes a higher standard, because the technology is 
> available to reasonably do so.  IMO, this is the right thing to do.

I don't argue that plain text passwords shouldn't be used on non-secure 
connections. But that's an HTTP question, not one for CalDAV to answer.

Best regards, Julian

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] References in draft-dusseault-caldav-12
Date: Fri, 23 Jun 2006 09:47:19 -0700
To: Julian Reschke <[email-masked]>
Cc: [email-masked]

On Jun 23, 2006, at 6:23 AM, Julian Reschke wrote:
>
>> Right now CalDAV effectively mandates the use of TLS (again not  
>> SSL) when BASIC authentication is used. Is that too strong of a  
>> position?
>
> I would think so. It's just something that CalDAV doesn't need to  
> make requirements about. See similar discussion for AtomPub.

That used to be true, when RFC2616 and RFC2518 were published.  It's  
not true any more.  See also RFC3552, particularly section 4.1

    "Unprotected (plaintext)
    username/password systems are not acceptable in IETF standards."

So, today the IESG imposes a higher standard, because the technology  
is available to reasonably do so.  IMO, this is the right thing to do.

Lisa

Date: Fri, 23 Jun 2006 17:02:20 +0200
Subject: Re: [Ietf-caldav] Access of external attachments a MUST?
From: Alexander Traud <[email-masked]>
To: CalDav <[email-masked]>

> [CalDAV clients] just have to be able to 'hand-off' the URL for processin=
g by
> some other service (e.g. local "helper app").

Just my thoughts on *this* "have to":
Clients might not be able to defer processing. In J2ME MIDP version 2 it is
possible to defer this, however, there is no control over the outcome how
and whether it succeeds. That is okay. However, in MIDP version 1 for
example, there is not even such a mechanism. Just one example I am aware
right now, there might be zillions of similar ones. Even in MIDP version 2
it does not offer this for URIs but URLs only.

Even a MUST only for deferring, will be a problem. You could save this,
making HTTP fetching a MUST=E2=80=A0 and deferring for all other URIs a condition=
al
MUST, depending whether the environment allows something like this. When
URLs are possible, this mechanism MUST be used.

=E2=80=A0 =E2=80=A6as CalDAV is based on WebDAV and WebDAV is based on HTTP. Or is WebD=
AV
not limited to HTTP/HTTP theoretically? Then the CalDAV bearer would a MUST
instead of saying anything about HTTP.

Date: Fri, 23 Jun 2006 17:02:20 +0200
Subject: Re: [Ietf-caldav] Client property loss?
From: Alexander Traud <[email-masked]>
To: CalDav <[email-masked]>

> There are several use cases that justify the statement we currently have:

Do not see a reason to point implementers on this. They figure out
themselves, when they need this (dangerous) feature. Additionally, I do not
say anything about MUST.

>> I would like to see a statement like "highly encouraging to" save keep all
>> unknown-to-client fields as far as possible here.
> Perhaps we could also mention that they need to do that if they want to
> 'hand-off' the iCal object to some other service (eg sync.).

What happens, when the server is not reachable? Let us tighten this a bit
more: Any client which (might) exchange a component with a third party
SHOULD load all properties. What about that? Yes I know, a SHOULD is rather
useless, however, better than the current situation. Perhaps the implementer
things twice about it then.

Date: Fri, 23 Jun 2006 09:39:48 -0400
From: Cyrus Daboo <[email-masked]>
To: Alexander Traud <[email-masked]>, CalDav <[email-masked]>
Subject: Re: [Ietf-caldav] Access of external attachments a MUST?

Hi Alexander,

--On June 23, 2006 11:11:54 AM +0200 Alexander Traud 
<[email-masked]> wrote:

> Just noticed, the whole Guidelines section *seems* to be informative
> instead of normative. You should state this in brackets to chapter 8.
> Found this in the to-be-removed version history only.
>
> This means every "MUST" in chapter 8 just repeats a MUST in another part
> of the/a specification for clarity. However, I cannot find such a
> references for some "MUST"s in chapter 8.5 and 8.6. Either find and
> mention a reference or drop the parts affected or move the parts to a
> chapter before chapter 8. Otherwise, have I overlooked these MUSTs and it
> is my misunderstanding?
>
> Any comments on this? Especially a word from the author(s) about the idea
> behind chapter 8 would be helpful - especially 8.5/8.6.
>

We (authors) are working on some new text for the attachment section to 
clarify the client behaviour. The bottom line is CalDAV clients themselves 
are not required to download/execute external attachments - they just have 
to be able to 'hand-off' the URL for processing by some other service (e.g. 
local "helper app").

As to Section 8 being informative - I will check about that, but I do think 
its normative because we are using MUST etc.

-- 
Cyrus Daboo

Date: Fri, 23 Jun 2006 15:23:38 +0200
From: Julian Reschke <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-caldav] References in draft-dusseault-caldav-12
Cc: [email-masked]

Cyrus Daboo schrieb:
> Hi Julian,
> 
> --On June 23, 2006 8:24:27 AM +0200 Julian Reschke 
> <[email-masked]> wrote:
> 
>> Running the checker...:
>>
>> Normative References:
>>
>> RFC2119: [BEST CURRENT PRACTICE] (-> BCP0014) ok
>> RFC2246: [PROPOSED STANDARD] obsoleted by RFC4346
>> RFC2445: [PROPOSED STANDARD] ok
>> RFC2446: [PROPOSED STANDARD] ok
>> RFC2616: [DRAFT STANDARD] ok
>> RFC2818: [INFORMATIONAL] ok
>> RFC3253: [PROPOSED STANDARD] ok
>> RFC3688: [BEST CURRENT PRACTICE] (-> BCP0081) ok
>> RFC3744: [PROPOSED STANDARD] ok
>> draft-ietf-webdav-rfc2518bis-15: [2006-05-15 active] ok
>>
>> Informative References:
>>
>> RFC2251: [PROPOSED STANDARD] obsoleted by RFC4510 RFC4511 RFC4513 RFC4512
>> RFC2426: [PROPOSED STANDARD] ok
>> RFC2739: [PROPOSED STANDARD] ok
>> RFC4331: [PROPOSED STANDARD] ok
>>
>> So,
>>
>> - the normative ref to RFF2818 may be problematic if CalDav is supposed
>> to be on the standards track (I think this has already been mentioned)
> 
> The issue of the 2818 reference was brought up during IESG review 
> yesterday. We are trying to determine the best way to deal with this.
> 
> Just as background: 2818 describes how to use TLS (as opposed to SSL) 
> within HTTP. Its status is 'informational', however CalDAV references it 
> as a 'normative' reference and thus causes a conflict.

Yep.

> Right now CalDAV effectively mandates the use of TLS (again not SSL) 
> when BASIC authentication is used. Is that too strong of a position? 

I would think so. It's just something that CalDAV doesn't need to make 
requirements about. See similar discussion for AtomPub.

> Should we allow SSL and TLS (even though SSL is not an IETF standard)? 
> How many client/server implementations actually handle TLS as opposed to 
> SSL, and how many follow 2818?

No idea.

> There are several ways to try and resolve this:
> 
> 1) Downgrade 2818 to an 'Informative reference' in CalDAV and add SSL 
> (or a 'suitable' security layer') as other options.

...actually, don't mention it at all.

> 2) Ask for a 'variance' from IESG to allow 2818 to be included as a 
> normative reference - this would require CalDAV implementations using 
> BASIC to support it.

Obviously not a good idea if today's clients can't do it.

> 3) Ask to have 2818 moved to proposed status so CalDAV's normative 
> reference would be OK.

That's certainly not easy.

Or 4) (for completeness): submit CalDAV as "informational" as well.

> The first two choices will likely require another last call of the 
> document as we are changing something that was previously 'normative'.

Yes, possibly.

>> - the ref to RFC2251 probably should be updated
> 
> Yup - the new LDAP documents just came out. I will look into updating 
> our reference.

Thanks (that probably could be done during AUTH48 as well).

Best regards, Julian

Date: Fri, 23 Jun 2006 09:06:50 -0400
From: Cyrus Daboo <[email-masked]>
To: Julian Reschke <[email-masked]>, [email-masked]
Subject: Re: [Ietf-caldav] References in draft-dusseault-caldav-12

Hi Julian,

--On June 23, 2006 8:24:27 AM +0200 Julian Reschke <[email-masked]> 
wrote:

> Running the checker...:
>
> Normative References:
>
> RFC2119: [BEST CURRENT PRACTICE] (-> BCP0014) ok
> RFC2246: [PROPOSED STANDARD] obsoleted by RFC4346
> RFC2445: [PROPOSED STANDARD] ok
> RFC2446: [PROPOSED STANDARD] ok
> RFC2616: [DRAFT STANDARD] ok
> RFC2818: [INFORMATIONAL] ok
> RFC3253: [PROPOSED STANDARD] ok
> RFC3688: [BEST CURRENT PRACTICE] (-> BCP0081) ok
> RFC3744: [PROPOSED STANDARD] ok
> draft-ietf-webdav-rfc2518bis-15: [2006-05-15 active] ok
>
> Informative References:
>
> RFC2251: [PROPOSED STANDARD] obsoleted by RFC4510 RFC4511 RFC4513 RFC4512
> RFC2426: [PROPOSED STANDARD] ok
> RFC2739: [PROPOSED STANDARD] ok
> RFC4331: [PROPOSED STANDARD] ok
>
> So,
>
> - the normative ref to RFF2818 may be problematic if CalDav is supposed
> to be on the standards track (I think this has already been mentioned)

The issue of the 2818 reference was brought up during IESG review 
yesterday. We are trying to determine the best way to deal with this.

Just as background: 2818 describes how to use TLS (as opposed to SSL) 
within HTTP. Its status is 'informational', however CalDAV references it as 
a 'normative' reference and thus causes a conflict.

Right now CalDAV effectively mandates the use of TLS (again not SSL) when 
BASIC authentication is used. Is that too strong of a position? Should we 
allow SSL and TLS (even though SSL is not an IETF standard)? How many 
client/server implementations actually handle TLS as opposed to SSL, and 
how many follow 2818?

There are several ways to try and resolve this:

1) Downgrade 2818 to an 'Informative reference' in CalDAV and add SSL (or a 
'suitable' security layer') as other options.

2) Ask for a 'variance' from IESG to allow 2818 to be included as a 
normative reference - this would require CalDAV implementations using BASIC 
to support it.

3) Ask to have 2818 moved to proposed status so CalDAV's normative 
reference would be OK.

The first two choices will likely require another last call of the document 
as we are changing something that was previously 'normative'.

> - the ref to RFC2251 probably should be updated

Yup - the new LDAP documents just came out. I will look into updating our 
reference.

-- 
Cyrus Daboo

Date: Fri, 23 Jun 2006 08:56:53 -0400
From: Cyrus Daboo <[email-masked]>
To: Alexander Traud <[email-masked]>, [email-masked]
Subject: Re: [Ietf-caldav] Client property loss?

Hi Alexander,

--On June 23, 2006 11:11:54 AM +0200 Alexander Traud 
<[email-masked]> wrote:

> Keeping only a part of components is a big problem in data
> synchronization. The next paragraph does not help, when the client
> forwards (partial) components to third parties not involving the original
> party (i.e. a CalDAV server). With today memory card sizes and prices,
> storage is not such a issue anymore even for clients.

There are several use cases that justify the statement we currently have:

1) Mobile devices - these do have limited storage.

2) A 'presentation only' calendar system that simply displays calendar data 
- such a system would only need to get the properties and values it would 
actually use.

3) A web-calendar using client-side javascript/xsl or whatever to transform 
the iCal (or xCal) data into presentations elements. Again, they would have 
no need for attachment data until a user actually requests to download an 
inline attachment.

The paragraph after the one you quoted does imply that clients will have to 
deal with the entire iCal object to do updates. Perhaps we could also 
mention that they need to do that if they want to 'hand-off' the iCal 
object to some other service (eg sync.).

-- 
Cyrus Daboo

Date: Fri, 23 Jun 2006 11:11:54 +0200
From: Alexander Traud <[email-masked]>
To: <[email-masked]>
Subject: [Ietf-caldav] Client property loss?

Chapter 8.2.2
https://www.greenbytes.de/tech/webdav/draft-dusseault-caldav-12.html#rfc.sec
tion.8.2.2
> Since some calendar property values can be large (e.g., ATTACH or ATTENDEE)
> clients can choose to restrict the calendar properties to be returned in a
> calendaring REPORT request to those it knows it will use.

I would like to see a statement like "highly encouraging to" save keep all
unknown-to-client fields as far as possible here.

Keeping only a part of components is a big problem in data synchronization.
The next paragraph does not help, when the client forwards (partial)
components to third parties not involving the original party (i.e. a CalDAV
server). With today memory card sizes and prices, storage is not such a
issue anymore even for clients.

Pointing to such a case and encouraging implementers might help to improve
data synchronization.

Chapter 5.3.3
> http://lists.osafoundation.org/pipermail/ietf-caldav/2005-December/000565.html
https://www.greenbytes.de/tech/webdav/draft-dusseault-caldav-12.html#rfc.sec
tion.5.3.3
> Servers MUST support the use of non-standard components, properties and
> parameters in calendar object resources stored via the PUT method.

This was discussed on this mailing list before and as far as I understand
because of WebDAV specification client properties (of the iCalendar
specification unknown to the server) SHOULD be kept. However, repeating or
pointing to this requirement might help (force?) implementers to keep *all*
type of properties from the client even standard-but-unknown-to-server and
not only X-type ones.

By the way is this now a MUST or a SHOULD to keep
standard-but-unknown-to-server properties in CalDAV? I do not want to repeat
or start the discussion on this again, however, I do not understand the
result of the discussion while reading the mailing list archive. A server
MUST keep X-type properties, however, for standard ones keeping is SHOULD
only? Do not get that. Where is my misunderstanding?

Two clarifications I would like to see in the specification. Any comment on
those?

Date: Fri, 23 Jun 2006 11:11:54 +0200
Subject: Re: [Ietf-caldav] Access of external attachments a MUST?
From: Alexander Traud <[email-masked]>
To: CalDav <[email-masked]>

Just noticed, the whole Guidelines section *seems* to be informative instead
of normative. You should state this in brackets to chapter 8. Found this in
the to-be-removed version history only.

This means every "MUST" in chapter 8 just repeats a MUST in another part of
the/a specification for clarity. However, I cannot find such a references
for some "MUST"s in chapter 8.5 and 8.6. Either find and mention a reference
or drop the parts affected or move the parts to a chapter before chapter 8.
Otherwise, have I overlooked these MUSTs and it is my misunderstanding?

Any comments on this? Especially a word from the author(s) about the idea
behind chapter 8 would be helpful - especially 8.5/8.6.

Date: Fri, 23 Jun 2006 08:24:27 +0200
From: Julian Reschke <[email-masked]>
To: [email-masked]
Subject: [Ietf-caldav] References in draft-dusseault-caldav-12

Running the checker...:

Normative References:

RFC2119: [BEST CURRENT PRACTICE] (-> BCP0014) ok
RFC2246: [PROPOSED STANDARD] obsoleted by RFC4346
RFC2445: [PROPOSED STANDARD] ok
RFC2446: [PROPOSED STANDARD] ok
RFC2616: [DRAFT STANDARD] ok
RFC2818: [INFORMATIONAL] ok
RFC3253: [PROPOSED STANDARD] ok
RFC3688: [BEST CURRENT PRACTICE] (-> BCP0081) ok
RFC3744: [PROPOSED STANDARD] ok
draft-ietf-webdav-rfc2518bis-15: [2006-05-15 active] ok

Informative References:

RFC2251: [PROPOSED STANDARD] obsoleted by RFC4510 RFC4511 RFC4513 RFC4512
RFC2426: [PROPOSED STANDARD] ok
RFC2739: [PROPOSED STANDARD] ok
RFC4331: [PROPOSED STANDARD] ok

So,

- the normative ref to RFF2818 may be problematic if CalDav is supposed 
to be on the standards track (I think this has already been mentioned)

- the ref to RFC2251 probably should be updated

Best regards, Julian

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Access of external attachments a MUST?
Date: Thu, 22 Jun 2006 12:12:18 +0200
To: CalDAV DevList <[email-masked]>

On Jun 22, 2006, at 08:55, Alexander Traud wrote:
> We have to *access* - not just refer to - external attachments (see =20=

> chapter
> 8.5.2 of current CalDAV draft 12).

Well, I think there is no specific definition of what "access" means. =20=

In the given context "access" will usually mean opening the =20
attachment in/using the systems web browser (inline or out of =20
application).
Eg Kontact can open external attachments as tabs inside the =20
appointment viewer by embedding Konqueror (or by opening Konqueror =20
itself).

But I agree, this section could be improved in the wording :-)

> My English dictionary states for access:
> "fetching and opening [the attachment]". Please correct me, if I
> misunderstand anything here.

Well, your misunderstanding is that there is a 1:1 mapping between =20
words and definitions :-) There are plenty of definitions for "access":

   http://www.infoplease.com/ipd/A0304736.html

Which is why the section should be a bit more specific about this. As =20=

this threads points out it can be misunderstood.

I really don't think that it is the intention that CalDAV clients =20
themselves must _fetch_ external content (and this is not written in =20
the spec). What would be the point? This doesn't belong into CalDAV =20
and is already specified in iCalendar.

   "CalDAV clients MUST support inline attachments as specified in =20
iCalendar"

This is a DUP if we already specify that "CalDAV clients MUST support =20=

iCalendar", no?

Probably the motivation to add a chapter about that topic was to =20
raise awareness that client will actually want to do that.
I suppose a situation which should not arise is that a user attaches =20
a lovely Word file to an event with one client, and when a different =20
client accesses the event the file is not even shown. However it =20
obviously cannot imply that the other clients needs to be able to =20
process Word files :-) [or arbitary URLs]

> https://www.greenbytes.de/tech/webdav/draft-dusseault-=20
> caldav-12.html#rfc.sec
> tion.8.5.2
>> =85 if the client accesses any calendar object resource it MUST be =20=

>> capable of
>> also accessing the external attachment if one exists.

Greets,
   Helge

Date: Thu, 22 Jun 2006 08:55:58 +0200
Subject: Re: [Ietf-caldav] Access of external attachments a MUST?
From: Alexander Traud <[email-masked]>
To: CalDav <[email-masked]>

Helge Hess wrote on 22nd June 2006:
> The requirement just states that the client and the server must store
> those URLs, it doesn't say that they need to be able to open / deal-
> with the URLs.

Cannot follow this interpretation.
We have to *access* - not just refer to - external attachments (see chapter
8.5.2 of current CalDAV draft 12). My English dictionary states for access:
"fetching and opening [the attachment]". Please correct me, if I
misunderstand anything here.

https://www.greenbytes.de/tech/webdav/draft-dusseault-caldav-12.html#rfc.se=
c
tion.8.5.2
> =E2=80=A6 if the client accesses any calendar object resource it MUST be capabl=
e of
> also accessing the external attachment if one exists.

Date: Thu, 22 Jun 2006 08:53:51 +0200
From: Julian Reschke <[email-masked]>
To: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Access of external attachments a MUST?
Cc: CalDAV DevList <[email-masked]>

Helge Hess schrieb:
> On Jun 22, 2006, at 24:49, Alexander Traud wrote:
>> I know I am here in an IETF environment, however, there are a lot of 
>> devices
>> out there in the wild which do not have FTP and will never get built 
>> in (for
>> example J2ME MIDP). So I would have to add a FTP client stack just to get
>> CalDAV client interoperability. Is this intended?
> 
> I can't really follow what you are talking about. An external attachment 
> is just a URL, right? All iCalendar/CalDAV specifies is that URLs can be 
> associated with events/tasks/etc.
> The requirement just states that the client and the server must store 
> those URLs, it doesn't say that they need to be able to open / deal-with 
> the URLs.

Well, that's not what it says:

"if the client accesses any calendar object resource it MUST be capable 
of also accessing the external attachment if one exists" 
(<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-12.html#rfc.section.8.5.2>)

As far as I can tell, that requirement is non-implementable, because it 
doesn't say what types of URLs are supported. That is, it can only be 
validated at runtime.

 > ...

Best regards, Julian

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Access of external attachments a MUST?
Date: Thu, 22 Jun 2006 01:05:17 +0200
To: CalDAV DevList <[email-masked]>

On Jun 22, 2006, at 24:49, Alexander Traud wrote:
> I know I am here in an IETF environment, however, there are a lot  
> of devices
> out there in the wild which do not have FTP and will never get  
> built in (for
> example J2ME MIDP). So I would have to add a FTP client stack just  
> to get
> CalDAV client interoperability. Is this intended?

I can't really follow what you are talking about. An external  
attachment is just a URL, right? All iCalendar/CalDAV specifies is  
that URLs can be associated with events/tasks/etc.
The requirement just states that the client and the server must store  
those URLs, it doesn't say that they need to be able to open / deal- 
with the URLs.

Thats exactly like with HTML where an <a href> or even an <img src>  
can contain arbitary URLs and its the browsers tasks to decide how to  
deal with them (I think the same is true for WML).

I suppose the requirement to store external attachments was added  
because not all servers store the iCal as a verbatim copy, that is,  
they might remove/reorder/transform various fields of the iCal  
entity. CalDAV basically says they are not allowed to do this for  
external attachments.

Greets,
   Helge

Date: Thu, 22 Jun 2006 00:49:13 +0200
Subject: Re: [Ietf-caldav] Access of external attachments a MUST?
From: Alexander Traud <[email-masked]>
To: CalDav <[email-masked]>

> FTP for external attachments

I know I am here in an IETF environment, however, there are a lot of devices
out there in the wild which do not have FTP and will never get built in (for
example J2ME MIDP). So I would have to add a FTP client stack just to get
CalDAV client interoperability. Is this intended?

I think you want to force implementers to use external attachments rather
than internal ones. This is a good idea, however, rather than forcing I
would go for convincing them. Make it SHOULD, however, explain why external
attachments are useful.

Nevertheless, personally I could live with a MUST for HTTP URIs. Perhaps
even HTTPS.

> If some clients can't handle external attachments, that would be a serious
> barrier to using them

Could you elaborate a bit more or point to a reference? I do not understand
your aims, yet. Was this discussed before? Have not found anything in the
archives.

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Access of external attachments a MUST?
Date: Wed, 21 Jun 2006 13:46:01 -0700
To: Alexander Traud <[email-masked]>
Cc: [email-masked]

On Jun 21, 2006, at 2:14 AM, Alexander Traud wrote:

> Chapter 8.5.2
> https://www.greenbytes.de/tech/webdav/draft-dusseault-=20
> caldav-12.html#rfc.sec
> tion.8.5.2
>> =85 if the client accesses any calendar object resource it MUST be =20=

>> capable of
>> also accessing the external attachment if one exists.
>
> Why is this a MUST?
>
We consider it a requirement that clients be able to handle both =20
internal and external attachments.  If some clients can't handle =20
external attachments, that would be a serious barrier to using them =20
despite the advantages of external attachments.

> It is impossible to access all URIs out there in one client. In my
> understanding, to confirm to CalDAV the client would need to reject =20=

> the
> whole component or the affected ATTACH property if the URI is not =20
> supported.
> Does this make sense if you want to forward the component to a =20
> third party
> client which might support this URI?

I think the intent was that this would be mostly HTTP URLs which =20
would be required to support, possibly also FTP.  Although we didn't =20
use MUST/MAY language, we provided some guidance on this in section =20
8.5.2:
"An external
    attachment could be:

    o  In a collection in the calendar collection containing the =20
calendar
       object resource;

    o  Somewhere else in the same repository that hosts the calendar
       collection; or

    o  On an HTTP or FTP server elsewhere."

It would certainly be sufficiently conducive to interoperability for =20
clients to support both HTTP and FTP for external attachments, and to =20=

error for other URI types.

lisa

From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>
Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements	in draft-dusseault-caldav-12
Date: Wed, 21 Jun 2006 10:23:20 -0700
To: Lisa Dusseault <[email-masked]>
Cc: Ted Hardie <[email-masked]>, HTTP Working Group <[email-masked]>, [email-masked], CalDAV DevList <[email-masked]>

--Apple-Mail-4-804709028
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

   Actually, I remember sending a few emails with feedback on this  
and not getting any replies, and then I went on my honeymoon, so it  
wasn't quite on my mind for a while.

   I think that document is the way to go, even if all it ends up  
saying is something similar to what you have in the CalDAV draft.

	-wsv

On Jun 20, 2006, at 4:59 PM, Lisa Dusseault wrote:

> We basically tried that.  What it turned into was this <http:// 
> www.ietf.org/internet-drafts/draft-whitehead-http-etag-00.txt> with  
> no consensus on the basic model or apparent drive to come to  
> consensus.  Got any feedback on that draft?

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

--Apple-Mail-4-804709028--

Date: Wed, 21 Jun 2006 16:27:16 +0200
Subject: Re: [Ietf-caldav] vCalender 1.0 component possible as return type?
From: Alexander Traud <[email-masked]>
To: CalDav <[email-masked]>

<C:supported-calendar-data xmlns:C="urn:ietf:params:xml:ns:caldav">
   <C:calendar-data content-type="text/calendar" />
   <C:calendar-data content-type="text/x-vcalendar" />
</C:supported-calendar-data>

I have to correct you, the above should be correct for vCalendar support, as
vCalendar 1.0 has no MIME media type registered with IANA and iCalendar does
not define a "version" parameter (see RFC2445). Correct me if I am wrong.

> we do not say anything about how a client might GET data in one preferred
> (supported) format over another.

Yes, there is no need to that in the CalDav specification.
The server detects the capabilities of the client through the HTTP "Accept"
header. When the client does not accept "text/calendar" or "text/calendar"
has a lower quality factor than another calendar data format supported by
the server, the one with the highest quality factor should be supplied to
the client.

>> Nevertheless, if [vCalendar 1.0 handling] succeeds, depends on the server
> a good client wanting to store calendar data in some other format will first
> check what is supported by the server and then only use a format that is known
> to be supported.

Sure, this is a way such a client should work then.
However, I was just asking the general idea whether it is possible at all.
Sorry for the confusion which my wrong wording and simplification created.

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] vCalender 1.0 component possible as return type?
Date: Wed, 21 Jun 2006 15:26:02 +0200
To: CalDAV DevList <[email-masked]>

On Jun 21, 2006, at 15:24, Cyrus Daboo wrote:
> However we do not say anything about how a client might GET data in  
> one preferred (supported) format over another.

Using the HTTP "accept" header?

Greets,
   Helge

Date: Wed, 21 Jun 2006 09:24:31 -0400
From: Cyrus Daboo <[email-masked]>
To: Alexander Traud <[email-masked]>, [email-masked]
Subject: Re: [Ietf-caldav] vCalender 1.0 component possible as return type?

Hi Cyrus,

--On June 21, 2006 9:02:58 AM -0400 Cyrus Daboo <[email-masked]> wrote:

> In theory a server could advertise:
>
>          <C:supported-calendar-data
>             xmlns:C="urn:ietf:params:xml:ns:caldav">
>            <C:calendar-data content-type="text/calendar" version="1.0"/>
>          </C:supported-calendar-data>
>
> Which would mean it ONLY supported vCalendar. However, section 2 states
> that iCalendar MUST be supported - so there is a little discrepancy there
> - I will look into fixing that.

To address this - section 2 mandates support for iCal V2, so the XML 
element above was wrong, it should have been:

          <C:supported-calendar-data
             xmlns:C="urn:ietf:params:xml:ns:caldav">
            <C:calendar-data content-type="text/calendar" version="1.0"/>
            <C:calendar-data content-type="text/calendar" version="2.0"/>
          </C:supported-calendar-data>

i.e. CalDAV servers are always required to support GET and PUT with iCal v2 
data, and MAY support GET/PUT with other calendar data types. However we do 
not say anything about how a client might GET data in one preferred 
(supported) format over another.

-- 
Cyrus Daboo

Date: Wed, 21 Jun 2006 09:02:58 -0400
From: Cyrus Daboo <[email-masked]>
To: Alexander Traud <[email-masked]>, [email-masked]
Subject: Re: [Ietf-caldav] vCalender 1.0 component possible as return type?

Hi Alexander,

--On June 21, 2006 10:52:44 AM +0200 Alexander Traud 
<[email-masked]> wrote:

> In reply to:
>> http://lists.osafoundation.org/pipermail/ietf-caldav/2005-May/000376.html
>
> I hope I understand this correctly, please correct me if I am wrong:
>
> - There is no requirement forcing a CalDAV client to understand or send
> iCalendar components. A CalDAV client can use for example vCalendar 1.0 or
> xCal or whatever as exchange format as long as the client states this in
> in Accept HTTP headers, of course. Nevertheless, if that succeeds,
> depends on the server.

Section 5.2.4 of the draft describes the CALDAV:supported-calendar-data. 
That is used by the server to advertise what types of calendar data it 
supports. In the absence of that property the server ONLY supports 
text/calendar VERSION:2.0. So a good client wanting to store calendar data 
in some other format will first check what is supported by the server and 
then only use a format that is known to be supported.

In theory a server could advertise:

         <C:supported-calendar-data
            xmlns:C="urn:ietf:params:xml:ns:caldav">
           <C:calendar-data content-type="text/calendar" version="1.0"/>
         </C:supported-calendar-data>

Which would mean it ONLY supported vCalendar. However, section 2 states 
that iCalendar MUST be supported - so there is a little discrepancy there - 
I will look into fixing that.

> - There is no requirement forcing a CalDAV server to alter a received
> vCalendar 1.0 component to iCalendar (on PUT or any other method) except a
> non-vCalendar aware client asks for the component. So a PUT with a
> vCalendar might be saved 1:1 by the server.

Correct - nothing forces a server to return calendar data in a format other 
than what was used to store it, but nothing prevents a server from doing 
that either.

Question: do you really have a need to still use vCalendar as opposed to 
iCalendar? If so, what is keeping you from upgrading?

-- 
Cyrus Daboo

Date: Wed, 21 Jun 2006 11:14:50 +0200
From: Alexander Traud <[email-masked]>
To: <[email-masked]>
Subject: [Ietf-caldav] Access of external attachments a MUST?

Chapter 8.5.2
https://www.greenbytes.de/tech/webdav/draft-dusseault-caldav-12.html#rfc.se=
c
tion.8.5.2
> =E2=80=A6 if the client accesses any calendar object resource it MUST be capabl=
e of
> also accessing the external attachment if one exists.

Why is this a MUST?

iCalendar chapter 4.8.1.1 Attachment
http://www.ietf.org/rfc/rfc2445.txt
> The default value type for this property is URI. The value type can also =
be
> set to BINARY to indicate inline binary encoded content information.

It is impossible to access all URIs out there in one client. In my
understanding, to confirm to CalDAV the client would need to reject the
whole component or the affected ATTACH property if the URI is not supported=
.
Does this make sense if you want to forward the component to a third party
client which might support this URI?

Date: Wed, 21 Jun 2006 10:52:44 +0200
From: Alexander Traud <[email-masked]>
To: <[email-masked]>
Subject: [Ietf-caldav] vCalender 1.0 component possible as return type?

In reply to:
> http://lists.osafoundation.org/pipermail/ietf-caldav/2005-May/000376.html

I hope I understand this correctly, please correct me if I am wrong:

- There is no requirement forcing a CalDAV client to understand or send
iCalendar components. A CalDAV client can use for example vCalendar 1.0 or
xCal or whatever as exchange format as long as the client states this in in
Accept HTTP headers, of course. Nevertheless, if that succeeds, depends on
the server.

- There is no requirement forcing a CalDAV server to alter a received
vCalendar 1.0 component to iCalendar (on PUT or any other method) except a
non-vCalendar aware client asks for the component. So a PUT with a vCalendar
might be saved 1:1 by the server.

Do not get me wrong, I like these features of CalDAV. I just want to confirm
these are in the spirit of the authors.

Date: Wed, 21 Jun 2006 02:16:09 +0200
From: Julian Reschke <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements	in draft-dusseault-caldav-12
Cc: Ted Hardie <[email-masked]>, HTTP Working Group <[email-masked]>, [email-masked], CalDAV DevList <[email-masked]>

Lisa Dusseault schrieb:
> 
> On Jun 20, 2006, at 10:27 AM, Wilfredo Sánchez Vega wrote:
> 
>>   Not really, no.
>>
>>   HTTP defines ETag.  An HTTP server should be able to use the same 
>> ETag logic on all HTTP resources, and not treat ETags for calendar 
>> resources differently than others.  Not all users of ETags are going 
>> to be aware that calendar resources are special.
>>
>>   My concern is that if there is *any* inconsistency between the 
>> general solution when it comes and CalDAV's, that an implementor may 
>> have to choose between being compliant with CalDAV or the more general 
>> ETag spec, or may have to continue to implement special semantics on 
>> calendar resources for purposes which are better served by the other 
>> spec.
>>
>>   I realize that "the other spec" doesn't exist today, and that this 
>> is a total drag.  Can't we take your one paragraph and put it into its 
>> own document?  I don't know IETF process very well, so I don't know 
>> what the next steps should be, but as an implementor, I'm 
>> uncomfortable with the prospect of dealing with two independently 
>> written specifications for the same behavior.
> 
> We basically tried that.  What it turned into was this 
> <http://www.ietf.org/internet-drafts/draft-whitehead-http-etag-00.txt> 
> with no consensus on the basic model or apparent drive to come to 
> consensus.  Got any feedback on that draft?

It's a shame we didn't make progress on that, but that doesn't 
invalidate the approach taken (making this an issue orthogonal to 
WebDAV, CalDAV or Atom).

Best regards, Julian

Date: Wed, 21 Jun 2006 02:14:31 +0200
From: Julian Reschke <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements	in	draft-dusseault-caldav-12
Cc: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>, Ted Hardie <[email-masked]>, HTTP Working Group <[email-masked]>, [email-masked], CalDAV DevList <[email-masked]>

Lisa Dusseault schrieb:
> My assertion was that if a strong ETag is returned, Xythos WFC assumes 
> that what it PUT was what the server stored, and it seems you agree.  
> You found that if a Last-Modified is returned instead, WFC makes the 
> same assumption -- naturally, they're very similar.

It seems that the client always assumes that the server does no 
content-rewriting, no matter what it returns. So it's incorrect to 
assume it makes specific assumptions about ETags on PUTs. It doesn't.

> You're probably quite right about the general case, that existing WebDAV 
> clients don't handle content-rewriting servers at all.  What's the best

Several clients handle it well, because they don't have a local content 
cache. Examples are Microsoft Office, Microsoft Webfolder, and the SAP 
Netweaver KM.

> thing a content-rewriting server can do in this situation?  I would hope 
> that if a client receives neither an ETag nor a Last-Modified in a PUT 
> response, then the next time it synchronizes and sees an ETag that it's 
> never seen before, the client downloads the resource.  This allows the 
> content to eventually get synchronized although perhaps not as fast as 
> would be ideal.

As there's no guarantee in HTTP about content rewriting not occurring, 
clients should always re-sync (at some point of time). An optimization 
(which happens to be the one I've been proposing several times now) 
would be a way for the server to indicate that content was *not* 
rewritten, avoiding the additional retrieval.

> But CalDAV clients will have to handle content-rewriting servers at 
> least handling events (calendar component resources), because during 
> protocol development we heard from a couple server developers that 
> they'd need to add custom iCalendar properties to an event as soon as it 
> was stored, thus rewriting the content.

Yes. I'm not sure how this is different from the generic case, though.

Best regards, Julian

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements	in draft-dusseault-caldav-12
Date: Tue, 20 Jun 2006 16:59:32 -0700
To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>
Cc: Ted Hardie <[email-masked]>, HTTP Working Group <[email-masked]>, [email-masked], CalDAV DevList <[email-masked]>

On Jun 20, 2006, at 10:27 AM, Wilfredo S=E1nchez Vega wrote:

>   Not really, no.
>
>   HTTP defines ETag.  An HTTP server should be able to use the same =20=

> ETag logic on all HTTP resources, and not treat ETags for calendar =20
> resources differently than others.  Not all users of ETags are =20
> going to be aware that calendar resources are special.
>
>   My concern is that if there is *any* inconsistency between the =20
> general solution when it comes and CalDAV's, that an implementor =20
> may have to choose between being compliant with CalDAV or the more =20
> general ETag spec, or may have to continue to implement special =20
> semantics on calendar resources for purposes which are better =20
> served by the other spec.
>
>   I realize that "the other spec" doesn't exist today, and that =20
> this is a total drag.  Can't we take your one paragraph and put it =20
> into its own document?  I don't know IETF process very well, so I =20
> don't know what the next steps should be, but as an implementor, =20
> I'm uncomfortable with the prospect of dealing with two =20
> independently written specifications for the same behavior.

We basically tried that.  What it turned into was this <http://=20
www.ietf.org/internet-drafts/draft-whitehead-http-etag-00.txt> with =20
no consensus on the basic model or apparent drive to come to =20
consensus.  Got any feedback on that draft?

Lisa

>
> 	-wsv
>
>
> On Jun 20, 2006, at 8:13 AM, Lisa Dusseault wrote:
>
>> Wilfredo, does it make a difference that CalDAV specifies special =20
>> ETag behavior only on Calendar Component resource items (not for =20
>> all HTTP resources)?
>

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements	in	draft-dusseault-caldav-12
Date: Tue, 20 Jun 2006 16:55:52 -0700
To: Julian Reschke <[email-masked]>
Cc: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>, Ted Hardie <[email-masked]>, HTTP Working Group <[email-masked]>, [email-masked], CalDAV DevList <[email-masked]>

On Jun 20, 2006, at 9:56 AM, Julian Reschke wrote:

> Lisa Dusseault schrieb:
>> Xythos WFC and Chandler (the Zanshin library that does WebDAV in  
>> python) behave this way and make the assumption I describe.  How  
>> else would you expect a caching or synching client to behave after  
>> doing a PUT, when the implementors of those clients were pretty  
>> sure that WebDAV servers stored the content without mucking with it?
>
> Chandler is not released and obviously operating based on what the  
> CalDAV spec currently says.
>
> Regarding the Xythos client: I just did some tests, and as far as I  
> can tell the behavior is the same independantly of whether the  
> server returns an ETag in PUT: the client always assumes that  
> content was not rewritten, and in the absence of an ETag uses the  
> Last-Modified date to check. So it seems that it doesn't handle  
> content-rewriting servers at all, right? (one needs to manually  
> purge the cache to get the actual content).

My assertion was that if a strong ETag is returned, Xythos WFC  
assumes that what it PUT was what the server stored, and it seems you  
agree.  You found that if a Last-Modified is returned instead, WFC  
makes the same assumption -- naturally, they're very similar.

You're probably quite right about the general case, that existing  
WebDAV clients don't handle content-rewriting servers at all.  What's  
the best thing a content-rewriting server can do in this situation?   
I would hope that if a client receives neither an ETag nor a Last- 
Modified in a PUT response, then the next time it synchronizes and  
sees an ETag that it's never seen before, the client downloads the  
resource.  This allows the content to eventually get synchronized  
although perhaps not as fast as would be ideal.

But CalDAV clients will have to handle content-rewriting servers at  
least handling events (calendar component resources), because during  
protocol development we heard from a couple server developers that  
they'd need to add custom iCalendar properties to an event as soon as  
it was stored, thus rewriting the content.

lisa

From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>
Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements	in draft-dusseault-caldav-12
Date: Tue, 20 Jun 2006 10:27:39 -0700
To: Lisa Dusseault <[email-masked]>
Cc: Ted Hardie <[email-masked]>, HTTP Working Group <[email-masked]>, [email-masked], CalDAV DevList <[email-masked]>

   Not really, no.

   HTTP defines ETag.  An HTTP server should be able to use the same  
ETag logic on all HTTP resources, and not treat ETags for calendar  
resources differently than others.  Not all users of ETags are going  
to be aware that calendar resources are special.

   My concern is that if there is *any* inconsistency between the  
general solution when it comes and CalDAV's, that an implementor may  
have to choose between being compliant with CalDAV or the more  
general ETag spec, or may have to continue to implement special  
semantics on calendar resources for purposes which are better served  
by the other spec.

   I realize that "the other spec" doesn't exist today, and that this  
is a total drag.  Can't we take your one paragraph and put it into  
its own document?  I don't know IETF process very well, so I don't  
know what the next steps should be, but as an implementor, I'm  
uncomfortable with the prospect of dealing with two independently  
written specifications for the same behavior.

	-wsv

On Jun 20, 2006, at 8:13 AM, Lisa Dusseault wrote:

> Wilfredo, does it make a difference that CalDAV specifies special  
> ETag behavior only on Calendar Component resource items (not for  
> all HTTP resources)?

Date: Tue, 20 Jun 2006 18:56:44 +0200
From: Julian Reschke <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements	in	draft-dusseault-caldav-12
Cc: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>, Ted Hardie <[email-masked]>, HTTP Working Group <[email-masked]>, [email-masked], CalDAV DevList <[email-masked]>

Lisa Dusseault schrieb:
> 
> Xythos WFC and Chandler (the Zanshin library that does WebDAV in python) 
> behave this way and make the assumption I describe.  How else would you 
> expect a caching or synching client to behave after doing a PUT, when 
> the implementors of those clients were pretty sure that WebDAV servers 
> stored the content without mucking with it?

Chandler is not released and obviously operating based on what the 
CalDAV spec currently says.

Regarding the Xythos client: I just did some tests, and as far as I can 
tell the behavior is the same independantly of whether the server 
returns an ETag in PUT: the client always assumes that content was not 
rewritten, and in the absence of an ETag uses the Last-Modified date to 
check. So it seems that it doesn't handle content-rewriting servers at 
all, right? (one needs to manually purge the cache to get the actual 
content).

> Your turn now:  do you have an example of a general-purpose (e.g. file 
> sharing, site synch)  shipping client that handles ETags and caches or 
> synchronizes content, which does a full GET of the content immediately 
> after PUT even if it receives a strong ETag?

No. And I don't think it necessarily needs to, unless it assumes that it 
can use the ETag in subsequent GET/Byte-Range operations.

> Even if there are such clients, the behavior we describe avoids nasty 
> errors on both such clients and clients like WFC.  It's the conservative 
> choice.

Well, it's a broken choice. There are servers that rewrite content and 
still return ETags upon PUT, and HTTP allows them do that.

Best regards, Julian

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements	in draft-dusseault-caldav-12
Date: Tue, 20 Jun 2006 08:13:44 -0700
To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>
Cc: Ted Hardie <[email-masked]>, HTTP Working Group <[email-masked]>, [email-masked], CalDAV DevList <[email-masked]>

Wilfredo, does it make a difference that CalDAV specifies special =20
ETag behavior only on Calendar Component resource items (not for all =20
HTTP resources)?

lisa

On Jun 19, 2006, at 12:58 PM, Wilfredo S=E1nchez Vega wrote:

>   Sure, OK, so some clients are broken today because they make some =20=

> assumptions that are only valid on some server implementations.
>
>   We know we need a solution; I just don't agree that CalDAV is the =20=

> right place to specify it.  I do understand how it's convenient.
>
> 	-wsv
>
>
> On Jun 19, 2006, at 12:32 PM, Lisa Dusseault wrote:
>
>> It's worse than that; many client authors *assumed* that to be the =20=

>> case, and implemented and deployed their clients assuming that if =20
>> the client receives a strong ETag in response to a PUT, it has no =20
>> further work to do to synchronize that resource.  So the deployed =20
>> base says that *is* the case today.  I don't feel our document =20
>> makes this situation any worse than the deployed base of clients =20
>> already does.
>

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements	in	draft-dusseault-caldav-12
Date: Tue, 20 Jun 2006 08:11:47 -0700
To: Julian Reschke <[email-masked]>
Cc: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>, Ted Hardie <[email-masked]>, HTTP Working Group <[email-masked]>, [email-masked], CalDAV DevList <[email-masked]>

Xythos WFC and Chandler (the Zanshin library that does WebDAV in =20
python) behave this way and make the assumption I describe.  How else =20=

would you expect a caching or synching client to behave after doing a =20=

PUT, when the implementors of those clients were pretty sure that =20
WebDAV servers stored the content without mucking with it?

Your turn now:  do you have an example of a general-purpose (e.g. =20
file sharing, site synch)  shipping client that handles ETags and =20
caches or synchronizes content, which does a full GET of the content =20
immediately after PUT even if it receives a strong ETag?

Even if there are such clients, the behavior we describe avoids nasty =20=

errors on both such clients and clients like WFC.  It's the =20
conservative choice.

Lisa

On Jun 19, 2006, at 12:41 PM, Julian Reschke wrote:

> Lisa Dusseault schrieb:
>> On Jun 15, 2006, at 9:32 AM, Wilfredo S=E1nchez Vega wrote:
>>>   I agree with Julian.
>>>
>>>   As we've mentioned before, Apache returns a weak ETag on PUT, =20
>>> which turns into a strong ETag sometime later.  If clients rely =20
>>> on being able to use that ETag on a GET later, they won't work =20
>>> with Apache, and IIRC, Apache is pretty popular.
>>>
>>>   The ETag requirements in the draft are what many clients =20
>>> authors might *like* to be the common case, but it is most =20
>>> certainly not so today.
>> It's worse than that; many client authors *assumed* that to be the =20=

>> case, and implemented and deployed their clients assuming that if =20
>> the client receives a strong ETag in response to a PUT, it has no =20
>> further work to do to synchronize that resource.  So the deployed =20
>> base says that *is* the case today.  I don't feel our document =20
>> makes this situation any worse than the deployed base of clients =20
>> already does.
>> Lisa
>
> Again: do you have any evidence of *shipping* clients making that =20
> assumption?
>
> Best regards, Julian
>
>

From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>
Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements	in draft-dusseault-caldav-12
Date: Mon, 19 Jun 2006 12:58:28 -0700
To: Lisa Dusseault <[email-masked]>
Cc: Ted Hardie <[email-masked]>, HTTP Working Group <[email-masked]>, [email-masked], CalDAV DevList <[email-masked]>

   Sure, OK, so some clients are broken today because they make some  
assumptions that are only valid on some server implementations.

   We know we need a solution; I just don't agree that CalDAV is the  
right place to specify it.  I do understand how it's convenient.

	-wsv

On Jun 19, 2006, at 12:32 PM, Lisa Dusseault wrote:

> It's worse than that; many client authors *assumed* that to be the  
> case, and implemented and deployed their clients assuming that if  
> the client receives a strong ETag in response to a PUT, it has no  
> further work to do to synchronize that resource.  So the deployed  
> base says that *is* the case today.  I don't feel our document  
> makes this situation any worse than the deployed base of clients  
> already does.

Date: Mon, 19 Jun 2006 21:41:17 +0200
From: Julian Reschke <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements	in	draft-dusseault-caldav-12
Cc: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>, Ted Hardie <[email-masked]>, HTTP Working Group <[email-masked]>, [email-masked], CalDAV DevList <[email-masked]>

Lisa Dusseault schrieb:
> 
> On Jun 15, 2006, at 9:32 AM, Wilfredo Sánchez Vega wrote:
> 
>>   I agree with Julian.
>>
>>   As we've mentioned before, Apache returns a weak ETag on PUT, which 
>> turns into a strong ETag sometime later.  If clients rely on being 
>> able to use that ETag on a GET later, they won't work with Apache, and 
>> IIRC, Apache is pretty popular.
>>
>>   The ETag requirements in the draft are what many clients authors 
>> might *like* to be the common case, but it is most certainly not so 
>> today.
> 
> It's worse than that; many client authors *assumed* that to be the case, 
> and implemented and deployed their clients assuming that if the client 
> receives a strong ETag in response to a PUT, it has no further work to 
> do to synchronize that resource.  So the deployed base says that *is* 
> the case today.  I don't feel our document makes this situation any 
> worse than the deployed base of clients already does.
> 
> Lisa

Again: do you have any evidence of *shipping* clients making that 
assumption?

Best regards, Julian

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements	in	draft-dusseault-caldav-12
Date: Mon, 19 Jun 2006 12:32:53 -0700
To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>
Cc: Ted Hardie <[email-masked]>, HTTP Working Group <[email-masked]>, [email-masked], CalDAV DevList <[email-masked]>

On Jun 15, 2006, at 9:32 AM, Wilfredo S=E1nchez Vega wrote:

>   I agree with Julian.
>
>   As we've mentioned before, Apache returns a weak ETag on PUT, =20
> which turns into a strong ETag sometime later.  If clients rely on =20
> being able to use that ETag on a GET later, they won't work with =20
> Apache, and IIRC, Apache is pretty popular.
>
>   The ETag requirements in the draft are what many clients authors =20
> might *like* to be the common case, but it is most certainly not so =20=

> today.

It's worse than that; many client authors *assumed* that to be the =20
case, and implemented and deployed their clients assuming that if the =20=

client receives a strong ETag in response to a PUT, it has no further =20=

work to do to synchronize that resource.  So the deployed base says =20
that *is* the case today.  I don't feel our document makes this =20
situation any worse than the deployed base of clients already does.

Lisa

>
>   Additionally, the draft doesn't just say that servers SHOULD =20
> return an ETag in a response when the data has not changed, but =20
> also that they MUST NOT do so if the data did change.  It's not =20
> entirely clear that this is the direction things will go, and any =20
> MUST requirements which conflict with whatever we do come up with =20
> later will be a real headache.
>
> 	-wsv
>
>
> On Jun 15, 2006, at 4:02 AM, Julian Reschke wrote:
>
>> I noticed that the ID tracker now has a comment from the authors =20
>> (see <https://datatracker.ietf.org/public/pidtracker.cgi?=20
>> command=3Dview_comment&id=3D52124>), which I'd like to comment over =20=

>> here...:
>>
>>> 	Author's response to Last Call comments on ETags
>>> 1) Best common practice in WebDAV
>>> Currently very few, if any at all, WebDAV servers change the =20
>>> content of resource data during a PUT request. Most WebDAV =20
>>> servers do return an ETag on PUT. Thus clients have come to rely =20
>>> on the presence of the ETag to effectively mean that the resource =20=

>>> data was stored unchanged and that the ETag can be used in =20
>>> subsequent GET requests etc. This justifies our statement that =20
>>> servers SHOULD return an ETag in a response when the data has not =20=

>>> changed.
>>
>> I have my doubts that this statement is based on actual testing. =20
>> In particular it seems to me that making claims about "most" =20
>> servers isn't useful here; servers that do rewrite content do =20
>> exist, but they are certainly outnumbered *installation-wise* by =20
>> IIS and Apache/moddav/fs which implement WebDAV as a "dumb" store =20
>> (in that they don't support special semantics on specific content =20
>> types). But that doesn't mean that being incompatible with that =20
>> class of servers (being fully compliant to RFC2616 and RFC2518) is =20=

>> acceptable.
>>
>> That being said, I just tested:
>>
>> - Microsoft IIS 5.1 (as shipping with XPSP2): No ETag returned =20
>> upon PUT
>>
>> - Apache/moddav 2.0.55 (WinXPSP2): No ETag returned upon PUT
>>
>> - Xythos WFS (on www.sharemation.com): ETag returned
>>
>> - SAP Netweaver KM: ETag returned although content may be rewritten
>>
>> It seems to me that this shows that the statement above is =20
>> misleading.
>>
>>> Now we have CalDAV servers where the resource data MAY be =20
>>> changed. Therefore to be compatible with existing client behavior =20=

>>> a server MUST NOT send the ETag in a PUT response when the data =20
>>> changes, otherwise clients will misinterpret it. This justifies =20
>>> our 'MUST NOT' statement.
>>
>> It would be helpful if you could provide an example of a =20
>> *shipping* client that breaks if an ETag is returned upon PUT =20
>> although content was rewritten.
>>
>>> 2) Restricted behavior
>>> The ETag behavior we are talking about is restricted solely to =20
>>> calendar object resources being stored in calendar collections - =20
>>> i.e. it is very specific to CalDAV. This is not 'redefining' HTTP =20=

>>> behavior by rather extending it for this one specific application =20=

>>> need.
>>
>> But it's still an HTTP and WebDAV resource. A CalDAV server that =20
>> also happens to be a generic WebDAV server may need to make this a =20=

>> special case then. And this may be hard to do should there be =20
>> another HTTP/WebDAV related specification making an incompatible =20
>> requirement.
>>
>> As a matter of fact, in February the IESG has decided to solve =20
>> that very problem in a separate activity (see draft-whitehead-http-=20=

>> etag-00), independently of WebDAV and CalDAV. And, indeed, =20
>> RFC2518bis (the revision of WebDAV) delegates resolution of the =20
>> question to that very spec, instead of coming up with it's own. =20
>> This is what CalDAV should also be doing.
>>
>>> 3) Future conflicts
>>> One of Julian's arguments is that our requirement will "risk =20
>>> making CalDAV incompatible with other specs extending HTTP (or =20
>>> HTTP itself, for that matter)". Since we have been careful to =20
>>> require only behavior that already exists in deployed WebDAV =20
>>> servers, CalDAV adds no further incompatibility. If future work =20
>>> to better define the meaning of ETag on PUT ever happens, it will =20=

>>> need to take into account the deployed base, and the subset of =20
>>> CalDAV servers will simply happen to be a consistently behaving =20
>>> subset. We believe that our requirements improve the =20
>>> interoperability of CalDAV, without making the future/potential =20
>>> incompatibility problem any worse than it already is.
>>
>> See notes above. The behavior required by CalDAV is *not* what =20
>> current servers do. At least not the majority.
>>
>>> 4) Need/usefulness
>>> In addition to the authors' evaluation of the usefulness of this =20
>>> feature for keeping an offline calendar correct, there have been =20
>>> other requests for predictable behavior w.r.t. PUT and ETags and =20
>>> calendar resources. This was one of the first feature requests =20
>>> from client implementors, including Dan Mosedale and Grant Baillie.
>>
>> I totally agree that clients may be interested in finding out =20
>> whether content was rewritten. The solution to this is to either =20
>> put more energy into draft-whitehead-http-etag-00, or to have a =20
>> CalDAV-specific solution  that by design wouldn't interfere with =20
>> what we define in other specs later, as outlined in <http://=20
>> lists.osafoundation.org/pipermail/ietf-caldav/2006-April/=20
>> 000787.html>.  I'd really like to here why the solution suggested =20
>> back then isn't sufficient for CalDAV.
>>
>>
>> Best regards, Julian
>> _______________________________________________
>> Ietf-caldav mailing list -- [email-masked]
>> See http://ietf.webdav.org/caldav/ for more CalDAV resources
>> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>
Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements	in	draft-dusseault-caldav-12
Date: Thu, 15 Jun 2006 09:32:51 -0700
To: Julian Reschke <[email-masked]>, [email-masked], Ted Hardie <[email-masked]>, CalDAV DevList <[email-masked]>, HTTP Working Group <[email-masked]>

   I agree with Julian.

   As we've mentioned before, Apache returns a weak ETag on PUT,  
which turns into a strong ETag sometime later.  If clients rely on  
being able to use that ETag on a GET later, they won't work with  
Apache, and IIRC, Apache is pretty popular.

   The ETag requirements in the draft are what many clients authors  
might *like* to be the common case, but it is most certainly not so  
today.

   Additionally, the draft doesn't just say that servers SHOULD  
return an ETag in a response when the data has not changed, but also  
that they MUST NOT do so if the data did change.  It's not entirely  
clear that this is the direction things will go, and any MUST  
requirements which conflict with whatever we do come up with later  
will be a real headache.

	-wsv

On Jun 15, 2006, at 4:02 AM, Julian Reschke wrote:

> I noticed that the ID tracker now has a comment from the authors  
> (see <https://datatracker.ietf.org/public/pidtracker.cgi? 
> command=view_comment&id=52124>), which I'd like to comment over  
> here...:
>
>> 	Author's response to Last Call comments on ETags
>> 1) Best common practice in WebDAV
>> Currently very few, if any at all, WebDAV servers change the  
>> content of resource data during a PUT request. Most WebDAV servers  
>> do return an ETag on PUT. Thus clients have come to rely on the  
>> presence of the ETag to effectively mean that the resource data  
>> was stored unchanged and that the ETag can be used in subsequent  
>> GET requests etc. This justifies our statement that servers SHOULD  
>> return an ETag in a response when the data has not changed.
>
> I have my doubts that this statement is based on actual testing. In  
> particular it seems to me that making claims about "most" servers  
> isn't useful here; servers that do rewrite content do exist, but  
> they are certainly outnumbered *installation-wise* by IIS and  
> Apache/moddav/fs which implement WebDAV as a "dumb" store (in that  
> they don't support special semantics on specific content types).  
> But that doesn't mean that being incompatible with that class of  
> servers (being fully compliant to RFC2616 and RFC2518) is acceptable.
>
> That being said, I just tested:
>
> - Microsoft IIS 5.1 (as shipping with XPSP2): No ETag returned upon  
> PUT
>
> - Apache/moddav 2.0.55 (WinXPSP2): No ETag returned upon PUT
>
> - Xythos WFS (on www.sharemation.com): ETag returned
>
> - SAP Netweaver KM: ETag returned although content may be rewritten
>
> It seems to me that this shows that the statement above is misleading.
>
>> Now we have CalDAV servers where the resource data MAY be changed.  
>> Therefore to be compatible with existing client behavior a server  
>> MUST NOT send the ETag in a PUT response when the data changes,  
>> otherwise clients will misinterpret it. This justifies our 'MUST  
>> NOT' statement.
>
> It would be helpful if you could provide an example of a *shipping*  
> client that breaks if an ETag is returned upon PUT although content  
> was rewritten.
>
>> 2) Restricted behavior
>> The ETag behavior we are talking about is restricted solely to  
>> calendar object resources being stored in calendar collections -  
>> i.e. it is very specific to CalDAV. This is not 'redefining' HTTP  
>> behavior by rather extending it for this one specific application  
>> need.
>
> But it's still an HTTP and WebDAV resource. A CalDAV server that  
> also happens to be a generic WebDAV server may need to make this a  
> special case then. And this may be hard to do should there be  
> another HTTP/WebDAV related specification making an incompatible  
> requirement.
>
> As a matter of fact, in February the IESG has decided to solve that  
> very problem in a separate activity (see draft-whitehead-http- 
> etag-00), independently of WebDAV and CalDAV. And, indeed,  
> RFC2518bis (the revision of WebDAV) delegates resolution of the  
> question to that very spec, instead of coming up with it's own.  
> This is what CalDAV should also be doing.
>
>> 3) Future conflicts
>> One of Julian's arguments is that our requirement will "risk  
>> making CalDAV incompatible with other specs extending HTTP (or  
>> HTTP itself, for that matter)". Since we have been careful to  
>> require only behavior that already exists in deployed WebDAV  
>> servers, CalDAV adds no further incompatibility. If future work to  
>> better define the meaning of ETag on PUT ever happens, it will  
>> need to take into account the deployed base, and the subset of  
>> CalDAV servers will simply happen to be a consistently behaving  
>> subset. We believe that our requirements improve the  
>> interoperability of CalDAV, without making the future/potential  
>> incompatibility problem any worse than it already is.
>
> See notes above. The behavior required by CalDAV is *not* what  
> current servers do. At least not the majority.
>
>> 4) Need/usefulness
>> In addition to the authors' evaluation of the usefulness of this  
>> feature for keeping an offline calendar correct, there have been  
>> other requests for predictable behavior w.r.t. PUT and ETags and  
>> calendar resources. This was one of the first feature requests  
>> from client implementors, including Dan Mosedale and Grant Baillie.
>
> I totally agree that clients may be interested in finding out  
> whether content was rewritten. The solution to this is to either  
> put more energy into draft-whitehead-http-etag-00, or to have a  
> CalDAV-specific solution  that by design wouldn't interfere with  
> what we define in other specs later, as outlined in <http:// 
> lists.osafoundation.org/pipermail/ietf-caldav/2006-April/ 
> 000787.html>.  I'd really like to here why the solution suggested  
> back then isn't sufficient for CalDAV.
>
>
> Best regards, Julian
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Thu, 15 Jun 2006 13:02:17 +0200
From: Julian Reschke <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements	in	draft-dusseault-caldav-12
Cc: Ted Hardie <[email-masked]>, CalDAV DevList <[email-masked]>, HTTP Working Group <[email-masked]>

I noticed that the ID tracker now has a comment from the authors (see 
<https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=52124>), 
which I'd like to comment over here...:

> 	Author's response to Last Call comments on ETags
> 
> 1) Best common practice in WebDAV
> 
> Currently very few, if any at all, WebDAV servers change the content of resource data during a PUT request. Most WebDAV servers do return an ETag on PUT. Thus clients have come to rely on the presence of the ETag to effectively mean that the resource data was stored unchanged and that the ETag can be used in subsequent GET requests etc. This justifies our statement that servers SHOULD return an ETag in a response when the data has not changed.

I have my doubts that this statement is based on actual testing. In 
particular it seems to me that making claims about "most" servers isn't 
useful here; servers that do rewrite content do exist, but they are 
certainly outnumbered *installation-wise* by IIS and Apache/moddav/fs 
which implement WebDAV as a "dumb" store (in that they don't support 
special semantics on specific content types). But that doesn't mean that 
being incompatible with that class of servers (being fully compliant to 
RFC2616 and RFC2518) is acceptable.

That being said, I just tested:

- Microsoft IIS 5.1 (as shipping with XPSP2): No ETag returned upon PUT

- Apache/moddav 2.0.55 (WinXPSP2): No ETag returned upon PUT

- Xythos WFS (on www.sharemation.com): ETag returned

- SAP Netweaver KM: ETag returned although content may be rewritten

It seems to me that this shows that the statement above is misleading.

> Now we have CalDAV servers where the resource data MAY be changed. Therefore to be compatible with existing client behavior a server MUST NOT send the ETag in a PUT response when the data changes, otherwise clients will misinterpret it. This justifies our 'MUST NOT' statement.

It would be helpful if you could provide an example of a *shipping* 
client that breaks if an ETag is returned upon PUT although content was 
rewritten.

> 2) Restricted behavior
> 
> The ETag behavior we are talking about is restricted solely to calendar object resources being stored in calendar collections - i.e. it is very specific to CalDAV. This is not 'redefining' HTTP behavior by rather extending it for this one specific application need.

But it's still an HTTP and WebDAV resource. A CalDAV server that also 
happens to be a generic WebDAV server may need to make this a special 
case then. And this may be hard to do should there be another 
HTTP/WebDAV related specification making an incompatible requirement.

As a matter of fact, in February the IESG has decided to solve that very 
problem in a separate activity (see draft-whitehead-http-etag-00), 
independently of WebDAV and CalDAV. And, indeed, RFC2518bis (the 
revision of WebDAV) delegates resolution of the question to that very 
spec, instead of coming up with it's own. This is what CalDAV should 
also be doing.

> 3) Future conflicts
> 
> One of Julian's arguments is that our requirement will "risk making CalDAV incompatible with other specs extending HTTP (or HTTP itself, for that matter)". Since we have been careful to require only behavior that already exists in deployed WebDAV servers, CalDAV adds no further incompatibility. If future work to better define the meaning of ETag on PUT ever happens, it will need to take into account the deployed base, and the subset of CalDAV servers will simply happen to be a consistently behaving subset. We believe that our requirements improve the interoperability of CalDAV, without making the future/potential incompatibility problem any worse than it already is.

See notes above. The behavior required by CalDAV is *not* what current 
servers do. At least not the majority.

> 4) Need/usefulness
> 
> In addition to the authors' evaluation of the usefulness of this feature for keeping an offline calendar correct, there have been other requests for predictable behavior w.r.t. PUT and ETags and calendar resources. This was one of the first feature requests from client implementors, including Dan Mosedale and Grant Baillie.

I totally agree that clients may be interested in finding out whether 
content was rewritten. The solution to this is to either put more energy 
into draft-whitehead-http-etag-00, or to have a CalDAV-specific solution 
  that by design wouldn't interfere with what we define in other specs 
later, as outlined in 
<http://lists.osafoundation.org/pipermail/ietf-caldav/2006-April/000787.html>. 
  I'd really like to here why the solution suggested back then isn't 
sufficient for CalDAV.

Best regards, Julian

Date: Mon, 5 Jun 2006 16:50:09 -0700
To: Cyrus Daboo <[email-masked]>, Julian Reschke <[email-masked]>
From: Ted Hardie <[email-masked]>
Subject: Re: [Ietf-caldav] Last Call comment on Etag  requirements	in draft-dusseault-caldav-12
Cc: CalDAV DevList <[email-masked]>

>From a previous conversation, I thought that the authors had concluded
that the current text would be retained but that the IETF should note
that the best way forward would be a more general resolution of
the ETag issue.  I also believe if that results in the CalDav point solution
being out of the mainstream, it would have to re-cycle at proposed and
deal with the upgrade problems.  Since there is no more general solution
available, it seemed to me reasonable not to hold the document back
for the resolution to work that has not really begun, provided the
community was made aware of the issues in the write-up.

If the authors are still considering the issue, though, this document is
not ready for IESG consideration. I have removed it from this
week's agenda.  I have temporarily put it back two weeks, but it
may move further (or back through Last Call) if the authors decide
on significant changes.
			regards,
				Ted Hardie

At 2:34 PM -0400 6/5/06, Cyrus Daboo wrote:
>Hi Julian,
>
>--On June 5, 2006 8:30:25 PM +0200 Julian Reschke <[email-masked]> wrote:
>
>>I notice that draft-dusseault-caldav-12 now is in IESG Evaluation
>>(<https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag
>>=11253>).
>>
>>For the record: as far as I can tell, the issue that I raised below is
>>critical (given the fact that we have a separate activity to clarify this
>>in HTTP), and has not been addressed. It's not clear to me whether the
>>client issue it attempts to solve really is important. If it is, there is
>>a simpler way to accomplish this ([1]) that doesn't risk making CalDAV
>>incompatible with other specs extending HTTP (or HTTP itself, for that
>>matter).
>
>We are planning on addressing this ETag issue in a revision now that last-call is over. Authors are discussing right now.
>
>--
>Cyrus Daboo
>
>
>_______________________________________________
>Ietf mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ietf

Date: Mon, 05 Jun 2006 14:34:17 -0400
From: Cyrus Daboo <[email-masked]>
To: Julian Reschke <[email-masked]>, [email-masked]
Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements	in	draft-dusseault-caldav-12
Cc: Ted Hardie <[email-masked]>, CalDAV DevList <[email-masked]>

Hi Julian,

--On June 5, 2006 8:30:25 PM +0200 Julian Reschke <[email-masked]> 
wrote:

> I notice that draft-dusseault-caldav-12 now is in IESG Evaluation
> (<https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag
> =11253>).
>
> For the record: as far as I can tell, the issue that I raised below is
> critical (given the fact that we have a separate activity to clarify this
> in HTTP), and has not been addressed. It's not clear to me whether the
> client issue it attempts to solve really is important. If it is, there is
> a simpler way to accomplish this ([1]) that doesn't risk making CalDAV
> incompatible with other specs extending HTTP (or HTTP itself, for that
> matter).

We are planning on addressing this ETag issue in a revision now that 
last-call is over. Authors are discussing right now.

-- 
Cyrus Daboo

Date: Mon, 05 Jun 2006 20:30:25 +0200
From: Julian Reschke <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements in	draft-dusseault-caldav-12
Cc: Ted Hardie <[email-masked]>, CalDAV DevList <[email-masked]>

Hi.

I notice that draft-dusseault-caldav-12 now is in IESG Evaluation 
(<https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11253>).

For the record: as far as I can tell, the issue that I raised below is 
critical (given the fact that we have a separate activity to clarify 
this in HTTP), and has not been addressed. It's not clear to me whether 
the client issue it attempts to solve really is important. If it is, 
there is a simpler way to accomplish this ([1]) that doesn't risk making 
CalDAV incompatible with other specs extending HTTP (or HTTP itself, for 
that matter).

Best regards,

Julian

[1] 
<http://lists.osafoundation.org/pipermail/ietf-caldav/2006-April/000787.html>

Julian Reschke wrote:
> Lisa Dusseault wrote:
>> Thanks for the input.  Speaking as a document author here, I'm 
>> confident we've made a decent set of tradeoffs, balancing possible 
>> risks against benefits, and attempting to minimize the risks too.
>>
>> The basic risk is that any requirements related to ETags may conflict 
>> with future requirements.  We've attempted to minimize this risk by 
>> making only one requirement -- that servers MUST NOT return strong 
>> ETags if they have changed the data provided to be stored.  We believe 
>> that this requirement is quite within the spirit of ETag design.   We 
>> didn't make any requirements about weak ETags, nor did we require any 
>> behavior that future specs might make illegal.  Since today with HTTP 
>> it's perfectly acceptable not to return an ETag at all, future 
>> requirements on ETags would at least have to work with a huge deployed 
>> base of HTTP servers that don't return any ETag on PUT responses.
>>
>> Thus, any future ETag-related requirements that invalidated this 
>> CalDAV requirement, would also conflict with the huge deployed base of 
>> HTTP.  I 
> 
> How so?
> 
> A potential requirement of an XyzDav spec to return ETags even though 
> the content was rewritten wouldn't be in conflict with HTTP at all. It 
> would just be impossible to implement a resource that's both compliant 
> to CalDAV and XyzDav.
> 
> This is why I think CalDav uses the wrong approach. There's a simple way 
> to give CalDav clients that piece of information and which is guaranteed 
> to be compatible with other specs, and that's what CalDav should do.
> 
> Or, alternatively, it could just stay silent and let that other spec 
> work out the solution, instead of trying to come up with a fait accompli.
> 
>  > ...
> 
> Best regards, Julian
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

Date: Mon, 05 Jun 2006 09:01:50 -0700
From: Andrew Hsu <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-caldav] What happened to the CalDav website?
Cc: [email-masked]
Reply-To: [email-masked]

Thanks--that worked.

Bernard Desruisseaux wrote:
> There's an issue with the machine alias "ietf.webdav.org".
>
> Try this URL: http://ietf.cse.ucsc.edu/caldav
>
> Cheers,
> Bernard
>
> Andrew Hsu wrote:
>> Hello,
>>
>> I use to visit the CalDav website quite a lot, but the last few days 
>> I've been unable to connect:
>>
>> http://caldav.org/
>> http://www.caldav.org/
>> http://ietf.webdav.org/caldav/
>>
>> They all timeout on me from work or from home (Comcast).
>>
>> Is the site down for maintenance or has it moved to a new location?  
>> Even the Google cache has a blank page:
>> http://www.google.com/search?q=cache:www.caldav.org
>>
>> Cheers,
>> Andrew
>>

-- 
 .
 .  Andrew Hsu
 .  email: [email-masked]
 .

Date: Mon, 05 Jun 2006 09:09:17 -0400
From: Bernard Desruisseaux <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-caldav] What happened to the CalDav website?
Cc: [email-masked]

There's an issue with the machine alias "ietf.webdav.org".

Try this URL: http://ietf.cse.ucsc.edu/caldav

Cheers,
Bernard

Andrew Hsu wrote:
> Hello,
> 
> I use to visit the CalDav website quite a lot, but the last few days 
> I've been unable to connect:
> 
> http://caldav.org/
> http://www.caldav.org/
> http://ietf.webdav.org/caldav/
> 
> They all timeout on me from work or from home (Comcast).
> 
> Is the site down for maintenance or has it moved to a new location?  
> Even the Google cache has a blank page:
> http://www.google.com/search?q=cache:www.caldav.org
> 
> Cheers,
> Andrew
> 

Date: Sun, 04 Jun 2006 11:03:55 -0700
From: Andrew Hsu <[email-masked]>
To: [email-masked]
Subject: [Ietf-caldav] What happened to the CalDav website?
Reply-To: [email-masked]

Hello,

I use to visit the CalDav website quite a lot, but the last few days 
I've been unable to connect:

http://caldav.org/
http://www.caldav.org/
http://ietf.webdav.org/caldav/

They all timeout on me from work or from home (Comcast).

Is the site down for maintenance or has it moved to a new location?  
Even the Google cache has a blank page:
http://www.google.com/search?q=cache:www.caldav.org

Cheers,
Andrew

-- 
 .
 .  Andrew Hsu
 .  email: [email-masked]
 .

Date: Fri, 02 Jun 2006 22:19:49 -0400
From: Robert Yates <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume?
Cc: [email-masked]

Cyrus,

I agree with a lot of what you write here, but not your conclusions :)  
Yes, it is possible to work around all these things by doing more work 
and sometimes a lot more work.  I just have to ask why?  What is special 
about freebusy lookups that mean that they can't be accomplished in a 
manner that is more widely adopted and that most application developers 
are very familiar with.

The proposed GET matched the functionality of the CalDav freebusy report 
and so direct comparisons of development effort, testabilty, 
consumability and deployment can be made, and I still maintain that the 
effort will be substantially reduced for GET. However, below you seem to 
be arguing that the CalDav report is "not really useful" and go on to 
state that more functionality is required and hence GET is not that 
simple.  I am not really following your argument. If the freebusy report 
in CalDav is useful then it can be accomplished in a simpler manner with 
a GET.  If it is not that useful and something else is needed then we 
should look at what that is and also see if it is easier to consume, 
develop, test etc. using a GET vs. REPORT. 

Finally, if the freebusy report in CalDav really is not that useful then 
shouldn't it be an optional report, instead of a mandated one?

 more comments below.

Rob

Cyrus Daboo wrote:

> 1. httpclient/webdavclient libraries etc:
>
> FYI Last year I built a caldav client library using httpclient and the 
> slide client library together with my own iCal library. It was trivial 
> to do (though I knew enough about iCalendar in the first place). WRT 
> slide library not having been updated in a while - yes that is true 
> but it seems to work fine - and its open source so you can always 
> contribute. As to Legal - of course one has to go through that for 
> every piece of open source software at least once...

I agree with this, but as a product manager releasing a piece of 
software, would you want it to depend on a library that doesn't appear 
to have much momentum behind it (not having been updated since 2004) and 
that in turn depends on a jar file that has been end of life'd?

>
> 2. Using a simple GET request for free-busy:
>
> The example given is not as simple as it first seems: there is still 
> work you have to do to at the very least to parse and understand the 
> date/period format and know what 'BUSY-TENTATIVE' etc means. i.e. the 
> semantics of calendars still have to be understood no matter what 
> syntax or protocol is used to transport the data.

agreed, but this is nothing to do with the use of http GET vs. webdav 
REPORT.

>
> Certainly if all you want is a free-busy view of a single calendar, 
> the GET approach is trivial and easy. But the reality is there is much 
> more to calendaring than just that.
>
> Lets be clear, the free-busy report in CalDAV access is not really 
> useful when it comes to doing free busy lookups of calendar USERS as 
> opposed to just looking at a static calendar. The actual need is to 
> target calendar users (who may have more than one calendar 
> contributing to their free busy). The CalDAV schedule specification, a 
> new version of which was published to internet-drafts last week, 
> addresses this by allowing iTIP free busy requests targeted at one (or 
> more) local (or possibly remote) users on a CalDAV server. This 
> returns a much more useful response listing each user's f-b info. It 
> also deals with the issue of how to grant someone the right to only 
> see free busy and not the entire calendar data.

Am confused by what you are saying here.  The GET that I described could 
have the same functional semantics as the REPORT, namely that it would 
be possible to pass in the same parameters and get the same response.  
Are you stating that the REPORT as described in CalDav is not that 
useful? and if so, why is it mandatory?

>
> 3. REPORT method and firewalls:
>
> Any organization that has gone to the trouble to setup a firewall (be 
> it one that allows WebDAV methods or not) will likely require all 
> external users to use SSL when connecting from outside when accessing 
> company sensitive information such as email and calendars. So ssl 
> (https) will almost certainly be a requirement for CalDAV use and 
> that, as others have pointed out, pretty much gets around any firewall 
> problems.

Just to be clear the firewall issue is not only applicable to access 
originating from outside the company's intranet.  It applies equally to 
an end user sat on the corporate network accessing their corporate 
servers.  As we consider using PUT and DELETE methods in our products we 
are surveying clients infrastructure to see if it is viable. The early 
results are mixed and it looks likely that we will require a means to 
tunnel PUT and DELETE over POST, at least for the short term. We are not 
presently surveying for the REPORT method but I would guess it would 
produce a similar, if not worse, set of results. SSL is also no magic 
bullet here as is dramatically effects the throughput that can be 
achieved on any given server. Most of our customers are not eager to 
have it turned on for every single server request.

>
> 4. Make REPORTs optional:
>
> The reports are a key part of CalDAV, if you make them optional then 
> you might just as well do plain WebDAV (e.g. GroupDAV) or HTTP. They 
> are certainly not trivial to implement (well multiget is actually 
> pretty easy) but most of the complexity is tied up in the calendar 
> data semantics. For example, a time-range query seems simple at first 
> glance, but when you take into account all possibilities allowed by 
> iCalendar (timed, all-day, floating, timezones, recurrences, events 
> with a start only, to-do's with due only etc) it gets complicated. We 
> spent a fair bit of time putting together the tables describing how 
> that works for the different components in the hope that would save 
> implementers a lot of time.

Again, I find myself in violent agreement :).  It is hard to do the 
time-range queries and yes they are a key part, but some of the REPORTS 
that are mandated in section 7 are much more obtuse.  Example 7.7.7 is a 
case in point

In this example, the client requests the server to return the VEVENT
   components that have the ATTENDEE property with the value
   "mailto:[email-masked]" and for which the PARTSTAT parameter is set
   to "NEEDS-ACTION".

Maybe I missed it, but I cannot find the "feature" in my Calandering 
client (Lotus Notes) that requires this kind of query.  If I understand 
it correctly it asks for all the appointments in a Calendar where Lisa 
still needs to respond. I know I am tempting fate here, cos I know it is 
here for a reason, but which Calendaring system currently does this and 
why? and do all calendaring systems need to do this for interoperability?

I just wonder if it is worth prioritizing the REPORTs specified in 
CalDav and making some optional.  You stated above that the freebusy one 
is not that useful, although I disagree with this.  Are there others 
that are not that useful but mandated.  I saw folks on this thread 
stating both that CalDav was already too complex and asking whether 
REPORTs should be optional. Is it worth coming up with a more limited 
mandatory set?

>
> 5. iCalendar vs XML syntax:
>
> We did design CalDAV in such a way that an XML-representation of 
> iCalendar data could be used at some point in the future in a 
> backwards compatible manner once one has been standardized. It 
> certainly seems like standardizing that should be the first step to 
> the simple GET approach and to CalATOM etc. Someone needs to pick up 
> that effort again and run with it...

agreed, I'll see if I can garner any interest on this side.

> People have pointed to some benefits of XML syntax, including 
> XPath/XQuery. But again, those do not address the semantics of 
> calendaring. The most common query that is likely to used in 
> calendaring is a time-range query. XPath/XQuery would have to be 
> extended with a special 'timerange' test function for that to work 
> properly with recurrences, floating time etc - another syntax does not 
> hide the complexity of the semantics.

agreed, but it reduces the invention to a few functions vs. a whole new 
query syntax.

>
> In any case, I do think having an xml syntax a useful thing to have, 
> but its going to have to live alongside iCalendar for a long time to 
> come because iCalendar is already widely deployed and used. 
> Upgrading/changing data formats takes a very long time to do - don't 
> forget there are still many implementations using the older vCalendar 
> spec even today (e.g. many mobile devices).

agreed

>
>
> 6. xslt on free-busy:
>
> I'm not an xslt expert, but would welcome comment from others who are. 
> However, I do question whether a simple transformation is enough. For 
> example, the user would almost certainly want to see the UTC-relative 
> free-busy times shifted to their local timezone (or the timezone in 
> which they are planning the meeting) so the xslt transform would need 
> to apply timezone/dst rules. Of course you could push the timezone 
> offset calculation off to the server and have the returned free-busy 
> times already shifted.

Yup, here is a good example of a freebusy listing in html 
http://ifreebusy.com/neiljensen/freebusy.  The XSLT to produce that from 
an xCal representation would be a fairly trivial modification to the 
existing web page.

>
> Summary:
>
> At first glance having a simple free-busy lookup via GET sounds like a 
> great idea, but when you look at real use cases and constraints its 
> going to be a lot harder than originally proposed. Of course it can be 
> done, but by the time you've finished addressing the real-world use 
> cases you may well end up with something just as 'hard' to do as the 
> CalDAV equivalent.

A GET with an XML or an iCal response can functionally match the 
freebusy lookup REPORT in CalDav. It will be substantially less effort 
to consume in a shipping product for reasons that I point out in gory 
detail here http://robubu.com/?p=8, end of life'd jars, firewall issues, 
custom parsers. These are all headaches that we don't have if we stick 
to what everybody else is doing. I also failed to mention in that post 
that it is also harder to automate tests for REPORT vs. GET.  For a GET, 
I can use cURL http://curl.haxx.se/docs/, httpunit 
http://httpunit.sourceforge.net/ or even the browser.  I don't know of 
any WebDav equivalents that are as well maintained. Then there's load 
testing, does anyone know if loadrunner 
http://www.mercury.com/us/products/performance-center/loadrunner/ 
supports REPORT. All of this is more effort

>
> If people want to pursue this then I encourage you to write up the 
> actual use cases that need to be addressed and then see what needs to 
> be done. 

The GET proposal was to simply match the functionality provided by the 
freebusy report in CalDav.  I was assuming that use case analysis had 
already been done to ensure that this meets the current needs. The GET 
proposal is not to address any new functionality, it is just an 
alternative approach to that currently specified, so I am confused why 
any further use cases are needed.

Date: Fri, 02 Jun 2006 11:39:04 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-caldav] freebusy lookups in CalDav are too hard to consume?

Hi,
I am going to try and address several of the comments in this thread in one 
go.

1. httpclient/webdavclient libraries etc:

FYI Last year I built a caldav client library using httpclient and the 
slide client library together with my own iCal library. It was trivial to 
do (though I knew enough about iCalendar in the first place). WRT slide 
library not having been updated in a while - yes that is true but it seems 
to work fine - and its open source so you can always contribute. As to 
Legal - of course one has to go through that for every piece of open source 
software at least once...

2. Using a simple GET request for free-busy:

The example given is not as simple as it first seems: there is still work 
you have to do to at the very least to parse and understand the date/period 
format and know what 'BUSY-TENTATIVE' etc means. i.e. the semantics of 
calendars still have to be understood no matter what syntax or protocol is 
used to transport the data.

Certainly if all you want is a free-busy view of a single calendar, the GET 
approach is trivial and easy. But the reality is there is much more to 
calendaring than just that.

Lets be clear, the free-busy report in CalDAV access is not really useful 
when it comes to doing free busy lookups of calendar USERS as opposed to 
just looking at a static calendar. The actual need is to target calendar 
users (who may have more than one calendar contributing to their free 
busy). The CalDAV schedule specification, a new version of which was 
published to internet-drafts last week, addresses this by allowing iTIP 
free busy requests targeted at one (or more) local (or possibly remote) 
users on a CalDAV server. This returns a much more useful response listing 
each user's f-b info. It also deals with the issue of how to grant someone 
the right to only see free busy and not the entire calendar data.

3. REPORT method and firewalls:

Any organization that has gone to the trouble to setup a firewall (be it 
one that allows WebDAV methods or not) will likely require all external 
users to use SSL when connecting from outside when accessing company 
sensitive information such as email and calendars. So ssl (https) will 
almost certainly be a requirement for CalDAV use and that, as others have 
pointed out, pretty much gets around any firewall problems.

4. Make REPORTs optional:

The reports are a key part of CalDAV, if you make them optional then you 
might just as well do plain WebDAV (e.g. GroupDAV) or HTTP. They are 
certainly not trivial to implement (well multiget is actually pretty easy) 
but most of the complexity is tied up in the calendar data semantics. For 
example, a time-range query seems simple at first glance, but when you take 
into account all possibilities allowed by iCalendar (timed, all-day, 
floating, timezones, recurrences, events with a start only, to-do's with 
due only etc) it gets complicated. We spent a fair bit of time putting 
together the tables describing how that works for the different components 
in the hope that would save implementers a lot of time.

5. iCalendar vs XML syntax:

We did design CalDAV in such a way that an XML-representation of iCalendar 
data could be used at some point in the future in a backwards compatible 
manner once one has been standardized. It certainly seems like 
standardizing that should be the first step to the simple GET approach and 
to CalATOM etc. Someone needs to pick up that effort again and run with 
it...

People have pointed to some benefits of XML syntax, including XPath/XQuery. 
But again, those do not address the semantics of calendaring. The most 
common query that is likely to used in calendaring is a time-range query. 
XPath/XQuery would have to be extended with a special 'timerange' test 
function for that to work properly with recurrences, floating time etc - 
another syntax does not hide the complexity of the semantics.

In any case, I do think having an xml syntax a useful thing to have, but 
its going to have to live alongside iCalendar for a long time to come 
because iCalendar is already widely deployed and used. Upgrading/changing 
data formats takes a very long time to do - don't forget there are still 
many implementations using the older vCalendar spec even today (e.g. many 
mobile devices).

6. xslt on free-busy:

I'm not an xslt expert, but would welcome comment from others who are. 
However, I do question whether a simple transformation is enough. For 
example, the user would almost certainly want to see the UTC-relative 
free-busy times shifted to their local timezone (or the timezone in which 
they are planning the meeting) so the xslt transform would need to apply 
timezone/dst rules. Of course you could push the timezone offset 
calculation off to the server and have the returned free-busy times already 
shifted.

Summary:

At first glance having a simple free-busy lookup via GET sounds like a 
great idea, but when you look at real use cases and constraints its going 
to be a lot harder than originally proposed. Of course it can be done, but 
by the time you've finished addressing the real-world use cases you may 
well end up with something just as 'hard' to do as the CalDAV equivalent.

If people want to pursue this then I encourage you to write up the actual 
use cases that need to be addressed and then see what needs to be done. You 
might want to take a look at some of the use cases that Calconnect produced 
too: <http://www.calconnect.org/publications/caldavusecasesv1.0.pdf>.

I suspect there is still plenty more to discuss on this topic...

-- 
Cyrus Daboo