Comments on draft-hildebrand-webdav-notify-00

(see 
<http://greenbytes.de/tech/webdav/draft-hildebrand-webdav-notify-00.html> 
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

<http://greenbytes.de/tech/webdav/draft-hildebrand-webdav-notify-00.html#rfc.section.1.1.p.3>

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

<http://greenbytes.de/tech/webdav/draft-hildebrand-webdav-notify-00.html#rfc.section.1.2.p.2>

The first one ("viewing" a folder) seems to match what Microsoft is 
doing in Exchange/Sharepoint 
(<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/e2k3/e2k3/_techsel_tech_10.asp>). 
Would it make sense to discuss about this approach somehwere?


Section 1.5, PUBSUB terminology

<http://greenbytes.de/tech/webdav/draft-hildebrand-webdav-notify-00.html#rfc.section.1.5>

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


Section 2, Usage of namespaces

<http://greenbytes.de/tech/webdav/draft-hildebrand-webdav-notify-00.html#rfc.section.2>

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

<http://greenbytes.de/tech/webdav/draft-hildebrand-webdav-notify-00.html#rfc.section.2.1>

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

<http://greenbytes.de/tech/webdav/draft-hildebrand-webdav-notify-00.html#rfc.section.3.1>

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

<http://greenbytes.de/tech/webdav/draft-hildebrand-webdav-notify-00.html#rfc.section.3.1.p.8>

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

<http://greenbytes.de/tech/webdav/draft-hildebrand-webdav-notify-00.html#rfc.section.3.1.p.5>

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

<http://greenbytes.de/tech/webdav/draft-hildebrand-webdav-notify-00.html#rfc.section.3.2>

"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

<http://greenbytes.de/tech/webdav/draft-hildebrand-webdav-notify-00.html#rfc.section.3.3>

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


Section 3.5, copy/move

<http://greenbytes.de/tech/webdav/draft-hildebrand-webdav-notify-00.html#rfc.section.3.5>

s/body/both/

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

<http://greenbytes.de/tech/webdav/draft-hildebrand-webdav-notify-00.html#rfc.section.4.5>

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

<http://greenbytes.de/tech/webdav/draft-hildebrand-webdav-notify-00.html#rfc.references.2>

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



Best regards,

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Friday, 1 October 2004 22:20:54 UTC