Subject: [VCARDDAV] I-D Action:draft-ietf-vcarddav-webdav-mkcol-01.txt

From: [email-masked]
Date: Mon, 24 Nov 2008 20:45:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the vCard and CardDAV Working Group of the IETF.

	Title           : Extended MKCOL for WebDAV
	Author(s)       : C. Daboo
	Filename        : draft-ietf-vcarddav-webdav-mkcol-01.txt
	Pages           : 11
	Date            : 2008-11-24

This specification extends the WebDAV MKCOL method to allow
collections of arbitrary resourcetype to be created and to allow
properties to be set at the same time.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-vcarddav-webdav-mkcol-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Julian Reschke <[email-masked]>
Date: Wed, 26 Nov 2008 17:38:30 +0100

Hi,

I just checked, and it appears my comments for draft -00 really haven't 
been considered yet: 
<http://www.ietf.org/mail-archive/web/vcarddav/current/msg00496.html>. 
Please do so.

On reading -01, I found one other issue: when using extended MKCOL, is 
it required to specify DAV:collection in the resource type? It appears 
irrelevant (as the resource always will be a collection) -- I don't have 
any specific preference, but it could be good to clarify that in order 
to avoid interop problems.

Besides that, I found mainly editorial issues (sent privately to Cyrus), 
such as:

1) too generic references (I prefer when a spec tells the reader which 
secton to visit), and

2) RFC-Editor nits (unexpanded abbreviations, text talking about "this 
proposal" instead of "this specification", Title Case in Section Titles) 
-- I think it's good to have them resolved as early as possible -- the 
less changes the RFC Editor needs to do, the better (speaking from 
experience :-).

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 26 Nov 2008 17:38:30 +0100

Hi,

BR, Julian