W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2004

Comments on draft-hildebrand-webdav-notify-00

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 02 Oct 2004 00:20:15 +0200
Message-ID: <415DD81F.3060308@gmx.de>
To: w3c-dist-auth@w3.org

and <http://ietf.org/internet-drafts/draft-hildebrand-webdav-notify-00.txt>:

Introductory remark: I know little-to-nothing about XMPP and PUBSUB, but 
have some background on WebDAV. Please read the following with this in 
mind :-).

Section 1.1, Rational


The rational mentions email as potential notification mechanism. It 
claims that the natural WebDAV event payload using XML makes it a bad 
fit. I would assume that sending XML attachments by email is an 
absolutely natural thing to do. If email is used as example how not to 
do it, a stronger point should to be made (performance?).

Section 1.2, Use cases


The first one ("viewing" a folder) seems to match what Microsoft is 
doing in Exchange/Sharepoint 
Would it make sense to discuss about this approach somehwere?

Section 1.5, PUBSUB terminology


Is there a good summary of PUBSUB for people not knowing much about the 
spec (like me)?

Section 2, Usage of namespaces


I note that the spec is using XML namespaces properly (is uses valid 
namespace URIs, and doesn't put stuff into other people's namespaces). 
This is A Good Thing. However, I'm not sure why it introduces so many 
new namespaces. Is there any particular reason why the new properties 
can't all live in the same namespace? This may sound like nitpicking, 
but I'd really like to find out the motivation for this...

Section 2.1, Notify property


Nitpicking: the property value in the example is neither "true" nor 
"false" but "<CR>        true<CR>      " (whitespace in property values 
is significant).

Not nitpicking: can't "notify" and "node" be rolled into a single property?

Section 3.1, payload


Editorial note: when talking of things defined in RFC2396, it always 
makes sense to refer to a specific grammar production to avoid confusion 
(some people believe a relativeURI is a URI, some don't :-). Maybe say 
"absoluteURI (see ...)" here.

Section 3.1, MKCOL/PUT


I think for those not familiar with XMPP/PUBSUB it would be nice to 
understand what benefit there is in re-using existing formats here (I'm 
sure there are!). For instance, what will a generic PUPSUB event 
receiver do with these events?

Section 3.1, payload for UNLOCK


The payload for UNLOCK needs to carry the lock token (you can have 
multiple shared locks on the same URI).

Section 3.2, payload for LOCK


"Note: A WebDAV service MAY send less information than shown above, and 
for security purposes SHOULD NOT include the <locktoken/> element 
described in [WEBDAV]."

Why would that be a security problem? In particular, if the server makes 
the locktoken visible in PROPFIND anyway, why should it remove it from 
the event notification?

Section 3.3, payload for diffs


Is there any extensibility planned for the "format" attribute?

Section 3.5, copy/move



Q: how does this work for COPY/depth:infinity? The same way as for MOVE 
(that is, only one item needed?) What if a COPY or MOVE operation 
completes with errors (resources not moved or copied)?

Section 4.5, Unlock


I'm aware of the fact that the spec says to ignore whitespace in the XML 
examples (I'd prefer them to be rewritten such that this is irrelevant). 
Anyway, even ignoring whitespace, 
"opaquelocktoken:e71d4fae-5dec-22d6-\fea5-00a0c91e6be4" isn't a valid 
lock token (note the "\").

Section 6.2, References


It would be nice if the GDIFF reference came with a URI. Same for 
XMPP-PUBSUB in section 6.1.

Best regards,


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Friday, 1 October 2004 22:20:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:32 UTC