Subject: Comments on draft-daboo-carddav-02

From: Julian Reschke <[email-masked]>
Date: Sun, 15 Jul 2007 12:21:31 +0200

Below are some high-level comments on draft-daboo-carddav-02 
(<http://tools.ietf.org/html/draft-daboo-carddav-02>). I'm cross-posting 
this to the WebDAV and Carddav mailing lists, but will send a separate 
mail going into some other details of CardDAV just to the CardDAV 
mailing list.

The CardDAV design essentially is the same as for CalDAV, which has 
recently been approved by the IESG and been published as RFC4791. So it 
must be good, right?

Although I do agree that CalDAV solves an interesting problem, and that 
it is likely going to work in practice, it made several design decisions 
that I think hurt it with respect to acceptance, performance and 
generality. I understand that it's very tempting to just copy over the 
design; but I think it would be really good to reconsider the points below.

Overall design / new methods

Both specs use standard MIME types, and expose data through HTTP. This 
is a good thing. They also define new subclasses of WebDAV collections, 
which add some new constraints on their contents. I'm not entirely 
convinced that this is really needed, but in this case I'll trust the 
domain knowledge from the calendaring people. I'm not sure though 
whether the constraints for address books really require this.

The introduction of new DAV:resourcetypes however has lead to the 
introduction of new HTTP methods, with the single purpose of creating a 
WebDAV collection with a certain set of properties. I think this is an 
extremely bad idea.

Now I do *not* belong to the group of people with "new method angst". 
Defining new methods that have general applicability is completely ok 
IMHO. Good examples are COPY/MOVE, some of the versioning methods, BIND 
and so on. The difference to MKCALENDAR and MKADDRESSBOOK is that these 
ones are restricted to a single application use case. So what's next? 
MKPHOTOCOLLECTION? MKMUSIKCOLLECTION?

Instead, I'd suggest defining what MKCALENDAR and MKADDRESSBOOK have in 
common, and come up with a single solution to that. For instance, such 
as MKCOL using a request body that carries a set of properties, 
including the WebDAV resource type.

Use of Reports

Everytime a new REPORT is introduced, a new set of information is made 
hard to cache. In some cases that may be harmless (such as when it's 
something like a query, line in some RFC3744 reports).

However, defining a "multiget" really seems to be a bad idea, and now 
there are even two of those! Please take this out until it can be shown 
that just sending a bunch of GET requests (which can take advantage of 
caching) is not sufficient.

Property model

The specs avoid exposing the content of their data objects as WebDAV 
properties. This leads to lots of workarounds, such as introducing 
"pseudo-properties" containing the actual content 
(CARDDAV:addressbook-data), and abuse of DAV:prop for something that is 
not a WebDAV property. Don't do this, it requires generic WebDAV servers 
to use lots of special cases. (WebDAV SEARCH started with pseudo 
properties but got successfully rid of them, so this can be done).

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sun, 15 Jul 2007 23:49:39 -0400

I agree with all of Julian's comments below.

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 16 Jul 2007 10:35:17 -0400

Hi Julian,
Thanks for your detailed review.

--On July 15, 2007 12:21:31 PM +0200 Julian Reschke <[email-masked]> 
wrote:

> common, and come up with a single solution to that. For instance, such as
> MKCOL using a request body that carries a set of properties, including
> the WebDAV resource type.

Note that it was actually RFC3253 that let the cat out of the bag (so to 
speak) wrt new methods for creating collections (MKWORKSPACE and 
MKACTIVITY). In CalDAV We chose to be consistent with that approach by 
having MKCALENDAR, and hence CardDAV has MKADDRESSBOOK.

However, I do agree that this is not an ideal state of affairs. If there is 
consensus in the WebDAV community to do so, I agree that we should write up 
a formal extension to MKCOL that would cover all the other MKxxx's 
behaviors. However, I do not believe that belongs in CardDAV, it should be 
a separate extension that CardDAV can itself leverage. I would be happy to 
put a spec together on that (extracting the behaviors from the existing 
specs).

What do others thinks about this?

> caching) is not sufficient.

CalDAV has proved (to me at least) that multiget is a big win for both 
server and  client. Perhaps other implementers can also comment.

Its a win for several reasons including:

1) Cutting down on roundtrips. We did have discussion about why pipelining 
is not reliable in the PATCH extension thread on the HTTP list, though in 
this case we are only dealing with GETs.

2) multiget allows both the data and properties to be returned in one go: 
i.e. it is the equivalent of a GET and a PROPFIND.

3) It is much more efficient for a server to process a single request for a 
bunch of resources than to do separate requests. Whilst this ma admittedly 
be implementation specific, I can tell you that being able to cache certain 
things during the multiget is handy (e.g. only having to calculate the 
inherited aces that propagate down to all child resource of the same 
collection once, or being able to do a single DB query for all properties 
in one transaction rather than multiple ones for each resource).

Bottom line is I think multiget is vital to performance and should remain 
in.

That said, perhaps a more generic "multiget" behavior could be done that 
would be applicable to WebDAV as a whole. Really all multiget is is a 
PROPFIND that targets specific resources - with the one addition of the 
"pseudo" resource body property (which is the only thing that differs 
between CalDAV and CardDAV).

> properties but got successfully rid of them, so this can be done).

Well CardDAV and CalDAV are special cases of a generic WebDAV server. So I 
don't see this as being a big issue. There are reasons for doing things the 
way they are and I will address those in more detail in a follow up to your 
more detailed review posted to the CardDAV list.

-- 
Cyrus Daboo

---

From: Julian Reschke <[email-masked]>
Date: Mon, 16 Jul 2007 16:57:09 +0200

> Thanks for your detailed review.

And thanks for the feedback!

> having MKCALENDAR, and hence CardDAV has MKADDRESSBOOK.

Understood. I think there's a small difference in that RFC3253 defined a 
generic framework for versioning -- which may be applicable to many use 
cases -- where Ca*DAV use it for a very specific business case. I'll 
admit that the border between "generic" and these ones is fuzzy, though.

> However, I do agree that this is not an ideal state of affairs. If there 
> is consensus in the WebDAV community to do so, I agree that we should 
> write up a formal extension to MKCOL that would cover all the other 
> MKxxx's behaviors. However, I do not believe that belongs in CardDAV, it 
> should be a separate extension that CardDAV can itself leverage. I would 
> be happy to put a spec together on that (extracting the behaviors from 
> the existing specs).

I think that would be great. I think all we need is a request body (XML 
+ mime type) that will allow to specify a set of WebDAV properties, 
including the resource type.

 > ...
> 1) Cutting down on roundtrips. We did have discussion about why 
> pipelining is not reliable in the PATCH extension thread on the HTTP 
> list, though in this case we are only dealing with GETs.

Yes, so I don't think that these concerns apply.

> 2) multiget allows both the data and properties to be returned in one 
> go: i.e. it is the equivalent of a GET and a PROPFIND.

Understood, but this is related to the issue below: if the contents of 
the calendar/address resource would be exposed as *true* WebDAV 
property, a single PROPFIND would be sufficient.

> ...
> Well CardDAV and CalDAV are special cases of a generic WebDAV server. So 
> I don't see this as being a big issue. There are reasons for doing 
> things the way they are and I will address those in more detail in a 
> follow up to your more detailed review posted to the CardDAV list.
 > ...

Looking forward to that. As this is a general WebDAV design question, 
maybe we should keep it over on this list...

Best regards, Julian

---

From: "Mr. Demeanour" <[email-masked]>
Date: Mon, 16 Jul 2007 16:06:30 +0100

Cyrus Daboo wrote:
> 
> However, I do agree that this is not an ideal state of affairs. If
> there is consensus in the WebDAV community to do so, I agree that we
> should write up a formal extension to MKCOL that would cover all the
> other MKxxx's behaviors. However, I do not believe that belongs in
> CardDAV, it should be a separate extension that CardDAV can itself
> leverage. I would be happy to put a spec together on that (extracting
> the behaviors from the existing specs).
> 

Strongly in favour - and I agree with you that it should be separate
from the CardDAV spec.

But that doesn't force you to adopt the MKADDRESSBOOK route in the
meantime, does it?
>  go: i.e. it is the equivalent of a GET and a PROPFIND.

Not really; the CalDAV multiget requires the server to parse the
resource body, because the client can ask for selected iCalendar
properties. ASs it happens, I think that was a rotten idea, and multiget
would be better-off without that feature.

-- 
Jack.

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 16 Jul 2007 11:19:17 -0400

Hi Mr.,

> But that doesn't force you to adopt the MKADDRESSBOOK route in the

That is true. One option would be to keep MKADDRESSBOOK in, but if the 
MKCOL extension  spec beats CardDAV to the IESG we could remove it.

> would be better-off without that feature.

Returning partial data is important for "low capacity" devices such as 
mobile devices, who arguably benefit the most from multiget as well. Note 
that parsing the data is an implementation issue, e.g. servers that store 
the data in a database can simply implement the the "partial data" aspect 
by doing a query for only the requested parameters etc.

-- 
Cyrus Daboo

---

From: "Mr. Demeanour" <[email-masked]>
Date: Mon, 16 Jul 2007 16:41:22 +0100

> Hi Mr.,

Perhaps I should have signed up using a less silly email address! My
name is Jack Cleaver. I shall alter my list registration details "soon".
>> properties. ASs it happens, I think that was a rotten idea, and
>> multiget would be better-off without that feature.
> 
> Returning partial data is important for "low capacity" devices such
> as mobile devices, who arguably benefit the most from multiget as
> well.

OK, I appreciate that. IME the amount of data in a single CalDAV
resource is generally under about 3K, unless there is an essay in the
<description> field. But I take the point.

> Note that parsing the data is an implementation issue, e.g. servers
> that store the data in a database can simply implement the the
> "partial data" aspect by doing a query for only the requested
> parameters etc.

OK; I'm aware that the majority of CalDAV servers (perhaps the majority
of DAV servers) rely on a database, and that as a consequence, data and
properties are all implemented as columns in a RDB, and are therefore
logically more-or-less equivalent. But that shouldn't colour the
approach taken by spec-writers; otherwise we will end up with specs that
place pressure on implementors to use a RDBMS. In the extreme, we'll end
up with specs that implicitly mandate a RDBMS.

Declaration of interest:
my own project is to implement a CalDAV server that has no DBMS
dependency - it's a servlet that uses exclusively the filesystem for
storing data. I have repeatedly run into details in the specs that would
have been *much* easier to implement had a database been my underlying
store; typically these details relate to the blurred distinction between
data and properties.

-- 
Jack.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 16 Jul 2007 17:47:37 +0200

> store; typically these details relate to the blurred distinction between

So let's assume that the parts of a vCard resource would be exposed as 
(potentially computed) WebDAV properties -- wouldn't the need for the 
multiget report just go away? PROPFIND would be all that's needed, then...

Best regards, Julian

---

From: Stefan Eissing <[email-masked]>
Date: Mon, 16 Jul 2007 17:52:08 +0200

Am 16.07.2007 um 16:57 schrieb Julian Reschke:
>> there is consensus in the WebDAV community to do so, I agree that  
>> we should write up a formal extension to MKCOL that would cover  
>> all the other MKxxx's behaviors. However, I do not believe that  
>> belongs in CardDAV, it should be a separate extension that CardDAV  
>> can itself leverage. I would be happy to put a spec together on  
>> that (extracting the behaviors from the existing specs).
>
> I think that would be great. I think all we need is a request body  
> (XML + mime type) that will allow to specify a set of WebDAV  
> properties, including the resource type.

Maybe send a POST + request body to the parent collection?

POST seems to have been avoided by WebDAV to not interfere with  
webapps using the same URIs. But those days are over.

//Stefan

---

From: Julian Reschke <[email-masked]>
Date: Mon, 16 Jul 2007 18:00:12 +0200

Stefan Eissing wrote:
> POST seems to have been avoided by WebDAV to not interfere with webapps 
> using the same URIs. But those days are over.

That could work as well, but I don't see why we shouldn't use MKCOL when 
we're actually creating a collection.

Best regards, Julian

PS: I'm still not convinced that ADDMEMBER (with precise semantics as 
opposed to POST) isn't needed in HTTP -- see 
<http://greenbytes.de/tech/webdav/draft-reschke-http-addmember-00.html>.

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 16 Jul 2007 12:02:56 -0400

Hi Mr.,

> name is Jack Cleaver. I shall alter my list registration details "soon".

Sorry, my email client has an option to auto-generate the "Hi xxx" line by 
trying to extract the first name from the From email address. Doesn't 
always work well...

> <description> field. But I take the point.

iCalendar data for large recurrence sets with lots of overridden instances 
can grow large. Also, attachments can be included inline with iCalendar 
data so those can get (very) big.

In terms of vCard, PHOTO or SOUND properties are defined, so those can add 
a lot of data.

> up with specs that implicitly mandate a RDBMS.

I agree...see below.

> store; typically these details relate to the blurred distinction between

Actually I have worked on several CalDAV servers to date (something like 
three) and all had slightly different approaches to storing/indexing data. 
In one case it was a pure filesystem store and all queries, partial fetches 
had to go through an iCalendar parser etc - certainly did not perform great 
but was OK for low volume personal use. Another used a pure database 
backend, that was better but still had issues. Another uses the filesystem, 
but augments that with index files for handling queries.

So I think CalDAV and CardDAV do provide the flexibility that is needed - 
but performance will be affected by choice of backend - obviously.

-- 
Cyrus Daboo

---

From: "Mr. Demeanour" <[email-masked]>
Date: Mon, 16 Jul 2007 17:19:43 +0100

Julian Reschke wrote:
> 
> So let's assume that the parts of a vCard resource would be exposed 
> as (potentially computed) WebDAV properties -- wouldn't the need for 
> the multiget report just go away? PROPFIND would be all that's 
> needed, then...

Yes, that's correct, as far as I can see.

If one did that, however, the consequence would be that the GET method
would then become anomalous for CalDAV and CardDAV resources; the data
that it returned would be properties masquerading as content. Similarly
the PUT method would become obsolete, as any CalDAV or CardDAV content
should then be set using PROPPATCH. Anyway, it seems most natural to map
iCalendar/vCard properties to WebDAV properties, rather than to WebDAV
content.

I don't really see that as a terrible problem for CalDAV and CardDAV;
GET and PUT on CalDAV/CardDAV resources could be left undefined, or
those methods could be freed-up for other purposes. GET, in particular,
might be used to present a rendition of the resource. The fact that GET
is easy to cache, and PROPFIND and REPORT are not, would be quite
consistent with that approach - returning a stale, cached version of a
rendition would be a much less serious problem than returning stale
(but live) property data.

This all feels a bit theoretical, though; to make all CalDAV/CardDAV
content become instead grade-A properties would be a pretty fundamental
change in approach, affecting five or six different RFCs, and I hesitate
to suggest anything that radical (without working it through properly
first!).

-- 
Jack.

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 16 Jul 2007 12:22:54 -0400

Hi Julian,

> multiget report just go away? PROPFIND would be all that's needed, then...

The problem is mapping vCard "properties" on to WebDAV "properties". We had 
the same problem in iCalendar which is why CalDAV does not do that. One 
issue is how to represent multiple instances of the same property - in 
vCard/iCalendar certainly properties can appear more than once, yet WebDAV 
only allows one property of an element type per resource. Yes you could do 
things with list elements but it starts to get messy - so we avoided it. It 
would also mean inventing an XML representation of the data - we certainly 
did not want to go down that route with CalDAV at the time.

-- 
Cyrus Daboo

---

From: Julian Reschke <[email-masked]>
Date: Mon, 16 Jul 2007 18:27:51 +0200

> iCalendar/vCard properties to WebDAV properties, rather than to WebDAV

I think GET and PUT should just continue to do what they do today.

> (but live) property data.

You mean, like an HTML view? That can always be done using content 
negotiation, I'd say.

> to suggest anything that radical (without working it through properly

Sorry? It would only affect a single RFC (RFC4791), no?

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 16 Jul 2007 09:35:56 -0700

Synchronization for bodies is also better-defined than  
synchronization for properties.  With the choice of CalDAV bodies  
plus multiget:
  - clients can view just the ETags for a collection to see what  
bodies have changed
  - clients can ask for the bodies of the changed/new resources
  - clients don't have to worry about synchronizing property values  
-- property values are outside the calendaring domain, and the  
server's business

Why not put the content or data in the body of the resource?   For  
calendaring, that's the entire iCalendar object, even though some of  
the iCalendar insides are structured that doesn't mean they're  
metadata -- they *are* the data.  Non-Calendar stuff like ETag is  
true metadata.   It's a confusion in terminology (that WebDAV uses  
"property" for metadata while iCalendar uses "property" for  
structured data) that continually tempts us to use WebDAV metadata  
storage, instead of data storage,  for iCalendar data.

We still don't have the ability to synchronize property values in  
WebDAV.  We could start designing that, but there's not a strong call  
to, unless we start getting confused and put data into the metadata.

Lisa

On Jul 16, 2007, at 9:22 AM, Cyrus Daboo wrote:

>
> Hi Julian,
>
> --On July 16, 2007 5:47:37 PM +0200 Julian Reschke  
> <[email-masked]> wrote:
>
> The problem is mapping vCard "properties" on to WebDAV  
> "properties". We had the same problem in iCalendar which is why  
> CalDAV does not do that. One issue is how to represent multiple  
> instances of the same property - in vCard/iCalendar certainly  
> properties can appear more than once, yet WebDAV only allows one  
> property of an element type per resource. Yes you could do things  
> with list elements but it starts to get messy - so we avoided it.  
> It would also mean inventing an XML representation of the data - we  
> certainly did not want to go down that route with CalDAV at the time.
>
> -- 
> Cyrus Daboo
>
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 16 Jul 2007 18:32:45 +0200

Cyrus Daboo wrote:
> The problem is mapping vCard "properties" on to WebDAV "properties". We 
> had the same problem in iCalendar which is why CalDAV does not do that. 
> One issue is how to represent multiple instances of the same property - 
> in vCard/iCalendar certainly properties can appear more than once, yet 
> WebDAV only allows one property of an element type per resource. Yes you 
> could do things with list elements but it starts to get messy - so we 
> avoided it. It would also mean inventing an XML representation of the 
> data - we certainly did not want to go down that route with CalDAV at 
> the time.

But aren't you already doing that with the calendar-data pseudo 
property? It just has a bigger granularity (the whole entry, rather than 
a subset).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 16 Jul 2007 18:44:56 +0200

Lisa Dusseault wrote:
> 
> Synchronization for bodies is also better-defined than synchronization 
> for properties.  With the choice of CalDAV bodies plus multiget:
>  - clients can view just the ETags for a collection to see what bodies 
> have changed
>  - clients don't have to worry about synchronizing property values -- 
> property values are outside the calendaring domain, and the server's 
> business

Now wouldn't it be nice if a client could check for changed resources 
*and* get their content in a single request? That seems to be something 
obvious missing from the multiget report.

> calendaring, that's the entire iCalendar object, even though some of the 
> iCalendar insides are structured that doesn't mean they're metadata -- 
> they *are* the data.  Non-Calendar stuff like ETag is true metadata.   
> It's a confusion in terminology (that WebDAV uses "property" for 
> metadata while iCalendar uses "property" for structured data) that 
> continually tempts us to use WebDAV metadata storage, instead of data 
> storage,  for iCalendar data.

I totally agree that the specs should treat calendar/address book 
objects as proper HTTP resources. What I was mainly complaining about 
was that the content (or parts of the content) are treated as 
"pseudo-properties" for some reports, instead of making them proper 
(computed) properties (or to change the marshalling in the report so 
that no pseudo-properties are introduced).

Everytime a spec defines a new name for a pseudo property (to be used 
where otherwise property names are allowed), that name becomes unusable 
for a true property anyway, so there's really no point at all not to 
expose that information in PROPFIND as well. Fewer special cases, please.

> to, unless we start getting confused and put data into the metadata.

That's a separate issue that should be solved. As a matter of fact, I 
think I've got a good idea to address this and other related things, but 
I didn't have time so far to write it down (famous last words, I know).

Best regards, Julian

---

From: "Mr. Demeanour" <[email-masked]>
Date: Mon, 16 Jul 2007 18:09:22 +0100

Julian Reschke wrote:
> Mr. Demeanour wrote:
> 
>> This all feels a bit theoretical, though; to make all 
>> CalDAV/CardDAV content become instead grade-A properties would be a
>>  pretty fundamental change in approach, affecting five or six 
>> different RFCs, and I hesitate to suggest anything that radical 
>> (without working it through properly first!).
> 

Yes, you're quite right; my mistake.

There are other places in the RFCs where there is a confusion as to the
true nature of WebDAV properties; ACL is maybe the most obvious example.
That's what led me to make that remark.

> storage, instead of data storage,  for iCalendar data.

If ETag is "true metadata", and CalDAV content is "real" data, then what
is the status of a WebDAV/CalDAV property such as <calendar-timezone>?
In iCalendar terms, a VTIMEZONE is an object with status equivalent to
(for example) a VEVENT - but not in CalDAV.

Yes, there are multiple terminological confusions regarding what is and
what is not a property, and what is data. If this subject could be
cleared up properly, I think that would be enormously beneficial.

I'd better finish (and publish) my project, and then sit back for a few
months' reflection. I think these are hard questions, and I'm a bit too
close to it to be able to see it clearly at the moment.

-- 
Jack.

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 16 Jul 2007 10:27:30 -0700

On Jul 16, 2007, at 9:44 AM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>>
>
> Now wouldn't it be nice if a client could check for changed  
> resources *and* get their content in a single request? That seems  
> to be something obvious missing from the multiget report.

I've worked on some synch stuff and it would be even nicer to make  
replication general, not specific to CalDAV.  So I agree, and I'm  
happy Cyrus is doing some work on that.

>> calendaring, that's the entire iCalendar object, even though some  
>> of the iCalendar insides are structured that doesn't mean they're  
> objects as proper HTTP resources. What I was mainly complaining  
> about was that the content (or parts of the content) are treated as  
> (computed) properties (or to change the marshalling in the report  
> so that no pseudo-properties are introduced).
>
> Everytime a spec defines a new name for a pseudo property (to be  
> used where otherwise property names are allowed), that name becomes  
> unusable for a true property anyway, so there's really no point at  
> all not to expose that information in PROPFIND as well. Fewer  
> special cases, please.

Fair enough.

>> WebDAV.  We could start designing that, but there's not a strong  
>> call to, unless we start getting confused and put data into the  
>> metadata.
>
> That's a separate issue that should be solved. As a matter of fact,  
> I think I've got a good idea to address this and other related  
> things, but I didn't have time so far to write it down (famous last  
> words, I know).

Sounds intriguing.

Lisa

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 16 Jul 2007 13:50:23 -0400

Hi Lisa,

--On July 16, 2007 10:27:30 AM -0700 Lisa Dusseault 
<[email-masked]> wrote:

> replication general, not specific to CalDAV.  So I agree, and I'm happy
> Cyrus is doing some work on that.

Yes its true that its nice to be able to do all that, and the 
synchronization report extension was designed to allow that with the 
extension of using the "pseudo" properties for at least CalDAV and CardDAV.

Note however, that clients may not always want to get the data. In fact 
that could be a bad thing to do if there have been lots of changes. Since 
the client has no control over the amount of information the server would 
return, and since resource bodies may be much larger than the set of 
properties otherwise asked for, this could be a big problem on limited 
capacity devices or over slow links.

What I would expect is that a client would use the sync. report to find the 
list of changed resources and then do a series of multigets to "page" 
through the changes and update its cache making sure that each response is 
likely to be within any resource constraints it might have. So I think 
there is a need for both the sync. and multiget reports as separate 
features. Of course we could combine all these into one, but then we might 
end up with one big monster...

-- 
Cyrus Daboo

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Mon, 16 Jul 2007 11:52:32 -0700

This would have been useful in CalDAV; rather than having the  
client hope that the name it chooses isn't already in use.

	-wsv

On Jul 16, 2007, at 9:00 AM, Julian Reschke wrote:

> PS: I'm still not convinced that ADDMEMBER (with precise semantics  
> as opposed to POST) isn't needed in HTTP -- see <http://greenbytes.de/tech/webdav/draft-reschke-http-addmember-00.html 
> >.

—
Wilfredo Sánchez - [email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Mon, 16 Jul 2007 21:23:46 +0200

Wilfredo Sánchez Vega wrote:
> 
>   This would have been useful in CalDAV; rather than having the client 
> hope that the name it chooses isn't already in use.
> 
>     -wsv

PUT ...
If-None-Match: "*"

?

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Mon, 16 Jul 2007 14:02:46 -0700

Sure, but if you fail, you get to try again.  Better to have a way  
for the server to choose a name and tell you.  Granted, the odds are  
pretty low if you use GUIDs or something, but you still have to  
implement the logic to try again, just in case.

	-wsv

—

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 16 Jul 2007 17:04:34 -0400

Hi Julian,

>> hope that the name it chooses isn't already in use.

Whilst that tells you if you have a conflict, you still end up having to 
take a guess at another resource name to use to actually save the new data. 
Hopefully, the second guess will work.

The one benefit I have heard to the POST/ADDMEMBER approach is if the 
server has limitations on resource names. Typically those are servers that 
proxy their data to/from another, more rigid, system.

-- 
Cyrus Daboo

---

From: Julian Reschke <[email-masked]>
Date: Mon, 16 Jul 2007 23:13:50 +0200

Cyrus Daboo wrote:
> take a guess at another resource name to use to actually save the new 
> data. Hopefully, the second guess will work.
> 
> server has limitations on resource names. Typically those are servers 
> that proxy their data to/from another, more rigid, system.

Yep. And that's why I think ADDMEMBER would be useful. POST just is too 
generic.

Best regards, Julian

---

From: Stefan Eissing <[email-masked]>
Date: Tue, 17 Jul 2007 09:26:01 +0200

Am 16.07.2007 um 23:13 schrieb Julian Reschke:
> Cyrus Daboo wrote:
>> Whilst that tells you if you have a conflict, you still end up  
>> having to take a guess at another resource name to use to actually  
>> save the new data. Hopefully, the second guess will work.
>> The one benefit I have heard to the POST/ADDMEMBER approach is if  
>> the server has limitations on resource names. Typically those are  
>> servers that proxy their data to/from another, more rigid, system.
>
> Yep. And that's why I think ADDMEMBER would be useful. POST just is  
> too generic.

I think a client would need context for both methods. If you think of  
adding ADDMEMBER to a generic client like "curl", it's not much more  
it could do besides what it already does for POST.

If you talk about a "higher level" client (e.g. more aware of the  
context it works on), the method name again does not make a big  
difference. If AtomPub would have used ADDMEMBER instead of POST,  
what improvement exactly would one expect from that?

Cheers,

Stefan

---

From: Elias Sinderson <[email-masked]>
Date: Mon, 16 Jul 2007 09:32:54 -0700

Cyrus Daboo wrote:
> --On July 15, 2007 12:21:31 PM +0200 Julian Reschke 
>> introduction of new HTTP methods, with the single purpose of creating 
>> a WebDAV collection with a certain set of properties. I think this is 
>> an extremely bad idea. [...] I'd suggest defining what MKCALENDAR and 
>> MKADDRESSBOOK have in common, and come up with a single solution to 
>> that. For instance, such as MKCOL using a request body that carries a 
>> set of properties, including the WebDAV resource type.
> [...] I do agree that this is not an ideal state of affairs. If there 
> MKxxx's behaviors. However, I do not believe that belongs in CardDAV, 
> it should be a separate extension that CardDAV can itself leverage. I 
> would be happy to put a spec together on that (extracting the 
> behaviors from the existing specs).
>
I believe that this is a most sensible idea -- the creation of new 
protocol methods to operate on resource types is Really Bad (TM) and 
defining a generic, extensible solution that supports domain specific 
MKxxx behavior is clearly preferred. Extending MKCOL with semantics 
covering the optional inclusion of a request body containing properties 
would seem like a very reasonable starting point in this.

It would further be my preference to see the above specified prior to 
pushing CardDAV along the RFC track.

Regards,
Elias

---

From: Julian Reschke <[email-masked]>
Date: Sun, 22 Jul 2007 16:30:06 +0200

> I didn't have time so far to write it down (famous last words, I know).

OK,

in the meantime I've spent some time on a proposal, see 
<http://greenbytes.de/tech/webdav/draft-reschke-http-get-location-latest.html>.

Essentially it's based on the fact that PROPFIND/REPORT/SEARCH are safe 
methods, but that the information they provide is "off" the bookmarkable 
and cacheable web. So let's try to fix that.

A new entity header would *allow* the server to advertise that location, 
for instance 
(<http://greenbytes.de/tech/webdav/draft-reschke-http-get-location-latest.html#examples>):

-----

A.1.  WebDAV Collection Membership

    In this example the client uses the WebDAV PROPFIND method ("HTTP
    Extensions for Web Distributed Authoring and Versioning", [RFC4918],
    Section 9.1) to get a list of all collection members, along with
    their DAV:resourcetype property ([RFC4918], Section 15.9):

    >>Request

    PROPFIND /collection/ HTTP/1.1
    Host: example.com
    Depth: 1
    Content-Type: application/xml

    <propfind xmlns="DAV:">
      <prop>
        <resourcetype/>
      </prop>
    </propfind>

    The response contains the requested information, plus the GET-
    Location header, identifying a separate resource which can provide
    the same information using the HTTP GET method:

    >>Response

    HTTP/1.1 207 Multi-Status
    Content-Type: application/xml
    GET-Location: <http://example.com/collection/;members>; etag="123";
                  max-age=3600

    <multistatus xmlns="DAV":>
      <response>
        <href>/collection/</href>
        <propstat>
          <prop>
            <resourcetype><collection/></resourcetype>
          </prop>
          <status>HTTP/1.1 200 OK</status>
        </propstat>
      </response>
      <response>
        <href>/collection/member</href>
        <propstat>
          <prop>
            <resourcetype/>
          </prop>
          <status>HTTP/1.1 200 OK</status>
        </propstat>
      </response>
    </multistatus>

    The responses provided the URL of a "gettable" resource, so when the
    client wishes to refresh the collection information, it uses that
    URI.  The response contained the entity tag for the data being
    returned, so it can make the request conditional:

    >>Request

    GET /collection/;members HTTP/1.1
    Host: example.com
    Accept: application/xml
    If-None-Match: "123"

    The information did not change, so the server does not need to return
    new data:

    >>Response

    HTTP/1.1 304 Not Modified

    Later on, the client tries again.  This time, however, a second
    member has been added:

    >>Request

    GET /collection/;members HTTP/1.1
    Host: example.com
    Accept: application/xml
    If-None-Match: "123"

    >>Response

    HTTP/1.1 200 OK
    Content-Type: application/xml
    ETag: "124"

    <multistatus xmlns="DAV":>
      <response>
        <href>/collection/</href>
        <propstat>
          <prop>
            <resourcetype><collection/></resourcetype>
          </prop>
          <status>HTTP/1.1 200 OK</status>
        </propstat>
      </response>
      <response>
        <href>/collection/member</href>
        <propstat>
          <prop>
            <resourcetype/>
          </prop>
          <status>HTTP/1.1 200 OK</status>
        </propstat>
      </response>
      <response>
        <href>/collection/member2</href>
        <propstat>
          <prop>
            <resourcetype/>
          </prop>
          <status>HTTP/1.1 200 OK</status>
        </propstat>
      </response>
    </multistatus>

    Finally, the collection has been removed by somebody else.  The
    client tries a refresh:

    >>Request

    GET /collection/;members HTTP/1.1
    Host: example.com
    Accept: application/xml
    If-None-Match: "124"

    >>Response

    HTTP/1.1 404 Not Found

    Note that it may be hard to compute strong entity tags for more
    complex PROPFIND responses.  For instance, most properties depend on
    the state of the collection member, not the state of the collection
    itself, and thus the response will change even though the state of
    the collection itself did not change.

    This is why this extension leaves it to the server whether to return
    a GET-Location at all, and if so, whether to return cache validators
    along with it.

----

Feedback appreciated,

Julian