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

About the Halloween Memo

From: Jim Whitehead <ejw@ics.uci.edu>
Date: Tue, 10 Nov 1998 17:05:35 -0800
To: WEBDAV WG <w3c-dist-auth@w3.org>
Message-ID: <007301be0d0f$63e0cce0$d115c380@galileo.ics.uci.edu>
As many of you are aware, in the last week of October an internal Microsoft
memo was leaked to Eric Raymond.  This memo overviews the Open Source
Software movement and outlines strategies which Microsoft can use to
counteract its potential competitive threat. Since the memo was released to
the public on October 31, it has been called the "Halloweeen Memo" (named
after the US/Canada Halloween holiday).

My intent in making this post is to let you know about the leaked memo, in
case you hadn't already heard about it through the press, and to rebut the
DAV-specific content in the memo.  This topic has been discussed at length
on the ietf@ietf.org mailing list (archived at:
http://www.ietf.org/mail-archive/ietf/maillist.html, thread begins at
http://www.ietf.org/mail-archive/ietf/msg02760.html), and on many other
mailing lists.  I encourage you to read through the discussion on the
ietf@ietf.org mailing list before making a post on this subject to the
WebDAV WG.  You may find your point was already made.

The memo can be found online at:


This site also contains another leaked Microsoft memo, called "Halloween
II", which focuses solely on Linux, as opposed to the first memo which
considered the Open Source Software movement more broadly.

The first Halloween memo also discusses Internet protocols, noting that one
of the strengths of Linux is as a server for these protocols.  The WebDAV
Distributed Authoring protocol was explicitly mentioned in this memo.
Salient parts of the DAV discussion are (a specific product name has been
"X"'ed out):

    HTTP-DAV. DAV is complex and the protocol spec provides an
    infinite level of implementation complexity for various
    applications (e.g. the design for XXXXXXX over DAV is good but
    certainly not the single obvious design). Apache will be hard
    pressed to pick and choose the correct first areas of DAV to implement.

These assertions are false.  In fact, there currently exist three WebDAV
servers and one WebDAV client which were not developed by Microsoft, nor
developed by editors of the WebDAV specification.  Each of the servers was
implemented by a single individual. The client was implemented by a team of
5 UCI *undergraduates* over two quarters.  As announced on the
mailing list last week, one of the servers is a module for Apache.

So, this does not sound to me like "infinite implementation complexity."
Rather, it sounds like rough consensus (the spec. they were working from)
and running code.

The Halloween memo also discusses making proprietary extensions to existing
protocols as a means to de-commoditize them.  In particular, this
discussion, in close proximity to the text about WebDAV, raised the question
of whether WebDAV has been designed in such a way to make it susceptible to
proprietary extension.  It has not.  Every Internet protocol which has
mechanisms for extensibility creates the possibility that those mechanism
can be used for proprietary extensions.  In this regard, WebDAV is like
other Internet protocols.  Furthermore, since many of the extensibility
mechanisms in WebDAV are inherited from HTTP, if DAV has been designed for
ease of proprietary extension, HTTP likely shares those problems.

Personally, I think this entire episode will turn out to be a minor plus for
WebDAV.  The memo has introduced WebDAV to a broader audience, and ensured
that Greg Stein's WebDAV Apache module received more attention than it
otherwise might have.  On the down side, some people may come away with the
impression that WebDAV is complex, and hard to implement.  I hope you'll
join me in providing lots of facts to reverse this impression whenever it
pops up.

- Jim
Received on Tuesday, 10 November 1998 20:17:02 UTC

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