From w3c-dist-auth-request@www10.w3.org  Wed May  6 11:05:40 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id LAA20802 for <w3c-dist-auth@www19.w3.org>; Wed, 6 May 1998 11:05:39 -0400 (EDT)
Received: from ietf.org (ietf.org [132.151.1.19]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id LAA27381 for <w3c-dist-auth@w3.org>; Wed, 6 May 1998 11:05:38 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA10716;
	Wed, 6 May 1998 11:05:34 -0400 (EDT)
Message-Id: <199805061505.LAA10716@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: w3c-dist-auth@w3.org
>From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 06 May 1998 11:05:34 -0400
Sender: cclark@CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-webdav-enpreq-01.txt

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the WWW Distributed Authoring and Versioning 
Working Group of the IETF.

	Title		: Requirements for Event Notification Protocol
	Author(s)	: M. Fisher, S. Reddy
	Filename	: draft-ietf-webdav-enpreq-01.txt
	Pages		: 7
	Date		: 05-May-98
	
   This document describes the requirements for an Event Notification
   Protocol.  The objective is to provide a simple, scalable and highly
   efficient notification protocol while also providing the appropriate
   flexibility to meet the needs of both the Internet and enterprise
   environments. Intent of this document is to collect all notification
   requirements in one place and leverage the work already done in other
   working groups.
 
   This document is one of a set of documents which together describe
   all aspects of a new Event Notification Protocol (ENP). ENP is an
   application level protocol that can be used for distributed event
   notification. The full set of ENP documents include:

      (1). Requirements for Event Notification Protocol
 
      (2). Model and Semantics Event Notification Protocol
 
      (3). Protocol Specification for Event Notification Protocol
 
      (4). Rationale for the Structure and Model for the Event
           Notification Protocol

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-webdav-enpreq-01.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-webdav-enpreq-01.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ietf.org.  In the body type:
	"FILE /internet-drafts/draft-ietf-webdav-enpreq-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19980505145738.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-webdav-enpreq-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-webdav-enpreq-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19980505145738.I-D@ietf.org>

--OtherAccess--

--NextPart--



From w3c-dist-auth-request@www10.w3.org  Fri May  8 16:43:25 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id QAA19033 for <w3c-dist-auth@www19.w3.org>; Fri, 8 May 1998 16:43:25 -0400 (EDT)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50]) by www10.w3.org (8.8.5/8.7.3) with SMTP id QAA16370 for <w3c-dist-auth@w3.org>; Fri, 8 May 1998 16:43:23 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa20204;
          8 May 98 13:33 PDT
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: w3c-dist-auth@w3.org
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
Date: Fri, 8 May 1998 13:38:43 -0700
Message-ID: <002e01bd7ac1$4ac8eac0$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <3.0.3.32.19980424163122.00a53de0@pop-server.wrc.xerox.com>
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Subject: RE: Circular References

The risk from circular references for the server comes when operations on
the server "follow" the referential member to its destination, and end up in
a loop.  However, my understanding of the sense of the room at the LA IETF
and from previous discussions on this topic is that people are opposed to
having the server follow referential members.  So, for example, a PROPFIND
of Depth infinity used to list the members of a collection hierarchy would
only list the existence of the referential members, but would not follow
these referential members into any collections to which they might
potentially refer.

Based on this, I see no risks to the server from circular references, since
the server will not encounter these loops in its processing.

A will client which is proactively requesting the destination of a
referential member of a collection could run into situations where it
encounters circular reference loops.  As Judy points out, these loops are
inevitable since external members can point off to servers outside the
control of the originating server. Since these circular links can occur, and
are infeasible to prevent, I recommend we permit circular loops, and add
language to the protocol draft warning client implementors of the potential
existence of these loops.

- Jim


> -----Original Message-----
> From: Judith Slein [mailto:slein@wrc.xerox.com]
> Sent: Friday, April 24, 1998 1:31 PM
> To: w3c-dist-auth@w3.org
> Subject: Circular References
>
>
> Based on the minutes of the April 2 WebDAV meeting, it sounds as if there
> needs to be more discussion of circular references in the context of the
> advanced collections requirements.
>
> Once we support referential members of collections, there is potential for
> circular references unless we do something to prevent it.  Earlier DAV
> drafts explicitly stated that servers are not required to detect circular
> references.  It is probably unrealistic to expect a server to prevent
> circular references, since references can cross servers.
>
> What do people think?
>
>
> Name:		Judith A. Slein
> E-Mail:		slein@wrc.xerox.com
> Phone:  	(716) 422-5169
> Fax:		(716) 422-2938
>
> Xerox Corporation
> Mail Stop 105-50C
> 800 Phillips Road
> Webster, NY 14580


From w3c-dist-auth-request@www10.w3.org  Fri May  8 16:53:58 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id QAA19323 for <w3c-dist-auth@www19.w3.org>; Fri, 8 May 1998 16:53:58 -0400 (EDT)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50]) by www10.w3.org (8.8.5/8.7.3) with SMTP id QAA16507 for <w3c-dist-auth@w3.org>; Fri, 8 May 1998 16:53:55 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa21802;
          8 May 98 13:42 PDT
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: w3c-dist-auth@w3.org
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
Date: Fri, 8 May 1998 13:47:14 -0700
Message-ID: <002f01bd7ac2$7b405660$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <3.0.3.32.19980424161904.00a54d40@pop-server.wrc.xerox.com>
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Subject: RE: Collections and Referential Integrity

Comments below.

> -----Original Message-----
> From: Judith Slein [mailto:slein@wrc.xerox.com]
> Sent: Friday, April 24, 1998 1:19 PM
> To: w3c-dist-auth@w3.org
> Subject: Collections and Referential Integrity
>
>
> Based on the minutes of the April 2 WebDAV meeting, it sounds as if there
> needs to be more discussion of the collections requirements related to
> referential integrity.
>
> It was agreed at that meeting that there should be a new requirement
>
> N.2 It is possible to request creation of a referential member that
> the server will guarentee to have referentially integrity.
>
> Presumably if the client requests a guarantee of referential
> integrity that the server is unable to provide, the server must
> not create the referential member, but respond with some 4xx code.
> In cases where the target of the referential member is on a different
> server, it is unlikely that the server will be able to guarantee
> referential integrity.

I agree, and I believe this represented the sense of the room in LA.

> It looks to me as if N.2 is incompatible with the proposed "N.1 Operations
> on a target do not affect the reference(s)."  Guaranteeing referential
> integrity will sometimes require the server to modify the referential
> member.  For example, when the target is moved, the server must change the
> reference to point to its new location.

Good catch.  In this case, N.1 needs to be modified so the referential
integrity of "strong" links is always maintained, and the server should
refuse to create a "strong" link for which it cannot maintain its
referential integrity.  So the original wording of N.1 holds for "weak"
links, but not for "strong" links.

> Two other proposed requirements build on N.2:
>
> N.3 It is possible to discover whether or not a referential
> member has such 'integrity protection'.
>
> N.4 It is possible to discover whether a resource is the target of
> such a 'protected referential member'.
>
> N.3 would be easy to implement with a property on the referential member.
> But what is the rationale for this requirement?  Perhaps that for cases
> where constructing and submitting a request on the target resource is
> expensive, a client might want to check whether the target is
> guaranteed to be at the URI before attempting the request.  But if
> the answer is "No," it might still be there.  Wouldn't it be better
> just to do a HEAD on the target?

For me, the rationale was simply that the client should have a mechanism for
determining the expected future behavior of the referential member.  If
there is no way for the client to determine what kind of referential member
it is dealing with, it may have to adopt potentially wasteful strategies
(for example, if the client doesn't know the referential integrity is being
maintained, it might, as a matter of policy, re-create the referential
member to maintain referential integrity even if such integrity were
automatically maintained.)

> N.4 is probably equally easy.  If the server is in a position to guarantee
> referential integrity, it must be in a position to maintain a property on
> the target resource.  It is at least maintaining a reference count, and
> perhaps a list of referential members that refer to the resource,
> depending
> upon how it is maintaining referential integrity.  It is easier to see a
> rationale for this requirement -- I can imagine an author or owner of a
> resource wanting to know how many / which places are referencing it.

Another way of looking at these two requirements is that they ensure that
both ends of a referential integrity relationship have the same information
available.

- Jim


From w3c-dist-auth-request@www10.w3.org  Fri May  8 19:18:51 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id TAA21421 for <w3c-dist-auth@www19.w3.org>; Fri, 8 May 1998 19:18:51 -0400 (EDT)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50]) by www10.w3.org (8.8.5/8.7.3) with SMTP id TAA17517 for <w3c-dist-auth@w3.org>; Fri, 8 May 1998 19:18:49 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa09039;
          8 May 98 16:12 PDT
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: w3c-dist-auth@w3.org
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
Date: Fri, 8 May 1998 16:17:36 -0700
Message-ID: <004201bd7ad7$7c8e4da0$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <3.0.3.32.19980424172849.00a54c40@pop-server.wrc.xerox.com>
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Subject: RE: Ordered Collections

Comments below.

> -----Original Message-----
> From: Judith Slein [mailto:slein@wrc.xerox.com]
> Sent: Friday, April 24, 1998 2:29 PM
> To: w3c-dist-auth@w3.org
> Subject: Ordered Collections
>
>
> Based on the minutes of the April 2 WebDAV meeting, it looks to me as if
> there is no consensus that ordered collections are needed.
> (Those who were present, correct me if this is the wrong interpretation.)

Hmm.  I wouldn't go this far -- my sense of the room was there is
substantial support for ordered collections.  Exactly what is meant by
"ordered" was the topic underlying most debate.

> Once these go away, requirement 3.2.3 becomes simply the requirement
> that a client be able to request that a response to a PROPFIND present
> the members order defined for that collection.

Agreed.

> So suppose we allow only a single ordering, and that it must contain each
> collection member exactly once.  Now it seems reasonable to say
> that we are getting nothing beyond what we could already get from
> a search with a sorting capability.  (I'm trying to reconstruct a
> train of thought from the minutes.  Correct me if I am wrong.)

Not exactly -- ordered collections can support arbitrary orderings (i.e.,
put "bar" first, "foo" second, "xxx" third, etc.) which is impossible to
accomplish with sorting.

> My view about this is that if we didn't have an ordering capability
> independent of search, we would in effect be implementing ordering as a
> property on each member of a collection.  I want to suggest that this is a
> bad implementation of ordering.  In particular, it violates requirement
> 3.2.9 that it be possible to modify an ordering efficiently.

This isn't the only possible ordering. As you point out in your last
paragraph, ordering information could be maintained in a property on the
collection.  Or, perhaps the repository for ordering state isn't even
available via a WebDAV abstraction (e.g., a database record), and is only
retrievable via a WebDAV property.

Short answer: I don't think this creates any efficiency concerns.

> Search with sort works well for ordering if the property that is the basis
> of the sort has a semantic life of its own independent of the ordering.
> That is, if we assign values to the property *not* based on solving the
> problem of getting the resource to sort to the right position,
> but based on
> some intrinsic feature of the resource.  So I assign a value to "Author"
> based on who created the resource, and it happens that I can sort
> alphabetically on author.  Or I can assign a value to "Difficulty-level"
> and then it's possible to sort from easy to difficult.

So this scenario sounds like a good use of DASL.

> But if I have 15 chapters of a book that I want to appear in a certain
> order, assigning a value to an "order" property is a bad way to
> get them to
> sort into that order.  I can't just assign 1 to the first
> chapter, 2 to the
> second, etc., unless I know that I will never want to insert a new chapter
> in the middle of the book.  I can leave gaps between the values to allow
> for some number of insertions, but those might get used up.  In short,
> maintenance of an ordering implemented in this way is extremely
> inefficient.

This sounds like a good use of DAV ordered collections.

> So my view is that a better implementation of ordering is the one many
> people have had in mind all along:  as a property on the collection that
> lists its members in the desired order.

Well, I tihnk this will need to be explored in the protocol document for
ordered collections, but it strikes me that this might be a good way to
quickly retrieve the ordering of a collection. On the other hand, if
PROPFIND of Depth 1 can also retrieve the ordering of a collection, perhaps
we don't want two ways of getting at the same information.

- Jim


From w3c-dist-auth-request@www10.w3.org  Mon May 11 17:52:04 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id RAA06095 for <w3c-dist-auth@www19.w3.org>; Mon, 11 May 1998 17:52:04 -0400 (EDT)
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by www10.w3.org (8.8.5/8.7.3) with SMTP id RAA04096 for <w3c-dist-auth@w3.org>; Mon, 11 May 1998 17:52:02 -0400 (EDT)
Received: from brandy ([13.0.33.227]) by alpha.xerox.com with SMTP id <53880(2)>; Mon, 11 May 1998 14:51:31 PDT
Received: from jslein2 (dhcp016) by brandy (5.x/XeroxClient-1.1)
	id AA16039; Mon, 11 May 1998 17:45:04 -0400
Message-Id: <3.0.3.32.19980511175009.00970cc0@pop-server.wrc.xerox.com>
X-Sender: slein@pop-server.wrc.xerox.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 11 May 1998 14:50:09 PDT
To: ejw@ics.uci.edu
>From: Judith Slein <slein@wrc.xerox.com>
Cc: w3c-dist-auth@w3.org
In-Reply-To: <004201bd7ad7$7c8e4da0$d115c380@galileo.ics.uci.edu>
References: <3.0.3.32.19980424172849.00a54c40@pop-server.wrc.xerox.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Ordered Collections

Thanks to those who have provided comments on the advanced collections
requirements.  I've revised the requirements based on those comments.
Here's how they look at the moment.  Unless I hear protests by close of
business Wednesday May 13, this is what I will submit to the Internet
Drafts directory this week.  I'm expecting that this draft will be the
basis for discussion in Seattle in June.

--Judy

-----------------------


     WEBDAV Working Group                                          J. Slein
     INTERNET DRAFT                                       Xerox Corporation
     <draft-ietf-webdav-collection-reqts-01>                   May 15, 1998
     Expires Novermber 15, 1998

          Requirements for Advanced Collection Functionality in WebDAV

     Status of this Memo

        This document is an Internet-Draft. Internet-Drafts are working
        documents of the Internet Engineering Task Force (IETF), its
        areas, and its working groups. Note that other groups may also
        distribute working documents as Internet-Drafts.

        Internet-Drafts are draft documents valid for a maximum of six
        months and may be updated, replaced, or made obsolete by other
        documents at any time. It is inappropriate to use Internet-Drafts
        as reference material or to cite them other than as "work in
        progress".

        To view the entire list of current Internet-Drafts, please check
        the "1id-abstracts.txt" listing contained in the Internet-Drafts
        Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
        (Northern Europe), ftp.nis.garr.it (Southern Europe),munnari.oz.au 
        (Pacific Rim), ftp.ietf.org (US EastCoast), or ftp.isi.edu (US West
        Coast).

        Distribution of this document is unlimited. Please send comments
        to the Distributed Authoring and Versioning (WebDAV) working group
        at <w3c-dist-auth@w3.org>, which may be joined by sending a
        message with subject "subscribe" to <w3c-dist-auth-
        request@w3.org>.

        Discussions of the WEBDAV working group are archived at URL:
        <http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth>.

     Abstract

        The base WebDAV protocol [Goland et al., 1998] provides basic
        support for collections.  It defines a MKCOL method for creating
        collections and specifies how other HTTP and WebDAV methods
        interact with collections.  It supports only internal members of
        collections, which it defines as members whose URIs are
        immediately relative to the URI of the collection.

        This draft sets out requirements for more advanced, optional
        collection functionality. It extends the base functionality in two
        general directions: support for referential members, and support
        for ordered collections.  A separate WebDAV specification is
        expected to define protocol elements providing the functionality
        described here.

     1  Terminology

        The terminology used here differs from that in the base WebDAV
        protocol specification [Goland et al., 1998], particularly in its
        definition of internal member resource.

        Collection
           A resource that contains member resources

        Member Resource
           A resource contained by a collection

        Referential Member Resource
           A member resource that has no content of its own, but rather is
           a reference to another resource

        Strong Reference
           A reference whose integrity is guaranteed by the server

        Weak Reference
           A reference whose integrity is not guaranteed by the server

        Internal Member Resource
           A member resource that either has content of its own or is
           empty, but is not a reference to another resource

        Target Resource
           The resource referenced by a referential member of a collection

     2  Introduction and Rationale

        The simple collections that the base WebDAV specification supports
        are powerful enough to be widely useful.  They provide for the
        hierarchical organization of resources, with mechanisms for
        creating and deleting collections, copying and moving them,
        locking them, adding resources to them and deleting resources from
        them, and getting listings of their members.  Delete, copy, move,
        list, and lock operations can be applied recursively, so that a
        client can operate on whole hierarchies with a single request.

        Many applications, however, need more powerful collections.  There
        are two areas in particular where more powerful functionality is
        often needed: referential members and ordering.  This draft
        details the additional functionality that is needed in these two
        areas.

     2.1  Referential Members

        Referential members make it possible for many collections, on the
        same or different servers, to share the same resource.  Because
        the collections share the resource by referencing it, only one
        physical copy of the resource need exist, and any changes made in
        the resource are visible from all the collections that reference
        it.

        So, for example, the mathematics department at one university can
        create a collection of resources on fractals that contains some
        local resources, but also references resources at several other
        universities.

        A manufacturing company develops and maintains its product
        maintenance manuals on the Web, with a separate collection for
        each product manual.  Each manual is divided into sections, one
        section for every product component.  Since many of the company’s
        products contain some of the same components, many of the product
        maintenance manuals have sections in common.  Each manual may have
        some unique sections, which are internal members of its
        collection.  But for product components that are common to
        multiple products, the manual has a referential member that
        references a resource in a shared library.

     2.2  Ordered Collections

        It is useful for many applications to be able to impose an
        ordering on a collection.  In the product manual application
        above, the sections of each manual may be ordered so that they can
        be printed together as a book.  A configuration management
        application might use a collection to represent a version series,
        in which case the "derives from" relationship might be represented
        as an ordering on the collection.

        A collection ordering may sometimes be based on property values.
        An example of such an ordering is one that is alphabetical by
        author’s last name, or one from most recent to oldest last-
        modified-date.  An ordering need not be based on property values,
        however.  A professor may order a collection of course readings in
        the sequence that makes sense to coordinate them with her lectures,
        where there is no property on the member resources that could be
        used to create this ordering.

        WebDAV already provides tools that could be used for creating and
        maintaining ordered collections.  For example, using only the base
        WebDAV specification, an application could create a WebDAV property
        called "Order" on a collection resource.  The value of this
        property might be a list of the URIs of the collection members.

        What the base WebDAV specification does not do is standardize a
        single way to represent orderings for collections.

        Different applications and services should be able to operate on
        the same collection without private agreements about how to manage
        and examine its order.  To make this possible, there needs to be a
        standard way to manipulate and retrieve the order of a collection,
        and a standard representation of the ordering.

        In any situation where collaborative management of a collection
        takes place, and different authoring tools or WebDAV servers might
        be used by the collaborators, standardization is important.  It is
        also important where a different tool may be used to view the
        collection from the one that was used to create it.

        So for example, two users from different organizations, using
        different authoring tools, are working together to create a
        collection.  One of the tools uses a property on the collection
        called "Order" to store an ordering of the collection.  The other
        tool uses a property on the member called "SequenceNumber".  If
        each user adds some members to the collection, there will be no
        reliable ordering.

     3  Requirements

     3.1  Referential Members of Collections

        Requirements 3.1.1 - 3.1.5 follow naturally from the definition of
        Referential Member Resource.  Although the behavior of referential
        members could be forced to be different from what is described in
        these requirements, the fact that referential members are
        references to other resources makes the behavior described here
        the natural one, and the easy one to implement.

     3.1.1  The same resource may be referenced by referential members of
            multiple collections.

        This is the primary benefit that referential members bring.
        Resources can be shared by multiple collections, which may reside
        on the same server as the shared resource or on other servers.

     3.1.2  The same resource may be referenced by more than one
            referential member of the same collection.

        It is often useful to allow the same resource to be referenced in
        a collection multiple times.  Typically, these are cases where the
        collection is ordered.  Consider a case where a collection
        represents a book, with one member resource for each page in the
        book.  A particular graphic needs to appear in several places in
        the book, and so needs to appear in the collection several times.

     3.1.3  It is possible for the same resource to be an internal member
            of a collection and also to be referenced by one or more
            referential members of that same collection.

        In the example just described, the collection might contain the
        graphic as an internal member, which is also referenced by
        referential members of the same collection so that it can appear
        multiple times in the book.

     3.1.4  Operations on a referential member do not affect the resource
            it references.

        There needs to be some way to operate on the referential member
        itself.  If requests to the referential member were automatically
        redirected to its target resource, this would not be possible.

        Passing operations through to the target resource would expose 
        servers to the risks of circular references and long chains of
        references that refer to other references.

        In addition, passing operations through to the target resource can
        be problematic if the referential member and the target resource
        are on different servers.  Issues about what credentials to use
        would need to be addressed.

        Requirement 3.1.6 makes it unnecessary for the server to pass
        operations through to the target resource.  The client can always
        obtain the URI of the target resource and operate directly on the
        target.

     3.1.5 Operations on a resource do not affect weak references to them.

        This requirement is the mirror of 3.1.4.  Just as we do not expect
        operations on a reference to affect its target, so we do not expect
        operations on a target to affect references to it.  Locking a 
        target does not cause the references to it to be locked.  Modifying
        the properties of a target does not cause changes in the properties
        of references to it.  Etc.

        Just as in 3.1.4 passing operations through to the target can be
        problematic, so here reflecting operations back to the referencing
        resource can be problematic if the referential member and the
        target resource are on different servers.  Issues about what
        credentials to use would need to be addressed.

        The requirement cannot apply to all referential members, however.
        Section 1 defined weak references and strong references.  Strong
        references are those whose referential integrity is guaranteed by
        the server.  Weak references are those whose referential integrity
        is not guaranteed by the server.  For strong references, some
        operations on targets must cause changes in references to them. For
        strong references, if the target is moved, the reference must
        change to reflect the new location of the target, for example.

        Requirement 3.1.11 makes it possible that some servers will support
        strong references.  Consequently, the requirement cannot apply to
        all referential members, but only to weak references.

     3.1.6  For any referential member of a collection, it is possible to
            obtain the URI of the resource it references.

        This will allow clients to resolve references themselves in order
        to operate on the target resources.

     3.1.7  It is possible to add a referential member to a collection.

     3.1.8  It is possible to remove a referential member from a
            collection.

        It is important to note that this is a different operation from
        deleting the referential member’s target resource.  According to
        requirement 3.1.4, operations on a referential member do not
        affect the target resource, so removing a referential member from
        a collection does not cause its target resource to be deleted.

     3.1.9  It is possible for a referential member of a collection to
            carry its own properties, distinct from those of the resource
            it refers to.

        There are properties like "who added this resource to this
        collection" and "when was this resource added to this collection"
        that clearly belong to the referential member, and not to its
        target resource, which may be referenced by referential members of
        many collections.

     3.1.10 A listing of the members of a collection shows both the
            internal members and the referential members.

        A listing of collection members with Depth = 1 shows all members of
        the collection, whether internal or external.  If Depth = infinity,
        however, the listing will not follow references into any
        collections to which they may refer.  This is to avoid the risk of
        being caught in a circle of references.

     3.1.11 It is possible to request creation of a referential member that
            the server will guarantee to have referential integrity.

        For some applications, broken references are unacceptable.  
        Breakage may be unavoidable when a target resource resides on a 
        different server from the referential member that references it.
        Servers can, however, maintain the integrity of referential 
        collection members when they receive MOVE or DELETE requests for 
        resources under their own control.  For applications that require
        referential integrity, it must be possible to specify with a
        request for creation of a referential member that its integrity
        be guaranteed.  If the server cannot honor this request, it must
        decline to create the referential member.  A referential member
        whose integrity is guaranteed by the server is called a strong
        reference.

     3.1.12 For any member of a collection, it is possible to discover
            whether it is an internal or a referential member.

        Since operations on referential members are not passed
        through to their targets, it is important for clients to be able
        to discover which members are referential.  Then the client can
        resolve the references for the referential members to perform
        operations on their targets.

     3.1.13 It is possible to discover whether a referential member is a 
            strong reference or a weak reference.

        Knowing whether a referential member is strong or weak allows a
        client to choose intelligently its own strategy for working with
        referential members.  For example, if a client does not know
        whether a particular reference is strong or weak, it may choose to
        recreate that referential member to be sure of referential
        integrity; but if it knows that the reference is strong, it will
        not bother to do this.

     3.1.14 It is possible to discover whether a resource is the target of
            a strong reference.

        This requirement insures that both ends of a referential integrity
        relationship have the same information available.

     3.2  Ordered Collections

     3.2.1  Ordering is sufficiently standardized that different 
            applications and servers can operate on the same ordering 
            without private agreements.

        Applications and servers can apply an ordering to a collection’s 
        members or discover the ordering of a collection's members without
        private agreements.  They can also modify an ordering, at least
        with the help of a human user for semantics (See 3.2.2), without
        private agreements.

        This is the minimum that is needed to support collaborative
        management of an ordered collection, where different authoring
        tools might be used by the collaborators.  It is also what allows
        a different tool to be used to view the collection from the one
        that was used to create it.  Finally, it is needed in order for
        servers to list collection members in order, as required by 3.2.3.

     3.2.2  The semantics of an ordering are discoverable.

        The semantics of an ordering is the principle or rule according to
        which the collection members are ordered.  This principle must be
        discoverable if someone (or some application) other than the one
        that created a collection is to be able to add a member to it and
        determine where it makes sense to position the new member in the
        collection's ordering.

        In some cases it may be possible for the semantics to be expressed
        in a machine-usable way, so that an application could automatically
        position a new member in the ordering.  In other cases the 
        semantics may require a human user to apply them.  In either case
        they should be discoverable.

     3.2.3  When a client requests a listing of the members of a
            collection, it can request that the collection ordering be
            applied to the response.  The server may decline to support
            the request for an ordered response.

        Although servers may ignore the request that the member listing be
        ordered, defining a request syntax that includes an ordering makes
        it possible for servers to free clients from the burden of
        applying the ordering to the member listing.

     3.2.4  It is possible to order the members of a collection in a
            client-specified way, not necessarily based on property values.

        Orderings that are based on property values can be obtained by a
        search protocol that supports sorted result sets.  This set of
        requirements is not concerned with such orderings.  It is intended
        primarily to support orderings that cannot be obtained by sorting
        on property values.

        A property is not always available that can serve as the basis for
        a desired ordering.  For example, a professor may wish to order a 
        collection of course readings in the sequence that makes sense to 
        coordinate the readings with her lectures.  But the properties of
        resources at the Web site are standardized and do not include one
        that is appropriate to use for this purpose.

        Even if the professor in the example could create a 
        "sequencenumber" property to use in sorting the collection, this
        strategy would be undesirable unless she knew she would not be
        adding any readings or changing the order of her lectures once the
        values of sequencenumber were set.  Inserting a new reading into
        the sequence would require updating the sequencenumber property of
        each reading that comes after the new one in the sequence.  Ordered
        collections are intended to support this sort of case, where
        sorting based on a property value is impossible or inefficient.

     3.2.5  Internal and referential members may be intermixed in the same
            ordering.

        The professor in the previous example may store some readings as
        internal resources of the collection, but reference others from
        servers at another university.  Nevertheless, all the readings
        need to be included in the ordering for her students’ use.

     3.2.6  It is possible to modify an existing ordering efficiently.

        The implementation of orderings and operations on them should
        minimize the number of round trips and the amount of data
        transferred when modifying an existing ordering.  This includes
        cases where a single collection member is inserted into an
        ordering or removed from an ordering, as well as cases where many
        collection members are moved to different positions in the
        ordering.

     4  Acknowledgements

        This draft has benefited from thoughtful discussion by Steve 
        Carter, Ellis Cohen, Jim Davis, Spencer Dawkins, Yaron Goland, 
        Alex Hopmann, Rohit Khare, Daniel LaLiberte, Steve Martin, 
        Surendra Koduru Reddy, Nick Shelness, John Turner, Jim Whitehead,
        and others. 


     5  References

        [Goland et al., 1998] Y. Y. Goland, E. J. Whitehead, Jr., A.
        Faizi, S. R. Carter, D. Jensen, "Extensions for Distributed
        Authoring on the World Wide Web - WebDAV." Draft-ietf-webdav-
        protocol-08. Microsoft, U.C. Irvine, Netscape, Novell. April,
        1998.

     6  Authors' Addresses

        J. Slein
        Xerox Corporation
        800 Phillips Road
        Webster, NY 14580
        Email: slein@wrc.xerox.com

     Expires November 15, 1998

Name:			Judith A. Slein
E-Mail:		slein@wrc.xerox.com
Internal Phone:  	8*222-5169
Fax:			(716) 422-2938
MailStop:		105-50C
Web Site:    http://www.nde.wrc.xerox.com/users/Slein/slein.htm


From w3c-dist-auth-request@www10.w3.org  Tue May 12 19:58:53 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id TAA01997 for <w3c-dist-auth@www19.w3.org>; Tue, 12 May 1998 19:58:52 -0400 (EDT)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50]) by www10.w3.org (8.8.5/8.7.3) with SMTP id TAA14954 for <w3c-dist-auth@w3.org>; Tue, 12 May 1998 19:58:50 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa03498;
          12 May 98 16:53 PDT
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: Judith Slein <slein@wrc.xerox.com>, w3c-dist-auth@w3.org
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
Date: Tue, 12 May 1998 16:58:04 -0700
Message-ID: <000101bd7e01$cd4bb5c0$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <3.0.3.32.19980511175009.00970cc0@pop-server.wrc.xerox.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Subject: RE: Ordered Collections

Super job Judy!  I have a few, mostly nitpicky comments below.

1) I have is the perception that there are really two different kinds of
ordered collections.  The first are "live" collections where the ordering is
maintained by the server, and any attempt by the client to place a resource
at a specific location in a collection will (unless the client is lucky and
places the resource where the server would put it anyway) not work.  The
second are "static" collections where the client maintains the ordering, and
places resources in exact locations.  With "live" collections, the server
maintains the semantics of the ordering, whereas with "static" collections,
the client maintains the ordering. I think the ordered collections protocol
draft needs to support both kinds.

I think it would be useful to add some discussion of this distinction to
Section 2.2 (which touches on it in the second paragraph), since these
categories and labels will be useful in our discussion.


2) Requirement 3.2.3 should be strengthened so a server always has to return
the members of a collection in order.  I'm thinking of wording something
along the lines of:

When a client requests a listing of the members of a collection, this
listing is returned in the order specified by the collection.

3) I think requirement 3.2.6 (it is possible to modify an existing ordering
efficiently) should be removed.  As stated it would be hard to determine
whether a given protocol did or did not meet the requirement.  I think there
is agreement in the working group that the ordering protocol needs to be
efficient, but adding a requirement for this doesn't really contribute much
towards achieving this goal.

Minor points follow:

>
>         Strong Reference
>            A reference whose integrity is guaranteed by the server
>
>         Weak Reference
>            A reference whose integrity is not guaranteed by the server
>


I'd add "referential" before integrity in both these definitions.


>      2.1  Referential Members
>
>         Referential members make it possible for many collections, on the
>         same or different servers, to share the same resource.  Because
>         the collections share the resource by referencing it, only one
>         physical copy of the resource need exist, and any changes made in
>         the resource are visible from all the collections that reference
>         it.


Instead of "physical copy", I prefer the term "authoritative location" since
it is technically possible to have the same physical data chunk accessible
at multiple locations (e.g., a file which can be accessed via FTP and HTTP),
so by referring to one of these location with a referential member, the
referential member doesn't really point to the physical data chunk, it
points to one location at which that physical data chunk can be accessed.

>      2.2  Ordered Collections
>
>         It is useful for many applications to be able to impose an
>         ordering on a collection.

I prefer the wording:

For many applications, it is useful to impose an ordering on a collection.


>         So for example, two users from different organizations, using
>         different authoring tools, are working together to create a
>         collection.  One of the tools uses a property on the collection
>         called "Order" to store an ordering of the collection.  The other
>         tool uses a property on the member called "SequenceNumber".  If
>         each user adds some members to the collection, there will be no
>         reliable ordering.

At the end of the last sentence, add "across tools."

>      3.1  Referential Members of Collections
>
>         Requirements 3.1.1 - 3.1.5 follow naturally from the definition of
>         Referential Member Resource.  Although the behavior of referential
>         members could be forced to be different from what is described in
>         these requirements, the fact that referential members are
>         references to other resources makes the behavior described here
>         the natural one, and the easy one to implement.

Rather than debating exactly what we mean by "natural", I think that the
word "naturally" should be removed from the first sentence, and the second
sentence should be removed.


>      3.1.10 A listing of the members of a collection shows both the
>             internal members and the referential members.
>
>         A listing of collection members with Depth = 1 shows all members
of
>         the collection, whether internal or external.  If Depth =
infinity,
>         however, the listing will not follow references into any
>         collections to which they may refer.  This is to avoid the risk of
>         being caught in a circle of references.

Since a listing of collection members with depth infinity will also list the
internal and external members of a collection, I recommend changing the
first sentence to read:

A listing of collection members with Depth = 1 or Depth = infinity shows all
members of the collection, whether internal or external.

>      3.1.11 It is possible to request creation of a referential
> member that
>             the server will guarantee to have referential integrity.
>
>         For some applications, broken references are unacceptable.
>         Breakage may be unavoidable when a target resource resides on a
>         different server from the referential member that references it.
>         Servers can, however, maintain the integrity of referential
>         collection members when they receive MOVE or DELETE requests for
>         resources under their own control.  For applications that require
>         referential integrity, it must be possible to specify with a

"with" --> "in"

>      3.1.13 It is possible to discover whether a referential member is a
>             strong reference or a weak reference.
>
>         Knowing whether a referential member is strong or weak allows a
>         client to choose intelligently its own strategy for working with

The Enterprise may boldly go, but in this case, I think the client should
"intelligently choose".

That's it.  I think we should be able to wrap these up soon after the
Redmond meeting.

- Jim


From w3c-dist-auth-request@www10.w3.org  Thu May 14 11:46:05 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id LAA02553 for <w3c-dist-auth@www19.w3.org>; Thu, 14 May 1998 11:46:04 -0400 (EDT)
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by www10.w3.org (8.8.5/8.7.3) with SMTP id LAA05455 for <w3c-dist-auth@w3.org>; Thu, 14 May 1998 11:46:02 -0400 (EDT)
Received: from brandy ([13.0.33.227]) by alpha.xerox.com with SMTP id <60918(2)>; Thu, 14 May 1998 08:44:50 PDT
Received: from jslein2 (dhcp016) by brandy (5.x/XeroxClient-1.1)
	id AA17806; Thu, 14 May 1998 11:43:27 -0400
Message-Id: <3.0.3.32.19980514114833.0095e430@pop-server.wrc.xerox.com>
X-Sender: slein@pop-server.wrc.xerox.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Thu, 14 May 1998 08:48:33 PDT
To: ejw@ics.uci.edu
>From: Judith Slein <slein@wrc.xerox.com>
Cc: Judith Slein <slein@wrc.xerox.com>, w3c-dist-auth@w3.org
In-Reply-To: <000101bd7e01$cd4bb5c0$d115c380@galileo.ics.uci.edu>
References: <3.0.3.32.19980511175009.00970cc0@pop-server.wrc.xerox.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Ordered Collections

Thanks for your comments, Jim. I've made most of your suggested changes,
but I'm hesitating about a few of them.

At 04:58 PM 5/12/98 PDT, Jim Whitehead wrote:
>1) I have is the perception that there are really two different kinds of
>ordered collections.  The first are "live" collections where the ordering is
>maintained by the server, and any attempt by the client to place a resource
>at a specific location in a collection will (unless the client is lucky and
>places the resource where the server would put it anyway) not work.  The
>second are "static" collections where the client maintains the ordering, and
>places resources in exact locations.  With "live" collections, the server
>maintains the semantics of the ordering, whereas with "static" collections,
>the client maintains the ordering. I think the ordered collections protocol
>draft needs to support both kinds.
>
>I think it would be useful to add some discussion of this distinction to
>Section 2.2 (which touches on it in the second paragraph), since these
>categories and labels will be useful in our discussion.

I think that we have gradually been paring back the ordered collections
requirements to arrive at a point where the server is not required to
maintain orderings in any way -- so that orderings are always "dead,"
client-maintained.  Jim Davis has expressed his opposition to
server-maintained orderings.  In the more distant past, Yaron did, too,
although he may not care so much now that ordered collections are in a
separate specification.  So I'm a little reluctant to add back in a
requirement for "live" orderings.

That said, here's a related problem.  Based on the LA meeting, I took out
the requirements for orderings that contain only a subset of collections
members and for orderings that contain a collection member more than once.
The implication is that each collection member must be in an ordering
exactly once -- I should have added a requirement to this effect to make it
explicit.  But once we say this, the server is required to do some work to
maintain the integrity of the ordering -- it must prevent clients from
adding members to orderings more than once and it must make sure that when
a member gets added to a collection, it gets added to the ordering
somewhere.  This is, by the WebDAV definition, "live," whether or not the
ordering is server-maintained (read-only).

>
>
>2) Requirement 3.2.3 should be strengthened so a server always has to return
>the members of a collection in order.  I'm thinking of wording something
>along the lines of:
>
>When a client requests a listing of the members of a collection, this
>listing is returned in the order specified by the collection.

Again, Jim Davis and Yaron have both opposed requiring a server to apply
the ordering to any list of collection members it returns.  Jim's view is
that it is just as easy for the client to retrieve the ordering and apply
it.  So that's how 3.2.3 got weakened to its current state.  Are there
others who think it should be strengthened again?

>
>Minor points follow:
>
>>      2.1  Referential Members
>>
>>         Referential members make it possible for many collections, on the
>>         same or different servers, to share the same resource.  Because
>>         the collections share the resource by referencing it, only one
>>         physical copy of the resource need exist, and any changes made in
>>         the resource are visible from all the collections that reference
>>         it.
>
>
>Instead of "physical copy", I prefer the term "authoritative location" since
>it is technically possible to have the same physical data chunk accessible
>at multiple locations (e.g., a file which can be accessed via FTP and HTTP),
>so by referring to one of these location with a referential member, the
>referential member doesn't really point to the physical data chunk, it
>points to one location at which that physical data chunk can be accessed.
>
I've stayed with "physical copy" because I think it's clearer and it's
really the point.  Whether the referential member points to its target at
the FTP location or the HTTP location, the important thing is that we
didn't have to make a physical copy of the resource inside the collection
in order to get access to it through the collection.

>
>>         So for example, two users from different organizations, using
>>         different authoring tools, are working together to create a
>>         collection.  One of the tools uses a property on the collection
>>         called "Order" to store an ordering of the collection.  The other
>>         tool uses a property on the member called "SequenceNumber".  If
>>         each user adds some members to the collection, there will be no
>>         reliable ordering.
>
>At the end of the last sentence, add "across tools."
>

I kept this as it was because it's really true that there will be no
reliable ordering. Period.  It's not that one tool could get you access to
a reliable ordering, but the other could not.  Once you have modified an
ordering using each of the tools, neither ordering is reliable any more.


Name:			Judith A. Slein
E-Mail:		slein@wrc.xerox.com
Internal Phone:  	8*222-5169
Fax:			(716) 422-2938
MailStop:		105-50C
Web Site:    http://www.nde.wrc.xerox.com/users/Slein/slein.htm


From w3c-dist-auth-request@www10.w3.org  Fri May 15 13:54:07 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id NAA02229 for <w3c-dist-auth@www19.w3.org>; Fri, 15 May 1998 13:54:06 -0400 (EDT)
Received: from binky.ics.uci.edu (binky.ics.uci.edu [128.195.1.14]) by www10.w3.org (8.8.5/8.7.3) with SMTP id NAA15548 for <w3c-dist-auth@w3.org>; Fri, 15 May 1998 13:54:05 -0400 (EDT)
Received: from paris.ics.uci.edu by binky.ics.uci.edu id af00490;
          15 May 98 10:52 PDT
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa10386;
          15 May 98 10:50 PDT
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Fri, 15 May 1998 10:54:51 -0700
Message-ID: <003a01bd802a$8f38fba0$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Subject: WebDAV tutorial at Hypertext'98

WEBDAV TUTORIAL

A tutorial on the WebDAV Distributed Authoring Protocol will be offered at
the Hypertext'98 Conference. Jim Whitehead, U.C. Irvine, and Josh Cohen,
Microsoft, will be the presenters for this half day tutorial.  Tutorials
will be held Sunday, June 21, at the Marriott City Center, Pittsburgh, PA.

Note that this is *not* an official meeting of the WebDAV WG, and no
official business will be conducted.  The tutorial offers an opportunity for
people to learn about the WebDAV Distributed Authoring Protocol, and I
imagine people who are newcomers to WebDAV, or who are considering
implementations of WebDAV would find this tutorial to be of interest.

Since the tutorial is being held in conjunction with Hypertext'98, there is
a charge of USD$150 associated with the tutorial.  This fee is about an
order of magnitude smaller than equivalent commercial offerings.

The Hypertext'98 Conference is the premier academic conference for research
in hypermedia, and this is the ninth conference in the series, which started
in 1987.

For a detailed description of the tutorial:

http://www.stg.brown.edu/~stg/HT98tutorials/T10.html

For a description of all tutorials:

http://www.stg.brown.edu/~stg/HT98tutorials/
(Note that at present, this lists the WebDAV tutorial as tentative -- this
is incorrect, and should be fixed shortly.)

For information on how to register for the tutorial:

http://www.ks.com/HT98/97.html

For information on the Hypertext'98 conference:

http://www.ks.com/HT98/

For information on fees:

http://www.ks.com/HT98/83.html

Note that if you're interested in attending the Hypertext'98 conference, the
early registration deadline ends May 20.

- Jim


From w3c-dist-auth-request@www10.w3.org  Fri May 15 14:02:13 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id OAA02553 for <w3c-dist-auth@www19.w3.org>; Fri, 15 May 1998 14:02:13 -0400 (EDT)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50]) by www10.w3.org (8.8.5/8.7.3) with SMTP id OAA15633 for <w3c-dist-auth@w3.org>; Fri, 15 May 1998 14:02:11 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa11421;
          15 May 98 10:58 PDT
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: Judith Slein <slein@wrc.xerox.com>, WEBDAV WG <w3c-dist-auth@w3.org>
Date: Fri, 15 May 1998 11:02:45 -0700
Message-ID: <003b01bd802b$a9ea5e20$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <3.0.3.32.19980514114833.0095e430@pop-server.wrc.xerox.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Subject: RE: Ordered Collections


> Thanks for your comments, Jim. I've made most of your suggested changes,
> but I'm hesitating about a few of them.
>
> At 04:58 PM 5/12/98 PDT, Jim Whitehead wrote:
> >1) I have is the perception that there are really two different kinds of
> >ordered collections.  The first are "live" collections where the
> >ordering is maintained by the server, and any attempt by the client to
place
> >a resource at a specific location in a collection will (unless the client
> >is lucky and places the resource where the server would put it anyway)
> >not work. The second are "static" collections where the client maintains
the
> >ordering, and places resources in exact locations.  With "live"
collections,
> >the server maintains the semantics of the ordering, whereas with "static"
> >collections, the client maintains the ordering. I think the ordered
> >collections protocol draft needs to support both kinds.
> >
> >I think it would be useful to add some discussion of this distinction to
> >Section 2.2 (which touches on it in the second paragraph), since these
> >categories and labels will be useful in our discussion.
>
> I think that we have gradually been paring back the ordered collections
> requirements to arrive at a point where the server is not required to
> maintain orderings in any way -- so that orderings are always "dead,"
> client-maintained.  Jim Davis has expressed his opposition to
> server-maintained orderings.  In the more distant past, Yaron did, too,
> although he may not care so much now that ordered collections are in a
> separate specification.  So I'm a little reluctant to add back in a
> requirement for "live" orderings.

Ahh.  In this case, then, a note stating that the intent is to only support
non-live ordering should be added.

> That said, here's a related problem.  Based on the LA meeting, I took out
> the requirements for orderings that contain only a subset of collections
> members and for orderings that contain a collection member more than once.
> The implication is that each collection member must be in an ordering
> exactly once -- I should have added a requirement to this effect
> to make it
> explicit.  But once we say this, the server is required to do some work to
> maintain the integrity of the ordering -- it must prevent clients from
> adding members to orderings more than once and it must make sure that when
> a member gets added to a collection, it gets added to the ordering
> somewhere.  This is, by the WebDAV definition, "live," whether or not the
> ordering is server-maintained (read-only).

Well, this is certainly live in the sense that the server is performing some
consistency checks before allowing a resource to be added to a collection,
but it isn't live in the sense the server will be doing the actual ordering.
So, I don't see a problem with the language in this case -- for any
operation, the server is always allowed to perform some checks.

However, this does raise a problem with repsect to referential members of
collections, since we allow in 3.1.2 the same resource to be referenced
multiple times int he same collection.  However, since we haven't said
anything about having a local name for references, this implies to me that
the same URI can appear in a collection mutiple times (once as an internal
member, and then potentially multiple times as an reference).  An ordered
collection then has to handle this situation.

> >2) Requirement 3.2.3 should be strengthened so a server always
> has to return
> >the members of a collection in order.  I'm thinking of wording something
> >along the lines of:
> >
> >When a client requests a listing of the members of a collection, this
> >listing is returned in the order specified by the collection.
>
> Again, Jim Davis and Yaron have both opposed requiring a server to apply
> the ordering to any list of collection members it returns.  Jim's view is
> that it is just as easy for the client to retrieve the ordering and apply
> it.  So that's how 3.2.3 got weakened to its current state.  Are there
> others who think it should be strengthened again?

Except that I think they were thinking the server would be performing some
action like alphabetizing the listing before sending it out.  If the
ordering is static (non-live), then returning the members of the collection
in order seems reasonable to me.

> >Minor points follow:
> >
> >>      2.1  Referential Members
> >>
> >>         Referential members make it possible for many
> collections, on the
> >>         same or different servers, to share the same resource.  Because
> >>         the collections share the resource by referencing it, only one
> >>         physical copy of the resource need exist, and any
> changes made in
> >>         the resource are visible from all the collections that
> reference
> >>         it.
> >
> >
> >Instead of "physical copy", I prefer the term "authoritative
> location" since
> >it is technically possible to have the same physical data chunk
> accessible
> >at multiple locations (e.g., a file which can be accessed via
> FTP and HTTP),
> >so by referring to one of these location with a referential member, the
> >referential member doesn't really point to the physical data chunk, it
> >points to one location at which that physical data chunk can be accessed.
> >
> I've stayed with "physical copy" because I think it's clearer and it's
> really the point.  Whether the referential member points to its target at
> the FTP location or the HTTP location, the important thing is that we
> didn't have to make a physical copy of the resource inside the collection
> in order to get access to it through the collection.

OK.

> >>         So for example, two users from different organizations, using
> >>         different authoring tools, are working together to create a
> >>         collection.  One of the tools uses a property on the collection
> >>         called "Order" to store an ordering of the collection.
>  The other
> >>         tool uses a property on the member called "SequenceNumber".  If
> >>         each user adds some members to the collection, there will be no
> >>         reliable ordering.
> >
> >At the end of the last sentence, add "across tools."
> >
>
> I kept this as it was because it's really true that there will be no
> reliable ordering. Period.  It's not that one tool could get you access to
> a reliable ordering, but the other could not.  Once you have modified an
> ordering using each of the tools, neither ordering is reliable any more.

OK.

- Jim


From w3c-dist-auth-request@www10.w3.org  Fri May 15 17:06:51 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id RAA07513 for <w3c-dist-auth@www19.w3.org>; Fri, 15 May 1998 17:06:51 -0400 (EDT)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50]) by www10.w3.org (8.8.5/8.7.3) with SMTP id RAA17374 for <w3c-dist-auth@w3.org>; Fri, 15 May 1998 17:06:49 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa29565;
          15 May 98 13:55 PDT
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Fri, 15 May 1998 14:00:11 -0700
Message-ID: <005501bd8044$72ece0a0$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <003a01bd802a$8f38fba0$d115c380@galileo.ics.uci.edu>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Subject: Link correction: WebDAV tutorial at Hypertext'98

Yikes! I appear to have transcribed the first two links incorrectly in my
post about the tutorials (I put ~stg instead of ~sjd).  The corrected links
are (thanks go to Howard Modell for pointing this out):

For a detailed description of the tutorial:

http://www.stg.brown.edu/~sjd/HT98tutorials/T10.html

For a description of all tutorials:

http://www.stg.brown.edu/~sjd/HT98tutorials/

(Note that at present, this lists the WebDAV tutorial as tentative -- this
is incorrect, and should be fixed shortly.)

For information on how to register for the tutorial:

http://www.ks.com/HT98/97.html

For information on the Hypertext'98 conference:

http://www.ks.com/HT98/

For information on fees:

http://www.ks.com/HT98/83.html

- Jim


From w3c-dist-auth-request@www10.w3.org  Fri May 15 17:06:53 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id RAA07525 for <w3c-dist-auth@www19.w3.org>; Fri, 15 May 1998 17:06:52 -0400 (EDT)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50]) by www10.w3.org (8.8.5/8.7.3) with SMTP id RAA17376 for <w3c-dist-auth@w3.org>; Fri, 15 May 1998 17:06:51 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa00380;
          15 May 98 14:03 PDT
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Fri, 15 May 1998 14:08:24 -0700
Message-ID: <005701bd8045$9957aa80$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Subject: Working Group Status

This document reflects the current status of the WebDAV working group.

UPCOMING MEETINGS

* Interim WebDAV working group meeting
  June 15-17, 1998
  Microsoft Campus, Redmond, WA
  http://www.ics.uci.edu/pub/ietf/webdav/redmond/
  Registration deadline: June 10, 1998
  Topics of discussion: Versioning, Advanced Collections, Access Control
  DASL WG will be meeting for a half day on the 17th.

* Chicago IETF (42nd IETF) - WebDAV WG session
  August 23-28, 1998
  Registration opens 2 months ahead of the meeting.
  http://www.ietf.org/meetings/Chicago.html


DOCUMENTS

The latest revisions of all documents can be retrieved from the WebDAV home
page at:

http://www.ics.uci.edu/pub/ietf/webdav/

* Distributed Authoring Protocol
  "Extensions for Distributed Authoring on the World Wide Web"
  <draft-ietf-webdav-protocol-08>
  Editor: Del Jensen

  This document has ended its IETF-wide last call for comments, and is
  currently in queue for consideration by the IESG.

  There was only one comment received on this document during IETF last
  call, and this comment noted that the WebDAV protocol specification
  makes use of the text/xml media type, yet this media type has not
  been registered with IANA.  I have been working with Murata Makoto of
  the W3C XML SIG to develop a draft to register the text/xml and
  application/xml media types, <draft-whitehead-mime-xml-03>. This draft
  is now complete, and will be submitted to the IESG for approval as an
  Informational RFC next week.  Since this draft will be in the approval
  pipeline, I do not expect the lack of registration for text/xml to
  hold up approval of the Distributed Authoring Protocol.

* Requirements for Ordered Collections and References
  "Requirements for Advanced Collection Functionality in WebDAV"
  <draft-ietf-webdav-collection-reqts-00>
  Editor: Judith Slein

  Judy is current revising this document based on the discussion at the
  Los Angeles IETF meeting, and discussion on the list, and a new revision
  is expected shortly.

  Once a new revision has been completed, I'd appreciate feedback on the
  ordered collections requirements from members of the list (I think the
  requirements for references are stable, and complete).  This section
  of functionality yielded the most discussion at the Los Angeles IETF,
  and I'd like to see if there is consensus on these new ordered collections
  requirements.

* Access Control Requirements
  "Requirements for Access Control within Distributed Authoring and
  Versioning Environments on the World Wide Web"
  <draft-ietf-webdav-acreq-00>
  Editor: Howard Palmer

  This document is currently in process of revision based on the discussion
  at the Washington IETF meeting.

  While this revision process is underway, I'd appreciate feedback from list
  participants on these requirements.

* Access Control Protocol
  "WebDAV ACL Protocol"
  <draft-ietf-webdav-acl-00>
  Editors: Lisa Dusseault, Yaron Goland, Paul Leach

  This document is currently in process of revision based on discussion at
  the Washington IETF meeting.  Feedback on this draft to the list would
  help revise this document.

* Scenarios Document
  "HTTP-based Distributed COntent Editing Scenarios"
  <draft-ietf-webdav-scenarios-00>
  Editor: Walter Houser

  This document needs to be reviewed to ensure there are scenarios which
  describe each of the requirements in RFC 2291, and addition of scenarios
  for access control, ordered collections, and references would be very
nice.
  Walter Houser volunteered to edit this document at the Washington, IETF.

- Jim Whitehead



From w3c-dist-auth-request@www10.w3.org  Sun May 17 14:46:32 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id OAA00966 for <w3c-dist-auth@www19.w3.org>; Sun, 17 May 1998 14:46:32 -0400 (EDT)
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by www10.w3.org (8.8.5/8.7.3) with SMTP id OAA25555 for <w3c-dist-auth@w3.org>; Sun, 17 May 1998 14:46:26 -0400 (EDT)
Received: from brandy ([13.0.33.227]) by alpha.xerox.com with SMTP id <52037(1)>; Sun, 17 May 1998 11:46:19 PDT
Received: from jslein2 (dhcp016) by brandy (5.x/XeroxClient-1.1)
	id AA12701; Sun, 17 May 1998 14:46:50 -0400
Message-Id: <3.0.3.32.19980517145157.00905bc0@pop-server.wrc.xerox.com>
X-Sender: slein@pop-server.wrc.xerox.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Sun, 17 May 1998 11:51:57 PDT
To: ejw@ics.uci.edu
>From: Judith Slein <slein@wrc.xerox.com>
Cc: Judith Slein <slein@wrc.xerox.com>, WEBDAV WG <w3c-dist-auth@w3.org>
In-Reply-To: <003b01bd802b$a9ea5e20$d115c380@galileo.ics.uci.edu>
References: <3.0.3.32.19980514114833.0095e430@pop-server.wrc.xerox.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Ordered Collections

I've submitted a new draft of the collection requirements to
Internet-Drafts, so they should be available in a few days.

I made the following changes, mostly in response to Jim Whitehead's recent
comments:

1.  I added a paragraph discussing server-maintained vs. client-maintained
orderings, and stated explicitly that the requirements are only for
client-maintained orderings.

2.  I added a requirement (3.2.2) stating that collections are not required
to be ordered.

3.  I added a requirement (3.2.4) stating that each collection member must
appear in the ordering exactly once.  I added some text explaining the
implications of this for server behavior.

4.  I added a requirement (3.2.5) stating that orderings must not contain
resources that are not members of the collection, and again discussed the
implications of this for server behavior.

5.  I strengthened 3.2.6 to say that a server must return listings of
collection members in the order specified by the collection ordering.

6.  I added a requirement (3.1.15) stating that a referential member of a
collection is itself a resource.  I think this was already implied by the
requirement that referential members be able to carry their own properties,
but it needed to be made explicit.  As Jim noted, this has implications for
3.2.4.


At 11:02 AM 5/15/98 PDT, Jim Whitehead wrote:
>
>> At 04:58 PM 5/12/98 PDT, Jim Whitehead wrote:
>> >1) I have is the perception that there are really two different kinds of
>> >ordered collections.  The first are "live" collections where the
>> >ordering is maintained by the server, and any attempt by the client to
>place
>> >a resource at a specific location in a collection will (unless the client
>> >is lucky and places the resource where the server would put it anyway)
>> >not work. The second are "static" collections where the client maintains
>the
>> >ordering, and places resources in exact locations.  With "live"
>collections,
>> >the server maintains the semantics of the ordering, whereas with "static"
>> >collections, the client maintains the ordering. I think the ordered
>> >collections protocol draft needs to support both kinds.
>> >
>> >I think it would be useful to add some discussion of this distinction to
>> >Section 2.2 (which touches on it in the second paragraph), since these
>> >categories and labels will be useful in our discussion.
>>
>> I think that we have gradually been paring back the ordered collections
>> requirements to arrive at a point where the server is not required to
>> maintain orderings in any way -- so that orderings are always "dead,"
>> client-maintained.  Jim Davis has expressed his opposition to
>> server-maintained orderings.  In the more distant past, Yaron did, too,
>> although he may not care so much now that ordered collections are in a
>> separate specification.  So I'm a little reluctant to add back in a
>> requirement for "live" orderings.
>
>Ahh.  In this case, then, a note stating that the intent is to only support
>non-live ordering should be added.
>
>> That said, here's a related problem.  Based on the LA meeting, I took out
>> the requirements for orderings that contain only a subset of collections
>> members and for orderings that contain a collection member more than once.
>> The implication is that each collection member must be in an ordering
>> exactly once -- I should have added a requirement to this effect
>> to make it
>> explicit.  But once we say this, the server is required to do some work to
>> maintain the integrity of the ordering -- it must prevent clients from
>> adding members to orderings more than once and it must make sure that when
>> a member gets added to a collection, it gets added to the ordering
>> somewhere.  This is, by the WebDAV definition, "live," whether or not the
>> ordering is server-maintained (read-only).
>
>Well, this is certainly live in the sense that the server is performing some
>consistency checks before allowing a resource to be added to a collection,
>but it isn't live in the sense the server will be doing the actual ordering.
>So, I don't see a problem with the language in this case -- for any
>operation, the server is always allowed to perform some checks.
>
>However, this does raise a problem with repsect to referential members of
>collections, since we allow in 3.1.2 the same resource to be referenced
>multiple times int he same collection.  However, since we haven't said
>anything about having a local name for references, this implies to me that
>the same URI can appear in a collection mutiple times (once as an internal
>member, and then potentially multiple times as an reference).  An ordered
>collection then has to handle this situation.
>
>> >2) Requirement 3.2.3 should be strengthened so a server always
>> has to return
>> >the members of a collection in order.  I'm thinking of wording something
>> >along the lines of:
>> >
>> >When a client requests a listing of the members of a collection, this
>> >listing is returned in the order specified by the collection.
>>
>> Again, Jim Davis and Yaron have both opposed requiring a server to apply
>> the ordering to any list of collection members it returns.  Jim's view is
>> that it is just as easy for the client to retrieve the ordering and apply
>> it.  So that's how 3.2.3 got weakened to its current state.  Are there
>> others who think it should be strengthened again?
>
>Except that I think they were thinking the server would be performing some
>action like alphabetizing the listing before sending it out.  If the
>ordering is static (non-live), then returning the members of the collection
>in order seems reasonable to me.
>

Name:			Judith A. Slein
E-Mail:		slein@wrc.xerox.com
Internal Phone:  	8*222-5169
Fax:			(716) 422-2938
MailStop:		105-50C
Web Site:    http://www.nde.wrc.xerox.com/users/Slein/slein.htm


From w3c-dist-auth-request@www10.w3.org  Mon May 18 12:49:15 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id MAA19368 for <w3c-dist-auth@www19.w3.org>; Mon, 18 May 1998 12:49:15 -0400 (EDT)
Received: from doggate.exchange.microsoft.com (doggate.Exchange.microsoft.com [131.107.88.55]) by www10.w3.org (8.8.5/8.7.3) with SMTP id MAA02490 for <w3c-dist-auth@w3.org>; Mon, 18 May 1998 12:49:14 -0400 (EDT)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2217.0)
	id <K84TTR73>; Mon, 18 May 1998 09:49:15 -0700
Message-ID: <2FBF98FC7852CF11912A000000000001090F5586@DINO>
>From: "Lisa Dusseault (Exchange)" <lisadu@exchange.microsoft.com>
To: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>,
        "'hep@acm.org'"
	 <hep@acm.org>
Date: Mon, 18 May 1998 09:49:15 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2217.0)
MIME-Version: 1.0
Content-Type: multipart/signed;
	boundary="----=_NextPart_000_0015_01BD8241.E3A30A00";
	protocol="application/x-pkcs7-signature";
	micalg=SHA-1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Subject: Feedback on draft-ietf-webdav-acreq-01.txt

This is a multi-part message in MIME format.

------=_NextPart_000_0015_01BD8241.E3A30A00
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000E_01BD8241.E2DAB0F0"


------=_NextPart_000_000E_01BD8241.E2DAB0F0
Content-Type: text/plain;
	charset="windows-1252"
Content-Transfer-Encoding: 7bit

I've read the WebDAV ACLs Requirements document, and I have some rather
detailed feedback on it.  Will there be another version of this document
sometime?  It looks like it will expire in a couple days.

In general, I see a lot of sentences which say "the server may" or
"servers should".  We don't want to define the protocol yet, or say how
the implementations must work.  Instead, language can be carefully
restricted to "the protocol must define whether implementations..." and
"the protocol should specify how...".  Requirements should be stated in
terms of what the functional result should be, rather than the framework
for how to achieve that functional result.  In other words, we should
constrain protocol functionality, not protocol design.

The scope is very broad for something we'd actually like to accomplish.
I'd like to see a narrower required scope, with fewer features "required"
of the protocol, and the others can be "desired" features of the protocol.
The document could be more specific on precisely which features are MUST
have, SHOULD have and MAY have features.

Here is a section-by-section list of my comments on the draft.  Many of
the comments can be boiled down to saying that the requirements document
needs to focus on the desired or required functionality of the protocol,
not on the server implementations.

Section 3.  Terminology

It may be useful to define what you mean by ACE and ACL, but I'm not sure
that ACEs would be required by a successful protocol design that met the
functional requirements.  Recommending the use of ACE's be investigated
would be enough of a requirement, so that we can avoid hampering protocol
designers.

The definition for a Principal Description requires use of boolean logic.
There may be another way of describing a principal that could meet the
functional requirements.

The rest of the definitions are very useful by defining existing or
required concepts such as a collection.

Section 4.3. Access Control Entry (ACE)

"An Access Control Entry is the most fundamental unit of access control
policy.  An ACE contains a list of access rights, a principal
description, and an indication of whether the specified access rights
are to be granted or denied for principal identities which match the
principal description.  An ACE has no applicability to principal
identities which do not match its principal description."

This presumes the existence of ACE's, then constrains ACEs.  This
definition belongs in the protocol specification document, if anywhere.
What if the protocol designers decide to allow only one access right per
entry?  Having a single access right per entry could still meet the
functional requirements.

Section 4.4. Access Control List (ACL)

"An Access Control List is an ordered list of ACEs which are directly
associated with a given resource.  When policies expressed by the ACEs
in a given ACL are in conflict, the policies expressed by ACEs nearer
the beginning of the list have precedence.  "

This constrains protocol design.  How about rephrasing this in terms of
required functionality:  "The protocol must allow access rights to be
associated with a given resource.  The protocol may define some method to
avoid conflicting access rights."

"Evaluation stops either when all requested access rights have
been granted by one or more ACEs, or when any one of the requested
access rights has been denied by one of the ACEs.  ACEs containing
principal descriptions that do not match the current principal identity
have no effect on the outcome of the evaluation."

Same thing.  How about "The protocol may define short-circuit methods by
which servers can make a decision on access rights before all possible
access rights are evaluated."

Section 4.5.  Inheritance

Is it required for the protocol to do discovery and conflict resolution of
inheritance?  This could be difficult to standardize.  Are there other
models for inheritance besides the ones you've defined (static & dynamic)?
Is dynamic inheritance always done in exactly the way you've defined?

Section 4.5.2. Conflict Resolution

 - Good discussion and information on some of the issues that will have to
be addressed.
 - However, some of the things you said were quite implementation
specific:
"potential conflict between inherited ACLs, the resource ACL, and
user-based ACLs is also resolved by specifying a logical ordering or
precedence."
That assumes logical ordering is the way to resolve conflicts.  I think
that should be left open in the requirements doc, so that it can be
resolved either in the protocol specification or in each implementation.

"The order is different for dynamic inheritance.  First, any dynamic,
user-based ACL is evaluated, then any dynamic ACL on the collection root,
and so on, down to any dynamic ACL on the collection containing the
resource being access, and finally, any resource ACL on the resource
itself."

Are all implementations of dynamic inheritance already in compliance with
this statement?

Section 4.5.3. Distinction of Inherited ACLs

"Servers should interpret operations to retrieve and set the ACL of a
resource as applying only to the resource ACL on that resource, and not to
any inherited ACLs."
This should be left up to the protocol specification or to each
implementation.

Section 4.7. Other Access Control

"A compliant server may support other kinds of access control, which are
outside the scope of this protocol.  "

This is the kind of sentence that could well go into the protocol
specification, not the requirements doc

Section 5.1. Discovery

"The protocol must provide a way for a client to discover any optional or
extended functionality that may be implemented on a server, without
side-effects.  "
That's a big requirement for the protocol!  ANY optional or extended
functionality?  Discovery mechanisms are difficult.

"Compliant servers must be able to respond meaningfully to discovery
operations."
This specifies behaviour for servers, which the protocol should be doing
rather than the requirements doc.

Section 5.2.1.1. Rationale [for discovery]

Should it be possible to add an ACE without having permission to read the
whole ACL?  I can see that this would be desirable, but the requirements
document seems to preclude this.

Section 5.2.2. ACL Creation

This section specifies that certain features must be done with separate
operations.  That unduly constrains the protocol design.  Saying that the
protocol must support these features should be sufficient.

Section 5.2.4.  ACE Insertion

Supporting ACE insertion could be difficult.  I'd like to see this
optional in the protocol.  It depends on how the protocol resolves
conflict, which could be via ordering or some other mechanism.

Section 5.2.6. Test access

Why is this required of the protocol?  Perhaps it should be optional.

Section 5.3.  ACE Contents

"The contents of an ACE must include a list of access rights, a principal
description, and an indication of whether the rights are granted or
denied for matching principal identities."

This constrains the protocol to a very specific design.  This could be
rephrased as "The protocol must support multiple access rights granted or
denied to a described principal."  to leave the protocol designers free to
use some other mechanism to achieve the same functionality.

Section 5.4. Principal Description Semantics

Is it necessary to support arbitrary boolean expressions in defining a
principal?  Will all implementations that wish to support DAV ACLs be
willing to support that requirement?  Also, the requirement that
implementations must do short-circuiting is too restrictive for a
requirements document (should go in protocol specification if at all).

Section 5.6. Principal Attributes.

I don't see support for access based on group membership  (For example, to
allow full access to all members of group "sysops").

Section 5.6.3. User Name

By user name, do you mean "userid"?  Do you mean "lisadu" or "Lisa
Dusseault" or both or neither?

Section 5.7.1. Rationale [ for access rights]

"Some server implementations may perform mappings between WebDAV access
rights and native file system access rights.  "

I agree this is desirable.  How about rephrasing it as "The protocol
should make some allowance for implementations which map WEbDAV access
rights to native file system rights."

Section 5.7.2. List

"If a client attempts to create an ACE containing the "list" right, but
not the "read" right, such a server should return an error indicating that
"list" is not supported as an independent right."

A cool idea, but this defines the protocol, not requirements for the
protocol.


Lisa Dusseault



------=_NextPart_000_000E_01BD8241.E2DAB0F0
Content-Type: text/html;
	charset="windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2163.0">
<TITLE></TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Courier New">I've read the WebDAV ACLs =
Requirements document, and I have some rather detailed feedback on =
it.&nbsp; Will there be another version of this document sometime?&nbsp; =
It looks like it will expire in a couple days.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">In general, I see a lot of =
sentences which say &quot;the server may&quot; or &quot;servers =
should&quot;.&nbsp; We don't want to define the protocol yet, or say how =
the implementations must work.&nbsp; Instead, language can be carefully =
restricted to &quot;the protocol must define whether =
implementations...&quot; and &quot;the protocol should specify =
how...&quot;.&nbsp; Requirements should be stated in terms of what the =
functional result should be, rather than the framework for how to =
achieve that functional result.&nbsp; In other words, we should =
constrain protocol functionality, not protocol design.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">The scope is very broad for =
something we'd actually like to accomplish.&nbsp; I'd like to see a =
narrower required scope, with fewer features &quot;required&quot; of the =
protocol, and the others can be &quot;desired&quot; features of the =
protocol.&nbsp; The document could be more specific on precisely which =
features are MUST have, SHOULD have and MAY have features.&nbsp; =
</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Here is a section-by-section list =
of my comments on the draft.&nbsp; Many of the comments can be boiled =
down to saying that the requirements document needs to focus on the =
desired or required functionality of the protocol, not on the server =
implementations.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Section 3.&nbsp; Terminology =
</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">It may be useful to define what =
you mean by ACE and ACL, but I'm not sure that ACEs would be required by =
a successful protocol design that met the functional requirements.&nbsp; =
Recommending the use of ACE's be investigated would be enough of a =
requirement, so that we can avoid hampering protocol =
designers.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">The definition for a Principal =
Description requires use of boolean logic.&nbsp; There may be another =
way of describing a principal that could meet the functional =
requirements.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">The rest of the definitions are =
very useful by defining existing or required concepts such as a =
collection. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Section 4.3. Access Control Entry =
(ACE) </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&quot;An Access Control Entry is =
the most fundamental unit of access control </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">policy.&nbsp; An ACE contains a =
list of access rights, a principal </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">description, and an indication =
of whether the specified access rights </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">are to be granted or denied for =
principal identities which match the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">principal description.&nbsp; An =
ACE has no applicability to principal </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">identities which do not match =
its principal description.&quot; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">This presumes the existence of =
ACE's, then constrains ACEs.&nbsp; This definition belongs in the =
protocol specification document, if anywhere.&nbsp; What if the protocol =
designers decide to allow only one access right per entry?&nbsp; Having =
a single access right per entry could still meet the functional =
requirements.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Section 4.4. Access Control List =
(ACL) </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&quot;An Access Control List is =
an ordered list of ACEs which are directly </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">associated with a given =
resource.&nbsp; When policies expressed by the ACEs </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">in a given ACL are in conflict, =
the policies expressed by ACEs nearer </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">the beginning of the list have =
precedence.&nbsp; &quot; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">This constrains protocol =
design.&nbsp; How about rephrasing this in terms of required =
functionality:&nbsp; &quot;The protocol must allow access rights to be =
associated with a given resource.&nbsp; The protocol may define some =
method to avoid conflicting access rights.&quot;</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&quot;Evaluation stops either =
when all requested access rights have </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">been granted by one or more =
ACEs, or when any one of the requested </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">access rights has been denied by =
one of the ACEs.&nbsp; ACEs containing </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">principal descriptions that do =
not match the current principal identity </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">have no effect on the outcome of =
the evaluation.&quot; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Same thing.&nbsp; How about =
&quot;The protocol may define short-circuit methods by which servers can =
make a decision on access rights before all possible access rights are =
evaluated.&quot;</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Section 4.5.&nbsp; Inheritance =
</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Is it required for the protocol =
to do discovery and conflict resolution of inheritance?&nbsp; This could =
be difficult to standardize.&nbsp; Are there other models for =
inheritance besides the ones you've defined (static &amp; =
dynamic)?&nbsp; Is dynamic inheritance always done in exactly the way =
you've defined?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Section 4.5.2. Conflict =
Resolution </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;- Good discussion and =
information on some of the issues that will have to be addressed. =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;- However, some of the =
things you said were quite implementation specific: </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&quot;potential conflict between =
inherited ACLs, the resource ACL, and user-based ACLs is also resolved =
by specifying a logical ordering or precedence.&quot;</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">That assumes logical ordering is =
the way to resolve conflicts.&nbsp; I think that should be left open in =
the requirements doc, so that it can be resolved either in the protocol =
specification or in each implementation.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&quot;The order is different for =
dynamic inheritance.&nbsp; First, any dynamic, user-based ACL is =
evaluated, then any dynamic ACL on the collection root, and so on, down =
to any dynamic ACL on the collection containing the resource being =
access, and finally, any resource ACL on the resource =
itself.&quot;</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Are all implementations of =
dynamic inheritance already in compliance with this statement? </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Section 4.5.3. Distinction of =
Inherited ACLs </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&quot;Servers should interpret =
operations to retrieve and set the ACL of a resource as applying only to =
the resource ACL on that resource, and not to any inherited =
ACLs.&quot;</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">This should be left up to the =
protocol specification or to each implementation. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Section 4.7. Other Access Control =
</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&quot;A compliant server may =
support other kinds of access control, which are outside the scope of =
this protocol.&nbsp; &quot; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">This is the kind of sentence that =
could well go into the protocol specification, not the requirements doc =
</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Section 5.1. Discovery </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&quot;The protocol must provide a =
way for a client to discover any optional or extended functionality that =
may be implemented on a server, without side-effects.&nbsp; =
&quot;</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">That's a big requirement for the =
protocol!&nbsp; ANY optional or extended functionality?&nbsp; Discovery =
mechanisms are difficult.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&quot;Compliant servers must be =
able to respond meaningfully to discovery operations.&quot; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">This specifies behaviour for =
servers, which the protocol should be doing rather than the requirements =
doc. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Section 5.2.1.1. Rationale [for =
discovery] </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Should it be possible to add an =
ACE without having permission to read the whole ACL?&nbsp; I can see =
that this would be desirable, but the requirements document seems to =
preclude this.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Section 5.2.2. ACL Creation =
</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">This section specifies that =
certain features must be done with separate operations.&nbsp; That =
unduly constrains the protocol design.&nbsp; Saying that the protocol =
must support these features should be sufficient.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Section 5.2.4.&nbsp; ACE =
Insertion </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Supporting ACE insertion could be =
difficult.&nbsp; I'd like to see this optional in the protocol.&nbsp; It =
depends on how the protocol resolves conflict, which could be via =
ordering or some other mechanism.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Section 5.2.6. Test access =
</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Why is this required of the =
protocol?&nbsp; Perhaps it should be optional. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Section 5.3.&nbsp; ACE Contents =
</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&quot;The contents of an ACE must =
include a list of access rights, a principal </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">description, and an indication =
of whether the rights are granted or </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">denied for matching principal =
identities.&quot; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">This constrains the protocol to a =
very specific design.&nbsp; This could be rephrased as &quot;The =
protocol must support multiple access rights granted or denied to a =
described principal.&quot;&nbsp; to leave the protocol designers free to =
use some other mechanism to achieve the same functionality.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Section 5.4. Principal =
Description Semantics </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Is it necessary to support =
arbitrary boolean expressions in defining a principal?&nbsp; Will all =
implementations that wish to support DAV ACLs be willing to support that =
requirement?&nbsp; Also, the requirement that implementations must do =
short-circuiting is too restrictive for a requirements document (should =
go in protocol specification if at all).</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Section 5.6. Principal =
Attributes. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">I don't see support for access =
based on group membership&nbsp; (For example, to allow full access to =
all members of group &quot;sysops&quot;).</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Section 5.6.3. User Name </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">By user name, do you mean =
&quot;userid&quot;?&nbsp; Do you mean &quot;lisadu&quot; or &quot;Lisa =
Dusseault&quot; or both or neither? </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Section 5.7.1. Rationale [ for =
access rights] </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&quot;Some server implementations =
may perform mappings between WebDAV access </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">rights and native file system =
access rights.&nbsp; &quot; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">I agree this is desirable.&nbsp; =
How about rephrasing it as &quot;The protocol should make some allowance =
for implementations which map WEbDAV access rights to native file system =
rights.&quot;</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Section 5.7.2. List </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&quot;If a client attempts to =
create an ACE containing the &quot;list&quot; right, but not the =
&quot;read&quot; right, such a server should return an error indicating =
that &quot;list&quot; is not supported as an independent =
right.&quot;</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">A cool idea, but this defines the =
protocol, not requirements for the protocol. </FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Lisa Dusseault </FONT>
</P>
<BR>

</BODY>
</HTML>
------=_NextPart_000_000E_01BD8241.E2DAB0F0--

------=_NextPart_000_0015_01BD8241.E3A30A00
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"


A/oVnAtF5vDcV0NCbJmwtwoAAAAAAAA=

------=_NextPart_000_0015_01BD8241.E3A30A00--


From w3c-dist-auth-request@www10.w3.org  Tue May 19 00:25:39 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id AAA29704 for <w3c-dist-auth@www19.w3.org>; Tue, 19 May 1998 00:25:38 -0400 (EDT)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50]) by www10.w3.org (8.8.5/8.7.3) with SMTP id AAA06667 for <w3c-dist-auth@w3.org>; Tue, 19 May 1998 00:25:38 -0400 (EDT)
Received: from [166.55.224.42] by paris.ics.uci.edu id aa19663;
          18 May 98 21:10 PDT
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Mon, 18 May 1998 21:14:45 -0700
Message-ID: <000001bd82dc$a8c2da00$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <3.0.3.32.19980517145157.00905bc0@pop-server.wrc.xerox.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Subject: RE: Ordered Collections

Judy,

Thank you for your hard work on this draft!

> I've submitted a new draft of the collection requirements to
> Internet-Drafts, so they should be available in a few days.

In the meanwhile, the draft is available at:

http:/www.ics.uci.edu/pub/ietf/webdav/collection/draft-ietf-webdav-collectio
n-reqts-01.txt

It is also accessible off the WebDAV home page at:

http://www.ics.uci.edu/pub/ietf/webdav/

- Jim


From w3c-dist-auth-request@www10.w3.org  Tue May 19 09:48:21 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id JAA07082 for <w3c-dist-auth@www19.w3.org>; Tue, 19 May 1998 09:48:21 -0400 (EDT)
Received: from ietf.org (ietf.org [132.151.1.19]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id JAA09678 for <w3c-dist-auth@w3.org>; Tue, 19 May 1998 09:48:20 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA18995;
	Tue, 19 May 1998 09:48:15 -0400 (EDT)
Message-Id: <199805191348.JAA18995@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: w3c-dist-auth@w3.org
>From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 19 May 1998 09:48:15 -0400
Sender: cclark@CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-webdav-collection-reqts-01.txt

--NextPart

A Revised Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the WWW Distributed Authoring and Versioning Working 
Group of the IETF.

	Title		: Requirements for Advanced Collection Functionality 
                          in WebDAV
	Author(s)	: J. Slein
	Filename	: draft-ietf-webdav-collection-reqts-01.txt
	Pages		: 9
	Date		: 18-May-98
	
        The base WebDAV protocol [Goland et al., 1998] provides basic
        support for collections.  It defines a MKCOL method for creating
        collections and specifies how other HTTP and WebDAV methods
        interact with collections.  It supports only internal members of
        collections, which it defines as members whose URIs are
        immediately relative to the URI of the collection.
 
        This draft sets out requirements for more advanced, optional
        collection functionality. It extends the base functionality in two
        general directions: support for referential members, and support
        for ordered collections.  A separate WebDAV specification is
        expected to define protocol elements providing the functionality
        described here.


Internet-Drafts are available by anonymous FTP.  Login wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-webdav-collection-reqts-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-webdav-collection-reqts-01.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ds.internic.net.  In the body type:
	"FILE /internet-drafts/draft-ietf-webdav-collection-reqts-01.txt".
	
NOTE:	The mail server at ds.internic.net can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID:	<19980518133301.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-webdav-collection-reqts-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-webdav-collection-reqts-01.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19980518133301.I-D@ietf.org>

--OtherAccess--

--NextPart--




From w3c-dist-auth-request@www10.w3.org  Wed May 20 00:28:21 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id AAA21812 for <w3c-dist-auth@www19.w3.org>; Wed, 20 May 1998 00:28:20 -0400 (EDT)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50]) by www10.w3.org (8.8.5/8.7.3) with SMTP id AAA16147 for <w3c-dist-auth@w3.org>; Wed, 20 May 1998 00:28:22 -0400 (EDT)
Received: from usr16-dialup27.mix1.Bloomington.mci.net by paris.ics.uci.edu
          id aa24908; 19 May 98 21:23 PDT
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Tue, 19 May 1998 21:27:46 -0700
Message-ID: <003001bd83a7$a3aad1a0$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Subject: FW: question on "charset"s

Caught by the spam filter.  I have asked to have this email address for Mike
added to the accept list for the WebDAV list.

- Jim

-----Original Message-----
>From: Mike_Spreitzer.PARC@xerox.com
[mailto:Mike_Spreitzer.PARC@xerox.com]
Sent: Tuesday, May 19, 1998 9:30 AM
To: w3c-dist-auth@w3.org
Cc: Mike_Spreitzer.PARC@xerox.com
Subject: [Spam?] question on "charset"s


In IETF jargon, a "charset" encompases: (1) an abstract set of characters,
(2)
an association between numeric codes and abstract characters, and (3) a way
to
encode those numeric codes in byte sequences.  "Unicode" is about (1) and
(2),
and XML recognizes the need for (3) as well.  My question is this: does a
WebDAV server preserve (1), (2), and (3), or just (1) and (2)?  That is, if
I
write entity bodies or properties or other metadata in one particular
encoding,
are read operations required to return that content in the same encoding?


From w3c-dist-auth-request@www10.w3.org  Wed May 20 12:58:29 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id MAA01896 for <w3c-dist-auth@www19.w3.org>; Wed, 20 May 1998 12:58:28 -0400 (EDT)
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by www10.w3.org (8.8.5/8.7.3) with SMTP id MAA21302 for <w3c-dist-auth@w3.org>; Wed, 20 May 1998 12:58:30 -0400 (EDT)
Received: from mailback.parc.xerox.com ([13.1.101.39]) by alpha.xerox.com with SMTP id <54864(4)>; Wed, 20 May 1998 09:00:53 PDT
Received: from huisje.parc.xerox.com ([13.0.209.88]) by mailback.parc.xerox.com with SMTP id <166676>; Wed, 20 May 1998 08:48:40 PDT
Message-Id: <3.0.3.32.19980520084601.00816420@mailback.parc.xerox.com>
X-Sender: jdavis@mailback.parc.xerox.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 20 May 1998 08:46:01 PDT
To: WEBDAV WG <w3c-dist-auth@w3.org>
>From: Jim Davis <jdavis@parc.xerox.com>
Cc: spreitzer@parc.xerox.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: Re: FW: question on "charset"s

At 09:27 PM 5/19/98 PDT, Mike_Spreitzer.PARC@xerox.com wrote
>In IETF jargon, a "charset" encompases: (1) an abstract set of characters,
(2) an association between numeric codes and abstract characters, and (3) a
way to encode those numeric codes in byte sequences.  "Unicode" is about
(1) and (2), and XML recognizes the need for (3) as well.  My question is
this: does a WebDAV server preserve (1), (2), and (3), or just (1) and (2)?
 That is, if I write entity bodies or properties or other metadata in one
particular encoding, are read operations required to return that content in
the same encoding?

It seems to me that WebDAV is silent on this question - it just does
whatever HTTP 1.1 does.

HTTP mandates support for UTF-8, which defines the encoding (your point
number 3).  I don't see (but may have missed) any language that prohibits
other encodings.

By "same encoding" did you mean same algorithm (e.g. always UTF-8) or
byte-for-byte identical when using the same algorithm?  

If the latter, section 3.4 of RFC 2068 says "a character set may provide
more than one sequence of octets to represent a particular character",
which to me implies that HTTP servers in general, and WebDAV serves in
particular, need not guarantee that the octet sequence returned by a GET is
byte for byte identical with the one created with a PUT.  I don't even see
a requirement there that the sequence returned be the 'canonical' one, if
there is a choice.

That's my opinion, but I don't consider myself expert.

Jim


From w3c-dist-auth-request@www10.w3.org  Wed May 20 13:07:47 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id NAA02198 for <w3c-dist-auth@www19.w3.org>; Wed, 20 May 1998 13:07:47 -0400 (EDT)
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by www10.w3.org (8.8.5/8.7.3) with SMTP id NAA21383 for <w3c-dist-auth@w3.ORG>; Wed, 20 May 1998 13:07:48 -0400 (EDT)
>From: Mike_Spreitzer.PARC@xerox.com
Received: from dmsms2.OSBU_North.Xerox.xns by alpha.xerox.com via XNS id <53150(5)>; Wed, 20 May 1998 10:07:29 PDT
X-NS-Transport-ID: 0800201FCE5D3905303F
Date: Wed, 20 May 1998 10:06:55 PDT
In-Reply-to: <3.0.3.32.19980520084601.00816420@mailback.parc.xerox.com>
To: jdavis@parc.xerox.COM
cc: w3c-dist-auth@w3.org, spreitzer@parc.xerox.COM
Message-Id: <98May20.100729pdt."53150(5)"@alpha.xerox.com>
Subject: Re: FW: question on "charset"s

That's starting to answer the question for entities; HTTP/1.1 doesn't have
properties.

HTTP/1.1, at the start of section 9.6, says ``The PUT method requests that the
enclosed entity be stored under the supplied Request-URI''.  I'd say the most
natural interpretation of this is that the entity body be preserved
byte-for-byte.


From w3c-dist-auth-request@www10.w3.org  Wed May 20 14:27:10 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id OAA03355 for <w3c-dist-auth@www19.w3.org>; Wed, 20 May 1998 14:27:10 -0400 (EDT)
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by www10.w3.org (8.8.5/8.7.3) with SMTP id OAA22086 for <w3c-dist-auth@w3.org>; Wed, 20 May 1998 14:27:11 -0400 (EDT)
Received: from mailback.parc.xerox.com ([13.1.101.39]) by alpha.xerox.com with SMTP id <52187(4)>; Wed, 20 May 1998 11:27:06 PDT
Received: from huisje.parc.xerox.com ([13.0.209.88]) by mailback.parc.xerox.com with SMTP id <166790>; Wed, 20 May 1998 11:26:36 PDT
Message-Id: <3.0.3.32.19980520104105.00840390@mailback.parc.xerox.com>
X-Sender: jdavis@mailback.parc.xerox.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 20 May 1998 10:41:05 PDT
To: Mike_Spreitzer.PARC@xerox.com
>From: Jim Davis <jdavis@parc.xerox.com>
Cc: w3c-dist-auth@w3.org
In-Reply-To: <98May20.100729pdt."53150(5)"@alpha.xerox.com>
References: <3.0.3.32.19980520084601.00816420@mailback.parc.xerox.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: Re: FW: question on "charset"s

At 10:06 AM 5/20/98 PDT, Mike_Spreitzer.PARC@xerox.com wrote:
>That's starting to answer the question for entities; HTTP/1.1 doesn't have
>properties.

I assume that properties will be treated just like entity bodies.

>HTTP/1.1, at the start of section 9.6, says ``The PUT method requests that
the
>enclosed entity be stored under the supplied Request-URI''.  I'd say the most
>natural interpretation of this is that the entity body be preserved
>byte-for-byte.

Uh, I think you'll find some disagreement on this.  For one thing, consider
active content (e.g. server side includes).

Earlier traffic on this list (Sorry, I don't have time to search for it)
has stressed the *absence* of any such guarantee.  WebDAV does not, for
example, promise that the result of a COPY is byte-for-byte the same.  It
says (7.8.1) the result is "a new resource ... whose state and behavior
match that of the source resource as closely as possible".

This is the last I'll say on the topic.  Hopefully someone better informed
will speak up.



From w3c-dist-auth-request@www10.w3.org  Wed May 20 15:17:00 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id PAA03922 for <w3c-dist-auth@www19.w3.org>; Wed, 20 May 1998 15:16:59 -0400 (EDT)
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by www10.w3.org (8.8.5/8.7.3) with SMTP id PAA22508 for <w3c-dist-auth@w3.ORG>; Wed, 20 May 1998 15:17:01 -0400 (EDT)
>From: Mike_Spreitzer.PARC@xerox.com
Received: from dmsms2.OSBU_North.Xerox.xns by alpha.xerox.com via XNS id <52426(5)>; Wed, 20 May 1998 12:16:47 PDT
X-NS-Transport-ID: 0800201FCE5D39053045
Date: Wed, 20 May 1998 12:16:26 PDT
In-Reply-to: <3.0.3.32.19980520104105.00840390@mailback.parc.xerox.com>
To: jdavis@parc.xerox.COM
cc: Mike_Spreitzer.PARC@xerox.com, w3c-dist-auth@w3.org
Message-Id: <98May20.121647pdt."52426(5)"@alpha.xerox.com>
Subject: Re: FW: question on "charset"s

OK, thanks.  I too hope others speak up.

Am I right in presuming a server is allowed to offer "content negotiation" over
charset of a resource given to it, necesarily in exactly one charset, by PUT?
Presumably a server is also allowed to be completely inflexible in its "content
negotiation" over charset.  If these things are so, then I would not be
surprised to hear that (1) a server is allowed, but certainly not required, to
return exactly (byte-for-byte) the given entity body when given no guidance
through Accept-Charset, and (2) a server is allowed, but certainly not
required, to map given entity bodies into a single charset preferred by the
server and offer only that charset in "content negotiation", and (3) lots of
other variations, as these are all a matter of server policy, which the
protocol aims to not restrict.

Does WebDAV have anything like charset negotiation for properties?  If not,
it's not obvious to me that the above analysis would apply to properties.


From w3c-dist-auth-request@www10.w3.org  Wed May 20 16:46:46 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id QAA05592 for <w3c-dist-auth@www19.w3.org>; Wed, 20 May 1998 16:46:45 -0400 (EDT)
Received: from mail3-b.microsoft.com (mail3-b.microsoft.com [131.107.3.123]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id QAA23515 for <w3c-dist-auth@w3.org>; Wed, 20 May 1998 16:46:47 -0400 (EDT)
Received: by mail3-b.microsoft.com with Internet Mail Service (5.5.2217.0)
	id <LKFBRQPY>; Wed, 20 May 1998 13:47:09 -0700
Message-ID: <3FF8121C9B6DD111812100805F31FC0D02971364@red-msg-59.dns.microsoft.com>
>From: Yaron Goland <yarong@microsoft.com>
To: "'Mike_Spreitzer.PARC@xerox.com'" <Mike_Spreitzer.PARC@xerox.com>,
        jdavis@parc.xerox.com
Cc: w3c-dist-auth@w3.org
Date: Wed, 20 May 1998 13:47:07 -0700
X-Mailer: Internet Mail Service (5.5.2217.0)
Subject: RE: FW: question on "charset"s

Section 14.2 of
http://www.ietf.org/internet-drafts/draft-ietf-http-v11-spec-rev-03.txt
defines the accept-charset header that allows charset negotiation. This
would apply to any method it is used with. Thus sending accept-charset with
a PROPFIND does cause negotiation over the charset used in the PROPFIND
response.

Section 15 of
http://www.ietf.org/internet-drafts/draft-ietf-webdav-protocol-08.txt
specifies that all DAV systems MUST support the charset requirements of XML.

Section 2.2 of http://www.w3.org/TR/REC-xml#syntax specifies that all XML
systems MUST support UTF-8 and UTF-16.

Therefore you are guaranteed that that all DAV servers will be able to
accept properties in UTF-8 or UTF-16 and be able to return properties in one
of those two charsets.

	I hope this clarifies matters,

			Yaron


From w3c-dist-auth-request@www10.w3.org  Thu May 21 02:46:18 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id CAA13925 for <w3c-dist-auth@www19.w3.org>; Thu, 21 May 1998 02:46:17 -0400 (EDT)
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by www10.w3.org (8.8.5/8.7.3) with SMTP id CAA27259 for <w3c-dist-auth@w3.org>; Thu, 21 May 1998 02:46:19 -0400 (EDT)
Received: from casablanca.parc.xerox.com ([13.2.16.111]) by alpha.xerox.com with SMTP id <52475(1)>; Wed, 20 May 1998 23:46:11 PDT
Received: from copper-208.parc.xerox.com ([13.2.17.217]) by casablanca.parc.xerox.com with SMTP id <71820>; Wed, 20 May 1998 23:45:45 PDT
>From: "Larry Masinter" <masinter@parc.xerox.com>
To: "Jim Davis" <jdavis@parc.xerox.com>, "WEBDAV WG" <w3c-dist-auth@w3.org>
Cc: <spreitzer@parc.xerox.com>
Date: Wed, 20 May 1998 23:45:41 PDT
Message-ID: <001601bd8484$129a6620$15d0000d@copper-208.parc.xerox.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <3.0.3.32.19980520084601.00816420@mailback.parc.xerox.com>
Subject: RE: FW: question on "charset"s

HTTP explicitly places no requirements on the relationship
between the data sent by a PUT and the data returned by a subsequent GET.
Any number of transformations (including charset, encoding, or whatever)
might be applied, for example.

#  HTTP/1.1 does not define how a PUT method affects the state of an origin
# server.


Larry
--
http://www.parc.xerox.com/masinter
 


From w3c-dist-auth-request@www10.w3.org  Fri May 22 17:57:20 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id RAA19301 for <w3c-dist-auth@www19.w3.org>; Fri, 22 May 1998 17:57:20 -0400 (EDT)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50]) by www10.w3.org (8.8.5/8.7.3) with SMTP id RAA10265 for <w3c-dist-auth@w3.org>; Fri, 22 May 1998 17:57:21 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa07065;
          22 May 98 14:53 PDT
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Fri, 22 May 1998 14:58:05 -0700
Message-ID: <003701bd85cc$b2bb8be0$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Subject: FW: Comments on ENP requirements draft

Caught by the spam filter.  I've added John to the accept2 list for the
mailing list.

- Jim

-----Original Message-----
>From: John Stracke [mailto:francis@netscape.com]
Sent: Thursday, May 21, 1998 1:02 PM
To: WebDAV WG
Subject: [Spam?] Comments on ENP requirements draft


Hi, I'm a new member of Jim Cunningham's group here at Netscape; I'm
working on agents, so I read over the ENP requirements draft
(draft-ietf-webdav-enpreq-01.txt), and I had some comments on the
requirements list (section 4):

   * 4.2: "It SHOULD be possible to associate attributes with the
     notification request."  I'm afraid I don't quite see why--would
     they just be opaque data to be passed back to the client?
   * 4.3: queued notifications.  Sounds like email to me.  :-)
   * 4.4: notification with reliable delivery.  How important is it that
     order be preserved? I would think that, for most applications, it
     would suffice to provide guaranteed delivery with timestamps;
     receivers that need ordering can just sort the events.  (True, this
     doesn't solve the problem of "message 3 is useless without message
     2"--but that can be handled with application-level sequence
     numbers.)
   * 4.7: a consumer MUST be able to specify a list of other consumers
     to receive notifications.  This bothers me; it seems subject to
     spam-like abuse.  My feeling is that, if consumer A wants consumers
     X, Y, and Z to be notified, A should just forward the notifications
     itself.
   * 4.13: This follows from 4.15 and 4.17.
   * 4.14: What's an event channel? You haven't defined it.
   * 4.16: This is a subset of 4.18--copy&paste error?
   * 4.17: I'm not sure why this needs to be specified--any server
     should be able to handle multiple clients, and any client should be
     able to connect to multiple servers; the protocol doesn't normally
     have to worry about it.

Also, some thoughts on design (too early?): I believe that our best bet
would be to define the event format as a MIME type, so that events can
be carried in any MIME-bearing transport (mail, news, HTTP, Web push
protocols), rather than in a new notification delivery protocol.  This
would also let us get security by means of S/MIME.

One option would be to define a new report-type for multipart/report
(RFC1892), similar to DSN (RFC1894), since multipart/report is meant for
delivering event notifications.  This would simplify the work of making
sure that DSN can travel via the same notification protocols as ENP (as
Larry Masinter recommended back in January).

--
/==================================================================\
|John (Francis) Stracke    |My opinions are my own.| Due to        |
|Software Retrophrenologist|=======================/ circumstances |
|Netscape Comm. Corp.      | beyond your control, you are master of|
|francis@netscape.com      |  your fate, and captain of your soul. |
\==================================================================/
New area code for work number: 650




From w3c-dist-auth-request@www10.w3.org  Fri May 22 19:30:28 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id TAA20739 for <w3c-dist-auth@www19.w3.org>; Fri, 22 May 1998 19:30:28 -0400 (EDT)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50]) by www10.w3.org (8.8.5/8.7.3) with SMTP id TAA10681 for <w3c-dist-auth@w3.org>; Fri, 22 May 1998 19:30:30 -0400 (EDT)
Received: from kiwi.ics.uci.edu by paris.ics.uci.edu id aa18764;
          22 May 98 16:25 PDT
To: Larry Masinter <masinter@parc.xerox.com>
cc: WEBDAV WG <w3c-dist-auth@w3.org>
In-reply-to: Your message of "Wed, 20 May 1998 23:45:41 PDT."
             <001601bd8484$129a6620$15d0000d@copper-208.parc.xerox.com> 
Date: Fri, 22 May 1998 16:25:54 -0700
>From: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Message-ID:  <9805221625.aa18764@paris.ics.uci.edu>
Subject: Re: FW: question on "charset"s 

>HTTP explicitly places no requirements on the relationship
>between the data sent by a PUT and the data returned by a subsequent GET.
>Any number of transformations (including charset, encoding, or whatever)
>might be applied, for example.
>
>#  HTTP/1.1 does not define how a PUT method affects the state of an origin
># server.

I think you are reading too much into that sentence.  HTTP/1.1 does not
define the extent to which a successful PUT affects the overall state of the
origin server, such as how many new resources are created as a result
of the PUT (versioning), or how it may impact interdependent resources
(collections, derived resources like server-side include, etc.).

However, it does define the semantics of what the PUT means for the
exact resource being PUT.  In particular, the origin server is not
allowed to transform the content and then reply with 200 or 204 -- doing
so would destroy the correspondence between the resource and the
entity-header fields PUT with the entity, and make operations like a
write-read-verify impossible.  The only way to allow that sort of thing
would be to introduce a new response code for 2xx Accepted with Transform,
which would tell the UA that it needs to re-GET the resource if it
wants to know what was actually created.  [BTW, I do think it would
be a good idea for WebDAV to add such a response code.]

Folks who are worried about derived resources like server-side includes
or automatic charset translaters should rest easy -- WebDAV servers will
not allow such resources to be PUT directly.  Instead, the server must
inform the client that the derived resource does not allow PUT, and that
its "source resource" is at another URL.  The same applies to resources
that are negotiation handles for variants.  In addition to simplifying the
semantic questions, this approach makes it easier for a server to control
read access for things that non-authors should never see.

....Roy


From w3c-dist-auth-request@www10.w3.org  Thu May 28 13:16:57 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id NAA07307 for <w3c-dist-auth@www19.w3.org>; Thu, 28 May 1998 13:16:56 -0400 (EDT)
Received: from leporello.cs.unibo.it (leporello.cs.unibo.it [130.136.1.110]) by www10.w3.org (8.8.5/8.7.3) with SMTP id NAA17211 for <w3c-dist-auth@w3.org>; Thu, 28 May 1998 13:17:11 -0400 (EDT)
Received: from [130.136.2.212] (cool.cs.unibo.it) by leporello.cs.unibo.it (5.67b/96.09.13)
	id AA15494; Thu, 28 May 1998 19:13:28 +0200
X-Sender: fabio@130.136.1.110
Message-Id: <v03007805b19344ac957b@[130.136.2.212]>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="============_-1315746737==_============"
Date: Thu, 28 May 1998 19:15:54 +0200
To: WEBDAV WG <w3c-dist-auth@w3.org>
>From: Fabio Vitali <fabio@CS.UniBO.IT>
Cc: David Durand <dgd@cs.bu.edu>
Subject: The 7 Deadly Sins of Versioning

--============_-1315746737==_============
Content-Type: text/plain; charset="us-ascii"

Dear all,

As the WebDAV group is now preparing to consider versioning in detail, and
we will not be attending the meeting in June at Microsoft, David Durand and
I felt that our best contribution would be to record a list of possible
decisions that should be avoided for versioning on the WWW. We have thus
written a document, "The 7 Deadly Sins of Versioning (plus a venial one)",
that we would like to submit to the attention of the WEBDAV group.

The document is both attached here and available at:
http://www.cs.unibo.it/~fabio/webdav/7sins.html

Our experience is that there are large number of pitfalls ahead of us.
We've certainly fallen prey to some of them ourselves (as well as
occasionally falling prey to systems that have them). By arguing that these
items should be examined for avoidance, we intend to forestall
possbilities. This is not an accusation, but a mild warning. We hope that
our cautions and fears are considered exxagerated and pointless. The
reaction that would please us most, would be that everyone says "This is
all obvious. Why are they wasting our time with this stuff?"

Furthermore, we do not mean to provide answers to the problems we list.
Although we do feel that our VTML format, properly applied, would help
solve most of these problems, still we would like to avoid partisanship,
and concentrate on ensuring that the issues are fully discussed and then
dismissed.

Regards to all,

Fabio Vitali & David G. Durand


--============_-1315746737==_============
Content-Type: text/html; name="7sins.html"; charset="us-ascii"
Content-Disposition: attachment; filename="7sins.html"

<H1 ALIGN =CENTER>The 7 Deadly Sins of Versioning <BR>
(plus a venial one)</H1>
<P ALIGN =CENTER>David Durand and Fabio Vitali</P>

<P>As the WebDAV group is now preparing to consider versioning in detail,
and we will not be attending the meeting this June, we felt that our  best
contribution would be to record a list of possible decisions that should be
avoided for versioning on the WWW. Our experience is that there are large
number of pitfalls in this area. We've certainly fallen prey to some of
them ourselves (as well as occasionally falling prey to systems that have
them). This list is intended to point out some awaiting problems. </P>
<P>By arguing that these decisions should be pre-rejected, we intend to
forestall possbilities. This is not an accusation, but a warning. The
reaction that would please us most, would that everyone says &quot;Why are
they wasting our time with this obvious stuff?&quot;</P>
<P>Furthermore, this document is not meant to provide answers to the
problems we list. We do feel that our VTML format, properly applied would
help solve most of these problems, but we would like to avoid partisanship,
and concentrate on ensuring that  the issues are fully discussed and then
dismissed. </P>
<H2>1. Enforced linear versioning</H2>
<P>Imposing a linear style of versioning allows very simple applications to
be set up: each author checks out the last version of the document,
modifies it and checks it back in; all other authors have to wait for the
first to check the document in; old versions are read-only; it is not
possible to create variants of a document without making a copy and editing
that.</P>
<P>Even if we decides that linear versioning is all that DAV must require
in the first revision, the time will come when more complex versioning
schemes will be needed, and the protocols must not require fundamental
change to accomodate more sophisticated servers. Linear versioning
protocols forbid parallel editing by multiple authors, imposes particular
(and rigid) turn-taking and workflow management policies on the authors,
requires the server to lock files (or allow &quot;lost updates&quot;). The
need for strong locking protocols strongly suggests a single server
implementation that will prevent disconnected operation. </P>
<P>Protocols and data formats that are only capable of linear versioning
will very soon come to their limits in any real world situation. Locking
the standard into linear versioning implies that the whole standard will
need to be re-discussed very soon. On the other hand, allowing branching
versions in the protocols and data formats, even if first generation
servers only deal with linear versions, allows future releases to be
developed without changing the fundamental levels of the standard. </P>
<H2>2. Serial editing</H2>
<P>Branching versions could be allowed both explicitly (a specific
operation is necessary to create a branch, or alternate version, of a
document) and implicitly (if more than one author edits the same document,
their versions will be parallel branches of the original version). We
strongly encourage considering implicit branching, i.e., support for
parallel edits, right at the core of the discussion on versioning styles.
</P>
<P>Parallel editing is required for collaboration  and is fundamental for
many kinds of detached and disconnected authoring. While parallel editing
implies branching versions, it need not imply lack of locks: where
workflows need to be controlled and guided, locking policies control how
many and what people can edit a document simultaneously. DAV should allow
parallel editing to happen at any moment based on the policies required by
particular clients and servers, rather than by &quot;one size fits all
(almost)&quot; policies wired into the basic protocol. </P>
<P>Requiring serial edits forces a particular and restrictive collaboration
policy that is inadequate in many situations. We believe embedding specific
policies in the protocols is the worst possible move the group could make,
and that forcing serial editing is the kind of decision that could haunt
the standard right for its entire life. </P>
<H2>3. Integrating versioning and structure information</H2>
<P>If a markup language (such as XML or HTML) is used as part of the
protocol (for instance to describe and transmit updates of versioned
documents), it should be completely separated from structural markup.</P>
<P>There are several good reasons for not mixing versioning and structure: </P>
<OL>
<LI>Schema definitions become very problematic. the mixing of structural
and revision information means that document schemas (like DTDs) must
describe versioning information as well as structural information. We are
aware of systems that use SGML attributes to control versioning, but they
require non-standard validation processes, as well as requiring the user's
DTD to be transformed into a &quot;system DTD&quot; augmented with
versioning information. This complexity is not necessary.</LI>
<LI>It won't work for media types that don't mark structure in a compatible
way, since there will be no place to attach the versioning information.</LI>
<LI>It requires a more complex syntax, since there are 3 kinds of change
that must be accomodated: Changes to document content are marked by special
tags; Changes to structural elements must use attributes (or violate XML
and HTML nesting rules); changes to attribute lists are extremely
difficult, and would probably involve some kind of ad hoc supplemental
attribute syntax.</LI>
<LI>The structural and versioning structures will not necessarily be that
compatible. Content changes that don't comply with the general structure of
the document become very verbose (for example, it is difficult to remove
data that span across several markup elements).</LI>
<LI>Versioning integrated into the structural markup doesn't even buy that
much: it doesn't allow sensible processing by versioning-unaware tools,
either for authoring or display.</LI>
<LI>The fallback of using comments to store deleted data (as we did in the
first VTML paper from the WWW4 proceedings) is only slightly less limited
than using special tags: it allows only linear editing and probably just
one revision. Finally, it becomes extremely difficult to use the same
versioning style to handle non-markup and binary formats.</LI>
</OL>
<P>All these reasons leads us to suggest to strongly separate information
about versioning and from document structure: there is just no simple and
satisfying way to use tags for versioning that interact and mix with tags
for structure. Versioning information should be kept separate and dealt
with in a separate step in the processing of the document, in much the same
way as content-encodings or compression are. Only in this manner we can
safely create versioning protocols and languages for any kind of document,
data format and versioning structure. We already tried this mix in the
first VTML paper, but it became overly complex whenever we tried to
integrate the needs of versioning-unaware tools and more complex versioning
policies. </P>
<H2>4. Using binary formats</H2>
<P>If there is one lesson we should learn from the success of the WWW (and
the prior history of SGML-based markup), it is the power of text-based
protocols and data formats. Texts (even ones not intended for human
processing) are much easier to understand, debug and proof. Text-based
tools can be built in a fraction of the time required by similar
binary-based tools, can be tested without requiring special environments
(e.g. one can test an HTTP server by simply telnetting to it), and can be
debugged more easily. The only drawback of text-based formats is that they
may be verbose. </P>
<P>Of course, change information may become quite large after even just a
few editing operations on a file. For instance, a single global change may
make thousands of changes in a file, each of which has to be stored
singularly. This is a very appropriate place to apply compression
technology. It can reduce storage and transmission costs considerably. But,
while the temptation to create a binary format may be strong, probably the
best way to compress change information is simply to use compression
algorithms on the set of changes. Furthermore, HTTP 1.1 provides a standard
way to do this already. Compression should be an additional, optional step
in the processing of versioning information. There are several solutions,
from ICCPC to MIME's Content-Transfer-Encoding to plain and simple zip
files, that all allow consistent space savings without mixing concerns.
Once space-saving for storage and transmission is dealt with independently
from the issue of describing versioning information, then we believe there
are no more good reasons not to choose a text-based format.</P>
<P>We believe that XML is the best bet for text-based formats for the
future (not just a fashionble one), and that choosing an XML-based data
format for describing changes in documents is a good candidate for a
solution.</P>
<H2>5. Hard-wiring policy</H2>
<P>It is hard to design things so that systems with very different
architectural and design criteria can interoperate, but it is particularly
important for versioning, despite the fact that it is also particularly
hard for versioning. There are so many different applications and needs
that any particular behavior or policy may block an effective solution for
some class of applications. The need to write simple-minded servers and
clients has to be respected, but it is important not to hardwire specific
behaviors (e.g., locking, check-out/check-in sequences, branching
operations, etc.) that would prevent advanced systems from even
existing.</P>
<P>There are two kinds of strategy to ensure this: (1) implicit fallback
rules for client and server behavior when they prefer differing models; or
(2) explicit feature testing operations, so that clients and servers can
match capabilities before making requests. </P>
<H2>6. Confusing bytes and characters </H2>
<P>If we use XML as a basis for a change description language, as we would
suggest, then extra care is required to handle the versioning of different
data formats. XML is defined in terms of characters (using the character
set defined by Unicode and ISO). This means that XML documents can be
transcoded to totally different byte-streams and still convey the same
information. This also means that the kind of internal format used in most
diff languages will cause problems for binary data.</P>
<P>In particular, it's not possible to apply the trick common in many ASCII
formats of just using a special byte escape sequence, and then ensuring
that applications process all byte equally. When an XML document is
represented in UTF-16 or another 16-bit encoding, not all sequences of
bytes are legal, and even if they were, the escaping rules for octet
sequences would become unworkably complex. This could be a fatal blow to
the use of XML syntax, except that the benefits of widely available parsing
software, familiarity, and so forth would be lost. </P>
<P>We believe that the best approach is to keep the XML philosophy and
possibly even XML tools (reusing existing parsers and taking advantage of
current XML popularity) and use a Multipart MIME type to separately package
change information (in XML) and the data (in an application/binary part).
This allows great freedom in managing changes to any kind of text-based or
binary. The key thing is not to assume that it's easy to pack arbitrary
bytes directly into XML documents. It's not practical, and it also violates
the intent of the specification by making the correctness of the document
dependent on a particular character encoding.</P>
<H2>7. Not providing a computable evolution of addresses</H2>
<P>An important application of versioning systems it to be able to
determine the position, content and identity of all subparts of a resource
in all its versions in which they exist in some form. Ideally it should be
possible to retrieve and identify any single character of a document in all
the versions in which it existed. </P>
<P>There are many applications for this information:  Perhaps the most
important is that it enables persistence and update of externally stored
links (from other documents or in XML Linking-style independent links).
External link bases can use address propagation to determine the identity
of link endpoints in the current version of a document, even if it has
changed. Transclusions can automatically update themselves in spite of the
changes occurred in both the source and the host documents (and reveal the
fact and form of the change at a later date, on user request). Dynamic
changes can be applied by knowledgeable applications even if disconnected
editing operations changed data outside of their control (e.g., standing
commands such as &quot;sort paragraph&quot; or &quot;globally change 'x' to
'y'&quot; could still be executed even if the underlying document has
changed).</P>
<P>All these situations share the need to determine the &quot;address&quot;
of one or more &quot;relevant object&quot; in any affected version. Objects
(e.g. characters, words, elements, subparts) may be identified by names,
structural relations or offsets relative to fixed, well-known parts. We
consider these all as &quot;addresses&quot; for that object. We are not
advocating that the group determines the semantics and behaviors of all
dynamic operations potentially affecting the content of a document. But
sufficiently fine-grained diff formats allow knowledgeable applications to
compute the current address of objects based on the history of changes
these objects have been subjected to. Therefore we urge the group to
consider this or any other method that would allow either client-side or
server-side applications to be able to determine the history and evolution
of any subpart of the resources they are interested in. Certainly, the
final result should not prevent the use of such fine-grained information
within the framework.</P>
<H2>Conclusions: Ignoring VTML </H2>
<P>We are not brainwashed advocates for VTML (in any of its versions). On
the other hand, VTML has addressed all the problems here except for #6 (and
#6 is easy to deal with). We urge the group to look at our solutions; we
believe that VTML may give some insight into ways of dealing with the many
pitfalls that lie in this area. </P>
<P>The suggestions contained so far in the document clearly point to a
specific class of solutions that we believe embody the best possible
approach for providing versioning support on the Web: versioning
information is provided in the form of a delta package containing finely
grained differences from one version to another, stored as XML elements
pointing to the relevant separate data using a Multipart MIME object. </P>
<P>VTML lies in this class of solutions, but it by no means comprises the
whole class. On the other hand, if we also ask for a minimal set of change
operations, and ask for the set of change attributes to be an open set,
then the differences between VTML and any proposed alternative solution
becomes negligible.</P>

--============_-1315746737==_============
Content-Type: text/plain; charset="us-ascii"

Fabio Vitali                            Tiger got to hunt, bird got to fly,
Dept of Computer Science         Man got to sit and wonder "Why, why, why?"
Univ. of Bologna  ITALY               Tiger got to sleep, bird got to land,
e-mail: fabio@cs.unibo.it           Man got to tell himself "I understand".
                                                             Kurt Vonnegut

--============_-1315746737==_============--


From w3c-dist-auth-request@www10.w3.org  Thu May 28 14:28:55 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id OAA08854 for <w3c-dist-auth@www19.w3.org>; Thu, 28 May 1998 14:28:55 -0400 (EDT)
Received: from mail2-b.microsoft.com (mail2-b.microsoft.com [131.107.3.124]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id OAA17903 for <w3c-dist-auth@w3.org>; Thu, 28 May 1998 14:29:16 -0400 (EDT)
Received: by mail2-b.microsoft.com with Internet Mail Service (5.5.2166.0)
	id <LWHV4HKV>; Thu, 28 May 1998 11:30:56 -0700
Message-ID: <174A69422993D111A13C00805FFE51B4053C6F@sjc-msg-01.dns.microsoft.com>
>From: Marcus Jager <mjager@microsoft.com>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Thu, 28 May 1998 11:30:53 -0700
X-Mailer: Internet Mail Service (5.5.2166.0)
Subject: RE: The 7 Deadly Sins of Versioning

Hi,

Excuse me for de-lurking and asking a silly question.

Is it necessary to handle versioning differently from language alternates?

To put it another way, can we unify the problem to how we handle alternate
resources for particular resource. Thus leaving the problem of
interpretation of what the alternates mean and operating on them to the
clients outside of WebDAV.

So far WebDAV has avoided forcing any structure or format on the contents of
the resources that it accesses and stores. I think it would be dangerous to
give this up.

Marcus.


From w3c-dist-auth-request@www10.w3.org  Thu May 28 17:39:16 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id RAA10932 for <w3c-dist-auth@www19.w3.org>; Thu, 28 May 1998 17:39:15 -0400 (EDT)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50]) by www10.w3.org (8.8.5/8.7.3) with SMTP id RAA19149 for <w3c-dist-auth@w3.org>; Thu, 28 May 1998 17:39:37 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa10810;
          28 May 98 13:29 PDT
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Thu, 28 May 1998 13:33:56 -0700
Message-ID: <003a01bd8a77$efa12a60$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Subject: FW: File attributes (was :File attributes (RE: The 7 Deadly Sins   of Versioning))

Caught by the spam filter.  This email address has been added to the accept
list for the mailing list.

- Jim

-----Original Message-----
>From: James Blaisdell [mailto:webdav@rapidlogic.com]
Sent: Thursday, May 28, 1998 12:16 PM
To: WEBDAV WG
Subject: [Spam?] File attributes (was :File attributes (RE: The 7 Deadly
Sins of Versioning))


What you're asking would require a way to attach file attributes/properties
to a document.  One of the best things about WebDAV is that it make very
few assumptions about the server's underlying OS.  Inorder to keep track of
different properties for a document you would need something akin to a
resource fork.

There are some simple work-a-rounds:
Different directories could store different language versions of a document.
The html documents could contain a META tag that specifies the language.

What you are proposing is a much more elegant solution, however where would
one stop?  Certainly content language is not the only http header one may
wish to attach to a document, the protocol would have to have a way to
specify all of the header information for a specific document.  Opening a
whole new can a worms, and actually changing the way an HTTP server
operates.

j.

At 11:30 AM 5/28/98 -0700, Marcus Jager wrote:
>Hi,
>
>Excuse me for de-lurking and asking a silly question.
>
>Is it necessary to handle versioning differently from language alternates?
>
>To put it another way, can we unify the problem to how we handle alternate
>resources for particular resource. Thus leaving the problem of
>interpretation of what the alternates mean and operating on them to the
>clients outside of WebDAV.
>
>So far WebDAV has avoided forcing any structure or format on the contents
of
>the resources that it accesses and stores. I think it would be dangerous to
>give this up.
>
>Marcus.
>


From w3c-dist-auth-request@www10.w3.org  Thu May 28 18:41:19 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id SAA12019 for <w3c-dist-auth@www19.w3.org>; Thu, 28 May 1998 18:41:19 -0400 (EDT)
Received: from leporello.cs.unibo.it (leporello.cs.unibo.it [130.136.1.110]) by www10.w3.org (8.8.5/8.7.3) with SMTP id SAA19609 for <w3c-dist-auth@w3.org>; Thu, 28 May 1998 18:41:40 -0400 (EDT)
Received: from [137.204.33.38] (tc38.pppnet.unibo.it) by leporello.cs.unibo.it (5.67b/96.09.13)
	id AA23340; Fri, 29 May 1998 00:37:46 +0200
X-Sender: fabio@leporello.cs.unibo.it
Message-Id: <v03007802b19392973cc2@[137.204.33.5]>
In-Reply-To: 
 <174A69422993D111A13C00805FFE51B4053C6F@sjc-msg-01.dns.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 29 May 1998 00:39:37 +0200
To: Marcus Jager <mjager@microsoft.com>
>From: Fabio Vitali <fabio@CS.UniBO.IT>
Cc: WEBDAV WG <w3c-dist-auth@w3.org>
Subject: RE: The 7 Deadly Sins of Versioning

At 20:30 +0200 28-05-1998, Marcus Jager wrote:

>Is it necessary to handle versioning differently from language alternates?
>To put it another way, can we unify the problem to how we handle alternate
>resources for particular resource. Thus leaving the problem of
>interpretation of what the alternates mean and operating on them to the
>clients outside of WebDAV.

Marcus, thanks for de-lurking: I believe this question would have come out
sooner or later, and it's better to have it right at the start letting us
discuss it before everything else.

So: can we label versions as just another kind of alternate resources, and
forget about it? IMHO: Sure we can. This would simplify the work of the
group a big deal.

On the other hand, it would constitute a major occasion lost to discuss and
provide for the interoperability of different implementations of versioning
systems. Furthermore, it would constitute a substantial betrayal of the V
part of the WEBDAV acronym.

Versions differ from language alternates at least for one major issue: they
are machine-processable. And usually machine-generated. This means that
with versions it is possible to provide more sophisticated services than
simply prompting the user: "I have 23 alternatives of this resources. Here
is the list. Which one do you want?" Thus I believe that providing a way
for these services to interact across implementations is extremely
important and well within the scope of the WEBDAV charter.

>So far WebDAV has avoided forcing any structure or format on the contents of
>the resources that it accesses and stores. I think it would be dangerous to
>give this up.

Indeed. Especially if the structures and formats eventually come out
limited in scope and flexibility by implementation haste, good-enough
attitude and lack of temporal perspective.

My personal dream is that WEBDAV identifies the overall and long-term
requirements for such structures or formats, and then fork a sub-group to
provide a first generation one that can be, if necessary, good enough and
done in haste, but also one that can be easily grown out of when the need
comes, without at the same time requiring the whole V part of the WEBDAV
standard to be re-discussed.

Fabio



From w3c-dist-auth-request@www10.w3.org  Thu May 28 19:11:18 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id TAA12723 for <w3c-dist-auth@www19.w3.org>; Thu, 28 May 1998 19:11:18 -0400 (EDT)
Received: from alicia.nttlabs.com (alicia.nttlabs.com [204.162.36.12]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id TAA19791 for <w3c-dist-auth@w3.org>; Thu, 28 May 1998 19:11:40 -0400 (EDT)
Received: from nttlabs.com by alicia.nttlabs.com (8.8.5/3.5W(96/10/22))
	id QAA02515; Thu, 28 May 1998 16:11:33 -0700 (PDT)
Message-ID: <356DEE7A.967D85CD@nttlabs.com>
Date: Thu, 28 May 1998 16:08:42 -0700
>From: Kenji Takahashi <kt@nttlabs.com>
Organization: NTT Multimedia Communications Labs
X-Mailer: Mozilla 4.02 [en] (Win95; I)
MIME-Version: 1.0
To: Fabio Vitali <fabio@CS.UniBO.IT>
CC: Marcus Jager <mjager@microsoft.com>, WEBDAV WG <w3c-dist-auth@w3.org>
References: <v03007802b19392973cc2@[137.204.33.5]>
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Subject: Re: The 7 Deadly Sins of Versioning

> Versions differ from language alternates at least for one major issue: they
> are machine-processable. And usually machine-generated. This means that
> with versions it is possible to provide more sophisticated services than
> simply prompting the user: "I have 23 alternatives of this resources. Here
> is the list. Which one do you want?" Thus I believe that providing a way
> for these services to interact across implementations is extremely
> important and well within the scope of the WEBDAV charter.

Another difference is that versions are related to each other (usually)
in semi-ordered manner (or tree structure).  I'm not sure what "language 
alternatives" but it sounds like to be able to represent only
relationships
between one resource and its variants.

Regards,

Kenji
-- 
Kenji Takahashi, Ph.D.
NTT Multimedia Communications Laboratories
250 Cambridge Avenue, Suite 205, Palo Alto, CA 94306 USA
e-mail: kt@nttlabs.com  URL: http://www.nttlabs.com/~kt
Phone: 650 833 3604  Fax: 650 833 3633


From w3c-dist-auth-request@www10.w3.org  Thu May 28 19:14:27 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id TAA12778 for <w3c-dist-auth@www19.w3.org>; Thu, 28 May 1998 19:14:27 -0400 (EDT)
Received: from mail1-b.microsoft.com (mail1-b.microsoft.com [131.107.3.125]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id TAA19804 for <w3c-dist-auth@w3.org>; Thu, 28 May 1998 19:14:49 -0400 (EDT)
Received: by INET-IMC-01 with Internet Mail Service (5.5.2328.0)
	id <LWHWL2VH>; Thu, 28 May 1998 16:16:31 -0700
Message-ID: <174A69422993D111A13C00805FFE51B4053C71@sjc-msg-01.dns.microsoft.com>
>From: Marcus Jager <mjager@microsoft.com>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Thu, 28 May 1998 16:16:25 -0700
X-Mailer: Internet Mail Service (5.5.2328.0)
Subject: Version format (Was: The 7 Deadly Sins of Versioning)

Actually on this subject I would go the other way.

WebDAV should actively avoid all content issues. WebDAV defines the protocol
for communicating version information and operations on them, not the
storage format.

Marcus.

> -----Original Message-----
> From:	Fabio Vitali [SMTP:fabio@CS.UniBO.IT]
> Sent:	Thursday, May 28, 1998 15:40
> To:	Marcus Jager
> Cc:	WEBDAV WG
> Subject:	RE: The 7 Deadly Sins of Versioning
> 
	[delete]

> My personal dream is that WEBDAV identifies the overall and long-term
> requirements for such structures or formats, and then fork a sub-group to
> provide a first generation one that can be, if necessary, good enough and
> done in haste, but also one that can be easily grown out of when the need
> comes, without at the same time requiring the whole V part of the WEBDAV
> standard to be re-discussed.
> 
> Fabio
> 


From w3c-dist-auth-request@www10.w3.org  Thu May 28 19:15:07 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id TAA12882 for <w3c-dist-auth@www19.w3.org>; Thu, 28 May 1998 19:15:07 -0400 (EDT)
Received: from mail1-b.microsoft.com (mail1-b.microsoft.com [131.107.3.125]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id TAA19812 for <w3c-dist-auth@w3.org>; Thu, 28 May 1998 19:15:29 -0400 (EDT)
Received: by INET-IMC-01 with Internet Mail Service (5.5.2328.0)
	id <LWHWL2XC>; Thu, 28 May 1998 16:17:11 -0700
Message-ID: <174A69422993D111A13C00805FFE51B4053C72@sjc-msg-01.dns.microsoft.com>
>From: Marcus Jager <mjager@microsoft.com>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Thu, 28 May 1998 16:17:11 -0700
X-Mailer: Internet Mail Service (5.5.2328.0)
Subject: Re: File attributes (RE: The 7 Deadly Sins of Versioning)

The WebDAV requirements punted on alternates (variants). It just said that
they are needed and gave some vague ideas about what was needed. However the
versioning requirements asks for the server to have very strong notions
about the versions and their relationships.

I am asking if we can find a way of merging the variants with versioning so
that we get a solution to both.

Marcus.

> -----Original Message-----
> From: James Blaisdell [mailto:webdav@rapidlogic.com]
> Sent: Thursday, May 28, 1998 12:16 PM
> To: WEBDAV WG
> Subject: [Spam?] File attributes (was :File attributes (RE: The 7 Deadly
> Sins of Versioning))
> 
> 
> What you're asking would require a way to attach file
> attributes/properties
> to a document.  One of the best things about WebDAV is that it make very
> few assumptions about the server's underlying OS.  Inorder to keep track
> of
> different properties for a document you would need something akin to a
> resource fork.
> 
> There are some simple work-a-rounds:
> Different directories could store different language versions of a
> document.
> The html documents could contain a META tag that specifies the language.
> 
> What you are proposing is a much more elegant solution, however where
> would
> one stop?  Certainly content language is not the only http header one may
> wish to attach to a document, the protocol would have to have a way to
> specify all of the header information for a specific document.  Opening a
> whole new can a worms, and actually changing the way an HTTP server
> operates.
> 
> j.
> 
> At 11:30 AM 5/28/98 -0700, Marcus Jager wrote:
> >Hi,
> >
> >Excuse me for de-lurking and asking a silly question.
> >
> >Is it necessary to handle versioning differently from language
> alternates?
> >
> >To put it another way, can we unify the problem to how we handle
> alternate
> >resources for particular resource. Thus leaving the problem of
> >interpretation of what the alternates mean and operating on them to the
> >clients outside of WebDAV.
> >
> >So far WebDAV has avoided forcing any structure or format on the contents
> of
> >the resources that it accesses and stores. I think it would be dangerous
> to
> >give this up.
> >
> >Marcus.
> >


From w3c-dist-auth-request@www10.w3.org  Thu May 28 20:24:32 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id UAA13967 for <w3c-dist-auth@www19.w3.org>; Thu, 28 May 1998 20:24:31 -0400 (EDT)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50]) by www10.w3.org (8.8.5/8.7.3) with SMTP id UAA20070 for <w3c-dist-auth@w3.org>; Thu, 28 May 1998 20:24:53 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa05674;
          28 May 98 17:11 PDT
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Thu, 28 May 1998 17:15:11 -0700
Message-ID: <005e01bd8a96$d8996160$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Subject: FW: The 7 Deadly Sins of Versioning

Sent to the w3c-dist-auth-request address (which is routed to my personal
inbox) by accident.

- Jim

-----Original Message-----
>From: Jim Amsden [mailto:jamsden@us.ibm.com]
Sent: Thursday, May 28, 1998 4:32 PM
To: w3c-dist-auth-request@w3.org
Subject: RE: The 7 Deadly Sins of Versioning


>Is it necessary to handle versioning differently from language alternates?
>To put it another way, can we unify the problem to how we handle alternate
>resources for particular resource. Thus leaving the problem of
>interpretation of what the alternates mean and operating on them to the
>clients outside of WebDAV.

No, it's probably not necessary, but might still be a good idea. The notion
of
a version could indicate that something changed in the in the meaning of the
resource, its semantics. Variants might be different views of the same
meaning
for different audiences. With XML, the content and views are separate
allowing
each to change independently, either with versions of variants.


From w3c-dist-auth-request@www10.w3.org  Thu May 28 21:06:11 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id VAA14238 for <w3c-dist-auth@www19.w3.org>; Thu, 28 May 1998 21:06:11 -0400 (EDT)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50]) by www10.w3.org (8.8.5/8.7.3) with SMTP id VAA20186 for <w3c-dist-auth@w3.org>; Thu, 28 May 1998 21:06:33 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa09445;
          28 May 98 17:48 PDT
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Thu, 28 May 1998 17:52:44 -0700
Message-ID: <006001bd8a9c$171008e0$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <174A69422993D111A13C00805FFE51B4053C72@sjc-msg-01.dns.microsoft.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Subject: Common Graph for Versions and Variants (was: RE: File attributes (RE: The 7 Deadly Sins of Versioning))

Marcus Jager writes:
> I am asking if we can find a way of merging the variants with
> versioning so that we get a solution to both.

I firmly believe that an elegant solution exists which handles both variants
and versions using the same operations.

When there is a sequence of versions of a resource, these versions are
related by a "is-revision-of" relationship.  Similarly, variants of a
resource are related by a "is-variant-of" relationship.  Both relationships
can easily co-exist in the same version-and-variant history graph. The nodes
of the graph are (pointers to) resources.  The arcs are either
"is-revision-of" or "is-variant-of" relationships.

This accomodates both versions and variants of a resource in the same graph
structure.

Fabio Vitali writes:
> Versions differ from language alternates at least for one major issue:
they
> are machine-processable. And usually machine-generated. This means that
> with versions it is possible to provide more sophisticated services than
> simply prompting the user: "I have 23 alternatives of this resources. Here
> is the list. Which one do you want?"

HTTP defines a mechanism for content negotiation using the "Accept" headers,
and hence there is already a well-defined mechanism for requesting a
particular variant if the user has established the preferences of their
user-agent.

Also, many variants are machine-generated: different renderings of the same
document (e.g., PDF, Postscript, HTML) are often machine-generated, although
the term "rendering" is often used instead of "variant". But this is moot.

In what way do you feel machine-processing of versions is important for our
protocol design?

>>So far WebDAV has avoided forcing any structure or format on the contents
of
>>the resources that it accesses and stores. I think it would be dangerous
to
>>give this up.
>
>Indeed. Especially if the structures and formats eventually come out
>limited in scope and flexibility by implementation haste, good-enough
>attitude and lack of temporal perspective.

A protocol which limits remote authoring (and versioning) to a small subset
of media types would be short-sighted indeed.  There are many media types in
existence, and more are likely to be defined in the future.  The only
constant in this area is change.  A remote authoring and versioning solution
which accomodates all media types provides the maximum flexibility for
accomodating this change.

- Jim


From w3c-dist-auth-request@www10.w3.org  Thu May 28 22:01:47 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id WAA14557 for <w3c-dist-auth@www19.w3.org>; Thu, 28 May 1998 22:01:47 -0400 (EDT)
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by www10.w3.org (8.8.5/8.7.3) with SMTP id WAA20413 for <w3c-dist-auth@w3.org>; Thu, 28 May 1998 22:02:09 -0400 (EDT)
Received: from mailback.parc.xerox.com ([13.1.101.39]) by alpha.xerox.com with SMTP id <52293(3)>; Thu, 28 May 1998 19:02:03 PDT
Received: from moriarty ([13.1.100.88]) by mailback.parc.xerox.com with SMTP id <169477>; Thu, 28 May 1998 19:01:55 PDT
Message-Id: <3.0.3.32.19980528184227.00989d80@mailback.parc.xerox.com>
X-Sender: jdavis@mailback.parc.xerox.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Thu, 28 May 1998 18:42:27 PDT
To: "'WEBDAV WG'" <w3c-dist-auth@w3.org>
>From: Jim Davis <jdavis@parc.xerox.com>
In-Reply-To: <01BD6EFA.6542D500.ejw@ics.uci.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: Lodging for WebDAV Interim Meeting, June 15-17

At 08:57 PM 4/23/98 PDT, Jim Whitehead wrote:
>An interim meeting of the WebDAV Working Group will be held June 15-17, 
>1998, on the Microsoft Campus in Redmond, Washington.

If you have not already made your arrangements for lodging for the WebDAV
meeting here's some information I gathered that may be helpful.  
The listing of hotels in the Microsoft page seems accurate except that some
hotels have changed their names.  The hotel prices range from $99 to $225 a
night.

I personally prefer to stay at bed and breakfast inns.  They are often more
comfortable, less anonymous (which can be good or bad) usually have great
breakfasts, and are often cheaper too.  Here's the phones of six in the
area.  None are known to me.  (Each B&B is different, whereas hotels are
consistent, but I have never been disappointed.)  For what it's worth, I
know the Cascade B&B is sold out for the nights of June 15 and 16.  I also
know it's cheaper ($75/night) than the cheapest hotel I called (Best
Western, at $99) and even cheaper when you consider it includes breakfast.

I hope this information is useful but I provide it with no warrantee
expressed or implied.  it would be great if Microsoft could add it to their
Web page.

Bed and Breakfast Inns in the Redmond area

Bellevue Bed & Breakfast      206-453-1048
 830  100th Ave    Bellevue

Bridle Trails Bed & Breakfast         206-861-0700
 Bellevue

Petersen Bed & Breakfast     206-453-143
 10228 SE 8th St
 Bellevue

Cottage Creek	425-881-5606
  Redmond

Shumway Mansion Bed & Breakfast    206-823-2303
   11410-99th Pl NE Kirkland

A Cascade View Bed & Breakfast      425-883-7078
 13425 NE 27th St Bellevue

HOTELS
                                                                          
Doubletree (formerly Red Lion Inn) (425) 455-1300
300 112th SE
Bellevue

Hyatt Regency (425) 462-2626   $225/night
NE 8th and Bellevue Way
Bellevue

Hilton Bellevue (425) 455-3330 $184/night
100 112th NE
Bellevue

La Quinta (425) 828-6585
10530 NE Northup Way
Kirkland

Best Western (formerly Holiday Inn) of Bellevue $99/night
(425) 462-6600 
11211 Main Street
Bellevue



From w3c-dist-auth-request@www10.w3.org  Fri May 29 04:19:41 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id EAA17877 for <w3c-dist-auth@www19.w3.org>; Fri, 29 May 1998 04:19:41 -0400 (EDT)
Received: from gammon.opentext.ch (gammon.opentext.ch [195.48.77.115]) by www10.w3.org (8.8.5/8.7.3) with SMTP id EAA21852 for <w3c-dist-auth@w3.org>; Fri, 29 May 1998 04:20:01 -0400 (EDT)
Received: from cassius (cassius.opentext.ch [195.48.77.23]) by gammon.opentext.ch (8.6.12/8.6.9) with SMTP id KAA10576; Fri, 29 May 1998 10:23:17 +0100
Received: by localhost with Microsoft MAPI; Fri, 29 May 1998 10:20:29 +0200
Message-ID: <01BD8AEB.67B932E0.dbarrell@opentext.ch>
>From: Dylan Barrell <dbarrell@opentext.ch>
Reply-To: "dbarrell@opentext.ch" <dbarrell@opentext.ch>
To: "'Marcus Jager'" <mjager@microsoft.com>,
        WEBDAV WG
	 <w3c-dist-auth@w3.org>
Date: Fri, 29 May 1998 10:20:28 +0200
Organization: Open Text Corporation
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: RE: The 7 Deadly Sins of Versioning

Yes it is necessary because each version may have different renditions (in format and/or language)

cheers
Dylan

-----Original Message-----
>From:	Marcus Jager [SMTP:mjager@microsoft.com]
Sent:	Donnerstag, 28. Mai 1998 20:31
To:	WEBDAV WG
Subject:	RE: The 7 Deadly Sins of Versioning

Hi,

Excuse me for de-lurking and asking a silly question.

Is it necessary to handle versioning differently from language alternates?

To put it another way, can we unify the problem to how we handle alternate
resources for particular resource. Thus leaving the problem of
interpretation of what the alternates mean and operating on them to the
clients outside of WebDAV.

So far WebDAV has avoided forcing any structure or format on the contents of
the resources that it accesses and stores. I think it would be dangerous to
give this up.

Marcus.


From w3c-dist-auth-request@www10.w3.org  Fri May 29 14:26:54 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id OAA23145 for <w3c-dist-auth@www19.w3.org>; Fri, 29 May 1998 14:26:53 -0400 (EDT)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50]) by www10.w3.org (8.8.5/8.7.3) with SMTP id OAA25290 for <w3c-dist-auth@w3.org>; Fri, 29 May 1998 14:27:15 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa25099;
          29 May 98 11:11 PDT
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Fri, 29 May 1998 11:15:37 -0700
Message-ID: <002b01bd8b2d$c7dd4c00$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <3.0.3.32.19980528184227.00989d80@mailback.parc.xerox.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Subject: RE: Lodging for WebDAV Interim Meeting, June 15-17

Jim,

Thank you for this information!  I've added it to the lodging information
page for the Redmond meeting, available off of:

http://www.ics.uci.edu/pub/ietf/webdav/redmond/

I believe that all phone numbers in Redmond, Bellevue, and Kirkland are now
425 area code, rather than 206 area code.

- Jim

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Davis
> Sent: Thursday, May 28, 1998 6:42 PM
> To: 'WEBDAV WG'
> Subject: Lodging for WebDAV Interim Meeting, June 15-17
>
>
> At 08:57 PM 4/23/98 PDT, Jim Whitehead wrote:
> >An interim meeting of the WebDAV Working Group will be held June 15-17,
> >1998, on the Microsoft Campus in Redmond, Washington.
>
> If you have not already made your arrangements for lodging for the WebDAV
> meeting here's some information I gathered that may be helpful.
> The listing of hotels in the Microsoft page seems accurate except
> that some
> hotels have changed their names.  The hotel prices range from $99
> to $225 a
> night.
>
> I personally prefer to stay at bed and breakfast inns.  They are
> often more
> comfortable, less anonymous (which can be good or bad) usually have great
> breakfasts, and are often cheaper too.  Here's the phones of six in the
> area.  None are known to me.  (Each B&B is different, whereas hotels are
> consistent, but I have never been disappointed.)  For what it's worth, I
> know the Cascade B&B is sold out for the nights of June 15 and 16.  I also
> know it's cheaper ($75/night) than the cheapest hotel I called (Best
> Western, at $99) and even cheaper when you consider it includes breakfast.
>
> I hope this information is useful but I provide it with no warrantee
> expressed or implied.  it would be great if Microsoft could add
> it to their
> Web page.
>
> Bed and Breakfast Inns in the Redmond area
>
> Bellevue Bed & Breakfast      206-453-1048
>  830  100th Ave    Bellevue
>
> Bridle Trails Bed & Breakfast         206-861-0700
>  Bellevue
>
> Petersen Bed & Breakfast     206-453-143
>  10228 SE 8th St
>  Bellevue
>
> Cottage Creek	425-881-5606
>   Redmond
>
> Shumway Mansion Bed & Breakfast    206-823-2303
>    11410-99th Pl NE Kirkland
>
> A Cascade View Bed & Breakfast      425-883-7078
>  13425 NE 27th St Bellevue
>
> HOTELS
>
> Doubletree (formerly Red Lion Inn) (425) 455-1300
> 300 112th SE
> Bellevue
>
> Hyatt Regency (425) 462-2626   $225/night
> NE 8th and Bellevue Way
> Bellevue
>
> Hilton Bellevue (425) 455-3330 $184/night
> 100 112th NE
> Bellevue
>
> La Quinta (425) 828-6585
> 10530 NE Northup Way
> Kirkland
>
> Best Western (formerly Holiday Inn) of Bellevue $99/night
> (425) 462-6600
> 11211 Main Street
> Bellevue
>
>
>


From w3c-dist-auth-request@www10.w3.org  Fri May 29 15:07:59 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id PAA23896 for <w3c-dist-auth@www19.w3.org>; Fri, 29 May 1998 15:07:59 -0400 (EDT)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50]) by www10.w3.org (8.8.5/8.7.3) with SMTP id PAA25569 for <w3c-dist-auth@w3.org>; Fri, 29 May 1998 15:08:21 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa00698;
          29 May 98 12:05 PDT
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Fri, 29 May 1998 12:09:10 -0700
Message-ID: <003101bd8b35$427da520$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Subject: Advanced Collections Protocol I-D available

Judy Slein has just submitted an Internet Draft titled, "WebDAV Advanced
Collections Protocol", <draft-ietf-webdav-collection-protocol-00>.  This
draft specifies operations for creating and manipulating referential members
of a collection and ordered collections.

This Internet Draft will appear in the I-D directory in the next few days.
In the meanwhile, it is available off of the WebDAV home page:

http://www.ics.uci.edu/pub/ietf/webdav/

It is also directly accessible at:

http://www.ics.uci.edu/pub/ietf/webdav/collection/draft-ietf-webdav-collecti
on-protocol-00.txt

Thank you, Judy, for drafting this initial advanced collections protocol
document.  This protocol will be discussed at the interim meeting in June.

- Jim


From w3c-dist-auth-request@www10.w3.org  Fri May 29 16:36:59 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id QAA24771 for <w3c-dist-auth@www19.w3.org>; Fri, 29 May 1998 16:36:59 -0400 (EDT)
Received: from dynamicdiagrams.com (iris.dynamicdiagrams.com [205.181.196.2]) by www10.w3.org (8.8.5/8.7.3) with SMTP id QAA26128 for <w3c-dist-auth@w3.org>; Fri, 29 May 1998 16:37:20 -0400 (EDT)
X-Authentication-Warning: www10.w3.org: Host iris.dynamicdiagrams.com [205.181.196.2] claimed to be dynamicdiagrams.com
Received: from [205.181.196.4] by dynamicdiagrams.com via ESMTP (940816.SGI.8.6.9/940406.SGI.AUTO)
	for <w3c-dist-auth@w3.org> id QAA05227; Fri, 29 May 1998 16:25:51 -0700
X-Sender: david@iris.dynamicdiagrams.com
Message-Id: <v03007802b194c452a376@[205.181.196.4]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 29 May 1998 16:25:37 -0400
To: w3c-dist-auth@w3.org
>From: "David G. Durand" <dgd@cs.bu.edu>
Subject: Versioning, responses to comments on our document

As Kenji noted, there are a number of predictable relationships between
versions. In particular there are contraints (version graphs can be no more
unrestricted than DAGs no matter how flexible the system).

Like variants (e.g by language, encoding format, etc.) versions relate many
particular forms (specialized URLs) of a single document (generic URL) that
represents a piece of intellectual content.

However, versions are an independent dimension from e.g. langauge variants
or format variants.

Scenario: Many language variants of one document. Each language variant has
a separate revision tree, since typos must be corrected by hand, and thus
the revision tree of the variants differs from that of the whole document.
However, there is a meaningful sense to "most recent version of revision
1.2 of the document", it just happens to be "mydoc, version 1.2, Spanish
rev 1.3"

Scenario: Many data formats fro one XML document. One single version tree
refers to the history of the XML document. Variants in delivery formats are
available in PDF, HTML, Postscript, Nroff output, etc. These variants are
accessible by content negotiation only, and do NOT have separate URLs.

The point is that version information is a relation, but that it is
orthogonal to other dimensions.

I think the arguments against making versioning "just another random
variation" relate to the following points:

1. Despite a great deal of variety, there are lots of common meaningful
semantics for versions as opposed to other forms of variation.

2. Editing applications must have access to at least some of this
information to offer meaningful editing, locking, browsing, and
user-interface features.

3. There is great potential value in being able to transmit, query, and
update the differences between _versions_ of documents, whereas there is no
such value in doing these operations on arbitrary axes of variation such as
target audience, encoding type, or natural language.

4. While some special media types (like text/* and application/XML) may
pragmatically deserve special acomoddation given their place in many
editorial processes, _any_ data type can accomodate operations like those
in point 3. since it can somehow be reduced to a sequence of octets, which
can then be compared, etc.

5. link endpoint propogation between versions of resources linked via
independent separately stored links requires access to low-level difference
information as in 3. These features should be acomodated by DAV, even
though they are unliekly to be required.

Whether or not typed relationships are used to represent versions for DAV
queries doesn't change the fact that DAV operations will affect these
version relations and that editors and servers will need special knowledge
about these relations (as they may not for language for media variants).

The issues of comparison and link-endpoint progation can be quite
significant. At least some editing methods (Such as the one I am doing my
thesis research on, and the one implemented by the CVS version system)
would be able to take significant advantage of the ability to transmit
changes rather than whole states of changing resources.

Sp without taking a position on whether the current DAV spec (which I'v not
read) provides suffcient representational muscle for versions, I do believe
that special semantics and server/client information exchanges are required
to handle versioning properly.

As I understand the goals of DAV, we are trying to define a lingua franca
to support interoperable versioning, not just an infrastructure that could
be applied to create a support mechanism (but that can't guarantee
interoperability, because it neither provides versioning operations, nor
specifies versioning related behavior, nor allows negotiation of
versioning-related policy).

In other words, the _semantics_ of versioning is squarely in this group's
mission.

   -- David

_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://www.dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________



From w3c-dist-auth-request@www10.w3.org  Fri May 29 19:16:59 1998
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id TAA27450 for <w3c-dist-auth@www19.w3.org>; Fri, 29 May 1998 19:16:59 -0400 (EDT)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50]) by www10.w3.org (8.8.5/8.7.3) with SMTP id TAA27061 for <w3c-dist-auth@w3.org>; Fri, 29 May 1998 19:17:21 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa25657;
          29 May 98 16:09 PDT
Reply-To: ejw@ics.uci.edu
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
To: WEBDAV WG <w3c-dist-auth@w3.org>
Date: Fri, 29 May 1998 16:13:09 -0700
Message-ID: <004001bd8b57$587acb60$d115c380@galileo.ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Subject: FW: GET on a referential member

Caught by the spam filter (not sure why, I'm looking into it).

- Jim

-----Original Message-----
>From: John Stracke [mailto:francis@netscape.com] 
Sent: Friday, May 29, 1998 3:39 PM
To: WebDAV WG
Subject: [Spam?] GET on a referential member


In the WebDAV Collection Protocol Draft just posted, at the end of
section 3.5, I read:

     A GET on a referential member of a collection returns its own
     content, which is the URI of its target resource, not the
     content of its target resource.

I'm not sure this is the optimal behavior, because it a non-DAV-aware
client, such as a browser, won't know what to do with the URI as a
content item, which would limit the usefulness of referential members.
Can we perhaps put it into the Location: header instead?

--
/======================================================================\
|John (Francis) Stracke    |My opinions are my own. | S/MIME supported |
|Software Retrophrenologist|===========================================|
|Netscape Comm. Corp.      |"You're nothing but a pack of ringleaders!"|
|francis@netscape.com      |  -- _Wyrd Sisters_, Terry Pratchett       |
\======================================================================/
New area code for work number: 650




