Re: I-D Action:draft-reschke-webdav-post-00.txt

Cyrus Daboo wrote:
> ...
> One thing this reminds me of: another reason why this POST may be needed 
> is if the server enforces a particular naming scheme on members. e.g., a 
> CalDAV server may require that all member path segments match the UID in 
> the calendar data, or match a record-id in its data store etc. In this 
> case the add-member behavior is required. So its not just the case of 
> "the client doesn't care to name members itself", but also this other 
> one. Probably worth adding a comment on this.
> ...

Well, if the server enforces a particular naming scheme, and does not 
support POST, then the client will need out-of-band information about 
the naming scheme, right? How would that work in practice?

I think what's more common is that the server would *like* to enforce a 
naming scheme, but can't, as clients assume PUT will just work. Isn't 
that the situation for many CalDAV servers?

What I've added is 
(<http://greenbytes.de/tech/webdav/draft-reschke-webdav-post-issues.html#issue.member-uri-content>):

"As a matter of fact, letting the server choose the member URI not only 
is a simplification for certain types of clients, but can also reduce 
the complexity of the server (in that it doesn't need to persist an 
additional client-supplied identifier where the it already has an 
internal one like a UUID or a primary key)."

That said, I think I'm ready to submit a new draft soon; comments on 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-post-latest.html> 
appreciated.

BR, Julian