- From: Juergen Reuter <reuterj@ira.uka.de>
- Date: Mon, 04 Dec 2000 12:08:44 +0100
- To: Lisa Dusseault <lisa@xythos.com>
- cc: w3c-dist-auth <w3c-dist-auth@w3.org>, reuterj@ira.uka.de, jjh@ira.uka.de
> Changing the syntax of the PROPFIND and PROPPATCH in the manner you
> suggest would break current implementations. This would change the bits
> on the wir= e for all PROP* messages, even for ones which include no
> extensions.
Not necessarily. Just think of HTTP itself. In HTTP/0.9, there were no
message headers (see Simple-Request/Response syntax in RFC1945). It was
HTTP/1.0 that introduced message headers along with the HTTP-Version
field. If a client does not provide the HTTP-Version field, the server
can assume the client to be an HTTP/0.9 client, and the server does not
serve any message header. Most implementations still maintain this
behaviour:
# telnet www.webdav.org 80
Trying 206.54.183.234...
Connected to www.webdav.org.
Escape character is '^]'.
GET /
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
...
</html>
Connection closed by foreign host.
#
The HTTP-Version field is essential for the behaviour. In HTTP/1.1, for
example, the Host message header became mandatory and thus effectively
introduced another incompatibility. It is again the HTTP-Version field
that lets the client and server smartly agree on a protocol version
without breaking existing client or server implementations.
The same trick can be done with WebDAV: The only thing to do is to
introduce -- for example -- a DAV-Version message header. If a client
does not submit such a header, the server can assume that this client
only understands the current format of WebDAV as of RFC2518. Vice versa,
if a client submits a DAV-Version header, but the server does not respond
with a DAV-Version header, the client can assume that the server only
understands the current format of WebDAV as of RFC2518. This behaviour
will not break current implementations, but allows you to introduce new
features or new syntax that otherwise would break current implementations.
Actually, I think something like a DAV-Version message header is really
missing in WebDAV.
It is somewhat a pity that WebDAV has to undergo the same lessons that
HTTP already had. It would be nice to collect such general lessons about
writing protocols and provide them for authors of other protocols --
maybe as an informational RFC for protocol authors?
> While it's arguable that it would be nice to have required valid XML when
> RFC 2818 was written, changing the bits on the wire for Proposed Standard
> protocols isn't done except for worse problems (or much smaller changes)
> than this.
In my opinion, using invalid XML is a really severe problem that probably
will lead to interoperability. Already now there are frequent postings
on this list about WebDAV implementations that produce faulty output.
And with all those extensions that are currently being developed, I think
the problems are getting worse. And as far as I know, there is still no
reference implementation of WebDAV (though at least mod_dav may have good
chances to become a reference server implementation some day). So, you
probably really want to check for correctness were possible.
> As far as validating XML to check interoperability, feel free: RFC2518
> includes a DTD, and implementors are welcome to check their
> implementation against the DTD by validating XML bodies.
No, that is not true. Did you try to apply the "DTD"? I did. RFC2518
contains lots of examples of invalid XML. Most of them have been
discussed on this list during 1999. WebDAV's DTD has a rather
informational than specifying character. Currently, you are not able to
do any validation that conforms to the XML specification. Actually,
WebDAV's "DTD" itself has some bugs in it; it does not conform to the XML
specification and can not be used for validating. I finally used a
non-validating XML parser and manually added some methods that do some
kind of non-conforming validation. Very ugly!
> The cat's already out of the bag and can't be put back in.
This sort of argumentation leads to those forever lasting nasty problems.
Just think of the 8+3 filename format that was invented around 1974 for
CP/M and which is -- for backwards compability -- still used today. Just
a few days ago, I once again had to manually rename files that I had
copied from a linux workstation (not connected to the internet) to a
solaris machine, using floppy discs, because the upper/lower case
handling of those 8+3 filenames still does not properly work.
In other words: let us remove those nasty bugs from RFC2518 better now
than in 30 years!
Bye,
Juergen
Received on Monday, 4 December 2000 06:06:40 UTC