From w3c-dist-auth-request@www10.w3.org  Sun Jun  1 15:01:56 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id PAA01279 for <w3c-dist-auth@www19.w3.org>; Sun, 1 Jun 1997 15:01:56 -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 PAA01748 for <w3c-dist-auth@w3.org>; Sun, 1 Jun 1997 15:01:55 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa12649;
          1 Jun 97 11:59 PDT
X-Sender: ejw@paris.ics.uci.edu
Message-Id: <afb76d59000210044c13@[128.195.21.209]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 1 Jun 1997 12:04:58 -0700
To: w3c-dist-auth@w3.org
>From: Jim Whitehead <ejw@ics.uci.edu>
Subject: Re: locks and trust (Re: Rejected Requirements)
Cc: ejw@ics.uci.edu
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring


When considering shared locks, there are really two trust sets in
operation.  The first trust set is created by access permissions.
Principals who are trusted have permission to write the resource, those who
are not, don't.  Among those who have access permission to write the
resource, the set of principals who have taken out an shared lock also must
trust each other, creating a (probably) smaller trust set within the access
permission write set.

Starting with every possible principal on the Internet, in most situations
the vast majority of these principals will not have write access to a given
resource.  Of the small number who do have write access, some principals
may decide to guarantee their edits are free from overwrite conflicts by
using exclusive write locks in conjunction with a precondition header
(If-State-Match, perhaps?) that checks for existence of the lock prior to
writing the resource. Others may decide they trust their collaborators (the
potential set of collaborators being the set of principals who have write
permission) and use a shared lock, which informs their collaborators that a
principal is potentially working on the resource.

It is important to remember that the WebDAV extensions to HTTP do not need
to provide all of the communications paths necessary for principals to
coordinate their activities.  When using shared locks, principals may use
any of the following forms of communication to coordinate their work:
face-to-face interaction, written notes (post-it notes on the screen),
telephone conversation, email, ...  The intent of a shared lock is to let
collaborators know who else is potentially working on a resource, so that
one of these communications paths can be used to negotiate writing to the
resource.

So, why not just use exclusive write locks all the time?  Experience from
initial Web distributed authoring systems has indicated that exclusive
write locks are often too rigid.  Researchers working on the BSCW system
initially started with exclusive locks, but relaxed them in later versions.


An exclusive write lock is used to enforce a particular editing process:
take out exclusive write lock, read resource, perform edits, write
resource, release lock.  What happens if the lock isn't released?  While
the time-out mechanism provides one solution, if you need to force the
release of a lock immediately, it doesn't help much.  Granted, an
administrator can release the lock for you, but this could become a
significant burden for large sites. Plus, what if the administrator can't
be reached immediately?

Despite their potential problems, exclusive write locks are extremely
useful, since often a guarantee of freedom from overwrite conflicts is
exactly what is needed.  The solution: provide exclusive write locks, but
also provide a less strict mechanism in the form of shared locks which can
be used by a set of people who trust each other, and have access to a
communications channel external to WebDAV which can be used to negotiate
writing to the resource.

- Jim




From w3c-dist-auth-request@www10.w3.org  Mon Jun  2 08:31:38 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id IAA10654 for <w3c-dist-auth@www19.w3.org>; Mon, 2 Jun 1997 08:31:38 -0400 (EDT)
Received: from go.opentext.ch (go.opentext.ch [195.48.77.130]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id IAA03807 for <w3c-dist-auth@w3.org>; Mon, 2 Jun 1997 08:31:34 -0400 (EDT)
Received: (from root@localhost) by go.opentext.ch (8.7.3/GO-3a) id OAA27196; Mon, 2 Jun 1997 14:18:36 +0200 (MET DST)
Received: from gammon.opentext.ch(195.48.77.115) by go.opentext.ch via smap (V1.3)
	id sma027194; Mon Jun  2 14:18:33 1997
Received: from cassius.opentext.ch (cassius.opentext.ch [195.48.77.23]) by gammon.opentext.ch (8.6.12/8.6.9) with SMTP id OAA29369; Mon, 2 Jun 1997 14:34:33 +0100
Received: by cassius.opentext.ch with Microsoft Mail
	id <01BC6F61.34793200@cassius.opentext.ch>; Mon, 2 Jun 1997 14:28:14 +-200
Message-ID: <01BC6F61.34793200@cassius.opentext.ch>
>From: Dylan Barrell <dbarrell@opentext.ch>
To: "'Jim Whitehead'" <ejw@ics.uci.edu>,
        "w3c-dist-auth@w3.org"
	 <w3c-dist-auth@w3.org>
Subject: RE: locks and trust (Re: Rejected Requirements)
Date: Mon, 2 Jun 1997 14:28:12 +-200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

I would like to see the shared-lock be an optional portion of the WebDAV =
standard. I think the minimum requirement for locking is exclusive =
locking and this should be the minimum that WebDAV requires.

Our experience with Livelink has been that exclusive locks are good =
enough. All other access can be regulated by the permissions. I.e. a =
shared lock can be seen as the permission of a group of people to write =
to the resource. Add to this the ability to change the permissions and =
the ability for someone to lock the resource (another individually =
specifiable permission) and you have all the flexibility you need.

In conclusion I don't even see the need for shared locks.

Cheers
Dylan=20

----------
>From:  Jim Whitehead[SMTP:ejw@ics.uci.edu]
Sent:  Sonntag, 1. Juni 1997 21:05
To:  w3c-dist-auth@w3.org
Cc:  ejw@ics.uci.edu
Subject:  Re: locks and trust (Re: Rejected Requirements)


When considering shared locks, there are really two trust sets in
operation.  The first trust set is created by access permissions.
Principals who are trusted have permission to write the resource, those =
who
are not, don't.  Among those who have access permission to write the
resource, the set of principals who have taken out an shared lock also =
must
trust each other, creating a (probably) smaller trust set within the =
access
permission write set.

Starting with every possible principal on the Internet, in most =
situations
the vast majority of these principals will not have write access to a =
given
resource.  Of the small number who do have write access, some principals
may decide to guarantee their edits are free from overwrite conflicts by
using exclusive write locks in conjunction with a precondition header
(If-State-Match, perhaps?) that checks for existence of the lock prior =
to
writing the resource. Others may decide they trust their collaborators =
(the
potential set of collaborators being the set of principals who have =
write
permission) and use a shared lock, which informs their collaborators =
that a
principal is potentially working on the resource.

It is important to remember that the WebDAV extensions to HTTP do not =
need
to provide all of the communications paths necessary for principals to
coordinate their activities.  When using shared locks, principals may =
use
any of the following forms of communication to coordinate their work:
face-to-face interaction, written notes (post-it notes on the screen),
telephone conversation, email, ...  The intent of a shared lock is to =
let
collaborators know who else is potentially working on a resource, so =
that
one of these communications paths can be used to negotiate writing to =
the
resource.

So, why not just use exclusive write locks all the time?  Experience =
from
initial Web distributed authoring systems has indicated that exclusive
write locks are often too rigid.  Researchers working on the BSCW system
initially started with exclusive locks, but relaxed them in later =
versions.


An exclusive write lock is used to enforce a particular editing process:
take out exclusive write lock, read resource, perform edits, write
resource, release lock.  What happens if the lock isn't released?  While
the time-out mechanism provides one solution, if you need to force the
release of a lock immediately, it doesn't help much.  Granted, an
administrator can release the lock for you, but this could become a
significant burden for large sites. Plus, what if the administrator =
can't
be reached immediately?

Despite their potential problems, exclusive write locks are extremely
useful, since often a guarantee of freedom from overwrite conflicts is
exactly what is needed.  The solution: provide exclusive write locks, =
but
also provide a less strict mechanism in the form of shared locks which =
can
be used by a set of people who trust each other, and have access to a
communications channel external to WebDAV which can be used to negotiate
writing to the resource.

- Jim





From w3c-dist-auth-request@www10.w3.org  Mon Jun  2 10:37:55 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id KAA13131 for <w3c-dist-auth@www19.w3.org>; Mon, 2 Jun 1997 10:37:55 -0400 (EDT)
Received: from shell3.ba.best.com (shell3.ba.best.com [206.184.139.134]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id KAA04517 for <w3c-dist-auth@w3.org>; Mon, 2 Jun 1997 10:37:55 -0400 (EDT)
Received: from localhost (gjw@localhost) by shell3.ba.best.com (8.8.5/8.7.3) with SMTP id HAA27946; Mon, 2 Jun 1997 07:37:36 -0700 (PDT)
X-Authentication-Warning: shell3.ba.best.com: gjw owned process doing -bs
Date: Mon, 2 Jun 1997 07:37:35 -0700 (PDT)
>From: "Gregory J. Woodhouse" <gjw@wnetc.com>
Sender: gjw@best.com
Reply-To: "Gregory J. Woodhouse" <gjw@wnetc.com>
To: Dylan Barrell <dbarrell@opentext.ch>
cc: "'Jim Whitehead'" <ejw@ics.uci.edu>,
        "w3c-dist-auth@w3.org" <w3c-dist-auth@w3.org>
Subject: RE: locks and trust (Re: Rejected Requirements)
In-Reply-To: <01BC6F61.34793200@cassius.opentext.ch>
Message-ID: <Pine.BSF.3.96.970602070135.20553A-100000@shell3.ba.best.com>
X-Url: http://www.wnetc.com/
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

On Mon, 2 Jun 1997, Dylan Barrell wrote:

> I would like to see the shared-lock be an optional portion of the WebDAV
> standard. I think the minimum requirement for locking is exclusive
> locking and this should be the minimum that WebDAV requires. 
> 
> Our experience with Livelink has been that exclusive locks are good
> enough. All other access can be regulated by the permissions. I.e. a
> shared lock can be seen as the permission of a group of people to write
> to the resource. Add to this the ability to change the permissions and
> the ability for someone to lock the resource (another individually
> specifiable permission) and you have all the flexibility you need. 
> 
> In conclusion I don't even see the need for shared locks.
> 
> Cheers
> Dylan 
> 

I have a feeling we're talking past eachother here. In fact, I'm not at
all sure who I agree with and who I disagree with because I'm not clear on
who is using what terminology. It seems to me that locks can vary along
at least four orthogonal axes:

mandatory/advisory
exclusive/shared
read/write/both
privilege

To go back to the mail example, I sort my mail into multiple inboxes using
procmail and then access them with an IMAP client. Quite frequently, I see
mail arrive in a mailbox while I have it open. From my point of view, I
hear a beep and the display is updated. Internally, procmail locks my
mailbox just long enough to deliver the message and then releases the
lock. This is an example of a mandatory exclusive lock. Once the message
is delivered, I can continue with my work undisturbed. Now, let's suppose
I  start up a second instance of Pine. What will happen is that the second
process is already in use and warn me. In  addition, both instances of
Pine will be accessing the mailbox in read-only mode. In other wors the
first process had an exclusive advisory read/write lock that was
effectively revoked by the second process, replacing it with a shared
readonly lock. Now, mail can still continue to arrive, and will be allowed
to secure temporary exclusive locks while delivering mail without
disturbing th existing advisory lock. Another possible scenario is where I
telnet in, start up Pine, disconnect, and then telnet back in again. What
happens here is that I am warned that Pine is attempting to secdure a lock
on a mailbox which is already locked by process <whatever>. In this case,
that process is no longer active, so my process can succesfully revoke the
orphaned lock. This raises an interesting point: though these locks are
"advisory" (and technically they all are unless the MDA is configured to
use flock() to lock the mailbox), it is not up to the user (or user
process) to decide when to modify or revoke a lock. In essence, these
locks are only in that they can be revoked or modified by a process with
sufficient privilege (by mail subsystem itself). (Note that I'm not
talking about privilege in the UNIX sense of the term.)


---
Gregory Woodhouse
gjw@wnetc.com    /    http://www.wnetc.com/home.html
If you're going to reinvent the wheel, at least try to come
up with a better one.



From w3c-dist-auth-request@www10.w3.org  Mon Jun  2 11:24:20 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id LAA13752 for <w3c-dist-auth@www19.w3.org>; Mon, 2 Jun 1997 11:24:20 -0400 (EDT)
Received: from go.opentext.ch (go.opentext.ch [195.48.77.130]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id LAA04888 for <w3c-dist-auth@w3.org>; Mon, 2 Jun 1997 11:24:17 -0400 (EDT)
Received: (from root@localhost) by go.opentext.ch (8.7.3/GO-3a) id RAA00265; Mon, 2 Jun 1997 17:11:23 +0200 (MET DST)
Received: from gammon.opentext.ch(195.48.77.115) by go.opentext.ch via smap (V1.3)
	id sma000263; Mon Jun  2 17:11:19 1997
Received: from cassius.opentext.ch (cassius.opentext.ch [195.48.77.23]) by gammon.opentext.ch (8.6.12/8.6.9) with SMTP id RAA29969; Mon, 2 Jun 1997 17:27:21 +0100
Received: by cassius.opentext.ch with Microsoft Mail
	id <01BC6F79.420856E0@cassius.opentext.ch>; Mon, 2 Jun 1997 17:20:24 +-200
Message-ID: <01BC6F79.420856E0@cassius.opentext.ch>
>From: Dylan Barrell <dbarrell@opentext.ch>
To: Dylan Barrell <dbarrell@opentext.ch>,
        "'Gregory J. Woodhouse'"
	 <gjw@wnetc.com>
Cc: "'Jim Whitehead'" <ejw@ics.uci.edu>,
        "w3c-dist-auth@w3.org"
	 <w3c-dist-auth@w3.org>
Subject: RE: locks and trust (Re: Rejected Requirements)
Date: Mon, 2 Jun 1997 17:20:23 +-200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

What you have just described is equivalent to a bunch of authors =
appending to the same document ONLY or only ever adding resources to a =
collection. Adding a mail message to a mailbox is different from =
updating an existing mail message.

Here is a slightly different description of the same principle.

There are permissions which regulate access to resources.
Some users have read only permissions and some may add resources or =
overwrite them.
Those who may add or overwrite resources essentially (as a group) hold a =
shared write lock on the resource.
By adding or removing people from this group (in the broadest sense of =
the word) one can change the membership of the shared lock.
Some users have the permission to place an exclusive lock on the =
resource.
Only they may then overwrite this resource
Only they may remove the exclusive lock (admin users excepted)

Same conclusion as before.

Cheers
Dylan

----------
>From:  Gregory J. Woodhouse[SMTP:gjw@wnetc.com]
Sent:  Montag, 2. Juni 1997 09:38
To:  Dylan Barrell
Cc:  'Jim Whitehead'; w3c-dist-auth@w3.org
Subject:  RE: locks and trust (Re: Rejected Requirements)

On Mon, 2 Jun 1997, Dylan Barrell wrote:

> I would like to see the shared-lock be an optional portion of the =
WebDAV
> standard. I think the minimum requirement for locking is exclusive
> locking and this should be the minimum that WebDAV requires.=20
>=20
> Our experience with Livelink has been that exclusive locks are good
> enough. All other access can be regulated by the permissions. I.e. a
> shared lock can be seen as the permission of a group of people to =
write
> to the resource. Add to this the ability to change the permissions and
> the ability for someone to lock the resource (another individually
> specifiable permission) and you have all the flexibility you need.=20
>=20
> In conclusion I don't even see the need for shared locks.
>=20
> Cheers
> Dylan=20
>=20

I have a feeling we're talking past eachother here. In fact, I'm not at
all sure who I agree with and who I disagree with because I'm not clear =
on
who is using what terminology. It seems to me that locks can vary along
at least four orthogonal axes:

mandatory/advisory
exclusive/shared
read/write/both
privilege

To go back to the mail example, I sort my mail into multiple inboxes =
using
procmail and then access them with an IMAP client. Quite frequently, I =
see
mail arrive in a mailbox while I have it open. From my point of view, I
hear a beep and the display is updated. Internally, procmail locks my
mailbox just long enough to deliver the message and then releases the
lock. This is an example of a mandatory exclusive lock. Once the message
is delivered, I can continue with my work undisturbed. Now, let's =
suppose
I  start up a second instance of Pine. What will happen is that the =
second
process is already in use and warn me. In  addition, both instances of
Pine will be accessing the mailbox in read-only mode. In other wors the
first process had an exclusive advisory read/write lock that was
effectively revoked by the second process, replacing it with a shared
readonly lock. Now, mail can still continue to arrive, and will be =
allowed
to secure temporary exclusive locks while delivering mail without
disturbing th existing advisory lock. Another possible scenario is where =
I
telnet in, start up Pine, disconnect, and then telnet back in again. =
What
happens here is that I am warned that Pine is attempting to secdure a =
lock
on a mailbox which is already locked by process <whatever>. In this =
case,
that process is no longer active, so my process can succesfully revoke =
the
orphaned lock. This raises an interesting point: though these locks are
"advisory" (and technically they all are unless the MDA is configured to
use flock() to lock the mailbox), it is not up to the user (or user
process) to decide when to modify or revoke a lock. In essence, these
locks are only in that they can be revoked or modified by a process with
sufficient privilege (by mail subsystem itself). (Note that I'm not
talking about privilege in the UNIX sense of the term.)


---
Gregory Woodhouse
gjw@wnetc.com    /    http://www.wnetc.com/home.html
If you're going to reinvent the wheel, at least try to come
up with a better one.




From w3c-dist-auth-request@www10.w3.org  Mon Jun  2 13:43:03 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id NAA19529 for <w3c-dist-auth@www19.w3.org>; Mon, 2 Jun 1997 13:43:03 -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 NAA06062 for <w3c-dist-auth@w3.org>; Mon, 2 Jun 1997 13:43:03 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa29125;
          2 Jun 97 10:33 PDT
X-Sender: ejw@paris.ics.uci.edu
Message-Id: <afb8ab6e0a02100481fd@[128.195.21.209]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 2 Jun 1997 10:39:18 -0700
To: Dylan Barrell <dbarrell@opentext.ch>, w3c-dist-auth@w3.org
>From: Jim Whitehead <ejw@ics.uci.edu>
Subject: RE: locks and trust (Re: Rejected Requirements)
Cc: Mark_Day/CAM/Lotus@lotus.com
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

>I would like to see the shared-lock be an optional portion of the WebDAV
>standard. I think the minimum requirement for locking is exclusive locking
>and this should be the minimum that WebDAV requires.

What is expressed in the latest locking draft is that *all* locking
capability should be optional.   Since some replicated storage systems
cannot enforce the semantics of a lock, and since people are interested in
building WebDAV servers on top of these replicated stores, we can't have
mandatory lock capability without excluding this very important type of
back-end.  As I recall, Mark Day was a major proponent of not having lock
functionality mandatory, so perhaps he could expand on this.

- Jim



From w3c-dist-auth-request@www10.w3.org  Mon Jun  2 13:43:06 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id NAA19539 for <w3c-dist-auth@www19.w3.org>; Mon, 2 Jun 1997 13:43:05 -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 NAA06064 for <w3c-dist-auth@w3.org>; Mon, 2 Jun 1997 13:43:05 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa29134;
          2 Jun 97 10:33 PDT
X-Sender: ejw@paris.ics.uci.edu
Message-Id: <afb8afcf0b0210048933@[128.195.21.209]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 2 Jun 1997 10:39:23 -0700
To: Dylan Barrell <dbarrell@opentext.ch>, w3c-dist-auth@w3.org
MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
>From: Jim Whitehead <ejw@ics.uci.edu>
Subject: RE: locks and trust (Re: Rejected Requirements)
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

At 10:20 AM 6/2/97, Dylan Barrell wrote:

>
>There are permissions which regulate access to resources.
>Some users have read only permissions and some may add resources or
>overwrite them.
>Those who may add or overwrite resources essentially (as a group) hold a
>shared write lock on the resource.

Well, the view described in the current lock draft is that those who may
add or overwrite (i.e., write) resources all have equivalent access
permission for adding or overwriting a resource.

Of those principals who have equivalent write access permission on a
resource, a shared lock indicates those principals who are, at present,
actively working on the resource.  However, a shared write lock still
prevents non-holders of the lock from overwriting the resource.

This is different from the set of principals who have write access
permission, because it is typically a smaller set.  So, if there are six
authors on a document, they all have write access.  However, if only two of
the authors are currently working on the document, only those two will have
shared write locks (if the authors decided to use shared write locks
instead of exclusive write locks, knowing by their choice that this entails
slightly more communication overhead).

>By adding or removing people from this group (in the broadest sense of the
>word) one can change the membership of the shared lock.

In the example above, it does not make sense to change the access rights
every time an author starts to edit the document.  It makes more sense to
change the access rights only when the set of authors changes.

>Some users have the permission to place an exclusive lock on the resource.
>Only they may then overwrite this resource
>Only they may remove the exclusive lock (admin users excepted)

This is certainly one allowable case.  The drawback to this case occurs
when the principal who has taken out the lock goes home for the day without
releasing the lock, then calls-in sick the next day, preventing their
collaborators from gaining write access to the resource. The other case is:

> Some principals have the permission to place a shared lock on the resource.
> Only they may then overwrite this resource
> Only they may remove their particular shared lock

In this case, if a collaborator forgets to release the lock, other
collaborators can still work on the resource.


Is there some deficiency in the current lock draft?  I believe the
semantics of exclusive write locks and shared write locks are detailed
fairly clearly in this draft.  If this draft is unclear in some way, then
changes need to be made to this draft.

The locking draft can be found at:

http://www.ics.uci.edu/~ejw/authoring/proposals/locking.html

In particular, Section 1.1 describes the difference between exclusive and
shared write locks, and Section 1.2 describes that no locking functionality
is mandatory.  Section 2.2 gives a precise definition of a write lock.
Section 2.7 gives a lock compatibility table which describes interactions
between shared and exclusive locks.

- Jim



From w3c-dist-auth-request@www10.w3.org  Mon Jun  2 14:11:47 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id OAA20491 for <w3c-dist-auth@www19.w3.org>; Mon, 2 Jun 1997 14:11:47 -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 OAA06233 for <w3c-dist-auth@w3.org>; Mon, 2 Jun 1997 14:11:47 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa00509;
          2 Jun 97 10:45 PDT
X-Sender: ejw@paris.ics.uci.edu
Message-Id: <afb8b5940c021004e436@[128.195.21.209]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 2 Jun 1997 10:51:28 -0700
To: "Gregory J. Woodhouse" <gjw@wnetc.com>, w3c-dist-auth@w3.org
>From: Jim Whitehead <ejw@ics.uci.edu>
Subject: RE: locks and trust (Re: Rejected Requirements)
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring


>I have a feeling we're talking past eachother here. In fact, I'm not at
>all sure who I agree with and who I disagree with because I'm not clear on
>who is using what terminology. It seems to me that locks can vary along
>at least four orthogonal axes:
>
>mandatory/advisory
>exclusive/shared
>read/write/both
>privilege

I've been representing the language in the current lock draft.  In this
draft, the terms "mandatory and advisory" are not used as modifier of lock
semantics.  From past discussions on this list, and past personal use of
the term, and advisory lock is extremely similar in meaning to the current
shared lock.  I'm not sure what is meant by mandatory.  I'm also not sure
what is meant by privilege.

The axes of variation for locking in the current lock draft are:

exclusive/shared
write/(potential expansion to other access control verbs)

Thus there is an exclusive write lock, and a shared write lock.

Since a lock mediates access to a resource among principals with equal
access permissions, a lock is constrained by access control.  A super user
administrator could have sufficient *access* permissions to be able to
remove any given lock.  But this is a special access permission, not a
special lock type.

- Jim



From w3c-dist-auth-request@www10.w3.org  Mon Jun  2 14:36:51 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id OAA20906 for <w3c-dist-auth@www19.w3.org>; Mon, 2 Jun 1997 14:36:50 -0400 (EDT)
Received: from eastwood.aldigital.algroup.co.uk (eastwood.aldigital.algroup.co.uk [194.128.162.193]) by www10.w3.org (8.8.5/8.7.3) with SMTP id OAA06440 for <w3c-dist-auth@w3.org>; Mon, 2 Jun 1997 14:36:47 -0400 (EDT)
Received: from gonzo.ben.algroup.co.uk (gonzo.ben.algroup.co.uk [193.133.15.1]) by eastwood.aldigital.algroup.co.uk (8.6.12/8.6.12) with SMTP id SAA11680; Mon, 2 Jun 1997 18:35:53 GMT
Subject: Re: locks and trust (Re: Rejected Requirements)
To: Jim Whitehead <ejw@ics.uci.edu>
Date: Mon, 2 Jun 1997 19:24:36 +0100 (BST)
>From: Ben Laurie <ben@gonzo.ben.algroup.co.uk>
Cc: gjw@wnetc.com, w3c-dist-auth@w3.org
In-Reply-To: <afb8b5940c021004e436@[128.195.21.209]> from "Jim Whitehead" at Jun 2, 97 10:51:28 am
Reply-To: ben@algroup.co.uk
X-Mailer: ELM [version 2.4 PL24 PGP2]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-ID:  <9706021924.aa04635@gonzo.ben.algroup.co.uk>
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

Jim Whitehead wrote:
> I'm not sure what is meant by mandatory.

A mandatory lock prevents the locked operation by others. That is, a mandatory
write lock prevents writes, whereas an advisory write lock prevents write
locks.

Cheers,

Ben.

-- 
Ben Laurie                Phone: +44 (181) 994 6435  Email: ben@algroup.co.uk
Freelance Consultant and  Fax:   +44 (181) 994 6472
Technical Director        URL: http://www.algroup.co.uk/Apache-SSL
A.L. Digital Ltd,         Apache Group member (http://www.apache.org)
London, England.          Apache-SSL author


From w3c-dist-auth-request@www10.w3.org  Tue Jun  3 13:52:29 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id NAA05000 for <w3c-dist-auth@www19.w3.org>; Tue, 3 Jun 1997 13:52:29 -0400 (EDT)
Received: from crash.novalink.com (crash.novalink.com [192.233.90.218]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id NAA12467 for <w3c-dist-auth@w3.org>; Tue, 3 Jun 1997 13:52:29 -0400 (EDT)
Received: from dongeo ([192.233.90.81]) by crash.novalink.com
          (Post.Office MTA v3.1 release PO203a ID# 0-36389U100L2S100)
          with SMTP id AAA109 for <w3c-dist-auth@w3.org>;
          Tue, 3 Jun 1997 14:49:32 -0400
Message-ID: <33945ABC.539D@novalink.com>
Date: Tue, 03 Jun 1997 13:56:12 -0400
>From: jradoff@novalink.com (Jon Radoff)
Reply-To: jradoff@novalink.com
Organization: NovaLink
X-Mailer: Mozilla 3.01Gold (WinNT; I)
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
Subject: Access Control Requirements
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

I will be posting a preliminary Access Control Requirements draft
within the next few days.  This will be based on some of the
censensus expressed here already, as well as some ideas of my own
where there are some gaps.  If anyone has some important points
to make before I put this together, please write me.  I would like
to ultimately finalize the Requirements draft sometime around the
Orem, UT meeting.

Jon


From w3c-dist-auth-request@www10.w3.org  Tue Jun  3 17:09:15 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id RAA10697 for <w3c-dist-auth@www19.w3.org>; Tue, 3 Jun 1997 17:09:15 -0400 (EDT)
Received: from go.opentext.ch (go.opentext.ch [195.48.77.130]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id RAA13696 for <w3c-dist-auth@w3.org>; Tue, 3 Jun 1997 17:09:11 -0400 (EDT)
Received: (from root@localhost) by go.opentext.ch (8.7.3/GO-3a) id WAA12157; Tue, 3 Jun 1997 22:56:08 +0200 (MET DST)
Received: from gammon.opentext.ch(195.48.77.115) by go.opentext.ch via smap (V1.3)
	id sma012155; Tue Jun  3 22:56:04 1997
Received: from cassius.opentext.ch (cassius.opentext.ch [195.48.77.23]) by gammon.opentext.ch (8.6.12/8.6.9) with SMTP id XAA32500; Tue, 3 Jun 1997 23:12:08 +0100
Received: by cassius.opentext.ch with Microsoft Mail
	id <01BC7072.D302F3E0@cassius.opentext.ch>; Tue, 3 Jun 1997 23:06:52 +-200
Message-ID: <01BC7072.D302F3E0@cassius.opentext.ch>
>From: Dylan Barrell <dbarrell@opentext.ch>
To: Dylan Barrell <dbarrell@opentext.ch>,
        "'Jim Whitehead'"
	 <ejw@ics.uci.edu>,
        "w3c-dist-auth@w3.org" <w3c-dist-auth@w3.org>
Subject: RE: locks and trust (Re: Rejected Requirements)
Date: Tue, 3 Jun 1997 23:03:26 +-200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

The only point I am trying to make is that shared locks are not really =
necessary. As far as I'm concerned the difference between what you are =
describing and what I described is academic.=20

Cheers
Dylan

----------
>From:  Jim Whitehead[SMTP:ejw@ics.uci.edu]
Sent:  Montag, 2. Juni 1997 19:39
To:  Dylan Barrell; w3c-dist-auth@w3.org
Subject:  RE: locks and trust (Re: Rejected Requirements)

At 10:20 AM 6/2/97, Dylan Barrell wrote:

>
>There are permissions which regulate access to resources.
>Some users have read only permissions and some may add resources or
>overwrite them.
>Those who may add or overwrite resources essentially (as a group) hold =
a
>shared write lock on the resource.

Well, the view described in the current lock draft is that those who may
add or overwrite (i.e., write) resources all have equivalent access
permission for adding or overwriting a resource.

Of those principals who have equivalent write access permission on a
resource, a shared lock indicates those principals who are, at present,
actively working on the resource.  However, a shared write lock still
prevents non-holders of the lock from overwriting the resource.

This is different from the set of principals who have write access
permission, because it is typically a smaller set.  So, if there are six
authors on a document, they all have write access.  However, if only two =
of
the authors are currently working on the document, only those two will =
have
shared write locks (if the authors decided to use shared write locks
instead of exclusive write locks, knowing by their choice that this =
entails
slightly more communication overhead).

>By adding or removing people from this group (in the broadest sense of =
the
>word) one can change the membership of the shared lock.

In the example above, it does not make sense to change the access rights
every time an author starts to edit the document.  It makes more sense =
to
change the access rights only when the set of authors changes.

>Some users have the permission to place an exclusive lock on the =
resource.
>Only they may then overwrite this resource
>Only they may remove the exclusive lock (admin users excepted)

This is certainly one allowable case.  The drawback to this case occurs
when the principal who has taken out the lock goes home for the day =
without
releasing the lock, then calls-in sick the next day, preventing their
collaborators from gaining write access to the resource. The other case =
is:

> Some principals have the permission to place a shared lock on the =
resource.
> Only they may then overwrite this resource
> Only they may remove their particular shared lock

In this case, if a collaborator forgets to release the lock, other
collaborators can still work on the resource.


Is there some deficiency in the current lock draft?  I believe the
semantics of exclusive write locks and shared write locks are detailed
fairly clearly in this draft.  If this draft is unclear in some way, =
then
changes need to be made to this draft.

The locking draft can be found at:

http://www.ics.uci.edu/~ejw/authoring/proposals/locking.html

In particular, Section 1.1 describes the difference between exclusive =
and
shared write locks, and Section 1.2 describes that no locking =
functionality
is mandatory.  Section 2.2 gives a precise definition of a write lock.
Section 2.7 gives a lock compatibility table which describes =
interactions
between shared and exclusive locks.

- Jim




From w3c-dist-auth-request@www10.w3.org  Tue Jun  3 18:05:16 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id SAA15460 for <w3c-dist-auth@www19.w3.org>; Tue, 3 Jun 1997 18:05:16 -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 SAA14060 for <w3c-dist-auth@w3.org>; Tue, 3 Jun 1997 18:05:15 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa20254;
          3 Jun 97 15:00 PDT
X-Sender: ejw@paris.ics.uci.edu
Message-Id: <afba406519021004c9c0@[128.195.21.209]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 3 Jun 1997 15:05:48 -0700
To: w3c-dist-auth@w3.org
>From: Jim Whitehead <ejw@ics.uci.edu>
Subject: New Requirements I-D Available
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring


There is a new version of the WebDAV Requirements document available as
Internet-Draft <draft-ietf-webdav-requirements-00.txt>.

Judith Slein, the requirements document editor, has done a great job
resolving open issues and soliciting comments from the discussion list
while producing this excellent draft.  For all of your hard work, thank
you.

An HTML version of the requirements draft can be retrieved at URL:

http://www.ics.uci.edu/~ejw/authoring/requirements/draft-ietf-webdav-require
ments-00.html

A text version can be retrieved at the following URLs:

http://www.ics.uci.edu/~ejw/authoring/requirements/draft-ietf-webdav-require
ments-00.txt
ftp://ds.internic.net/internet-drafts/draft-ietf-webdav-requirements-00.txt

Also, I have produced a version history of the requirements document which
is available at:

http://www.ics.uci.edu/~ejw/authoring/requirements/

Our Charter currently has the requirements document slated for submission
as an Informational RFC in August of this year, which is ambitious, but
possible providing we continue to work hard on resolving the open issues.

- Jim



From w3c-dist-auth-request@www10.w3.org  Wed Jun  4 20:04:02 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id UAA15813 for <w3c-dist-auth@www19.w3.org>; Wed, 4 Jun 1997 20:04:02 -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 UAA19885 for <w3c-dist-auth@w3.org>; Wed, 4 Jun 1997 20:04:02 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa25622;
          4 Jun 97 16:48 PDT
X-Sender: ejw@paris.ics.uci.edu
Message-Id: <afbbaec50f021004e8fd@[128.195.21.209]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 4 Jun 1997 16:54:03 -0700
To: w3c-dist-auth@w3.org
>From: Jim Whitehead <ejw@ics.uci.edu>
Subject: New Scenarios I-D Available
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

There is a new version of the WebDAV Scenarios document available as
Internet-Draft <draft-ietf-webdav-scenarios-00.txt>.

Many thanks are due Ora Lassila, the Scenarios Document editor, for his
work adding Judith Slein's access control scenarios, and resubmitting this
document as an Internet-Draft.

The document can be accessed at the following URLs:

http://www.ics.uci.edu/~ejw/authoring/scenarios/draft-ietf-webdav-scenarios-
00.txt
ftp://ds.internic.net/internet-drafts/draft-ietf-webdav-scenarios-00.txt

I have also put together a version history for this document, which is
available at:

http://www.ics.uci.edu/~ejw/authoring/scenarios/

This Internet Draft replaces the existing <draft-lassila-http-edit-dist-00.txt>.

At present, our Charter lists the scenarios document being  submitted as an
Informational RFC in August, 1997.

- Jim



From w3c-dist-auth-request@www10.w3.org  Thu Jun  5 20:47:40 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id UAA07331 for <w3c-dist-auth@www19.w3.org>; Thu, 5 Jun 1997 20:47:39 -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 UAA26590 for <w3c-dist-auth@w3.org>; Thu, 5 Jun 1997 20:47:39 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa18091;
          5 Jun 97 17:42 PDT
X-Sender: ejw@paris.ics.uci.edu
Message-Id: <afbcfd170e021004649e@[128.195.21.209]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 5 Jun 1997 17:48:36 -0700
To: w3c-dist-auth@w3.org
>From: Jim Whitehead <ejw@ics.uci.edu>
Subject: Open Requirements Issues
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

I'd like to start a dialog on the last remaining open issues in the
requirements document, since I feel that for most issues, a little bit of
discussion will resolve the issue.

The requirements document lists the following issues as still being under
discussion:

*       Whether support for multi-resource locking is needed
*       Whether reservations should be treated as shared or advisory locks
*       What requirements there should be for access control
*       What requirements there should be for internationalization
*       How far WebDAV should be concerned about compatibility with other
transport protocols besides HTTP

My views on these issues are as follows:

*       Whether support for multi-resource locking is needed

I feel we will need atomic multi-resource locking for exclusive locks (this
isn't a problem for shared locks).  If locking multiple resources requires
that each resource be individually locked (i.e., no atomic locking of
multiple resources is available), then if two or more principals try to
take out exclusive locks on the same set of resources, no principal will
end up with the desired result: having an exclusive lock on all resources.
I believe this can only be solved by making an exclusive lock of a set of
resources an atomic operation across all resources.

So I feel that yes, support for multi-resource locking is needed, and hence
the current requirement covering this ability should remain as-is:

5.3.1.2. Multi-Resource Locking. It must be possible to take out a lock
on multiple resources in the same action, and this locking operation
must be atomic across these resources.


*       Whether reservations should be treated as shared or advisory locks

In my view, a shared lock meets the requirements for reservations, which
are defined as:

5.4.1.1. Reserve. It must be possible to notify the server that a
resource is about to be edited by a given person.

If you have a set of principals with equivalent access permissions on a
resource, a shared write lock indicates that one of those principals is
about to be edited (since presumably the only reason to take out a shared
lock (or a reservation) is prior to performing edits).

Since a shared lock meets the requirement for reservations, the issue
arises whether the terminology for reservations should be modified to use
the term "shared lock" instead of "reservation."  This is a little less
clear.  I think there is better correspondence between the requirements and
the current proposals if the wording is changed, but since the current lock
proposal meets the reservation requirements, the language doesn't have to
be changed.  My inclination is to use the terminology "shared lock" in the
requirements document, but I could go either way.


*       What requirements there should be for access control

This will be the subject of a draft by Jon Radoff.


*       What requirements there should be for internationalization

We definitely need some words on this topic, however my lack of experience
in this area hinders my ability to construct a good requirement.  Something
along the lines of, "All fields which might be displayed to a human user of
client software should be fully international."  I'd appreciate some
assistance for good wording of "fully international" -- something along the
lines of "supports iso character set standard XXX" might work.


*       How far WebDAV should be concerned about compatibility with other
transport protocols besides HTTP

Well, since our charter limits us to discussion on HTTP and Email as
transport protocols, this open issue really concerns email access.  The
sense I have been receiving from the list is the current, "don't shoot,
don't spec." (don't shoot ourselves in the foot by making it impossible to
do an email mapping in the future, but don't actually write a spec. for
this right now) is how most would prefer to proceed.

If my reading of the sense of the working group is correct, then we should
not have a requirement on this topic, and can declare the issue closed.  If
there is strong support for writing a spec. on email access, then Gregory
Woodhouse, who has volunteered to look into this, needs to write up some
requirements, which may or may not end up in future versions of
draft-ietf-webdav-requirements.


Comments?

- Jim



From w3c-dist-auth-request@www10.w3.org  Thu Jun  5 21:22:50 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id VAA07549 for <w3c-dist-auth@www19.w3.org>; Thu, 5 Jun 1997 21:22:50 -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 VAA26704 for <w3c-dist-auth@w3.org>; Thu, 5 Jun 1997 21:22:49 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa20868;
          5 Jun 97 18:20 PDT
X-Sender: ejw@paris.ics.uci.edu
Message-Id: <afbd164b02021004507d@[128.195.21.209]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 5 Jun 1997 18:26:00 -0700
To: w3c-dist-auth@w3.org
>From: Jim Whitehead <ejw@ics.uci.edu>
Subject: Reminder: WebDAV WG meeting, Orem, UT
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

Reminder: WebDAV Working Group Meeting

There will be a meeting of the WebDAV Working Group, on July 14-15, 1997,
at the Novell facility in Orem, Utah.  Many thanks to Steve Carter and
Novell for hosting this meeting!  The purpose of the meeting is to provide
a forum for focused, detailed discussion on the current WebDAV protocol
specification and requirements document (a preliminary agenda will be
posted soon).  This is an open meeting -- anyone is welcome to attend.

What: WebDAV Working Group meeting
Where: Novell, Orem, Utah
When: July 14-15, 1997 (9AM-5PM both days)

This meeting is being held in addition to the upcoming Munich IETF meeting,
August 11-15, 1997, at which there will also be detailed review of the
WebDAV protocol specification, but over a much shorter time span.

Registration:

If you are planning on attending this meeting, please send an email to
Steve Carter <srcarter@novell.com> with a subject of "WebDAV Registration"
giving your name, and corporate affiliation (if applicable) by July 9.
This allows Steve to plan food amounts, and to notify Novell security that
you're coming.

Steve is currently working on arranging a block of rooms at the Provo Park
Hotel, so if you are planning on attending this meeting, please let Steve
know soon so he can provide the hotel with a good estimate of the number of
rooms needed.

Orem, Utah:

Orem is 45 minutes south of the Salt Lake City International airport, and
is right next to Provo.  My list of local hotels from when I visted last
December is:

  1) Marriott Courtyard, 1600 N Freedom Blvd, Provo
      tel (801) 373-2222, Reservations: 800 228-9290
  2) Provo Park Hotel, 101 W 100 N Provo
      tel (801) 377-4700, Reservations: 800 777-7144

I have stayed in the Provo Park Hotel, and it was very nice.

- Jim Whitehead <ejw@ics.uci.edu>



From w3c-dist-auth-request@www10.w3.org  Thu Jun  5 23:27:10 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id XAA08333 for <w3c-dist-auth@www19.w3.org>; Thu, 5 Jun 1997 23:27:10 -0400 (EDT)
Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id XAA27040 for <w3c-dist-auth@w3.org>; Thu, 5 Jun 1997 23:27:10 -0400 (EDT)
Received: from sub.sonic.net (sub.sonic.net [208.201.224.8])
          by marine.sonic.net (8.8.5/8.8.5) with ESMTP
	  id UAA25407 for <w3c-dist-auth@w3.org>; Thu, 5 Jun 1997 20:27:11 -0700
Received: from bolt.sonic.net (tallen@bolt.sonic.net [208.201.224.36]) by sub.sonic.net (8.8.5/8.8.5) with ESMTP id UAA32756; Thu, 5 Jun 1997 20:27:08 -0700
X-envelope-info: <tallen@bolt.sonic.net>
Received: (from tallen@localhost) by bolt.sonic.net (8.8.5/8.7.3) id UAA11230; Thu, 5 Jun 1997 20:27:21 -0700
Date: Thu, 5 Jun 1997 20:27:21 -0700
>From: Terry Allen <tallen@sonic.net>
Message-Id: <199706060327.UAA11230@bolt.sonic.net>
To: ejw@ics.uci.edu, w3c-dist-auth@w3.org
Subject: Re: Open Requirements Issues
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

>We definitely need some words on this topic, however my lack of experience
in this area hinders my ability to construct a good requirement.  Something
along the lines of, "All fields which might be displayed to a human user of
client software should be fully international."  I'd appreciate some
assistance for good wording of "fully international" -- something along the
lines of "supports iso character set standard XXX" might work.
                                       
How about "nothing in this specification shall be interpreted to
inhibit internationalization".  As for the character set, the IAB
view is ISO 10646.

Regards,

  Terry Allen    Electronic Publishing Consultant    tallen[at]sonic.net
                   http://www.sonic.net/~tallen/
    Davenport and DocBook:  http://www.ora.com/davenport/index.html
          T.A. at Passage Systems:  terry.allen[at]passage.com 


From w3c-dist-auth-request@www10.w3.org  Fri Jun  6 09:35:19 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id JAA12284 for <w3c-dist-auth@www19.w3.org>; Fri, 6 Jun 1997 09:35:18 -0400 (EDT)
Received: from go.opentext.ch (go.opentext.ch [195.48.77.130]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id JAA28453 for <w3c-dist-auth@w3.org>; Fri, 6 Jun 1997 09:35:17 -0400 (EDT)
Received: (from root@localhost) by go.opentext.ch (8.7.3/GO-3a) id PAA05557; Fri, 6 Jun 1997 15:22:08 +0200 (MET DST)
Received: from gammon.opentext.ch(195.48.77.115) by go.opentext.ch via smap (V1.3)
	id sma005555; Fri Jun  6 15:22:03 1997
Received: from cassius.opentext.ch (cassius.opentext.ch [195.48.77.23]) by gammon.opentext.ch (8.6.12/8.6.9) with SMTP id PAA04926; Fri, 6 Jun 1997 15:38:24 +0100
Received: by cassius.opentext.ch with Microsoft Mail
	id <01BC725C.8A5F7280@cassius.opentext.ch>; Fri, 6 Jun 1997 09:32:24 -0400
Message-ID: <01BC725C.8A5F7280@cassius.opentext.ch>
>From: Dylan Barrell <dbarrell@opentext.ch>
To: "ejw@ics.uci.edu" <ejw@ics.uci.edu>, "'Terry Allen'" <tallen@sonic.net>,
        "w3c-dist-auth@w3.org" <w3c-dist-auth@w3.org>
Subject: RE: Open Requirements Issues
Date: Fri, 6 Jun 1997 09:32:22 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

I would like to see some slightly better international support

1)  The server should support the notion of document language versions =
(similar in concept to renditions) and should always produce the =
language version corresponding to the language of the user's client, the =
explicit language version requested by the client (i.e. it should be =
possible to explicitly address a particular language version) or the =
default language.
2)  The client should be able to specify its preferred languages in =
order of preference and the server should present from the existing =
language versions the one highest on the client's list. Failing this the =
default language should be presented.
3)  It should be possible to specify to the server which language =
version is the default (master version)
4)  When asking for a list of objects in a collection it should be =
possible to obtain a list of all the different language versions of each =
resource (the default should simply return the list of default language =
resources)
5)  It should be possible to lock only a particular language version of =
a resource or all languages
6)  There must be a way of indicating which nodes in the version graph =
for each language can be considered equivalent (there might be a =
different number of versions for each language version)

Cheers
Dylan

----------
>From:  Terry Allen[SMTP:tallen@sonic.net]
Sent:  Donnerstag, 5. Juni 1997 23:27
To:  ejw@ics.uci.edu; w3c-dist-auth@w3.org
Subject:  Re: Open Requirements Issues

>We definitely need some words on this topic, however my lack of =
experience
in this area hinders my ability to construct a good requirement.  =
Something
along the lines of, "All fields which might be displayed to a human user =
of
client software should be fully international."  I'd appreciate some
assistance for good wording of "fully international" -- something along =
the
lines of "supports iso character set standard XXX" might work.
                                      =20
How about "nothing in this specification shall be interpreted to
inhibit internationalization".  As for the character set, the IAB
view is ISO 10646.

Regards,

  Terry Allen    Electronic Publishing Consultant    tallen[at]sonic.net
                   http://www.sonic.net/~tallen/
    Davenport and DocBook:  http://www.ora.com/davenport/index.html
          T.A. at Passage Systems:  terry.allen[at]passage.com=20



From w3c-dist-auth-request@www10.w3.org  Fri Jun  6 12:27:47 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id MAA15163 for <w3c-dist-auth@www19.w3.org>; Fri, 6 Jun 1997 12:27:47 -0400 (EDT)
Received: from mailgate2.boeing.com (mailgate2.boeing.com [199.238.248.100]) by www10.w3.org (8.8.5/8.7.3) with SMTP id MAA29346 for <w3c-dist-auth@w3.org>; Fri, 6 Jun 1997 12:27:44 -0400 (EDT)
Received: from splinter.boeing.com by mailgate2.boeing.com (SMI-8.6/SMI-SVR4)
	id JAA00255; Fri, 6 Jun 1997 09:27:40 -0700
Received: from warlok.ds.boeing.com by splinter.boeing.com with ESMTP
	(1.37.109.16/16.2) id AA164164193; Fri, 6 Jun 1997 09:23:13 -0700
Received: by warlok.ds.boeing.com (SMI-8.6/SMI-SVR4-DNI-8.0)
	id JAA22971; Fri, 6 Jun 1997 09:27:38 -0700
Date: Fri, 6 Jun 1997 09:27:38 -0700
Message-Id: <199706061627.JAA22971@warlok.ds.boeing.com>
To: w3c-dist-auth@w3.org
Subject: Re: Open Requirements Issues
Reply-To: webdav@warlok.ds.boeing.com
>From: howard.s.modell@boeing.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring


H:From w3c-dist-auth-request@w3.org  Thu Jun  5 18:45:29 1997
H:Resent-Message-Id: <199706060047.UAA07351@www19.w3.org>
H:Date: Thu, 5 Jun 1997 17:48:36 -0700
H:To: w3c-dist-auth@w3.org
H:From: Jim Whitehead <ejw@ics.uci.edu>
H:Subject: Open Requirements Issues
H:X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
H:X-See-Also: http://www.ics.uci.edu/~ejw/authoring
H:X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/861
H:X-Loop: w3c-dist-auth@w3.org
H:
H:I'd like to start a dialog on the last remaining open issues in the
H:requirements document, since I feel that for most issues, a little bit of
H:discussion will resolve the issue.
H:
H:The requirements document lists the following issues as still being under
H:discussion:
H:
H:*       Whether support for multi-resource locking is needed
H:*       Whether reservations should be treated as shared or advisory locks
H:*       What requirements there should be for access control
H:*       What requirements there should be for internationalization
H:*       How far WebDAV should be concerned about compatibility with other
H:transport protocols besides HTTP
H:
H:My views on these issues are as follows:
H:
H:*       Whether support for multi-resource locking is needed
H:
H:I feel we will need atomic multi-resource locking for exclusive locks (this
H:isn't a problem for shared locks).  If locking multiple resources requires
H:that each resource be individually locked (i.e., no atomic locking of
H:multiple resources is available), then if two or more principals try to
H:take out exclusive locks on the same set of resources, no principal will
H:end up with the desired result: having an exclusive lock on all resources.
H:I believe this can only be solved by making an exclusive lock of a set of
H:resources an atomic operation across all resources.
H:
H:So I feel that yes, support for multi-resource locking is needed, and hence
H:the current requirement covering this ability should remain as-is:
H:
H:5.3.1.2. Multi-Resource Locking. It must be possible to take out a lock
H:on multiple resources in the same action, and this locking operation
H:must be atomic across these resources.

I find no problems here.  However, I think it feeds directly into the next one ..

H:
H:*       Whether reservations should be treated as shared or advisory locks
H:
H:In my view, a shared lock meets the requirements for reservations, which
H:are defined as:
H:
H:5.4.1.1. Reserve. It must be possible to notify the server that a
H:resource is about to be edited by a given person.

I think that if "multi-resource locks" are supported, than Reservation must account
for them more strongly.  I think that if one wishes to edit multiple resources, than
the reserve operation should be "atomic", that is, you specify all resources that you
wish to edit "at the same time" and only if you can get a lock on *all* of them should
the server accept the reservation.  If you can't get all of them, the server has to 
inform you of that fact, and stop.

I suppose it could be permissible to request reservation of a set of resources without
the requirement of needing all of them at that moment, in which case being able to
reserve some but not all should be supported.

H:
H:
H:*       What requirements there should be for access control
H:
H:This will be the subject of a draft by Jon Radoff.
H:
H:
H:*       What requirements there should be for internationalization
H:
H:We definitely need some words on this topic, however my lack of experience
H:in this area hinders my ability to construct a good requirement.  Something
H:along the lines of, "All fields which might be displayed to a human user of
H:client software should be fully international."  I'd appreciate some
H:assistance for good wording of "fully international" -- something along the
H:lines of "supports iso character set standard XXX" might work.

is there an assumption that user-interaction with a WEBDAV server will always be 
mediated thru a web browser?  If so, couldn't we simply assert that a WEBDAV
server must have at least the functionality of a non-WEBDAV server with respect
to communicating with a "acculturated" browser?

H:
H:
H:*       How far WebDAV should be concerned about compatibility with other
H:transport protocols besides HTTP
H:
H:Well, since our charter limits us to discussion on HTTP and Email as
H:transport protocols, this open issue really concerns email access.  The
H:sense I have been receiving from the list is the current, "don't shoot,
H:don't spec." (don't shoot ourselves in the foot by making it impossible to
H:do an email mapping in the future, but don't actually write a spec. for
H:this right now) is how most would prefer to proceed.
H:
H:If my reading of the sense of the working group is correct, then we should
H:not have a requirement on this topic, and can declare the issue closed. 

I agree with this.

<signed>
Howard S. Modell
________________________________________________________________________
 Adv.Computing Technologist/2         POBox 3707, m/s 4A-25, Boeing D&SG
 howard.s.modell@boeing.com           Seattle, WA 98124-2207
 http://warlok.ds.boeing.com/~howie/  (206)662-0189[v] (206)662-4018[f]


From w3c-dist-auth-request@www10.w3.org  Fri Jun  6 13:12:03 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id NAA15676 for <w3c-dist-auth@www19.w3.org>; Fri, 6 Jun 1997 13:11:58 -0400 (EDT)
Received: from shell3.ba.best.com (shell3.ba.best.com [206.184.139.134]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id NAA29712 for <w3c-dist-auth@w3.org>; Fri, 6 Jun 1997 13:11:58 -0400 (EDT)
Received: from localhost (gjw@localhost) by shell3.ba.best.com (8.8.5/8.7.3) with SMTP id KAA03662; Fri, 6 Jun 1997 10:11:56 -0700 (PDT)
X-Authentication-Warning: shell3.ba.best.com: gjw owned process doing -bs
Date: Fri, 6 Jun 1997 10:11:55 -0700 (PDT)
>From: "Gregory J. Woodhouse" <gjw@wnetc.com>
Sender: gjw@best.com
To: webdav@warlok.ds.boeing.com
cc: w3c-dist-auth@w3.org
Subject: Re: Open Requirements Issues
In-Reply-To: <199706061627.JAA22971@warlok.ds.boeing.com>
Message-ID: <Pine.BSF.3.96.970606095706.21615B-100000@shell3.ba.best.com>
X-Url: http://www.wnetc.com/
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

It sounds to me like what you need is a kind of mandatory
content-negotiation in which

Accept-Language: en-us; q=1.0, *; q=0.0

Which would mean give me the US English version if it is available,
otherwise respond with 

406 Not Acceptable

Similarly, a PUT (or check in)  should be able to specify a language (It's
a little non-intuitive to use "Accept-Language" here, but I suppose it
would work. If the server is unable to store language specific versions,
or is unable to store the document under the language specified, I believe
it should respond with

409 Conflict

---
Gregory Woodhouse
gjw@wnetc.com    /    http://www.wnetc.com/home.html
If you're going to reinvent the wheel, at least try to come
up with a better one.


From w3c-dist-auth-request@www10.w3.org  Fri Jun  6 15:45:41 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id PAA20395 for <w3c-dist-auth@www19.w3.org>; Fri, 6 Jun 1997 15:45:37 -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 PAA01205 for <w3c-dist-auth@w3.org>; Fri, 6 Jun 1997 15:45:36 -0400 (EDT)
Received: from casablanca.parc.xerox.com ([13.2.16.111]) by alpha.xerox.com with SMTP id <17792(7)>; Fri, 6 Jun 1997 12:45:16 PDT
Received: from bronze.parc.xerox.com ([13.1.100.114]) by casablanca.parc.xerox.com with SMTP id <72163>; Fri, 6 Jun 1997 12:44:52 PDT
Message-ID: <339868AC.50F9@parc.xerox.com>
Date: Fri, 6 Jun 1997 12:44:44 PDT
>From: Larry Masinter <masinter@parc.xerox.com>
Organization: Xerox PARC
X-Mailer: Mozilla 3.01Gold (Win95; U)
MIME-Version: 1.0
To: "Gregory J. Woodhouse" <gjw@wnetc.com>
CC: webdav@warlok.ds.boeing.com, w3c-dist-auth@w3.org
Subject: Re: Open Requirements Issues
References: <Pine.BSF.3.96.970606095706.21615B-100000@shell3.ba.best.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

The proper label for the language of content is
content-language:, if it is part of the wrapper. Some
media types (e.g., text/html) also have provision for
labelling components as being in a particular language.
However, there isn't a direct correspondence between
accept-language (which describes the preference of
the user of the client) and content-language (which
denotes the language of the content for purposes of
viewing, hyphenation, display conventions, etc.).
> Similarly, a PUT (or check in)  should be able to specify a language (It's
> a little non-intuitive to use "Accept-Language" here, but I suppose it
> would work. If the server is unable to store language specific versions,
> or is unable to store the document under the language specified, I believe
> it should respond with

I think PUT on negotiated resources for which the variants don't
have URLs should basically be disallowed. (Well, you might PUT a
multipart/alternative and then expect the result to be content
negotiated as a response). That is, if you have
   foo.html
which is really 
   foo.fr.html and foo.en-us.html
and you just want to update the French version, then you should
PUT to foo.fr.html and not use some arcane invocation of PUT foo.html
which says "only replace a part of this".

It's probably the same reason why PUT on byte ranges should be
disallowed.

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


From w3c-dist-auth-request@www10.w3.org  Wed Jun 11 16:05:46 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id QAA16982 for <w3c-dist-auth@www19.w3.org>; Wed, 11 Jun 1997 16:05:46 -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 QAA23513 for <w3c-dist-auth@w3.org>; Wed, 11 Jun 1997 16:05:44 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa06681;
          11 Jun 97 13:01 PDT
X-Sender: ejw@paris.ics.uci.edu
Message-Id: <afc490a310021004779b@[128.195.21.209]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 11 Jun 1997 13:07:39 -0700
To: w3c-dist-auth@w3.org
>From: Jim Whitehead <ejw@ics.uci.edu>
Subject: Locking containers
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

One issue still remaining in the current locking draft (available at
<http://www.ics.uci.edu/~ejw/authoring/proposals/locking.html>) is how to
handle an exclusive write lock on a container.

At present, an exclusive write lock on a container prevents modification of
the membership of the container by any principal other than the owner of
the lock, i.e., preventing the addition and removal of members of the
collection. So far, so good.

However, an exclusive write lock on a member of a collection is currently
defined such that the owner of the lock may delete the resource.

The dilemma occurs during the following scenario: Principal P1 takes out an
exclusive write lock on Resource B which is a member of collection A.
Principal P2 later takes out an exclusive write lock on collection A.  What
does each lock mean in this situation?  If P2 can delete B, what then is
the meaning of the lock on A?  It appears that in this case, the meaning of
the lock depends on the state of locks on other resources, which is not
desirable.

This raises some questions.

1) Is it useful to allow locking of containers at all?

2) Assuming it is useful (I suspect there are many cases where this
functionality is needed), which of the several ways of solving this is
best?

One way is to mandate that an exclusive write lock on a container must lock
all members and subcollections -- if there are any existing locks on any
members, or members of subcollections, then the lock request fails.  Thus
there is no problem with locks changing meaning, because a lock of a
container also locks its members.  However, performing a recursive lock
like this is expensive, especially if you only want to make changes at one
level of a multi-level hierarchy.

Another way is to define an exclusive write lock such that the owner of the
lock is not guaranteed the ability to DELETE the resource (assuming they
have sufficient access rights to delete the resource).  To guarantee the
ability to delete the resource, they need to lock the collection containing
the resource.  This is less expensive than locking all levels of the
hierarchy, but does have the drawback that there is very little difference
between deleting a resource (which would not be allowed by a lock on an
individual resource) and zeroing out the contents of a resource (which is
allowed by an exclusive write lock on an individual resource).

- Jim



From w3c-dist-auth-request@www10.w3.org  Wed Jun 11 19:49:09 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id TAA26776 for <w3c-dist-auth@www19.w3.org>; Wed, 11 Jun 1997 19:49:09 -0400 (EDT)
Received: from relay6.UU.NET (relay6.UU.NET [192.48.96.16]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id TAA24494 for <w3c-dist-auth@w3.org>; Wed, 11 Jun 1997 19:49:08 -0400 (EDT)
Received: from felix.filenet.com by relay6.UU.NET with SMTP 
	(peer crosschecked as: felix.filenet.com [198.3.8.11])
	id QQctnr14922; Wed, 11 Jun 1997 19:49:25 -0400 (EDT)
Received: from fn-smtp.filenet.com by felix.filenet.com with SMTP
	(8.6.9/16.2) id TAA20804; Wed, 11 Jun 1997 19:42:31 -0400
Received: by fn-smtp.filenet.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5)
	id <01BC7687.C92307F0@fn-smtp.filenet.com>; Wed, 11 Jun 1997 16:52:02 -0700
Message-ID: <c=US%a=_%p=MSIMC%l=MSIMC/EX1/001C8AA1@fn-smtp.filenet.com>
>From: "Fay, Chuck" <cfay@filenet.com>
To: "'SMTP:w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
Subject: FW: DMA TC meeting in Orem, Utah, 7/16/97-7/17/97
Date: Wed, 11 Jun 1997 16:47:00 -0700
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5
Encoding: 144 TEXT
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

WebDAV participants --

When making your plans to attend the WebDAV Working Group meeting in
Orem this July, please note that you are welcome to stay over and attend
the DMA Technical Committee meeting the following two days.  The
Document Management Alliance (DMA) is an AIIM Task Force with the
charter to develop a uniform programming model enabling enterprise-wide
interoperability among document-oriented applications and document
management systems from different vendors.

The DMA 0.9 specification is now in trial use through October of this
year.  DMA member companies are working on prototype implementations
during this period.  The first prototype was completed and demonstrated
at the AIIM Show this past April.  The second prototype is underway now,
with a third prototype following later this summer.  The DMA 1.0
specification will be produced and voted on late this year, based on 0.9
plus refinements from the trial use experience.

For more on DMA, including the 0.9 specification, see the Standards area
on www.aiim.org.  See below for more on the July DMA TC meeting
opportunity.

 --Chuck Fay, chair, DMA TC
FileNet Corporation, 3565 Harbor Blvd., Costa Mesa, CA 92626
phone:  (714) 966-3513, fax:  (714) 966-3288, email:  cfay@filenet.com

 ----------
>From: Fay, Chuck
To: dmatech
Cc: dhamson@novell.com; srcarter@novell.com
Subject: DMA TC meeting in Orem, Utah, 7/16/97-7/17/97
Date: Tuesday, June 10, 1997 5:22PM

This is a reminder that the next DMA Technical Committee meeting will be
held July 16th and 17th at Novell facilities in Orem, Utah, 9 am to 5 pm
both days.

WebDAV Meeting Beforehand:

Thanks to a generous offer from Steve Carter and Novell to host DMA the
same week that they're hosting the WebDAV Working Group, this will be a
unique opportunity for the two standards groups to mix and explore the
synergy between the two efforts.  The WebDAV Working Group will be
meeting the preceding two days, July 14th and 15th, in the same Novell
facilities.  (See Jim Whitehead's message on that meeting below,
including travel arrangements information.  Jim is the WebDAV chair.)

Attendance and Voting:

The DMA TC meeting will be open to everyone, especially those attending
the preceding WebDAV meeting.  Note that the AIIM DMA Task Force
Agreement stipulates that only full DMA member companies can participate
in formal votes in the TC, however.

Goals of the Meeting:

The proposed goals of the TC meeting are to

1. Come to an understanding on the similarities, differences,
    and synergy between DMA and WebDAV
2. Review the results of the Trial Use Subcommittee
    -- review the progress of the second prototype
        (and see a demonstration, if possible)
    -- review the plans for the remainder of the trial use period
    -- discuss and act on proposed changes to the spec
3. Discuss and act on the Conformance SC's proposal
4. Discuss the status of the Java binding (subject to AC vote)
5. Discuss and act on the TC process proposal
6. Set the final schedule and process for publishing the 1.0 spec

Registration:

To register for the DMA TC meeting, please send email to Steve Carter
<srcarter@novell.com> and Chuck Fay (cfay@filenet.com) with a subject of
"DMA TC Registration" giving your name and corporate affiliation by July
9, earlier if possible.  If you plan to attend the WebDAV meeting as
well, send a second message as described below by Jim Whitehead.

See you all there!

 --Chuck Fay
FileNet Corporation, 3565 Harbor Blvd., Costa Mesa, CA 92626
phone:  (714) 966-3513, fax:  (714) 966-3288, email:  cfay@filenet.com

 ----------
>From: Jim Whitehead
To: w3c-dist-auth@w3.org
Subject: Reminder: WebDAV WG meeting, Orem, UT
Date: Thursday, June 05, 1997 6:26PM

Reminder: WebDAV Working Group Meeting

There will be a meeting of the WebDAV Working Group, on July 14-15,
1997,
at the Novell facility in Orem, Utah.  Many thanks to Steve Carter and
Novell for hosting this meeting!  The purpose of the meeting is to
provide
a forum for focused, detailed discussion on the current WebDAV protocol
specification and requirements document (a preliminary agenda will be
posted soon).  This is an open meeting -- anyone is welcome to attend.

What: WebDAV Working Group meeting
Where: Novell, Orem, Utah
When: July 14-15, 1997 (9AM-5PM both days)

This meeting is being held in addition to the upcoming Munich IETF
meeting,
August 11-15, 1997, at which there will also be detailed review of the
WebDAV protocol specification, but over a much shorter time span.

Registration:

If you are planning on attending this meeting, please send an email to
Steve Carter <srcarter@novell.com> with a subject of "WebDAV
Registration"
giving your name, and corporate affiliation (if applicable) by July 9.
This allows Steve to plan food amounts, and to notify Novell security
that
you're coming.

Steve is currently working on arranging a block of rooms at the Provo
Park
Hotel, so if you are planning on attending this meeting, please let
Steve
know soon so he can provide the hotel with a good estimate of the number
of
rooms needed.

Orem, Utah:

Orem is 45 minutes south of the Salt Lake City International airport,
and
is right next to Provo.  My list of local hotels from when I visited
last
December is:

  1) Marriott Courtyard, 1600 N Freedom Blvd, Provo
      tel (801) 373-2222, Reservations: 800 228-9290
  2) Provo Park Hotel, 101 W 100 N Provo
      tel (801) 377-4700, Reservations: 800 777-7144

I have stayed in the Provo Park Hotel, and it was very nice.

 - Jim Whitehead <ejw@ics.uci.edu>


From w3c-dist-auth-request@www10.w3.org  Wed Jun 11 19:54:50 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id TAA26811 for <w3c-dist-auth@www19.w3.org>; Wed, 11 Jun 1997 19:54:50 -0400 (EDT)
Received: from crash.novalink.com (crash.novalink.com [192.233.90.218]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id TAA24505 for <w3c-dist-auth@w3.org>; Wed, 11 Jun 1997 19:54:49 -0400 (EDT)
Received: from dongeo ([192.233.90.81]) by crash.novalink.com
          (Post.Office MTA v3.1 release PO203a ID# 0-36389U100L2S100)
          with SMTP id AAA108 for <w3c-dist-auth@w3.org>;
          Wed, 11 Jun 1997 20:51:48 -0400
Message-ID: <339F3BA1.2DB3@novalink.com>
Date: Wed, 11 Jun 1997 19:58:25 -0400
>From: jradoff@novalink.com (Jon Radoff)
Reply-To: jradoff@novalink.com
Organization: NovaLink
X-Mailer: Mozilla 3.01Gold (WinNT; I)
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
Subject: Access Control Preliminary Draft
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

Here is the preliminary access control requirements draft.

This is based on some of the general consensus reached here
on the list:

   1) Treating security policies as a resource was popular;
   2) Not including issues pertaining to authentication,
      auditing and encryption were favored;
   3) The methods should work within the framework of HTTP 1.1 as
      extended by WebDAV.

Please send all your comments this way.  I will be periodically
posting proposed changes/additions/deletions and will post a
proposed final draft after discussion starts to die down.

-------


   Proposed Requirements for Access Control within Distributed
           Authoring and Versioning Environments on the WWW

                      * * * Proposed Draft * * *

[Standard Document format and jargon to be done]

1.0 Abstract

To provide a robust model for modifying documents and data within
a distributed World Wide Web authoring environment, it is necessary
to furnish a methodology which controls access to objects.  Access
control may include the ability to read an object, modify an
object, or perform other more advanced functions upon an object.
Access control is necessary to prevent unauthorized access or
modification of objects within the authoring environment which
could lead to unintended loss, damage or disclosure of data.

This document describes functionality which could be incorporated
within the existing HTTP framework [1] to provide standardized
methods which would allow Web Servers, Web Applications and
Web Distributed Authoring and Versioning Tools (WebDAV) to
exchange and process information regarding access controls.

2.0 Rationale

The IDC report, "The Intranet's Many Faces" [2] points to
"Central Administration of user access rights and restrictions" as
an essential benefit of Web-based technology.  Unfortunately, this
fundamental requirement has not been standardized.  Existing Web
Server and Authoring Tool implementations do not have
an interoperable mechanism for assigning access control information
to a particular resource or requesting access control information
about a particular resource.

Present access control mechanisms, including native-operating system
methods and Web-based htaccess mechanisms do not adequately address
the need for managing the modification of documents within a
distributed authoring environment.  Native operating system methods
are ineffective because the users responsible for modifying
information on the Web site are generally not logged in
interactively to the server in a manner that maps their identity
to a local user-id.  Further, there are significant differences
between access control implementations on different operating
systems which make it difficult or impossible to create standardized
authoring tools that recognize access control information on different
platforms.  The "htaccess" file utilized on many Web Servers today
deals principally with read permission, and is unsuitable for the
more complex access control issues that exist in the distributed
authoring environment.

In addition, authoring tools need to the ability to assign permissions
to particular resources from within the authoring environment.  To
have a reasonable level of management, it is necessary to both
read and query for access control information within the framework
of the proposed HTTP standard.

This document describes requirements for a set of methods which
could be implemented within the framework of the proposed
HTTP standard for the following:

   Creation and modification of security policies
   Assignment of security policies to resources
   Querying for policy information on a resource
   Types of standard access control types

This document also specifies the principles that WebDAV-compliant
Web Server products should adhere to when dealing with resources
bound by security policies.  This will produce a consistent
expectation as to the behavior of access control attributes that
WebDAV applications can depend upon.

3. Terminology

Terminology is intended to be consistent with that specified
in the Internet Draft "Requirements for Distributed Authoring
and Versioning on the World Wide Web" [3].

In addition, the following terms are used within this document:

Access Policy
         A resource which contains information about who and
         under what conditions a particular access is allowed
         or denied.

Access Attribute
         An attribute that relates a specified type of access
         with a named access policy.

Web Application
         A type of resource which may have dynamic output and has
         the ability to interact with users.  A CGI (Command Gateway
         Interface) [4] program is an example of a Web Application.
         There are now numerous other means of implementating Web
         Applications than CGI.

4. General Principles

This section describes a set of general principles that
WebDAV-compliant access control systems should follow in
addition to the principles set forth as overall
WevDAV principles [3].

4.1 Abstraction of Security Implementation

The structure internal to Access Policy resources is not defined.
This is to allow the implementors of Web Servers and applications
maximum flexibility in identifying the relationship between users,
resources and their access capabilities.  Standardizing the
type of information that might be allowed within an access policy at
this point could prematurely limit the ability to create
complex access control rules.

4.2 Open User Authentication

It should not be a requirement that a particular user authentication
method be used.  How users are identified and authenticated and how
they relate to stated Access Policy resources should be handled
within the Web Server or Web Application implementation.  However,
certain recommended methods for user authentication may be
suggested.  Similarly, issues pertaining to user lists, user
list management and how a particular user is integrated with
access policy is left to the Web Server implementation.

5.0 Requirements

Standardized attributes must be provided for the purpose of associating
access control information with individual resources.  This section
covers how access attributes should be implemented.

5.1 Setting of Access Attributes

The setting of access attributes must be handled through the same
protocol that is used to query and specify other attribute data [2].

5.1.1 Rationale

WebDAV already intends to specify the means to set and query metadata.
Since access control information is really just another type of
metadata, there is no apparent reason to produce new ways to tackle
this problem.

5.2 Access Inheritance

It must be possible to assign an access attribute to a collection
(such as a directory).  By default, resources contained in a collection
must inherit access attributes from their parent resource.

5.2.1 Rationale

Inheritance of security information between directories and files
within most file systems behave in this manner.  This promotes an
orthagonal implementation on the Web.

5.3 Reporting to Web Applications

There must be a standard mechanism for reporting changes to access
attributes to Web Applications so that they can take any special
internal actions that might be appropriate for them.  It must be
possible for the Web Application to report back its acceptance or
advisory refusal of the access attribute change.

5.3.1 Rationale

Changing of access attributes on a static resource such as an HTML
document is relatively straightforward.  However, Web Applications
may wish to know that access control data has changes, because they
may need to update their internal information.  This is an
attempt to provide for an object-oriented view of how resources can
provide for their own access control when they are capable of
doing so.

5.4 Access Control to Access Policies

Since access policies are themselves a resource, they can in turn
be controlled by other access policy resources.

5.4.1 Rationale

This is intended to make it simple to administrate changes to access
policy information.

5.5 Standard Access Attributes

This section enumerates the access control attributes that must
be available in any WebDAV implementation.  It is acceptable if
some implementations wish to treat different access attributes
as synonymous (e.g., a change to the attribute controlling "list"
access may simultaneously change both "list" and "read").

5.5.1 Rationale

A set of standard access attributes will facilitate the creation
of interoperable tools that will make it easier to change or
query for access control information.  Further, by standardizing
on certain types of access control methods, we will promote a
more orthagonal implementation upon which tools and users can
base their expectations.

5.5.2 List

A standard access attribute must be provided that governs what
happens when the user wishes to list the contents of a collection
or confirm the existance of a particular resource.

5.5.2.1 Rationale

Experience with file systems has shown that unauthorized access
or attempts at circumventing security policies increase when
users have more information about the contents of the file system.
Therefore, it is helpful to define an access control attribute that
controls whether a user can obtain this information about a
particular resource.

5.5.3 Read-when-unlocked

A standard access attribute must be provided that controls access
to the object when it is in an "unlocked" state.

5.5.3.1 Rationale

Some resource may contain confidential or sensitive information.
It should be possible to limit whether a particular user is allowed
to read the contents of a resource.  "Unlocked" versus "locked"
states are split to allow the possibility of allowing certain
users to read a resource despite an advisory lock.

5.5.4 Read-when-locked

A standard access attribute must be provided that controls access
to that object when it is in a "locked" state.  It is recommended
that the default access control behavior be to deny access to read
the resource except by the owner of the lock.

5.5.5 Modify

A standard access attribute must be provided that controls access
to modify the contents of the object.  Implementations should
check the lock status and apply the appropriate read-when-locked
or read-when-unlocked access control policy prior to any modification
attempt.

5.5.5.1 Rationale

Experience with a wide number of information systems has shown that
different users need the ability to modify different resources.

5.5.6 Delete

A standard access attribute must be provided that governs what
happens when a user wishes to delete a resource.

5.5.6.1 Rationale

Experience with file systems has shown that it is sometimes preferable
to permit certain users to modify a particular resource without
allowing them to delete it.

5.5.7 Change-access-policy

A standard access attribute must be provided that governs what
happens when a user wishes to change an access attribute on
a resource.

5.5.7.1 Rationale

Experience with file systems has shown that there is a significant
desire to separate the management of information content (what
is contained within the resources when a user reads it) from the
manage of access control structure.  Often, different people in
different roles are responsible for these capabilities, and it
may compromise the intended security plan to allow users to change
access control information about a resource even if they are
normally allowed to change or delete it.

6.0 Security

This document generally deals with the issue of access control,
which is a fundamental security issue.  However, this document
raises other security concerns that implementors may wish
to consider.  For example, this requirements document does not
deal with issues pertaining to the integrity of a request to
change an access control attribute to a different access policy.
It is assumed that issues of spoofing, impersonating users,
data integrity and encryption are suitably dealt with elsewhere
and that nothing within the access control requirements preclude
these techniques.

7.0 Acknowledgements

TBD

8. References

[1] T. Julian, R. Villars, "The Intranet's Many Faces,"
Report 11344, International Data Corporation, April 1996.

[2] J. A. Slein, "Requirements for Distributed Authoring
and Versioning on the World Wide Web," Internet Draft,
draft-ietf-webdav-requirements-00.txt, May 1997.

[3] T. Berners-Lee, D. Connolly, "HyperText Markup Language
Specification - 2.0", RFC 1866, MIT/LCS, November 1995.     

[4] "The Common Gateway Interface 1.1," University of Illinois,
http://hoohoo.ncsa.uiuc.edu/cgi, December 1995.


From w3c-dist-auth-request@www10.w3.org  Wed Jun 11 20:01:25 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id UAA26870 for <w3c-dist-auth@www19.w3.org>; Wed, 11 Jun 1997 20:01:25 -0400 (EDT)
Received: from crash.novalink.com (crash.novalink.com [192.233.90.218]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id UAA24523 for <w3c-dist-auth@w3.org>; Wed, 11 Jun 1997 20:01:24 -0400 (EDT)
Received: from dongeo ([192.233.90.81]) by crash.novalink.com
          (Post.Office MTA v3.1 release PO203a ID# 0-36389U100L2S100)
          with SMTP id AAA140; Wed, 11 Jun 1997 20:58:23 -0400
Message-ID: <339F3D2C.1B15@novalink.com>
Date: Wed, 11 Jun 1997 20:05:00 -0400
>From: jradoff@novalink.com (Jon Radoff)
Reply-To: jradoff@novalink.com
Organization: NovaLink
X-Mailer: Mozilla 3.01Gold (WinNT; I)
MIME-Version: 1.0
To: Jim Whitehead <ejw@ics.uci.edu>
CC: w3c-dist-auth@w3.org
Subject: Re: Locking containers
References: <afc490a310021004779b@[128.195.21.209]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

I like the idea of being able to lock out a collection of resources
at once.  My main concern is that this could be somewhat
difficult to implement "well" on a filesystem with lots of
hierarchical levels.  (well = fast + reliable + low-server-consumption)

Jon


From w3c-dist-auth-request@www10.w3.org  Thu Jun 12 10:15:05 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id KAA12740 for <w3c-dist-auth@www19.w3.org>; Thu, 12 Jun 1997 10:15:04 -0400 (EDT)
Received: from f40.hotmail.com (F40.hotmail.com [207.82.250.51]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id KAA27244 for <w3c-dist-auth@w3.org>; Thu, 12 Jun 1997 10:14:56 -0400 (EDT)
Received: (from root@localhost)
	by f40.hotmail.com (8.8.5/8.8.5) id HAA18772;
	Thu, 12 Jun 1997 07:14:07 -0700 (PDT)
Message-Id: <199706121414.HAA18772@f40.hotmail.com>
Received: from 192.86.155.88 by www.hotmail.com with HTTP;
	Thu, 12 Jun 1997 07:14:05 PDT
X-Originating-IP: [192.86.155.88]
>From: "Arun Manchanda" <nalua@hotmail.com>
To: nalua@rocketmail.com
Cc: w3c-dist-auth@w3.org, urn-ietf@bunyip.com
Subject: Re: RFC 2141 on URN Syntax
Content-Type: text/plain
Date: Thu, 12 Jun 1997 07:14:05 PDT
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring



>From w3c-dist-auth-request@w3.org Fri May  9 09:27:02 1997
>Received: by www19.w3.org (8.6.12/8.6.12) id MAA00043; Fri, 9 May 1997 
12:10:42 -0400
>Resent-Date: Fri, 9 May 1997 12:10:42 -0400
>Resent-Message-Id: <199705091610.MAA00043@www19.w3.org>
>Message-Id: <3.0.32.19970509100833.006f06f4@cic-mail.lanl.gov>
>X-Sender: u114212@cic-mail.lanl.gov
>X-Mailer: Windows Eudora Pro Version 3.0 (32)
>Date: Fri, 09 May 1997 10:08:42 -0600
>To: Sukanta Ganguly <SGANGULY@novell.com>
>From: "Ron Daniel, Jr." <rdaniel@lanl.gov>
>Subject: Re: RFC 2141 on URN Syntax
>Cc: w3c-dist-auth@w3.org, urn-ietf@bunyip.com
>Mime-Version: 1.0
>Content-Type: text/plain; charset="us-ascii"
>X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
>X-See-Also: http://www.ics.uci.edu/~ejw/authoring
>Resent-From: w3c-dist-auth@w3.org
>X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/776
>X-Loop: w3c-dist-auth@w3.org
>Sender: w3c-dist-auth-request@w3.org
>Resent-Sender: w3c-dist-auth-request@w3.org
>Precedence: list
>
>At 08:54 AM 5/9/97 -0600, Sukanta Ganguly wrote:
>>Hi,
>>  I wanted to mention some things about the rfc 2141 that I found 
confusing.
>
>You should bring these questions up on the URN-WG list, not the
>Web DAV list. The URN list is urn-ietf@bunyip.com. I have added it
>to the CC list on this reply.
>
>>The syntax for a URN is specified as
>><URN> ::= "urn:" <NID> ":" <NSS>
>>and NSS also has ":" as a characters recognized within the <others> 
rule.
>>Based on this
>>    URN:foo::      -> Is this a valid URN ??
>
>That will depend on the rules for the namespace foo. The URN syntax
>is an attempt to be as liberal as possible so as to allow many
>different namespaces to exist. The rules for particular namespaces
>are intended to be much stricter. As an example, take a look at
>the URN-WG's internet draft on using bibliographic identifiers as URNs.
>Two of the namespaces in that document (ISBN and ISSN) disallow the use
>of ':' and many other characters. The third (SICI) has much more
>liberal rules because SICIs use lots of funny characters.
>
>>I feel that is ":" is used as a reserved terminator of a subsection of 
a
>>rule then it should not be used in the recognized character sets for 
the
>>other sub-sections of the rule. So I would imagine that ":" is not 
present
>>as a recognizable character within the <other> rule of NSS subsection.
>
>The URN sytnax RFC takes a strong position on the first two occurances
>of ':'. After that, it is up to particular namespaces how ':' is or is 
not
>used.
>
>>It just adds an extra amount of parsing effort for the applications to 
have
>>this feature in their parsing mechanisms. I don't say that it is 
impossible
>>to have it, but as a application developer, it  would be a much messy
>>approach for me to write code that has this feature in it. I hope this 
not
>>taken as a negative criticism. 
>
>No, it is not taken as a negative criticism. However, one of the 
requirements
>on URNs was the ability to grandfather legacy naming systems (such as 
SICIs).
>If allowing ':' makes it easier to accomodate some naming schemes, then 
we
>thought it would be worth some additional implementation difficulty. 
The
>additional difficulty seems very small. The first two ':' characters 
are
>required, so once one has stripped off the "urn:" prefix and the NID
>field with its colon, no more special treatment of ':' is required for
>a general URN parser. You will probably want to use the NID to lookup
>special parsing rules for the namespace, but that is another story.
>
>
>>I have a similar concern regarding the usage of "%" character within 
the
>><NSS> subsection. This is what the rule resolution says 
>><NSS> ::= 1*<URN chars>
>><URN chars> ::= <trans> | "%" <hex> <hex>
>><trans> ::= <upper> | <lower> | <number> | <other> | <reserved>
>><reserved> ::= '%" | "/" | "?" | "#"
>>
>>Here we observe that 
>>
>>  <NSS> ::= %    could be a valid rule according to the  rule 
definition. At
>>the same time the system has another defination that says wheneever 
"%" is
>>used two  <hex> characters should be used.
>>
>>  <NSS> ::=%%12  -> could also be a valid syntax for NSS.  
>>
>>My suggestion here is to remove "%" from the <reserved> subsection of 
<NSS>
>>rules.
>>
>>Please let me know if my thinking is along the lines of what the group 
has
>>in mind or am I way out of wack.
>
>Single occurances of '%' are disallowed. '%' is supposed to ALWAYS mean
>that the next two characters will be hex digits that are taken to
>form an octet.
>
>
>>I appreciate your acceptance of my
>>participation in the group.
>>
>>Thank You
>>Sukanta Ganguly
>>
>>>>> Jim Whitehead <ejw@ics.uci.edu> 05/06/97 12:07PM >>>
>>
>>Of potential interest to participants of this WG.
>>
>>- Jim
>>
>>>To: IETF-Announce: ;
>>>Subject: RFC 2141 on URN Syntax
>>>Cc: rfc-ed@isi.edu 
>>>Mime-Version: 1.0
>>>Date: Mon, 05 May 97 13:53:28 PDT
>>>Sender:ietf-announce-request@ietf.org 
>>>From: RFC Editor <rfc-ed@isi.edu>
>>>
>>>
>>>A new Request for Comments is now available in online RFC libraries.
>>>
>>>
>>>        RFC 2141:
>>>
>>>        Title:      URN Syntax
>>>        Author:     R. Moats
>>>        Date:       May 1997
>>>        Mailbox:    jayhawk@ds.internic.net 
>>>        Pages:      8
>>>        Characters: 14077
>>>        Updates/Obsoletes: None
>>>
>>>        URL:        ftp://ds.internic.net/rfc/rfc2141.txt 
>>>
>>>
>>>Uniform Resource Names (URNs) are intended to serve as persistent,
>>>location-independent, resource identifiers. This document sets
>>>forward the canonical syntax for URNs.  A discussion of both existing
>>>legacy and new namespaces and requirements for URN presentation and
>>>transmission are presented.  Finally, there is a discussion of URN
>>>equivalence and how to determine it. This document is the product of
>>>the Uniform Resource Names Working Group of the IETF.
>>>
>>>This is now a Proposed Standard Protocol.
>>>
>>>This document specifies an Internet standards track protocol for the
>>>Internet community, and requests discussion and suggestions for
>>>improvements.  Please refer to the current edition of the "Internet
>>>Official Protocol Standards" (STD 1) for the standardization state 
and
>>>status of this protocol.  Distribution of this memo is unlimited.
>>>
>>>This announcement is sent to the IETF list and the RFC-DIST list.
>>>Requests to be added to or deleted from the IETF distribution list
>>>should be sent to IETF-REQUEST@CNRI.RESTON.VA.US.  Requests to be
>>>added to or deleted from the RFC-DIST distribution list should
>>>be sent to RFC-DIST-REQUEST@ISI.EDU.
>>>
>>>Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
>>>an EMAIL message to rfc-info@ISI.EDU with the message body
>>>help: ways_to_get_rfcs.  For example:
>>>
>>>        To: rfc-info@ISI.EDU 
>>>        Subject: getting rfcs
>>>
>>>        help: ways_to_get_rfcs
>>>
>>>Requests for special distribution should be addressed to either the
>>>author of the RFC in question, or to admin@DS.INTERNIC.NET.  Unless
>>>specifically noted otherwise on the RFC itself, all RFCs are for
>>>unlimited distribution.
>>>
>>>Submissions for Requests for Comments should be sent to
>>>RFC-EDITOR@ISI.EDU.  Please consult RFC 1543, Instructions to RFC
>>>Authors, for further information.
>>>
>>>
>>>Joyce K. Reynolds and Mary Kennedy
>>>USC/Information Sciences Institute
>>>
>>
>>
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                               
>>
>>
>>
>Ron Daniel Jr.              voice:+1 505 665 0597
>Advanced Computing Lab        fax:+1 505 665 4939
>MS B287                     email:rdaniel@lanl.gov
>Los Alamos National Lab      http://www.acl.lanl.gov/~rdaniel
>Los Alamos, NM, USA, 87545  
>
>



---------------------------------------------------------
Get Your *Web-Based* Free Email at http://www.hotmail.com
---------------------------------------------------------


From w3c-dist-auth-request@www10.w3.org  Fri Jun 13 22:10:59 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id WAA13185 for <w3c-dist-auth@www19.w3.org>; Fri, 13 Jun 1997 22:10: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 WAA06508 for <w3c-dist-auth@w3.org>; Fri, 13 Jun 1997 22:10:57 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa23055;
          13 Jun 97 16:57 PDT
X-Sender: ejw@paris.ics.uci.edu
Message-Id: <afc78f2e0202100463f2@[128.195.21.209]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 13 Jun 1997 17:03:41 -0700
To: w3c-dist-auth@w3.org
>From: Jim Whitehead <ejw@ics.uci.edu>
Subject: Re: Access Control Preliminary Draft
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

>Here is the preliminary access control requirements draft.

Thank you for writing up this preliminary access control requirements draft!

Some comments I have are below:


>This document describes requirements for a set of methods which
>could be implemented within the framework of the proposed
>HTTP standard for the following:
>
>   Creation and modification of security policies
>   Assignment of security policies to resources
>   Querying for policy information on a resource
>   Types of standard access control types

I think it's important to keep a good separation of term usage between
"security," which many in the Web community view as "how to keep to
protocol stream safe from snooping," and "access control," which is what
you're talking about here.  I know access control is about keeping your
data secure, but to avoid terminological overload, we should stick to
access control.


>Web Application
>         A type of resource which may have dynamic output and has
>         the ability to interact with users.  A CGI (Command Gateway
>         Interface) [4] program is an example of a Web Application.
>         There are now numerous other means of implementating Web
>         Applications than CGI.

I prefer the term, "data producing process," which is used in RFC 2068,
over "web application," which is a little broad for this meaning -- after
all, a Web browser is a Web application too.

>
>4.1 Abstraction of Security Implementation
>
>The structure internal to Access Policy resources is not defined.
>This is to allow the implementors of Web Servers and applications
>maximum flexibility in identifying the relationship between users,
>resources and their access capabilities.  Standardizing the
>type of information that might be allowed within an access policy at
>this point could prematurely limit the ability to create
>complex access control rules.

There is a real tension between this, and wanting to give a specification
for what a policy object is.  I'm not sure that leaving this unspecified
gives enough information for an interoperable solution.  I definitely feel
uncomfortable with this as a general principle.

>4.2 Open User Authentication
>
>It should not be a requirement that a particular user authentication
>method be used.  How users are identified and authenticated and how
>they relate to stated Access Policy resources should be handled
>within the Web Server or Web Application implementation.  However,
>certain recommended methods for user authentication may be
>suggested.  Similarly, issues pertaining to user lists, user
>list management and how a particular user is integrated with
>access policy is left to the Web Server implementation.

I agree.

>5.1 Setting of Access Attributes
>
>The setting of access attributes must be handled through the same
>protocol that is used to query and specify other attribute data [2].
>

I find that this is blurring the line between requirements and design.

The requirement I see in this paragraph is:

It must be possible to set access control permissions on a resource.

The design decision embodied here is:

Access control permissions should be stored in a metadata item.

>5.1.1 Rationale
>
>WebDAV already intends to specify the means to set and query metadata.
>Since access control information is really just another type of
>metadata, there is no apparent reason to produce new ways to tackle
>this problem.

This is design rationale.

>5.2 Access Inheritance
>
>It must be possible to assign an access attribute to a collection
>(such as a directory).  By default, resources contained in a collection
>must inherit access attributes from their parent resource.

I like this.

>5.3 Reporting to Web Applications
>
>There must be a standard mechanism for reporting changes to access
>attributes to Web Applications so that they can take any special
>internal actions that might be appropriate for them.  It must be
>possible for the Web Application to report back its acceptance or
>advisory refusal of the access attribute change.

OK, this confused me.  Since these requirements should be focusing
exclusively on what facilities can be specified over the wire between a
client and a server, I think this doesn't belong in the requirements
document, since this is a internal server issue.

>
>5.3.1 Rationale
>
>Changing of access attributes on a static resource such as an HTML
>document is relatively straightforward.  However, Web Applications
>may wish to know that access control data has changes, because they
>may need to update their internal information.  This is an
>attempt to provide for an object-oriented view of how resources can
>provide for their own access control when they are capable of
>doing so.
>
>5.4 Access Control to Access Policies
>
>Since access policies are themselves a resource, they can in turn
>be controlled by other access policy resources.

There are really two requirements here:
1) access policies must be stored in a resource
2) the req't listed above

However, #1 above somewhat goes against your design intention of using
attributes to store access control, since the most recent metadata draft
has metadata being part of the state of the resource it describes (links
still exist, though, so a separate access control resource can still be
linked to a resource)

>5.5.2 List
>
>A standard access attribute must be provided that governs what
>happens when the user wishes to list the contents of a collection
>or confirm the existance of a particular resource.

If you have separate access rights for read and for confirm the existence
of a resource, how do they interact?  Persumably if I can read a resource,
it exists, and this is a confirmation of its existence.


>5.5.3 Read-when-unlocked
>
>A standard access attribute must be provided that controls access
>to the object when it is in an "unlocked" state.

Even though this is probably aimed at the scenario I brough up about
reducing access to a resource while editing is taking place, I suspect it
would be wise to keep access control and locking as separate as possible.
So I'd rather see a "read" permission, than the "read locked" and "read
unlocked" permissions.

>5.5.7 Change-access-policy
>
>A standard access attribute must be provided that governs what
>happens when a user wishes to change an access attribute on
>a resource.

If access control permissons are stored in a resource, then that resource
is subject to the "modify" access right, and hence there wouldn't be a
separate access permission for access permission resources.

That said, I think it makes sense to keep this requirement.


I've always thought that the easiest approach for access control on the Web
would be to create a matrix of:

{resource x HTTP method x {list of principals}}

So, one entry might be:

/jon/index.html GET *any*
/jon/index.html PUT jradoff

The most important concept for this document being the exact 1:1
correspondence between methods and access lists.  Some of your categories
cut across several HTTP methods, and I'm not sure that's a good thing.
Perhaps there should be requirements like:

Each HTTP method must have separate access permissions (excepting maybe
TRACE and OPTIONS).

But, since I like the grouping idea:

A mechanism for grouping related methods into a more abstract, named access
control permission must be available.

This way different access control schemes can be described using the same
primitives (which are HTTP methods).

- Jim



From w3c-dist-auth-request@www10.w3.org  Mon Jun 16 05:53:41 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id FAA22153 for <w3c-dist-auth@www19.w3.org>; Mon, 16 Jun 1997 05:53:41 -0400 (EDT)
Received: from go.opentext.ch (go.opentext.ch [195.48.77.130]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id FAA12239 for <w3c-dist-auth@w3.org>; Mon, 16 Jun 1997 05:53:38 -0400 (EDT)
Received: (from root@localhost) by go.opentext.ch (8.7.3/GO-3a) id LAA20701; Mon, 16 Jun 1997 11:39:54 +0200 (MET DST)
Received: from gammon.opentext.ch(195.48.77.115) by go.opentext.ch via smap (V1.3)
	id sma020699; Mon Jun 16 11:39:51 1997
Received: from cassius.opentext.ch (cassius.opentext.ch [195.48.77.23]) by gammon.opentext.ch (8.6.12/8.6.9) with SMTP id LAA07121; Mon, 16 Jun 1997 11:56:20 +0100
Received: by cassius.opentext.ch with Microsoft Mail
	id <01BC7A19.34CDB9C0@cassius.opentext.ch>; Mon, 16 Jun 1997 05:50:33 -0400
Message-ID: <01BC7A19.34CDB9C0@cassius.opentext.ch>
>From: Dylan Barrell <dbarrell@opentext.ch>
To: "'Jim Whitehead'" <ejw@ics.uci.edu>,
        "w3c-dist-auth@w3.org"
	 <w3c-dist-auth@w3.org>
Subject: RE: Locking containers
Date: Mon, 16 Jun 1997 05:50:32 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

This should be solved by forcing the lock on the collection to lock all =
sub-resources. If this is not the case then what is the point of a lock =
on a collection?

Cheers
Dylan

----------
>From:  Jim Whitehead[SMTP:ejw@ics.uci.edu]
Sent:  Mittwoch, 11. Juni 1997 16:08
To:  w3c-dist-auth@w3.org
Subject:  Locking containers

One issue still remaining in the current locking draft (available at
<http://www.ics.uci.edu/~ejw/authoring/proposals/locking.html>) is how =
to
handle an exclusive write lock on a container.

At present, an exclusive write lock on a container prevents modification =
of
the membership of the container by any principal other than the owner of
the lock, i.e., preventing the addition and removal of members of the
collection. So far, so good.

However, an exclusive write lock on a member of a collection is =
currently
defined such that the owner of the lock may delete the resource.

The dilemma occurs during the following scenario: Principal P1 takes out =
an
exclusive write lock on Resource B which is a member of collection A.
Principal P2 later takes out an exclusive write lock on collection A.  =
What
does each lock mean in this situation?  If P2 can delete B, what then is
the meaning of the lock on A?  It appears that in this case, the meaning =
of
the lock depends on the state of locks on other resources, which is not
desirable.

This raises some questions.

1) Is it useful to allow locking of containers at all?

2) Assuming it is useful (I suspect there are many cases where this
functionality is needed), which of the several ways of solving this is
best?

One way is to mandate that an exclusive write lock on a container must =
lock
all members and subcollections -- if there are any existing locks on any
members, or members of subcollections, then the lock request fails.  =
Thus
there is no problem with locks changing meaning, because a lock of a
container also locks its members.  However, performing a recursive lock
like this is expensive, especially if you only want to make changes at =
one
level of a multi-level hierarchy.

Another way is to define an exclusive write lock such that the owner of =
the
lock is not guaranteed the ability to DELETE the resource (assuming they
have sufficient access rights to delete the resource).  To guarantee the
ability to delete the resource, they need to lock the collection =
containing
the resource.  This is less expensive than locking all levels of the
hierarchy, but does have the drawback that there is very little =
difference
between deleting a resource (which would not be allowed by a lock on an
individual resource) and zeroing out the contents of a resource (which =
is
allowed by an exclusive write lock on an individual resource).

- Jim




From w3c-dist-auth-request@www10.w3.org  Mon Jun 16 08:06:14 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id IAA23687 for <w3c-dist-auth@www19.w3.org>; Mon, 16 Jun 1997 08:06:13 -0400 (EDT)
Received: from go.opentext.ch (go.opentext.ch [195.48.77.130]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id IAA12546 for <w3c-dist-auth@w3.org>; Mon, 16 Jun 1997 08:06:12 -0400 (EDT)
Received: (from root@localhost) by go.opentext.ch (8.7.3/GO-3a) id NAA22356; Mon, 16 Jun 1997 13:52:28 +0200 (MET DST)
Received: from gammon.opentext.ch(195.48.77.115) by go.opentext.ch via smap (V1.3)
	id sma022353; Mon Jun 16 13:52:26 1997
Received: from cassius.opentext.ch (cassius.opentext.ch [195.48.77.23]) by gammon.opentext.ch (8.6.12/8.6.9) with SMTP id OAA07445; Mon, 16 Jun 1997 14:08:53 +0100
Received: by cassius.opentext.ch with Microsoft Mail
	id <01BC7A2B.991369E0@cassius.opentext.ch>; Mon, 16 Jun 1997 08:02:12 -0400
Message-ID: <01BC7A2B.991369E0@cassius.opentext.ch>
>From: Dylan Barrell <dbarrell@opentext.ch>
To: "'Jon Radoff'" <jradoff@novalink.com>,
        "w3c-dist-auth@w3.org"
	 <w3c-dist-auth@w3.org>
Subject: RE: Access Control Preliminary Draft
Date: Mon, 16 Jun 1997 08:02:10 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

>5.2 Access Inheritance
>
>It must be possible to assign an access attribute to a collection
>(such as a directory).  By default, resources contained in a collection
>must inherit access attributes from their parent resource.
>
>5.2.1 Rationale
>
>Inheritance of security information between directories and files
>within most file systems behave in this manner.  This promotes an
>orthagonal implementation on the Web.

I think that specifying that the access attributes must inherit from the =
parent resource will require us to specify too many details regarding =
the semantics of changing the permissions of the various resources (eg =
what happens to the children's access attributes when we change those of =
the parent). I think this should be restated as

"5.2 It must be possible to assign an access attribute to a collection =
(such as a directory).  The system must assign appropriate default =
access attributes to resources added to a collection."

5.5.3 and 5.5.4

I don't see the necessity for splitting between locked and unlocked =
resources when it comes to access control. It must be possible to access =
a resource for reading when it is locked I would argue in favour of the =
default action being to allow read access to locked resources.



From w3c-dist-auth-request@www10.w3.org  Mon Jun 16 20:00:24 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id UAA07106 for <w3c-dist-auth@www19.w3.org>; Mon, 16 Jun 1997 20:00:23 -0400 (EDT)
Received: from novell.com (orm-mail20.orem.novell.com [151.155.174.10]) by www10.w3.org (8.8.5/8.7.3) with SMTP id UAA15906 for <w3c-dist-auth@w3.ORG>; Mon, 16 Jun 1997 20:00:20 -0400 (EDT)
X-Authentication-Warning: www10.w3.org: Host orm-mail20.orem.novell.com [151.155.174.10] claimed to be novell.com
Received: from INET-ORM-Message_Server by novell.com
	with Novell_GroupWise; Mon, 16 Jun 1997 13:17:47 -0600
Message-Id: <s3a53cfb.098@novell.com>
X-Mailer: Novell GroupWise 4.1
Date: Mon, 16 Jun 1997 13:17:39 -0600
>From: Steve Carter <srcarter@novell.com>
To: hamilton@parc.xerox.COM, w3c-dist-auth@w3.org
Subject: Maps for DMA and WebDAV meetings
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=_2476BF4B.5F3E598B"
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_2476BF4B.5F3E598B
Content-Type: text/plain
Content-Disposition: inline

Please remember to preregister with srcarter@novell.com so that I can have
your badges and security clearance preprocessed. I also need the count for
ordering food and stuff. Please, please preregister!

Attached is a list of hotels (Provo Park is the best and has a block of
rooms available at a corporate rate). Tell them that you are with the
WebDAV/DMA conference at Novell.

Also a map showing how to get from the airport to here and a map of the Orem
campus.

See you all there

***Dennis Hamilton*** I could not see the list server address on the AIIM
home page for DMA. Would you please forward this message out there. Also,
tell me how to subscribe so that I can communicate directly.

-src
Steve Carter
CTO, Novell Applications Division
1555 North Technology Way MS Orem F111
Orem, UT  84097-2399

801-228-5175
801-228-5176 fax
srcarter@novell.com
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
                                                                            
               

--=_2476BF4B.5F3E598B
Content-Type: application/zip
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="info.ZIP"
Content-Description: PKZIP (compressed) files


Z2lmUEsFBgAAAAADAAMArAAAAHBrAgAAAA==

--=_2476BF4B.5F3E598B--


From w3c-dist-auth-request@www10.w3.org  Mon Jun 16 20:11:27 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id UAA07189 for <w3c-dist-auth@www19.w3.org>; Mon, 16 Jun 1997 20:11:27 -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 UAA15930 for <w3c-dist-auth@w3.org>; Mon, 16 Jun 1997 20:11:25 -0400 (EDT)
Received: from rome.ics.uci.edu by paris.ics.uci.edu id aa23589;
          16 Jun 97 16:47 PDT
To: w3c-dist-auth@w3.org
Subject: New properties (metadata) draft
Date: Mon, 16 Jun 1997 16:47:17 -0700
>From: Jim Whitehead <ejw@rome.ICS.UCI.EDU>
Message-ID:  <9706161647.aa23589@paris.ics.uci.edu>
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring


Enclosed is the text of a new draft which satisfies the requirements
for attributes (Section 5.1 of the requirements document), linking
(Section 5.2 of the requirements), and retrieval of unprocessed source
(Requirements Section 5.5).  In this draft, an instance of a piece of
metadata is known as a property.  This draft differs from the previous
draft on metadata operations (the GETMETA, ADDMETA, DELMETA draft) in
that it uses GET to retrieve properties, and employs new PATCH method
to add and delete property values.  A SEARCH method provides the
capability to search properties.

This draft also makes use of the Extended Markup Language (XML) as an
on-the-wire representation for property names and values.  Due to the
recent release of the Meta Content Framework (MCF) draft, and the
similarity between MCF and the XML representation given in this draft,
there is currently debate within the Design Team over whether the
on-the-wire representation should use MCF.  The primary affect of this
debate is limited to Section 2.7, Visualizing a Property Tree Using
XML, which gives an algorithm for converting properties to an XML
representation, although it would also affect the examples throughout.

Since the XML specification has not yet been finalized (although there is
considerable agreement on most of its features) this draft has provided
a description of the subset of XML which is used within the specification.
This description occurs towards the end of the specification, in
Appendicies 1-5.  It also appears that this spec. mistakenly uses the
term "XML entity" instead of "XML element."


The properties draft is available at URL:
http://www.ics.uci.edu/~ejw/authoring/proposals/properties.html

The latest XML specification is available at URL:
http://www.textuality.com/sgml-erb/WD-xml-lang.html

The MCF proposal is available at URL:
http://developer.netscape.com/mcf.html


Your comments and ideas on this draft are definitely appreciated.

- Jim



               A Data Model and Operations for DAV Properties

Version 0.1, June 16, 1997

1 Introduction

1.1 Introduction

Properties are pieces of data that describe the state of a resource.
Properties are data about data. The term property is used within this
proposal to disambiguate the concept from the overloaded terms "metadata"
and "attribute".

Properties are used within distributed authoring environments to provide for
efficient discovery and management of resources. For example, a subject
property allows for the indexing of all resources by their subject and an
author property allows for the discovery of what authors have written which
documents. As explored in the next section, properties have a long history,
having proven themselves essential to the maintenance of large document
repositories.

1.2 Existing Metadata Proposals

Many current proposals contain some notion of a property. These include PICS
[Miller et al., 1996], PICS-NG, the Rel/Rev draft [Maloney, 1996], Web
Collections, XML [Bray, 1997], several proposals on representing
relationships within HTML, digital signature manifests (DCMF), and a
position paper on Web metadata architecture [Berners-Lee, 1997].

Some proposals come from a digital library perspective. These include the
Dublin Core [Weibel et al., 1995] metadata set and the Warwick Framework
[Lagoze, 1996], a container architecture for different metadata schemas. The
literature includes many examples of metadata, including MARC [MARC, 1994],
a bibliographic metadata format, RFC 1807 [Lasher, Cohen, 1995], a technical
report bibliographic format employed by the Dienst system, and the
proceedings from the first IEEE Metadata conference describe many
community-specific metadata sets.

Participants of the 1996 Metadata II Workshop in Warwick, UK [Lagoze, 1996],
noted that, "new metadata sets will develop as the networked infrastructure
matures" and "different communities will propose, design, and be responsible
for different types of metadata." These observations can be corroborated by
noting that many community-specific sets of metadata already exist, and
there is significant motivation for the development of new forms of metadata
as many communities increasingly make their data available in digital form,
requiring a metadata format to assist data location and cataloging.

1.3 Properties and HTTP Headers

Properties already exist, to a certain extent, within HTTP through the use
of message headers. However, in distributed authoring environments a
relatively large number of properties are needed to fully describe the state
of a resource and setting/returning them all through HTTP headers is
inefficient. Thus a mechanism is needed which allows a principal to identify
a set of properties in which the principal is interested and to then set or
retrieve just those properties.

1.4 Why Another Draft?

Given that this is the fourth major draft on metadata capabilities submitted
to the WebDAV working group, a reasonable question to ask is, "Why another
draft?" In short, the following limitations in "A Proposal for Web Metadata
Operations" [WebDAV, 1997] led to the development of this new proposal:

Poor Internationalization Support. While the simple name/value pairs in
[WebDAV, 1997] do allow the value field to contain an arbitrary sequence of
octets, there is no way to indicate their character encoding.

No Typing Support. Similar to the internationalization support, there is no
way to indicate the encoding of binary data in a value field in [WebDAV,
1997], for example, to indicate a sequence of octets should be viewed as an
integer, or as a floating point number,

Proliferation of Methods. Since [WebDAV, 1997] does not contain a naming
mechanism that combines the name of the resource and the name of the
property into a single name, the methods GETMETA, DELMETA, and ADDMETA are
necessary to "glue" together the name of the resource and the name of the
property.

No Sub-Properties. In [WebDAV, 1997] there is no way to define a property
which describes another property (i.e., data about properties), yet this
facility is useful for refining the meaning of a property. One important use
of sub-properties is to indicate their "liveness," whether the server is
enforcing the syntax and semantics of the property.

This draft introduces two main innovations: a tree data model for
properties, and a property naming mechanism for combining the URI of a
resource and the URI for a property type into a single URI which identifies
an instance of that property on the resource. The tree data model provides
support for sub-properties, which then afford typing support and
internationalization support. The property naming mechanism allows existing
HTTP/1.1 methods (GET, DELETE, PUT) to be used for operations on properties,
thus reducing the number of new methods and helping to ensure the utility of
methods as a mechanism for caching and security.

2 A Property Model for HTTP Resources

2.1 Overview

A property consists of a name and a value. However it is often the case that
a property may itself contain properties, such as a sub-property which
specifies its parent property is read only. The combination of properties
and sub-properties creates a tree.

  Resource Root Property
            |
         Property
        /       \
  Read Only      (Some Value)
       |
    Yes/No

2.2 Property Tree

The properties defined on a resource create a tree structure, whose root
node is called the root property. The property tree consists of two types of
nodes, a property node and a value node. A property node may have any number
of children, those children may in turn consist of any number and any
combination of property and values nodes. The ordering of these children
must be maintained. Value nodes do not have any children as they can not
contain properties, only a value. Property nodes are named, value nodes are
referred to via their parent.

To conceptualize this property model, one builds the previously mentioned
tree. Internal nodes are property nodes and leaf nodes are value nodes.

2.3 Multivalued Properties

It is possible for the children of a property to contain several properties
that have the same name. In order to prevent confusion among identically
named siblings, the ordering of siblings MUST be maintained by the resource.
Thus it is now possible to differentiate siblings through the use of an
index.

2.4 Property Names

A property name identifies both the syntax and semantics of the children of
a property node. It is critical that property names do not collide, that is,
two principals defining the same property name with two different meanings.

The URI framework provides for a mechanism to prevent namespace collision
and for varying degrees of administrative control. Rather than reinvent
these desirable features, DAV properties make use of them by requiring that
all DAV property names MUST be URIs.

2.5 Schemas

A schema is a group of property names. A schema may also define
relationships between properties. It is often useful to indicate support for
a particular schema in a request or a response. Schema discovery is also
useful for determining if a system supports a group of properties. A
property does not necessarily contain sufficient information to identify any
schemas it may be a member of.

As with property names, schemas MUST use URIs as their names.

2.6 Property Morphing

2.6.1 Problem Definition

Property definitions change in two ways, either a new property is added or
the value is marked up with new information.

An example of the first class of change will soon be upon us. The Digital
Signature (DSIG) group at the W3C
<http://www.w3.org/Security/DSig/Overview.html> is currently working on a
mechanism for signing chunks of data and properties. A value that previously
consisted of only a string will be turned into a property containing a
signature property and the string value. What would an older client, written
before DSIG, do? Where once it looked only for a string, now it finds a
string and a property.

An example of the second class of change, markup can turn unstructured data
into structured data. For example, a string which once contained a name is
instead turned into two properties, one indicating the personal name and the
second indicating the family name. What would an older client, written
before the marked up format, do? Where once the client looked only for a
string, now it finds two properties.

2.6.2 Solution Requirements

A mechanism must be provided so that a client can examine the children of a
property and upon encountering unknown properties know to either ignore the
unknown property or to ignore the markup and promote the property's children
one level up the parse tree.

2.7 Visualizing a Property Tree Using XML

While it is possible to visualize tree structures in many ways, for use by
WebDAV, this specification defines a linear visualization of property trees
using the Extensible Markup Language (XML) [Bray, 1997] suitable for
transmission as part of an HTTP protocol stream.

A sketch of an algorithm for creating an XML linearization of a property
tree is given below.

Begin by printing an "<XML>" element, if this is a standalone document.

Next, perform a traversal of the property tree, collecting the set of all
schemas used by all properties. Print one "<XML:Namespace>" ... "<AS>" XML
entity pair for each schema in use, ensuring that unique tags are used in
the "<AS>" XML entities. Save the mapping between schema names.

Next, perform a preorder traversal of the tree. For each node, print its
name as "<"{unique schema tag}":"{property URI which is relative to the
schema's URI}">", then print its value, then print "</>". Note that the
process is recursive for values which contain properties. Whitespace may be
printed between XML entities for prettyprinting.

Print a closing "</>" (to close the "<XML>") if the document is standalone.

A detailed description of "<XML:Namespace>" and "<AS>" XML entities is given
in Appendix 4.

3 Property Identifiers

3.1 Problem Definition

The addition of properties to the HTTP object model result in the state of
HTTP resources containing two separate areas, the body of the resource and
the properties of the resource. A mechanism is needed to unambiguously refer
to both.

3.2 Solution Requirement

The mechanism used for referring to the resource directly must also be
usable for referring to the resource's properties in such a manner that even
non-DAV aware clients can retrieve DAV properties.

3.3 DAV URL Parameter

To allow for the specification of property information in the context of an
http scheme URL, a switch is needed. This switch indicates that the path
segments following it specify a property location. To this end the "DAV"
param is introduced for use with http scheme URLs. All path segments to the
right of the DAV param MUST be formatted according to the XML Link standard,
described in appendix 3, XML Linking.

3.4 Hierarchical Naming

Properties on a resource are referred to as a hierarchy from the root
property on down. Thus if a resource has an author property defined on its
root property, which itself contains a family name property, then a
hierarchy three levels deep is needed to refer directly to the family name
property.

Root Property - Author Property - Family Name Property

The Root property is defined as "/". However both the author and family name
properties are referred to using URIs. The XML Link standard provides a
mechanism to refer to nested URIs.

For example, the following properties are defined on
http://somewhere.com/resource.

<XML>
 <Namespace><Ref>http://www.w3.org/standards/z39.50/</><AS>Z</></>
 <Namespace><Ref>AIIM:Dublin:</><AS>D</>
 <Z:Author><D:PersonalName>Shirley</><D:FamilyName>Mansai</></>
</>

To create a reference to the value "Mansai" one would perform the following
steps.

  1. Add the DAV parameter to the base URI,
     http://somewhere.com/resource;DAV.
  2. Add "/" to refer to the root of the resource's property namespace,
     http://somewhere.com/resource;DAV/.
  3. Change the author attribute's name into parameter format by changing
     the "/" to "!" and encasing it in parenthesis. We must encase it in
     parenthesis in order to indicate that we have made the "/" to "!"
     translation. We make the translation in order to prevent confusion over
     where segments are and to make sure that relative URIs will continue to
     work.
     http://somewhere.com/resource;DAV/(http:!!www.w3.org!standards!z39.50!author).
  4. Next we continue the path by adding the family name attribute. Because
     it does not include any "/" it does not require encoding.
     http://somewhere.com/resource;DAV/(http:!!www.w3.org!standards!z39.50!author)/AIIM:Dublin:FamilyName.

The process is now complete, the URL can be used in a GET or PATCH to
retrieve or alter the value. See appendix 3 for more information.

3.5 Compatibility with legacy systems

3.5.1 Problem Definition

The HTTP parameter space is uncontrolled, thus someone may already be using
a parameter with a value of "DAV" for some end other than the one described
here. Thus a client sending a URI with a DAV param to a server may receive
an unexpected or inappropriate response.

3.5.2 Solution Requirement

A mechanism is needed to prevent namespace collisions.

3.5.3 Proposed Solution

All DAV compliant servers MUST honor the DAV param type on http URLs. Thus
if a client knows it is talking to a DAV server, it can safely send an http
URL with the DAV param.

The client may send the http URL with the DAV param extension to a server
that is not know to be DAV compliant if the client uses PEP [Connolly, 1997]
to prevent collisions. The proper PEP header is:

DAVPEP = "PEP: {{map "DAV"}{strength must}}"

Note that this header PEP header is not compliant with [Connolly, 1997] but
the author has spoken with the authors of the PEP draft and they will be
changing the format to make the example legal.

4 DAV Schema

The DAV Schema is specified as http://www.ietf.org/standards/dav/. This
schema is used to indicate support for properties that can be defined on a
resource and XML entities that can be returned in responses.

4.1 Properties

4.1.1 Live Property

Name: http://www.ietf.org/standards/dav/live
Purpose: To indicate that the parent property has its syntax and semantics
enforced by the resource on which it is recorded.
Schema: http://www.ietf.org/standards/dav/
Parent: Any property
Values: None
Description: This property is used exclusively in a response to indicate if
the resource a property is recorded on is enforcing the syntax and semantics
of the property. The absence of the Live property tells the client that the
corresponding property does not have its syntax and semantics enforced by
the resource on which it is recorded.

4.1.2 ReadOnly Property

Name: http://www.ietf.org/standards/dav/readonly
Purpose: To indicate that the parent property can only be retrieved, not set
through the property mechanism.
Schema: http://www.ietf.org/standards/dav/
Parent: Any property
Values: None
Description: This property is used to indicate that the parent property can
only be retrieved, not set through the property mechanism. This property is
not meant as an access control mechanism but rather to reflect the fact that
the property is not designed to have its value set through the property
mechanism.

5 Link Property

5.1 Problem Description

A mechanism is needed to associate resources with other resources. These
associations, also known as links, consist of three values, a type
describing the nature of the association, the source of the link, and the
destination of the link. In the case of annotation, the source and
destination of a link may not be the resource upon which the link is
recorded.

5.2 Solution Requirements

The association mechanism must make use of the property mechanism in order
to make the existence of the associations searchable.

5.3 Link Property

Name: http://www.ietf.org/standards/dav/link
Purpose: To indicate the existence of a link associated with the parent
property.
Schema: http://www.ietf.org/standards/dav/
Parent: Any property that needs to have a link associated with it.
Values: Src 1*Dst
Description: Link is used to provide the source and one or more destinations
of the link. The parent property provides the type. Link is a multivalued
property so multiple Links may be used together to indicate multiple links
with the same type.

5.4 Src Property

Name: http://www.ietf.org/standards/dav/src
Purpose: To indicate the source of a link.
Schema: http://www.ietf.org/standards/dav/
Parent: http://www.ietf.org/standards/dav/link
Values: URI

5.5 Dst Property

Name: http://www.ietf.org/standards/dav/Dst
Purpose: To indicate one or more destinations of a link
Schema: http://www.ietf.org/standards/dav/
Parent: http://www.ietf.org/standards/dav/link Values: URI

5.6 Example

<XML>
        <Namespace><Ref>http://www.ietf.org/standards/dav/</><AS>D</></>
        <Namespace><Ref>http://www.foocorp.com/Project/</><AS>F</></>
        <D:Source>
                <D:Link>
                        <F:ProjectFiles>Source</>
                        <src>http://foo.bar/program</>
                        <dst>http://foo.bar/source/main.c</>
                </>

                <D:Link>
                        <F:ProjectFiles>Library</>
                        <src>http://foo.bar/program</>
                        <dst>http://foo.bar/source/main.lib</>
                </>

                <D:Link>
                        <F:ProjectFiles>Makefile</>
                        <src>http://foo.bar/program</>
                        <dst>http://foo.bar/source/makefile</>
                </>
        </>
</>

In this example the resource http://foo.bar/program has a source property
defined on it which contains three links. Each link contains three
properties, two of which, src and dst, are part of the DAV schema, defined
in this document, and one which is defined by the schema
http://www.foocorp.com/project/ (Source, Library, and Makefile). A client
which only implements the properties in the DAV spec will not know what the
foocorp properties are and will ignore them, thus seeing the expected source
and destination links. However an enhanced client may know about the foocorp
properties and thus be able to present the user with additional information
about the links.

6 Properties and Methods

6.1 DELETE

The delete method, when used on a property, causes the property and its
children to be removed.

6.2 GET

A GET on a property returns the name of the property and its children.
Accept types may be used to specify the format of the return value but all
DAV compliant servers MUST at minimum support a return type of
application/XML. If application/XML is used as the response format then it
MUST include the http://www.ietf.org/standards/dav/ schema.

6.2.1 GetResult XML Entity

Name: http://www.ietf.org/standards/dav/getresult
Purpose: To contain the results of a GET request
Schema: http://www.ietf.org/standards/dav/
Parent: Any, usually <XML>
Values: An XML Entity
Description: The GetResult XML Entity provides the context to inform the
client that its contents are not just some XML entity, but an XML
representation of the requested property.

6.2.2 Example

GET bar;DAV/(http:!!www.w3.org!standards!z39.50!Authors) HTTP/1.1
Host: foo.com

HTTP/1.1 200 OK
Content-Type: application/xml
Content-Length: xxxx
E-tag: "1234"
Last-Modified: xxxx

<XML>
        <XML:Namespace><Ref>http://www.ietf.org/standards/dav/</><AS>D</></>
        <XML:Namespace><Ref>http://www.w3.com/standards/z39.50/</><AS>Z</></>
        <D:GetResult><Z:Authors>
                        <Author>Jane Doe</>
                        <Author>Joe Doe</>
                        <Author>Lots o'Doe</>
</>     </>     </>

6.3 PATCH Method

The PATCH method, in the most general sense, specifies how to alter a
resource. The message body controls the actual action taken by a PATCH. All
DAV compliant servers are required to support the use of the application/XML
content-type using the http://www.ietf.org/standards/dav/patch/ schema in a
PATCH method with a request-URI that points to a property.

The changes in a http://www.ietf.org/standards/dav/patch/ request MUST be
atomically executed, partial results are not allowed.

6.3.1 Request URI

The request URI of a PATCH method with the
http://www.ietf.org/standards/dav/patch/ schema MUST point to the root of
the resource's properties.

6.3.2 PropertyUpdate XML Entity

Name: http://www.ietf.org/standards/dav/patch/PropertyUpdate
Purpose: To contain a request to alter the properties on a resource.
Schema: http://www.ietf.org/standards/dav/patch/
Parent: <XML>
Value: *(Create | Remove | Insert)
Description: This XML entity is a container for the information required to
modify the properties on the resource. This XML Entity is multivalued.

6.3.3 Create XML Entity

Name: http://www.ietf.org/standards/dav/patch/create
Purpose: To create the DAV property specified inside the Create XML entity.
Schema: http://www.ietf.org/standards/dav/patch/
Parent: http://www.ietf.org/standards/dav/patch/PropertyUpdate Values:
XML:Ref PatchValue
Description: This XML entity contains two values, a Ref and a PatchValue.
The Ref contains the name of the property to be created or overwritten, this
URI in Ref MUST be a relative URI whose base is the request-URI. The
PatchValue XML entity contains the value the new property is to have, this
value can contain both property and value nodes.

6.3.4 Remove XML Entity

Name: http://www.ietf.org/standards/dav/patch/remove
Purpose: To remove the DAV property specified inside the Remove XML entity.
Schema: http://www.ietf.org/standards/dav/patch/
Parent: http://www.ietf.org/standards/dav/patch/PropertyUpdate Values:
XML:Ref
Description: Remove orders that the property specified in Ref and its
children removed. Ordering the removal of a property that does not exist is
not an error. The URI in Ref MUST be a relative URI whose base is the
request-URI.

6.3.5 Insert XML Entity

Name: http://www.ietf.org/standards/dav/patch/insert
Purpose: To insert a DAV property between other DAV properties of the same
name.
Schema: http://www.ietf.org/standards/dav/patch/
Parent: http://www.ietf.org/standards/dav/patch/PropertyUpdate
Values: InsertPoint InsertName PatchValue
Description: Insert is used to insert the property referred to in
InsertName, whose value is given in PatchValue, at the position held by the
value specified in InsertPoint.

[Author's Note - Currently there is no way to directly address a value. So
if I have the equivalent of <foo>bar<blah></>oops</> there is no way for me
to say "I want "oops" to become "correct"". I have to replace the entire foo
property.]

6.3.6 InsertPoint XML Entity

Name: http://www.ietf.org/standards/dav/patch/InsertPoint
Purpose: To specify a property that the new property should either be
inserted before or after.
Schema: http://www.ietf.org/standards/dav/patch/
Parent: http://www.ietf.org/standards/dav/patch/Insert
Values: Position Ref
Description: The value in the Ref MUST be a relative URI whose base is the
request-URI.

6.3.7 Position XML Entity

Name: http://www.ietf.org/standards/dav/patch/position
Purpose: To specify if the property to be inserted is to be inserted before
or after the property specified in InsertPoint.
Schema: http://www.ietf.org/standards/dav/patch/
Parent: http://www.ietf.org/standards/dav/patch/InsertPoint
Values: "Before" | "After"
Description: If the value is Before then the property specified in
InsertName is to be inserted in the position directly before the position
held by the property specified in InsertPoint. If the value is After then
the property specified in InsertName is to be inserted in the position after
the position held by the property specified in InsertPoint.

6.3.8 InsertName XML Entity

Name: http://www.ietf.org/standards/dav/patch/position
Purpose: To specify the name of the new property to be inserted
Schema: http://www.ietf.org/standards/dav/patch/
Parent: http://www.ietf.org/standards/dav/patch/Insert
Values: Ref
Description: The Ref's value is the name of the property to be created at
the position specified by InsertPoint. The URI MUST be relative and its base
MUST be the request-URI. The value MUST NOT have an index on it.

6.3.9 PatchValue XML Entity

Name: http://www.ietf.org/standards/dav/patch/patchvalue
Purpose: To specify the name and when appropriate the value, of the
particular property to be altered.
Schema: http://www.ietf.org/standards/dav/patch/
Parent: Any parent which needs to specify the contents of a property
Values: The contents of a property

6.3.10 Response Codes

200 OK - The command succeeded. As there can be a mixture of PUT and DELETEs
in a body, a 201 Create seems inappropriate.

400 Bad Request - The client has provide a value whose syntax is illegal for
the property.

401 Unauthorized - The client does not have authorization to alter one of
the properties. This error also occurs if a property is inherently read
only.

403 Forbidden - The client, for reasons the server chooses not to specify,
can not alter one of the properties.

405 Conflict - The client has provided a value whose semantics are not
appropriate for the property.

6.3.11 Example

PATCH bar;DAV/ HTTP/1.1
Host: www.foo.com
Content-Type: application/XML
Content-Length: xxxx

<XML>
        <XML:Namespace><Ref>http://www.ietf.org/standards/dav/patch/</><AS>P</></>
        <XML:Namespace><Ref>D:patch/</><AS>P</></>
        <XML:Namespace><Ref>http://www.w3.com/standards/z39.50/</><AS>Z</></>
        <XML:Namespace><Ref>http://www.w3.com/standards/dublin/</><AS>D</></>
        <P:PropertyUpdate>
                <Create>
                        <XML:Ref>Z:authors</>
                        <PatchValue>
                                <Author>Jim Whitehead</>
                                <Author>Roy Fielding</>
                        </>
                </>

                <Remove><Ref>D:Copyright-Onwer</></>
                <Insert>
                        <InsertPoint><Position>Before</><XML:Ref>Z:producer</></>
                        <InsertName><XML:Ref>Z:Last-Modified</></>
                        <PatchValue></>
                </>
                <Insert>
                        <InsertPoint><Position>After</><XML:Ref>Z:editor(1)</></>
                        <InsertName><XML:Ref>Z:editor</></>
                </>
</>     </>

6.4 PUT

A PUT is specified in order to control what is returned by a GET. However a
GET on a property always returns some sort of property containment format.
As such PUT can not be used if the Request-URI refers to a property.

6.5 SEARCH

[Author's Note: The search section has never had a very good specification
and there has never been very wide agreement on what features should be made
available. The search specified here is the authors best efforts to try and
synthesize all the features and restrictions which have been asked for to
date.]

6.5.1 Request-URI

The request-URI of the search method specifies the scope of the search. If
the request-URI does not contain the ";DAV/" switch then the scope of the
search is all the properties on that resource. If the request-URI in the
previous case is a collection then the scope of the search is extended to
the collection's propagate members. If the request-URI specifies part of the
property space then the search is restricted to only that property space on
that resource, even if the resource is a container.

So, for example if http://www.foo.com/bar was the request-URI but not a
container, the search would be across all of http://www.foo.com/bar's
properties.

If was a container, then the search would be across all the properties on
and all its propagate member's properties. However if the request-URI were
http://bar/foo;DAV/ then the scope would only be the properties on
http://bar/foo, not on any of its propagate members.

The Depth header MUST NOT be used on a SEARCH method.

6.5.2 Command Format

The effects of a SEARCH method are defined by the message body. This section
defines an application/xml content type using the
http://www.ietf.org/standards/dav/search/ schema. This method is not
normally cacheable.

6.5.2.1 Limited-Search XML Entity

Name: http://www.ietf.org/standards/dav/search/limited-search
Purpose: To specify the set of matching properties
Schema: http://www.ietf.org/standards/dav/search/
Parent: <XML>
Values: The value is a single OR. The OR may only contain ANDs. The ANDs
MUST contain NAME and VALUE properties.
Description: This property indicates a very limited search. The search may
only be on HTTP properties.

6.5.2.2 OR XML Entity

Name: http://www.ietf.org/standards/dav/search/or
Purpose: To take its members, evaluate them, get a true or false result,
"or" the results together, and have that be the total result.
Schema: http://www.ietf.org/standards/dav/search/
Parent: Any property where an OR makes sense
Values: Any properties that can be evaluated into a true or false value. One
or more properties may be included.

6.5.2.3 AND XML Entity

Name: http://www.ietf.org/standards/dav/search/and
Purpose: To take its members, evaluate them, get a true or false result,
"and" the results together, and have that be the total result.
Schema: http://www.ietf.org/standards/dav/search/
Parent: Any property where an AND makes sense
Values: Any properties that can be evaluated into a true or false value. One
or more properties may be included.

6.5.2.4 Name XML Entity

Name: http://www.ietf.org/standards/dav/search/name
Purpose: To provide a pattern against which property names are to be
compared. If the name matches then the property evaluates to true, otherwise
false.
Schema: http://www.ietf.org/standards/dav/search/
Parent: Any property that is performing a search on a property.
Values: Match-Stream

6.5.2.5 Value XML Entity

Name: http://www.ietf.org/standards/dav/search/value
Purpose: To provide a pattern against which property values are to be
compared. If the value matches then the property evaluates to true,
otherwise false.
Schema: http://www.ietf.org/standards/dav/search/
Parent: Any property that is performing a search on a property.
Values: Match-Stream

6.5.2.6 Match-String XML Entity

Name: http://www.ietf.org/standards/dav/search/match-string
Purpose: To specify a search pattern to be matched against an octet stream
Schema: http://www.ietf.org/standards/dav/search/
Parent: Any property that needs to match a string against a search pattern
Values: ("*" | "?" | EncodedOctet)
EncodedOctet = <An EncodedOctet uses XML encoding to encode "*" and "?" as
well as "<" and ">"
Description: This entity provides a template against which anything that can
be expressed as an octet stream may be compared. "*" is a wildcard that
matches zero or more unspecified contiguous octets. "?" is a wildcard that
matches exactly one unspecified octet.

6.5.3 Response Format

The response is an application/xml message body which contains a single
SearchResult XML entity whose contents are a series of XML entities
representing matching properties.

6.5.3.1 SearchResult XML Entity

Name: http://www.ietf.org/standards/dav/search/searchresult
Purpose: To contain the results of a SEARCH request
Schema: http://www.ietf.org/standards/dav/search/
Parent: Any, usually <XML>
Values: An XML Entity
Description: The SearchResult XML Entity provides the context to inform the
client that its contents are not just some XML entity, but an XML
representation of the requested property.

6.5.4 Example

SEARCH  /container/ HTTP/1.1
Host: www.foo.bar
Content-Length: xxxx
Content-Type: application/xml

<XML>
        <XML:Namespace><Ref>http://www.ietf.org/standards/dav/search/</><AS>S</></>
        <S:limited-search><OR><AND><Name>*</></></></>
</>

HTTP/1.1 200 OK
Content-Type: application/xml
Content-Length: xxxxx

<XML>
        <XML:Namespace><Ref>D:search/</>S</>
        <XML:Namespace><Ref>http://www.foo.bar/container</><AS>R</></>
        <XML:Namespace><Ref>http://www.aiis.org/standards/dav/</><AS>A</>
        <S:SearchResult>
                <XML:Namespace><Ref>R:(A)</><AS>RA</></>
                <RA:author><D:live></>Jim Whitehead</>
                <XML:Namespace><Ref>R:/member1/(A)</><AS>M1</></>
                <M1:author><D:live></>Roy Fielding</>
</>     </>

The result will return all properties on the container and its members. In
this case only two properties were found, one on the container and one on
one of its members, both properties are live.

7 References

[Berners-Lee, 1997] T. Berners-Lee, "Metadata Architecture." Unpublished
white paper, January 1997.
http://www.w3.org/pub/WWW/DesignIssues/Metadata.html.

[Bray, 1997] T. Bray, C. M. Sperberg-McQueen, "Extensible Markup Language
(XML): Part I. Syntax", WD-xml-lang.html,
http://www.w3.org/pub/WWW/TR/WD-xml-lang.html.

[Connolly, 1997] D. Connolly, R. Khare, H.F. Nielsen, "PEP - an Extension
Mechanism for HTTP", Internet draft, work-in-progress.
draft-ietf-http-pep-03.txt,
ftp://ds.internic.net/internet-drafts/draft-ietf-http-pep-03.txt.

[Lasher, Cohen, 1995] R. Lasher, D. Cohen, "A Format for Bibliographic
Records," RFC 1807. Stanford, Myricom. June, 1995.

[Maloney, 1996] M. Maloney, "Hypertext Links in HTML." Internet draft
(expired), work-in-progress, January, 1996.

[MARC, 1994] Network Development and MARC Standards, Office, ed. 1994.
"USMARC Format for Bibliographic Data", 1994. Washington, DC: Cataloging
Distribution Service, Library of Congress.

[Miller et.al., 1996] J. Miller, T. Krauskopf, P. Resnick, W. Treese, "PICS
Label Distribution Label Syntax and Communication Protocols" Version 1.1,
W3C Recommendation REC-PICS-labels-961031.
http://www.w3.org/pub/WWW/TR/REC-PICS-labels-961031.html.

[WebDAV, 1997] WEBDAV Design Team. "A Proposal for Web Metadata Operations."
Unpublished manuscript.
http://www.ics.uci.edu/~ejw/authoring/proposals/metadata.html

[Weibel et al., 1995] S. Weibel, J. Godby, E. Miller, R. Daniel, "OCLC/NCSA
Metadata Workshop Report." http://purl.oclc.org/metadata/dublin_core_report.

[Yergeau, 1997] F. Yergeau, "UTF-8, a transformation format of Unicode and
ISO 10646", Internet Draft, work-in-progress, draft-yergeau-utf8-rev-00.txt,
http://www.internic.net/internet-drafts/draft-yergeau-utf8-rev-00.txt.

8 Appendix 1 - Content Type Application/XML

8.1 Syntax

The application/XML content type contains an XML document. Its syntax is as
defined below.

XML = XMLStart *XMLEntity Close

XMLStart = "<" "XML" ">"

XMLEntity= Open *(XMLText | XMLEntity) Close

Close = "</>" | "<""/"Entity-Name
Markup">"

Open = "<" Entity-Name Markup ">"

XMLText = <An Octet Stream which uses XML encoding
for "<" and ">">

Entity-Name = [As-Tag ":"] Name
As-Tag = 1*Alpha

Name = (alpha | "_") *(alpha | digit |
"." | "-" | "_" | other)

Other = <Other characters must be encoded>

Markup = SP "-" | ""

8.2 XML Entity

An XML entity, as defined in the BNF, is an open tag with content followed
by a close tag. In order to prevent confusion with the term entity as used
in HTTP, the term XML entity will be used.

The first XML entity of a XML document MUST be the <XML> XML entity. This
XML entity tells the parser that it is dealing with an XML document. So long
as this XML entity is present the parser can be sure that it can parse the
document, even if XML has been extended. If XML is ever altered in a manner
that is not backwards compatible with this specification then the
content-type and the outer most XML entity MUST be changed.

8.3 Entity-Name

All XML entity names must map to URIs. However due to historical
restrictions on what characters may appear in an XML entity name, URIs
cannot be expressed in an XML entity name. This issue is dealt with in more
detail in section 10.

Entity-Names without [AS] are relative URIs whose base is the enclosing
Entity-Name. If the enclosing Entity-Name is <XML> then the Entity-Name MUST
use an [AS].

8.4 Close

The close production marks the end of a XML entity.

8.5 XML Encoding

In different contexts certain characters are reserved, for example "/" can
not be used in an XML entity name and ">"/"<" can not be used in a value. As
such these values must be encoded as follows:

Encoding = Decimal | Hex4

Decimal = "&" Non-Zero *("0" | Non-Zero)

Hex4 = "&u-" 4(Hex)

Non-Zero = "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"

Hex = "0" | Non-Zero | "A" | "B" | "C" | "D" | "E" | "F"

The numbers MUST map to the UTF8 character encodings. Please note that the
"&" character must always be encoded.

8.6 Markup Modifier

The markup modifier, ("-", after the end of an XML entity) instructs the
principal how to treat a XML entity with an unknown name. If the modifier is
used and the XML entity is not recognized then the XML entity name MUST be
stripped and the XML entity's contents promoted one level in the parse tree.
If the modifier is not used and the XML entity name is unknown then the XML
entity and its contents MUST be ignored.

8.7 XML Syntax Shorthand

The following template is recommended for efficiently providing a
description of an XML entity.

Name: The name of the XML entity
Purpose: A one line description of the XML entity's purpose.
Schema: The schema, if any, that the XML entity belongs to
Parent: XML entities that this XML entity may be a child of.
Values: A description, usually a BNF, of the simple and compound values that
the XML entity supports.
Description: Further information.
Example: An example of the XML entity's use.

9 Appendix 2 - Parameter Syntax for Content-Type Application/XML

HTTP 1.1 provides for a mechanism to include a parameter with a content
type. In order to prevent namespace collisions the parameters for
application/XML must use the following syntax:

Parameter = #(<">URI<">  ["=" (token | Quoted-String)])

9.1 Schema Content-Type Parameter

Parameter = <"> http://www.w3.org/standards/xml/content-type/schema/
<"> "=" <"> #URI <">

The http://www.w3.org/standards/xml/content-type/schema/ URL is used as a
parameter to an application/xml content type. The URL indicates that its
value lists some subset of the schemas defined in NameSpace parameters
within the enclosed document. The URI can also be used in requests to
indicate schemas that should appear in the result.

An example of the use of this parameter is to include it in an accept-type
header on a request to indicate that the response should contain the
specified namespace. Thus the client is able to inform the server of its
support for a particular set of namespaces. The server is not required to
return a result with the specified namespaces.

10 Appendix 3 - URI Path Encoding

10.1 Problem Definition

A mechanism is needed to refer to specific DAV properties in a manner that
can handle simple, composite, and multivalued DAV properties.

10.2 Solution Requirement

The reference mechanism must use the standard URL syntax so it can be used
with both currently existing and future URLs. For example, the syntax could
be appended to an HTTP URL to specify a HTTP property on that URL.

10.3 Path Component

URIPath = "/" [path-segments]

Path-segments = segment *("/" segment)

Segment = ("(" Abs-URI ")" | Rel-URI)[Index]*(";" param)

Index = ["(" ["-"]*digit ")"]

Abs-URI = < An absolute or relative URI which has been URI-Path encoded >

Rel-URI = < A relative URI for which URI-Encoding(Rel-URI) == Rel-URI >

URI-Path encoding consists of the following algorithm:

  1. URL encode all "!" characters
  2. Map all "/" characters to "!" characters

Please note that all relative URIs are relative to the URI in the path
segment preceding them. Hence the URI in the first path segment MUST be an
absolute URI.

The purpose of the encoding is to allow URLs to be used as segments without
having to use % encoding on all the "/" which produces a URL form which is
extremely difficult for humans to deal with, and which changes the semantics
of the URL.

10.4 Composite DAV Properties

The DAV property namespace is hierarchical, allowing DAV properties to be
nested within each other. In order to refer to a particular DAV property one
must list all the DAV properties from the root to the desired DAV property.

For example, using XML notation for illustrative purposes,

<XML>
        <XML:Namespace><Ref>http://www.aiim.org/standards/dublin/</><AS>A</></>
        <XML:Namespace><Ref>http://www.ansi.org/standards/z39.50/</><AS>Z</></>
        <A:author><Name>
                        <Z:PersonalName >Freddie</>
                        <Z:FamilyName >Mercury</>
</>     </>     </>

Using the path specification one would refer to the PersonalName DAV
property as
"/(http:!!www.aiim.org!standards!dublin!author)/Name/(http:!!www.ansi.org!standards!z39.50!PersonalName)".
Name does not have to be encased in parenthesis because it meets the rel-uri
rule.

10.5 Multivalued DAV Properties

A DAV property may often have several siblings, for example, the resource
"A" has the following DAV properties defined on it, again using XML notation
for illustrative purposes,

<XML>
        <XML:Namespace><Ref>A</><AS>A</></>
        <A:b>
                <c>e</>
                <d>f</>
                <c>g</>
                <d>h</>
</>     </>

An index system is used to distinguish siblings with the same name. The
index indicates the relative positions of multivalued sibling DAV properties
to each other. The first sibling is at position 1 and the rest are at
position N+1 where N is the position of the previous sibling. Negative
position numbers may also be use such that -1 refers to the last sibling and
the index is decremented for each subsequent sibling.

In cases where a multivalued DAV properties exists but no index is provided,
the index value will default to 1.

Thus the parameters in the example would be referred to as follows:
 Parameter               Negative
 Value   Positive Index  Index
 <a:b>

 <c>e</>

 <d>f</>
         /A:b or /A:b(1)
 <c>g</>

 <d>h</>

 </>

 <c>e</> /A:b/c or       /A:b/c(-2)
         /A:b/c(1)

 <d>f</> /A:b/d or       /A:b/d(-2)
         /A:b/d(1)
 <c>g</> /A:b/c(2)       /A:b/c(-1)
 <d>h</> /A:b/d(2)       /A:b/d(-1)

11 Appendix 4 - XML URI

The "XML" scheme is to be registered with IANA as a reserved namespace that
will be owned by the XML group through the W3C.

The new URI is defined as:

XML = "XML" ":" XML-Path

12 Appendix 5 - XML Entities

12.1 Ref XML entity

Name: XML:Ref
Purpose: A XML entity that indicates that its contents are a URI.
Schema: XML
Parent: Any
Value: URI

12.2 Namespace

12.2.1 Namespace XML entity

Name: XML:Namespace
Purpose: To inform the parser that a particular schema is in use and to
provide a shorthand name for referring to XML entities related to that
schema.
Schema: XML
Parent: Any
Value: (Ref [AS])

Description: This XML entity contains two XML entities, Ref and AS. The
purpose of the XML entity is to inform the parser that a schema, identified
by the value of the Ref XML entity, is in use and, when appropriate, to
provide a shorthand name to refer XML entities derived from that schema
using the AS XML entity. The AS mechanism is needed for efficiency reasons
and because a URI can not be fully specified in an XML open tag. The
Namespace XML entity's scope is all siblings and their children.

12.2.2 AS XML entity

Name: XML:AS
Purpose: To provide a short name for the URI of the schema provided in the
Ref XML entity of a namespace XML entity.
Schema: XML
Parent: XML:Namespace
Value: 1*Alpha

Description: The AS XML entity is used to provide a shorthand reference for
the URI in the Ref XML entity of a Namespace XML entity. The value contained
in the AS XML entity is generated at the XML producer's discretion, the only
requirement is that all AS values MUST be unique within the contents of the
parent of the namespace element.

All XML entity open tags contain a name of the form As-Tag:Name. The As-Tag
is the value defined in an AS XML entity inside of a Namespace. To resolve
the As-Tag:Name into a properly formatted URI replace "As-Tag:" with the URI
provided in the Ref that the AS was defined with. Also note that AS value
also applies to any URIs defined in a Ref inside of Namespace.

For example,

<XML>
        <XML:Namespace><Ref>http://blah;DAV/</><AS>B</></>
        <XML:Namespace><Ref>B:(B:)/</><AS>C</></>
        <C:Moo></>
</>

So B:(B:) translates to http://blah;DAV/(http:!!blah;DAV!)/ and C:Moo
translates to http://blah;DAV/(http:!!blah;DAV!)/Moo.

12.2.3 Required XML entity

Name: XML:Required
Purpose: To indicate that the read MUST understand the associated Namespace
in order to successfully process the XML document.
Schema: XML
Parent: XML:Namespace
Value: None

12.2.4 The XML URI and Namespace

In order to prevent a logical loop the XML namespace is said to be declared,
with the AS value of "XML" as a consequence of the <XML> enclosing property.


From w3c-dist-auth-request@www10.w3.org  Mon Jun 16 21:24:00 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id VAA07538 for <w3c-dist-auth@www19.w3.org>; Mon, 16 Jun 1997 21:24:00 -0400 (EDT)
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id VAA16084 for <w3c-dist-auth@w3.org>; Mon, 16 Jun 1997 21:23:58 -0400 (EDT)
Received: by mail4.microsoft.com with Internet Mail Service (5.0.1458.30)
	id <M39NX4SR>; Mon, 16 Jun 1997 18:24:36 -0700
Message-ID: <11352BDEEB92CF119F3F00805F14F48502EE9C67@RED-44-MSG.dns.microsoft.com>
>From: Yaron Goland <yarong@microsoft.com>
To: "'Jim Whitehead'" <ejw@rome.ICS.UCI.EDU>, w3c-dist-auth@w3.org
Subject: RE: New properties (metadata) draft
Date: Mon, 16 Jun 1997 18:23:47 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.30)
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

Two of the examples have erroneously specified namespace values and the
Entity-Name entry in section 8.1 was not correct. The correct entries
are given below.

6.3.11	Example
		PATCH bar;DAV/ HTTP/1.1
		Host: www.foo.com
		Content-Type: application/XML
		Content-Length: xxxx

		<XML>

<XML:Namespace><Ref>http://www.w3.com/standards/dublin/</><AS>D</></>

<XML:Namespace><Ref>http://www.ietf.org/standards/dav/patch/</><AS>P</><
/>

<XML:Namespace><Ref>http://www.w3.com/standards/z39.50/</><AS>Z</></>
			
			<P:PropertyUpdate>
				<Create>
					<XML:Ref>Z:authors</>
					<PatchValue>
						<Author>Jim Whitehead</>
						<Author>Roy Fielding</>
					</>	
				</>
				<Remove><Ref>D:Copyright-Onwer</></>
				<Insert>

<InsertPoint><Position>Before</><XML:Ref>Z:producer</></>

<InsertName><XML:Ref>Z:Last-Modified</></>
					<PatchValue></>
				</>
				<Insert>

<InsertPoint><Position>After</><XML:Ref>Z:editor(1)</></>

<InsertName><XML:Ref>Z:editor</></>
				</>
</>	</>

6.5.4	Example
		SEARCH  /container/ HTTP/1.1
		Host: www.foo.bar
		Content-Length: xxxx
		Content-Type: application/xml

		<XML>

<XML:Namespace><Ref>http://www.ietf.org/standards/dav/search/</><AS>S</>
</>
			<S:limited-search><OR><AND><Name>*</></></></>
		</>

		HTTP/1.1 200 OK
		Content-Type: application/xml
		Content-Length: xxxxx

		<XML>

<XML:Namespace><Ref>http://www.ietf.org/standards/dav/search/</>S</>

<XML:Namespace><Ref>http://www.foo.bar/container</><AS>R</></>

<XML:Namespace><Ref>http://www.aiis.org/standards/dav/</><AS>A</>
			<S:SearchResult>
				<XML:Namespace><Ref>R:(A)</><AS>RA</></>
				<RA:author><D:live></>Jim Whitehead</>

<XML:Namespace><Ref>R:/member1/(A)</><AS>M1</></>
				<M1:author><D:live></>Roy Fielding</>
		</>	</>


8.1
Entity-Name = ([As-Tag ":"] Name) | (As-Tag ":")

				Yaron

> -----Original Message-----
> From:	Jim Whitehead [SMTP:ejw@rome.ICS.UCI.EDU]
> Sent:	Monday, June 16, 1997 4:47 PM
> To:	w3c-dist-auth@w3.org
> Subject:	New properties (metadata) draft
> 
> 
> Enclosed is the text of a new draft which satisfies the requirements
> for attributes (Section 5.1 of the requirements document), linking
> (Section 5.2 of the requirements), and retrieval of unprocessed source
> (Requirements Section 5.5).  In this draft, an instance of a piece of
> metadata is known as a property.  This draft differs from the previous
> draft on metadata operations (the GETMETA, ADDMETA, DELMETA draft) in
> that it uses GET to retrieve properties, and employs new PATCH method
> to add and delete property values.  A SEARCH method provides the
> capability to search properties.
> 
> This draft also makes use of the Extended Markup Language (XML) as an
> on-the-wire representation for property names and values.  Due to the
> recent release of the Meta Content Framework (MCF) draft, and the
> similarity between MCF and the XML representation given in this draft,
> there is currently debate within the Design Team over whether the
> on-the-wire representation should use MCF.  The primary affect of this
> debate is limited to Section 2.7, Visualizing a Property Tree Using
> XML, which gives an algorithm for converting properties to an XML
> representation, although it would also affect the examples throughout.
> 
> Since the XML specification has not yet been finalized (although there
> is
> considerable agreement on most of its features) this draft has
> provided
> a description of the subset of XML which is used within the
> specification.
> This description occurs towards the end of the specification, in
> Appendicies 1-5.  It also appears that this spec. mistakenly uses the
> term "XML entity" instead of "XML element."
> 
> 
> The properties draft is available at URL:
> http://www.ics.uci.edu/~ejw/authoring/proposals/properties.html
> 
> The latest XML specification is available at URL:
> http://www.textuality.com/sgml-erb/WD-xml-lang.html
> 
> The MCF proposal is available at URL:
> http://developer.netscape.com/mcf.html
> 
> 
> Your comments and ideas on this draft are definitely appreciated.
> 
> - Jim
> 
> 
> 
>                A Data Model and Operations for DAV Properties
> 
> Version 0.1, June 16, 1997
> 
> 1 Introduction
> 
> 1.1 Introduction
> 
> Properties are pieces of data that describe the state of a resource.
> Properties are data about data. The term property is used within this
> proposal to disambiguate the concept from the overloaded terms
> "metadata"
> and "attribute".
> 
> Properties are used within distributed authoring environments to
> provide for
> efficient discovery and management of resources. For example, a
> subject
> property allows for the indexing of all resources by their subject and
> an
> author property allows for the discovery of what authors have written
> which
> documents. As explored in the next section, properties have a long
> history,
> having proven themselves essential to the maintenance of large
> document
> repositories.
> 
> 1.2 Existing Metadata Proposals
> 
> Many current proposals contain some notion of a property. These
> include PICS
> [Miller et al., 1996], PICS-NG, the Rel/Rev draft [Maloney, 1996], Web
> Collections, XML [Bray, 1997], several proposals on representing
> relationships within HTML, digital signature manifests (DCMF), and a
> position paper on Web metadata architecture [Berners-Lee, 1997].
> 
> Some proposals come from a digital library perspective. These include
> the
> Dublin Core [Weibel et al., 1995] metadata set and the Warwick
> Framework
> [Lagoze, 1996], a container architecture for different metadata
> schemas. The
> literature includes many examples of metadata, including MARC [MARC,
> 1994],
> a bibliographic metadata format, RFC 1807 [Lasher, Cohen, 1995], a
> technical
> report bibliographic format employed by the Dienst system, and the
> proceedings from the first IEEE Metadata conference describe many
> community-specific metadata sets.
> 
> Participants of the 1996 Metadata II Workshop in Warwick, UK [Lagoze,
> 1996],
> noted that, "new metadata sets will develop as the networked
> infrastructure
> matures" and "different communities will propose, design, and be
> responsible
> for different types of metadata." These observations can be
> corroborated by
> noting that many community-specific sets of metadata already exist,
> and
> there is significant motivation for the development of new forms of
> metadata
> as many communities increasingly make their data available in digital
> form,
> requiring a metadata format to assist data location and cataloging.
> 
> 1.3 Properties and HTTP Headers
> 
> Properties already exist, to a certain extent, within HTTP through the
> use
> of message headers. However, in distributed authoring environments a
> relatively large number of properties are needed to fully describe the
> state
> of a resource and setting/returning them all through HTTP headers is
> inefficient. Thus a mechanism is needed which allows a principal to
> identify
> a set of properties in which the principal is interested and to then
> set or
> retrieve just those properties.
> 
> 1.4 Why Another Draft?
> 
> Given that this is the fourth major draft on metadata capabilities
> submitted
> to the WebDAV working group, a reasonable question to ask is, "Why
> another
> draft?" In short, the following limitations in "A Proposal for Web
> Metadata
> Operations" [WebDAV, 1997] led to the development of this new
> proposal:
> 
> Poor Internationalization Support. While the simple name/value pairs
> in
> [WebDAV, 1997] do allow the value field to contain an arbitrary
> sequence of
> octets, there is no way to indicate their character encoding.
> 
> No Typing Support. Similar to the internationalization support, there
> is no
> way to indicate the encoding of binary data in a value field in
> [WebDAV,
> 1997], for example, to indicate a sequence of octets should be viewed
> as an
> integer, or as a floating point number,
> 
> Proliferation of Methods. Since [WebDAV, 1997] does not contain a
> naming
> mechanism that combines the name of the resource and the name of the
> property into a single name, the methods GETMETA, DELMETA, and ADDMETA
> are
> necessary to "glue" together the name of the resource and the name of
> the
> property.
> 
> No Sub-Properties. In [WebDAV, 1997] there is no way to define a
> property
> which describes another property (i.e., data about properties), yet
> this
> facility is useful for refining the meaning of a property. One
> important use
> of sub-properties is to indicate their "liveness," whether the server
> is
> enforcing the syntax and semantics of the property.
> 
> This draft introduces two main innovations: a tree data model for
> properties, and a property naming mechanism for combining the URI of a
> resource and the URI for a property type into a single URI which
> identifies
> an instance of that property on the resource. The tree data model
> provides
> support for sub-properties, which then afford typing support and
> internationalization support. The property naming mechanism allows
> existing
> HTTP/1.1 methods (GET, DELETE, PUT) to be used for operations on
> properties,
> thus reducing the number of new methods and helping to ensure the
> utility of
> methods as a mechanism for caching and security.
> 
> 2 A Property Model for HTTP Resources
> 
> 2.1 Overview
> 
> A property consists of a name and a value. However it is often the
> case that
> a property may itself contain properties, such as a sub-property which
> specifies its parent property is read only. The combination of
> properties
> and sub-properties creates a tree.
> 
>   Resource Root Property
>             |
>          Property
>         /       \
>   Read Only      (Some Value)
>        |
>     Yes/No
> 
> 2.2 Property Tree
> 
> The properties defined on a resource create a tree structure, whose
> root
> node is called the root property. The property tree consists of two
> types of
> nodes, a property node and a value node. A property node may have any
> number
> of children, those children may in turn consist of any number and any
> combination of property and values nodes. The ordering of these
> children
> must be maintained. Value nodes do not have any children as they can
> not
> contain properties, only a value. Property nodes are named, value
> nodes are
> referred to via their parent.
> 
> To conceptualize this property model, one builds the previously
> mentioned
> tree. Internal nodes are property nodes and leaf nodes are value
> nodes.
> 
> 2.3 Multivalued Properties
> 
> It is possible for the children of a property to contain several
> properties
> that have the same name. In order to prevent confusion among
> identically
> named siblings, the ordering of siblings MUST be maintained by the
> resource.
> Thus it is now possible to differentiate siblings through the use of
> an
> index.
> 
> 2.4 Property Names
> 
> A property name identifies both the syntax and semantics of the
> children of
> a property node. It is critical that property names do not collide,
> that is,
> two principals defining the same property name with two different
> meanings.
> 
> The URI framework provides for a mechanism to prevent namespace
> collision
> and for varying degrees of administrative control. Rather than
> reinvent
> these desirable features, DAV properties make use of them by requiring
> that
> all DAV property names MUST be URIs.
> 
> 2.5 Schemas
> 
> A schema is a group of property names. A schema may also define
> relationships between properties. It is often useful to indicate
> support for
> a particular schema in a request or a response. Schema discovery is
> also
> useful for determining if a system supports a group of properties. A
> property does not necessarily contain sufficient information to
> identify any
> schemas it may be a member of.
> 
> As with property names, schemas MUST use URIs as their names.
> 
> 2.6 Property Morphing
> 
> 2.6.1 Problem Definition
> 
> Property definitions change in two ways, either a new property is
> added or
> the value is marked up with new information.
> 
> An example of the first class of change will soon be upon us. The
> Digital
> Signature (DSIG) group at the W3C
> <http://www.w3.org/Security/DSig/Overview.html> is currently working
> on a
> mechanism for signing chunks of data and properties. A value that
> previously
> consisted of only a string will be turned into a property containing a
> signature property and the string value. What would an older client,
> written
> before DSIG, do? Where once it looked only for a string, now it finds
> a
> string and a property.
> 
> An example of the second class of change, markup can turn unstructured
> data
> into structured data. For example, a string which once contained a
> name is
> instead turned into two properties, one indicating the personal name
> and the
> second indicating the family name. What would an older client, written
> before the marked up format, do? Where once the client looked only for
> a
> string, now it finds two properties.
> 
> 2.6.2 Solution Requirements
> 
> A mechanism must be provided so that a client can examine the children
> of a
> property and upon encountering unknown properties know to either
> ignore the
> unknown property or to ignore the markup and promote the property's
> children
> one level up the parse tree.
> 
> 2.7 Visualizing a Property Tree Using XML
> 
> While it is possible to visualize tree structures in many ways, for
> use by
> WebDAV, this specification defines a linear visualization of property
> trees
> using the Extensible Markup Language (XML) [Bray, 1997] suitable for
> transmission as part of an HTTP protocol stream.
> 
> A sketch of an algorithm for creating an XML linearization of a
> property
> tree is given below.
> 
> Begin by printing an "<XML>" element, if this is a standalone
> document.
> 
> Next, perform a traversal of the property tree, collecting the set of
> all
> schemas used by all properties. Print one "<XML:Namespace>" ... "<AS>"
> XML
> entity pair for each schema in use, ensuring that unique tags are used
> in
> the "<AS>" XML entities. Save the mapping between schema names.
> 
> Next, perform a preorder traversal of the tree. For each node, print
> its
> name as "<"{unique schema tag}":"{property URI which is relative to
> the
> schema's URI}">", then print its value, then print "</>". Note that
> the
> process is recursive for values which contain properties. Whitespace
> may be
> printed between XML entities for prettyprinting.
> 
> Print a closing "</>" (to close the "<XML>") if the document is
> standalone.
> 
> A detailed description of "<XML:Namespace>" and "<AS>" XML entities is
> given
> in Appendix 4.
> 
> 3 Property Identifiers
> 
> 3.1 Problem Definition
> 
> The addition of properties to the HTTP object model result in the
> state of
> HTTP resources containing two separate areas, the body of the resource
> and
> the properties of the resource. A mechanism is needed to unambiguously
> refer
> to both.
> 
> 3.2 Solution Requirement
> 
> The mechanism used for referring to the resource directly must also be
> usable for referring to the resource's properties in such a manner
> that even
> non-DAV aware clients can retrieve DAV properties.
> 
> 3.3 DAV URL Parameter
> 
> To allow for the specification of property information in the context
> of an
> http scheme URL, a switch is needed. This switch indicates that the
> path
> segments following it specify a property location. To this end the
> "DAV"
> param is introduced for use with http scheme URLs. All path segments
> to the
> right of the DAV param MUST be formatted according to the XML Link
> standard,
> described in appendix 3, XML Linking.
> 
> 3.4 Hierarchical Naming
> 
> Properties on a resource are referred to as a hierarchy from the root
> property on down. Thus if a resource has an author property defined on
> its
> root property, which itself contains a family name property, then a
> hierarchy three levels deep is needed to refer directly to the family
> name
> property.
> 
> Root Property - Author Property - Family Name Property
> 
> The Root property is defined as "/". However both the author and
> family name
> properties are referred to using URIs. The XML Link standard provides
> a
> mechanism to refer to nested URIs.
> 
> For example, the following properties are defined on
> http://somewhere.com/resource.
> 
> <XML>
>  <Namespace><Ref>http://www.w3.org/standards/z39.50/</><AS>Z</></>
>  <Namespace><Ref>AIIM:Dublin:</><AS>D</>
>  <Z:Author><D:PersonalName>Shirley</><D:FamilyName>Mansai</></>
> </>
> 
> To create a reference to the value "Mansai" one would perform the
> following
> steps.
> 
>   1. Add the DAV parameter to the base URI,
>      http://somewhere.com/resource;DAV.
>   2. Add "/" to refer to the root of the resource's property
> namespace,
>      http://somewhere.com/resource;DAV/.
>   3. Change the author attribute's name into parameter format by
> changing
>      the "/" to "!" and encasing it in parenthesis. We must encase it
> in
>      parenthesis in order to indicate that we have made the "/" to "!"
>      translation. We make the translation in order to prevent
> confusion over
>      where segments are and to make sure that relative URIs will
> continue to
>      work.
> 
> http://somewhere.com/resource;DAV/(http:!!www.w3.org!standards!z39.50!
> author).
>   4. Next we continue the path by adding the family name attribute.
> Because
>      it does not include any "/" it does not require encoding.
> 
> http://somewhere.com/resource;DAV/(http:!!www.w3.org!standards!z39.50!
> author)/AIIM:Dublin:FamilyName.
> 
> The process is now complete, the URL can be used in a GET or PATCH to
> retrieve or alter the value. See appendix 3 for more information.
> 
> 3.5 Compatibility with legacy systems
> 
> 3.5.1 Problem Definition
> 
> The HTTP parameter space is uncontrolled, thus someone may already be
> using
> a parameter with a value of "DAV" for some end other than the one
> described
> here. Thus a client sending a URI with a DAV param to a server may
> receive
> an unexpected or inappropriate response.
> 
> 3.5.2 Solution Requirement
> 
> A mechanism is needed to prevent namespace collisions.
> 
> 3.5.3 Proposed Solution
> 
> All DAV compliant servers MUST honor the DAV param type on http URLs.
> Thus
> if a client knows it is talking to a DAV server, it can safely send an
> http
> URL with the DAV param.
> 
> The client may send the http URL with the DAV param extension to a
> server
> that is not know to be DAV compliant if the client uses PEP [Connolly,
> 1997]
> to prevent collisions. The proper PEP header is:
> 
> DAVPEP = "PEP: {{map "DAV"}{strength must}}"
> 
> Note that this header PEP header is not compliant with [Connolly,
> 1997] but
> the author has spoken with the authors of the PEP draft and they will
> be
> changing the format to make the example legal.
> 
> 4 DAV Schema
> 
> The DAV Schema is specified as http://www.ietf.org/standards/dav/.
> This
> schema is used to indicate support for properties that can be defined
> on a
> resource and XML entities that can be returned in responses.
> 
> 4.1 Properties
> 
> 4.1.1 Live Property
> 
> Name: http://www.ietf.org/standards/dav/live
> Purpose: To indicate that the parent property has its syntax and
> semantics
> enforced by the resource on which it is recorded.
> Schema: http://www.ietf.org/standards/dav/
> Parent: Any property
> Values: None
> Description: This property is used exclusively in a response to
> indicate if
> the resource a property is recorded on is enforcing the syntax and
> semantics
> of the property. The absence of the Live property tells the client
> that the
> corresponding property does not have its syntax and semantics enforced
> by
> the resource on which it is recorded.
> 
> 4.1.2 ReadOnly Property
> 
> Name: http://www.ietf.org/standards/dav/readonly
> Purpose: To indicate that the parent property can only be retrieved,
> not set
> through the property mechanism.
> Schema: http://www.ietf.org/standards/dav/
> Parent: Any property
> Values: None
> Description: This property is used to indicate that the parent
> property can
> only be retrieved, not set through the property mechanism. This
> property is
> not meant as an access control mechanism but rather to reflect the
> fact that
> the property is not designed to have its value set through the
> property
> mechanism.
> 
> 5 Link Property
> 
> 5.1 Problem Description
> 
> A mechanism is needed to associate resources with other resources.
> These
> associations, also known as links, consist of three values, a type
> describing the nature of the association, the source of the link, and
> the
> destination of the link. In the case of annotation, the source and
> destination of a link may not be the resource upon which the link is
> recorded.
> 
> 5.2 Solution Requirements
> 
> The association mechanism must make use of the property mechanism in
> order
> to make the existence of the associations searchable.
> 
> 5.3 Link Property
> 
> Name: http://www.ietf.org/standards/dav/link
> Purpose: To indicate the existence of a link associated with the
> parent
> property.
> Schema: http://www.ietf.org/standards/dav/
> Parent: Any property that needs to have a link associated with it.
> Values: Src 1*Dst
> Description: Link is used to provide the source and one or more
> destinations
> of the link. The parent property provides the type. Link is a
> multivalued
> property so multiple Links may be used together to indicate multiple
> links
> with the same type.
> 
> 5.4 Src Property
> 
> Name: http://www.ietf.org/standards/dav/src
> Purpose: To indicate the source of a link.
> Schema: http://www.ietf.org/standards/dav/
> Parent: http://www.ietf.org/standards/dav/link
> Values: URI
> 
> 5.5 Dst Property
> 
> Name: http://www.ietf.org/standards/dav/Dst
> Purpose: To indicate one or more destinations of a link
> Schema: http://www.ietf.org/standards/dav/
> Parent: http://www.ietf.org/standards/dav/link Values: URI
> 
> 5.6 Example
> 
> <XML>
> 
> <Namespace><Ref>http://www.ietf.org/standards/dav/</><AS>D</></>
>         <Namespace><Ref>http://www.foocorp.com/Project/</><AS>F</></>
>         <D:Source>
>                 <D:Link>
>                         <F:ProjectFiles>Source</>
>                         <src>http://foo.bar/program</>
>                         <dst>http://foo.bar/source/main.c</>
>                 </>
> 
>                 <D:Link>
>                         <F:ProjectFiles>Library</>
>                         <src>http://foo.bar/program</>
>                         <dst>http://foo.bar/source/main.lib</>
>                 </>
> 
>                 <D:Link>
>                         <F:ProjectFiles>Makefile</>
>                         <src>http://foo.bar/program</>
>                         <dst>http://foo.bar/source/makefile</>
>                 </>
>         </>
> </>
> 
> In this example the resource http://foo.bar/program has a source
> property
> defined on it which contains three links. Each link contains three
> properties, two of which, src and dst, are part of the DAV schema,
> defined
> in this document, and one which is defined by the schema
> http://www.foocorp.com/project/ (Source, Library, and Makefile). A
> client
> which only implements the properties in the DAV spec will not know
> what the
> foocorp properties are and will ignore them, thus seeing the expected
> source
> and destination links. However an enhanced client may know about the
> foocorp
> properties and thus be able to present the user with additional
> information
> about the links.
> 
> 6 Properties and Methods
> 
> 6.1 DELETE
> 
> The delete method, when used on a property, causes the property and
> its
> children to be removed.
> 
> 6.2 GET
> 
> A GET on a property returns the name of the property and its children.
> Accept types may be used to specify the format of the return value but
> all
> DAV compliant servers MUST at minimum support a return type of
> application/XML. If application/XML is used as the response format
> then it
> MUST include the http://www.ietf.org/standards/dav/ schema.
> 
> 6.2.1 GetResult XML Entity
> 
> Name: http://www.ietf.org/standards/dav/getresult
> Purpose: To contain the results of a GET request
> Schema: http://www.ietf.org/standards/dav/
> Parent: Any, usually <XML>
> Values: An XML Entity
> Description: The GetResult XML Entity provides the context to inform
> the
> client that its contents are not just some XML entity, but an XML
> representation of the requested property.
> 
> 6.2.2 Example
> 
> GET bar;DAV/(http:!!www.w3.org!standards!z39.50!Authors) HTTP/1.1
> Host: foo.com
> 
> HTTP/1.1 200 OK
> Content-Type: application/xml
> Content-Length: xxxx
> E-tag: "1234"
> Last-Modified: xxxx
> 
> <XML>
> 
> <XML:Namespace><Ref>http://www.ietf.org/standards/dav/</><AS>D</></>
> 
> <XML:Namespace><Ref>http://www.w3.com/standards/z39.50/</><AS>Z</></>
>         <D:GetResult><Z:Authors>
>                         <Author>Jane Doe</>
>                         <Author>Joe Doe</>
>                         <Author>Lots o'Doe</>
> </>     </>     </>
> 
> 6.3 PATCH Method
> 
> The PATCH method, in the most general sense, specifies how to alter a
> resource. The message body controls the actual action taken by a
> PATCH. All
> DAV compliant servers are required to support the use of the
> application/XML
> content-type using the http://www.ietf.org/standards/dav/patch/ schema
> in a
> PATCH method with a request-URI that points to a property.
> 
> The changes in a http://www.ietf.org/standards/dav/patch/ request MUST
> be
> atomically executed, partial results are not allowed.
> 
> 6.3.1 Request URI
> 
> The request URI of a PATCH method with the
> http://www.ietf.org/standards/dav/patch/ schema MUST point to the root
> of
> the resource's properties.
> 
> 6.3.2 PropertyUpdate XML Entity
> 
> Name: http://www.ietf.org/standards/dav/patch/PropertyUpdate
> Purpose: To contain a request to alter the properties on a resource.
> Schema: http://www.ietf.org/standards/dav/patch/
> Parent: <XML>
> Value: *(Create | Remove | Insert)
> Description: This XML entity is a container for the information
> required to
> modify the properties on the resource. This XML Entity is multivalued.
> 
> 6.3.3 Create XML Entity
> 
> Name: http://www.ietf.org/standards/dav/patch/create
> Purpose: To create the DAV property specified inside the Create XML
> entity.
> Schema: http://www.ietf.org/standards/dav/patch/
> Parent: http://www.ietf.org/standards/dav/patch/PropertyUpdate Values:
> XML:Ref PatchValue
> Description: This XML entity contains two values, a Ref and a
> PatchValue.
> The Ref contains the name of the property to be created or
> overwritten, this
> URI in Ref MUST be a relative URI whose base is the request-URI. The
> PatchValue XML entity contains the value the new property is to have,
> this
> value can contain both property and value nodes.
> 
> 6.3.4 Remove XML Entity
> 
> Name: http://www.ietf.org/standards/dav/patch/remove
> Purpose: To remove the DAV property specified inside the Remove XML
> entity.
> Schema: http://www.ietf.org/standards/dav/patch/
> Parent: http://www.ietf.org/standards/dav/patch/PropertyUpdate Values:
> XML:Ref
> Description: Remove orders that the property specified in Ref and its
> children removed. Ordering the removal of a property that does not
> exist is
> not an error. The URI in Ref MUST be a relative URI whose base is the
> request-URI.
> 
> 6.3.5 Insert XML Entity
> 
> Name: http://www.ietf.org/standards/dav/patch/insert
> Purpose: To insert a DAV property between other DAV properties of the
> same
> name.
> Schema: http://www.ietf.org/standards/dav/patch/
> Parent: http://www.ietf.org/standards/dav/patch/PropertyUpdate
> Values: InsertPoint InsertName PatchValue
> Description: Insert is used to insert the property referred to in
> InsertName, whose value is given in PatchValue, at the position held
> by the
> value specified in InsertPoint.
> 
> [Author's Note - Currently there is no way to directly address a
> value. So
> if I have the equivalent of <foo>bar<blah></>oops</> there is no way
> for me
> to say "I want "oops" to become "correct"". I have to replace the
> entire foo
> property.]
> 
> 6.3.6 InsertPoint XML Entity
> 
> Name: http://www.ietf.org/standards/dav/patch/InsertPoint
> Purpose: To specify a property that the new property should either be
> inserted before or after.
> Schema: http://www.ietf.org/standards/dav/patch/
> Parent: http://www.ietf.org/standards/dav/patch/Insert
> Values: Position Ref
> Description: The value in the Ref MUST be a relative URI whose base is
> the
> request-URI.
> 
> 6.3.7 Position XML Entity
> 
> Name: http://www.ietf.org/standards/dav/patch/position
> Purpose: To specify if the property to be inserted is to be inserted
> before
> or after the property specified in InsertPoint.
> Schema: http://www.ietf.org/standards/dav/patch/
> Parent: http://www.ietf.org/standards/dav/patch/InsertPoint
> Values: "Before" | "After"
> Description: If the value is Before then the property specified in
> InsertName is to be inserted in the position directly before the
> position
> held by the property specified in InsertPoint. If the value is After
> then
> the property specified in InsertName is to be inserted in the position
> after
> the position held by the property specified in InsertPoint.
> 
> 6.3.8 InsertName XML Entity
> 
> Name: http://www.ietf.org/standards/dav/patch/position
> Purpose: To specify the name of the new property to be inserted
> Schema: http://www.ietf.org/standards/dav/patch/
> Parent: http://www.ietf.org/standards/dav/patch/Insert
> Values: Ref
> Description: The Ref's value is the name of the property to be created
> at
> the position specified by InsertPoint. The URI MUST be relative and
> its base
> MUST be the request-URI. The value MUST NOT have an index on it.
> 
> 6.3.9 PatchValue XML Entity
> 
> Name: http://www.ietf.org/standards/dav/patch/patchvalue
> Purpose: To specify the name and when appropriate the value, of the
> particular property to be altered.
> Schema: http://www.ietf.org/standards/dav/patch/
> Parent: Any parent which needs to specify the contents of a property
> Values: The contents of a property
> 
> 6.3.10 Response Codes
> 
> 200 OK - The command succeeded. As there can be a mixture of PUT and
> DELETEs
> in a body, a 201 Create seems inappropriate.
> 
> 400 Bad Request - The client has provide a value whose syntax is
> illegal for
> the property.
> 
> 401 Unauthorized - The client does not have authorization to alter one
> of
> the properties. This error also occurs if a property is inherently
> read
> only.
> 
> 403 Forbidden - The client, for reasons the server chooses not to
> specify,
> can not alter one of the properties.
> 
> 405 Conflict - The client has provided a value whose semantics are not
> appropriate for the property.
> 
> 6.3.11 Example
> 
> PATCH bar;DAV/ HTTP/1.1
> Host: www.foo.com
> Content-Type: application/XML
> Content-Length: xxxx
> 
> <XML>
> 
> <XML:Namespace><Ref>http://www.ietf.org/standards/dav/patch/</><AS>P</
> ></>
>         <XML:Namespace><Ref>D:patch/</><AS>P</></>
> 
> <XML:Namespace><Ref>http://www.w3.com/standards/z39.50/</><AS>Z</></>
> 
> <XML:Namespace><Ref>http://www.w3.com/standards/dublin/</><AS>D</></>
>         <P:PropertyUpdate>
>                 <Create>
>                         <XML:Ref>Z:authors</>
>                         <PatchValue>
>                                 <Author>Jim Whitehead</>
>                                 <Author>Roy Fielding</>
>                         </>
>                 </>
> 
>                 <Remove><Ref>D:Copyright-Onwer</></>
>                 <Insert>
> 
> <InsertPoint><Position>Before</><XML:Ref>Z:producer</></>
>                         <InsertName><XML:Ref>Z:Last-Modified</></>
>                         <PatchValue></>
>                 </>
>                 <Insert>
> 
> <InsertPoint><Position>After</><XML:Ref>Z:editor(1)</></>
>                         <InsertName><XML:Ref>Z:editor</></>
>                 </>
> </>     </>
> 
> 6.4 PUT
> 
> A PUT is specified in order to control what is returned by a GET.
> However a
> GET on a property always returns some sort of property containment
> format.
> As such PUT can not be used if the Request-URI refers to a property.
> 
> 6.5 SEARCH
> 
> [Author's Note: The search section has never had a very good
> specification
> and there has never been very wide agreement on what features should
> be made
> available. The search specified here is the authors best efforts to
> try and
> synthesize all the features and restrictions which have been asked for
> to
> date.]
> 
> 6.5.1 Request-URI
> 
> The request-URI of the search method specifies the scope of the
> search. If
> the request-URI does not contain the ";DAV/" switch then the scope of
> the
> search is all the properties on that resource. If the request-URI in
> the
> previous case is a collection then the scope of the search is extended
> to
> the collection's propagate members. If the request-URI specifies part
> of the
> property space then the search is restricted to only that property
> space on
> that resource, even if the resource is a container.
> 
> So, for example if http://www.foo.com/bar was the request-URI but not
> a
> container, the search would be across all of http://www.foo.com/bar's
> properties.
> 
> If was a container, then the search would be across all the properties
> on
> and all its propagate member's properties. However if the request-URI
> were
> http://bar/foo;DAV/ then the scope would only be the properties on
> http://bar/foo, not on any of its propagate members.
> 
> The Depth header MUST NOT be used on a SEARCH method.
> 
> 6.5.2 Command Format
> 
> The effects of a SEARCH method are defined by the message body. This
> section
> defines an application/xml content type using the
> http://www.ietf.org/standards/dav/search/ schema. This method is not
> normally cacheable.
> 
> 6.5.2.1 Limited-Search XML Entity
> 
> Name: http://www.ietf.org/standards/dav/search/limited-search
> Purpose: To specify the set of matching properties
> Schema: http://www.ietf.org/standards/dav/search/
> Parent: <XML>
> Values: The value is a single OR. The OR may only contain ANDs. The
> ANDs
> MUST contain NAME and VALUE properties.
> Description: This property indicates a very limited search. The search
> may
> only be on HTTP properties.
> 
> 6.5.2.2 OR XML Entity
> 
> Name: http://www.ietf.org/standards/dav/search/or
> Purpose: To take its members, evaluate them, get a true or false
> result,
> "or" the results together, and have that be the total result.
> Schema: http://www.ietf.org/standards/dav/search/
> Parent: Any property where an OR makes sense
> Values: Any properties that can be evaluated into a true or false
> value. One
> or more properties may be included.
> 
> 6.5.2.3 AND XML Entity
> 
> Name: http://www.ietf.org/standards/dav/search/and
> Purpose: To take its members, evaluate them, get a true or false
> result,
> "and" the results together, and have that be the total result.
> Schema: http://www.ietf.org/standards/dav/search/
> Parent: Any property where an AND makes sense
> Values: Any properties that can be evaluated into a true or false
> value. One
> or more properties may be included.
> 
> 6.5.2.4 Name XML Entity
> 
> Name: http://www.ietf.org/standards/dav/search/name
> Purpose: To provide a pattern against which property names are to be
> compared. If the name matches then the property evaluates to true,
> otherwise
> false.
> Schema: http://www.ietf.org/standards/dav/search/
> Parent: Any property that is performing a search on a property.
> Values: Match-Stream
> 
> 6.5.2.5 Value XML Entity
> 
> Name: http://www.ietf.org/standards/dav/search/value
> Purpose: To provide a pattern against which property values are to be
> compared. If the value matches then the property evaluates to true,
> otherwise false.
> Schema: http://www.ietf.org/standards/dav/search/
> Parent: Any property that is performing a search on a property.
> Values: Match-Stream
> 
> 6.5.2.6 Match-String XML Entity
> 
> Name: http://www.ietf.org/standards/dav/search/match-string
> Purpose: To specify a search pattern to be matched against an octet
> stream
> Schema: http://www.ietf.org/standards/dav/search/
> Parent: Any property that needs to match a string against a search
> pattern
> Values: ("*" | "?" | EncodedOctet)
> EncodedOctet = <An EncodedOctet uses XML encoding to encode "*" and
> "?" as
> well as "<" and ">"
> Description: This entity provides a template against which anything
> that can
> be expressed as an octet stream may be compared. "*" is a wildcard
> that
> matches zero or more unspecified contiguous octets. "?" is a wildcard
> that
> matches exactly one unspecified octet.
> 
> 6.5.3 Response Format
> 
> The response is an application/xml message body which contains a
> single
> SearchResult XML entity whose contents are a series of XML entities
> representing matching properties.
> 
> 6.5.3.1 SearchResult XML Entity
> 
> Name: http://www.ietf.org/standards/dav/search/searchresult
> Purpose: To contain the results of a SEARCH request
> Schema: http://www.ietf.org/standards/dav/search/
> Parent: Any, usually <XML>
> Values: An XML Entity
> Description: The SearchResult XML Entity provides the context to
> inform the
> client that its contents are not just some XML entity, but an XML
> representation of the requested property.
> 
> 6.5.4 Example
> 
> SEARCH  /container/ HTTP/1.1
> Host: www.foo.bar
> Content-Length: xxxx
> Content-Type: application/xml
> 
> <XML>
> 
> <XML:Namespace><Ref>http://www.ietf.org/standards/dav/search/</><AS>S<
> /></>
>         <S:limited-search><OR><AND><Name>*</></></></>
> </>
> 
> HTTP/1.1 200 OK
> Content-Type: application/xml
> Content-Length: xxxxx
> 
> <XML>
>         <XML:Namespace><Ref>D:search/</>S</>
>         <XML:Namespace><Ref>http://www.foo.bar/container</><AS>R</></>
> 
> <XML:Namespace><Ref>http://www.aiis.org/standards/dav/</><AS>A</>
>         <S:SearchResult>
>                 <XML:Namespace><Ref>R:(A)</><AS>RA</></>
>                 <RA:author><D:live></>Jim Whitehead</>
>                 <XML:Namespace><Ref>R:/member1/(A)</><AS>M1</></>
>                 <M1:author><D:live></>Roy Fielding</>
> </>     </>
> 
> The result will return all properties on the container and its
> members. In
> this case only two properties were found, one on the container and one
> on
> one of its members, both properties are live.
> 
> 7 References
> 
> [Berners-Lee, 1997] T. Berners-Lee, "Metadata Architecture."
> Unpublished
> white paper, January 1997.
> http://www.w3.org/pub/WWW/DesignIssues/Metadata.html.
> 
> [Bray, 1997] T. Bray, C. M. Sperberg-McQueen, "Extensible Markup
> Language
> (XML): Part I. Syntax", WD-xml-lang.html,
> http://www.w3.org/pub/WWW/TR/WD-xml-lang.html.
> 
> [Connolly, 1997] D. Connolly, R. Khare, H.F. Nielsen, "PEP - an
> Extension
> Mechanism for HTTP", Internet draft, work-in-progress.
> draft-ietf-http-pep-03.txt,
> ftp://ds.internic.net/internet-drafts/draft-ietf-http-pep-03.txt.
> 
> [Lasher, Cohen, 1995] R. Lasher, D. Cohen, "A Format for Bibliographic
> Records," RFC 1807. Stanford, Myricom. June, 1995.
> 
> [Maloney, 1996] M. Maloney, "Hypertext Links in HTML." Internet draft
> (expired), work-in-progress, January, 1996.
> 
> [MARC, 1994] Network Development and MARC Standards, Office, ed. 1994.
> "USMARC Format for Bibliographic Data", 1994. Washington, DC:
> Cataloging
> Distribution Service, Library of Congress.
> 
> [Miller et.al., 1996] J. Miller, T. Krauskopf, P. Resnick, W. Treese,
> "PICS
> Label Distribution Label Syntax and Communication Protocols" Version
> 1.1,
> W3C Recommendation REC-PICS-labels-961031.
> http://www.w3.org/pub/WWW/TR/REC-PICS-labels-961031.html.
> 
> [WebDAV, 1997] WEBDAV Design Team. "A Proposal for Web Metadata
> Operations."
> Unpublished manuscript.
> http://www.ics.uci.edu/~ejw/authoring/proposals/metadata.html
> 
> [Weibel et al., 1995] S. Weibel, J. Godby, E. Miller, R. Daniel,
> "OCLC/NCSA
> Metadata Workshop Report."
> http://purl.oclc.org/metadata/dublin_core_report.
> 
> [Yergeau, 1997] F. Yergeau, "UTF-8, a transformation format of Unicode
> and
> ISO 10646", Internet Draft, work-in-progress,
> draft-yergeau-utf8-rev-00.txt,
> http://www.internic.net/internet-drafts/draft-yergeau-utf8-rev-00.txt.
> 
> 8 Appendix 1 - Content Type Application/XML
> 
> 8.1 Syntax
> 
> The application/XML content type contains an XML document. Its syntax
> is as
> defined below.
> 
> XML = XMLStart *XMLEntity Close
> 
> XMLStart = "<" "XML" ">"
> 
> XMLEntity= Open *(XMLText | XMLEntity) Close
> 
> Close = "</>" | "<""/"Entity-Name
> Markup">"
> 
> Open = "<" Entity-Name Markup ">"
> 
> XMLText = <An Octet Stream which uses XML encoding
> for "<" and ">">
> 
> Entity-Name = [As-Tag ":"] Name
> As-Tag = 1*Alpha
> 
> Name = (alpha | "_") *(alpha | digit |
> "." | "-" | "_" | other)
> 
> Other = <Other characters must be encoded>
> 
> Markup = SP "-" | ""
> 
> 8.2 XML Entity
> 
> An XML entity, as defined in the BNF, is an open tag with content
> followed
> by a close tag. In order to prevent confusion with the term entity as
> used
> in HTTP, the term XML entity will be used.
> 
> The first XML entity of a XML document MUST be the <XML> XML entity.
> This
> XML entity tells the parser that it is dealing with an XML document.
> So long
> as this XML entity is present the parser can be sure that it can parse
> the
> document, even if XML has been extended. If XML is ever altered in a
> manner
> that is not backwards compatible with this specification then the
> content-type and the outer most XML entity MUST be changed.
> 
> 8.3 Entity-Name
> 
> All XML entity names must map to URIs. However due to historical
> restrictions on what characters may appear in an XML entity name, URIs
> cannot be expressed in an XML entity name. This issue is dealt with in
> more
> detail in section 10.
> 
> Entity-Names without [AS] are relative URIs whose base is the
> enclosing
> Entity-Name. If the enclosing Entity-Name is <XML> then the
> Entity-Name MUST
> use an [AS].
> 
> 8.4 Close
> 
> The close production marks the end of a XML entity.
> 
> 8.5 XML Encoding
> 
> In different contexts certain characters are reserved, for example "/"
> can
> not be used in an XML entity name and ">"/"<" can not be used in a
> value. As
> such these values must be encoded as follows:
> 
> Encoding = Decimal | Hex4
> 
> Decimal = "&" Non-Zero *("0" | Non-Zero)
> 
> Hex4 = "&u-" 4(Hex)
> 
> Non-Zero = "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
> 
> Hex = "0" | Non-Zero | "A" | "B" | "C" | "D" | "E" | "F"
> 
> The numbers MUST map to the UTF8 character encodings. Please note that
> the
> "&" character must always be encoded.
> 
> 8.6 Markup Modifier
> 
> The markup modifier, ("-", after the end of an XML entity) instructs
> the
> principal how to treat a XML entity with an unknown name. If the
> modifier is
> used and the XML entity is not recognized then the XML entity name
> MUST be
> stripped and the XML entity's contents promoted one level in the parse
> tree.
> If the modifier is not used and the XML entity name is unknown then
> the XML
> entity and its contents MUST be ignored.
> 
> 8.7 XML Syntax Shorthand
> 
> The following template is recommended for efficiently providing a
> description of an XML entity.
> 
> Name: The name of the XML entity
> Purpose: A one line description of the XML entity's purpose.
> Schema: The schema, if any, that the XML entity belongs to
> Parent: XML entities that this XML entity may be a child of.
> Values: A description, usually a BNF, of the simple and compound
> values that
> the XML entity supports.
> Description: Further information.
> Example: An example of the XML entity's use.
> 
> 9 Appendix 2 - Parameter Syntax for Content-Type Application/XML
> 
> HTTP 1.1 provides for a mechanism to include a parameter with a
> content
> type. In order to prevent namespace collisions the parameters for
> application/XML must use the following syntax:
> 
> Parameter = #(<">URI<">  ["=" (token | Quoted-String)])
> 
> 9.1 Schema Content-Type Parameter
> 
> Parameter = <"> http://www.w3.org/standards/xml/content-type/schema/
> <"> "=" <"> #URI <">
> 
> The http://www.w3.org/standards/xml/content-type/schema/ URL is used
> as a
> parameter to an application/xml content type. The URL indicates that
> its
> value lists some subset of the schemas defined in NameSpace parameters
> within the enclosed document. The URI can also be used in requests to
> indicate schemas that should appear in the result.
> 
> An example of the use of this parameter is to include it in an
> accept-type
> header on a request to indicate that the response should contain the
> specified namespace. Thus the client is able to inform the server of
> its
> support for a particular set of namespaces. The server is not required
> to
> return a result with the specified namespaces.
> 
> 10 Appendix 3 - URI Path Encoding
> 
> 10.1 Problem Definition
> 
> A mechanism is needed to refer to specific DAV properties in a manner
> that
> can handle simple, composite, and multivalued DAV properties.
> 
> 10.2 Solution Requirement
> 
> The reference mechanism must use the standard URL syntax so it can be
> used
> with both currently existing and future URLs. For example, the syntax
> could
> be appended to an HTTP URL to specify a HTTP property on that URL.
> 
> 10.3 Path Component
> 
> URIPath = "/" [path-segments]
> 
> Path-segments = segment *("/" segment)
> 
> Segment = ("(" Abs-URI ")" | Rel-URI)[Index]*(";" param)
> 
> Index = ["(" ["-"]*digit ")"]
> 
> Abs-URI = < An absolute or relative URI which has been URI-Path
> encoded >
> 
> Rel-URI = < A relative URI for which URI-Encoding(Rel-URI) == Rel-URI
> >
> 
> URI-Path encoding consists of the following algorithm:
> 
>   1. URL encode all "!" characters
>   2. Map all "/" characters to "!" characters
> 
> Please note that all relative URIs are relative to the URI in the path
> segment preceding them. Hence the URI in the first path segment MUST
> be an
> absolute URI.
> 
> The purpose of the encoding is to allow URLs to be used as segments
> without
> having to use % encoding on all the "/" which produces a URL form
> which is
> extremely difficult for humans to deal with, and which changes the
> semantics
> of the URL.
> 
> 10.4 Composite DAV Properties
> 
> The DAV property namespace is hierarchical, allowing DAV properties to
> be
> nested within each other. In order to refer to a particular DAV
> property one
> must list all the DAV properties from the root to the desired DAV
> property.
> 
> For example, using XML notation for illustrative purposes,
> 
> <XML>
> 
> <XML:Namespace><Ref>http://www.aiim.org/standards/dublin/</><AS>A</></
> >
> 
> <XML:Namespace><Ref>http://www.ansi.org/standards/z39.50/</><AS>Z</></
> >
>         <A:author><Name>
>                         <Z:PersonalName >Freddie</>
>                         <Z:FamilyName >Mercury</>
> </>     </>     </>
> 
> Using the path specification one would refer to the PersonalName DAV
> property as
> "/(http:!!www.aiim.org!standards!dublin!author)/Name/(http:!!www.ansi.
> org!standards!z39.50!PersonalName)".
> Name does not have to be encased in parenthesis because it meets the
> rel-uri
> rule.
> 
> 10.5 Multivalued DAV Properties
> 
> A DAV property may often have several siblings, for example, the
> resource
> "A" has the following DAV properties defined on it, again using XML
> notation
> for illustrative purposes,
> 
> <XML>
>         <XML:Namespace><Ref>A</><AS>A</></>
>         <A:b>
>                 <c>e</>
>                 <d>f</>
>                 <c>g</>
>                 <d>h</>
> </>     </>
> 
> An index system is used to distinguish siblings with the same name.
> The
> index indicates the relative positions of multivalued sibling DAV
> properties
> to each other. The first sibling is at position 1 and the rest are at
> position N+1 where N is the position of the previous sibling. Negative
> position numbers may also be use such that -1 refers to the last
> sibling and
> the index is decremented for each subsequent sibling.
> 
> In cases where a multivalued DAV properties exists but no index is
> provided,
> the index value will default to 1.
> 
> Thus the parameters in the example would be referred to as follows:
>  Parameter               Negative
>  Value   Positive Index  Index
>  <a:b>
> 
>  <c>e</>
> 
>  <d>f</>
>          /A:b or /A:b(1)
>  <c>g</>
> 
>  <d>h</>
> 
>  </>
> 
>  <c>e</> /A:b/c or       /A:b/c(-2)
>          /A:b/c(1)
> 
>  <d>f</> /A:b/d or       /A:b/d(-2)
>          /A:b/d(1)
>  <c>g</> /A:b/c(2)       /A:b/c(-1)
>  <d>h</> /A:b/d(2)       /A:b/d(-1)
> 
> 11 Appendix 4 - XML URI
> 
> The "XML" scheme is to be registered with IANA as a reserved namespace
> that
> will be owned by the XML group through the W3C.
> 
> The new URI is defined as:
> 
> XML = "XML" ":" XML-Path
> 
> 12 Appendix 5 - XML Entities
> 
> 12.1 Ref XML entity
> 
> Name: XML:Ref
> Purpose: A XML entity that indicates that its contents are a URI.
> Schema: XML
> Parent: Any
> Value: URI
> 
> 12.2 Namespace
> 
> 12.2.1 Namespace XML entity
> 
> Name: XML:Namespace
> Purpose: To inform the parser that a particular schema is in use and
> to
> provide a shorthand name for referring to XML entities related to that
> schema.
> Schema: XML
> Parent: Any
> Value: (Ref [AS])
> 
> Description: This XML entity contains two XML entities, Ref and AS.
> The
> purpose of the XML entity is to inform the parser that a schema,
> identified
> by the value of the Ref XML entity, is in use and, when appropriate,
> to
> provide a shorthand name to refer XML entities derived from that
> schema
> using the AS XML entity. The AS mechanism is needed for efficiency
> reasons
> and because a URI can not be fully specified in an XML open tag. The
> Namespace XML entity's scope is all siblings and their children.
> 
> 12.2.2 AS XML entity
> 
> Name: XML:AS
> Purpose: To provide a short name for the URI of the schema provided in
> the
> Ref XML entity of a namespace XML entity.
> Schema: XML
> Parent: XML:Namespace
> Value: 1*Alpha
> 
> Description: The AS XML entity is used to provide a shorthand
> reference for
> the URI in the Ref XML entity of a Namespace XML entity. The value
> contained
> in the AS XML entity is generated at the XML producer's discretion,
> the only
> requirement is that all AS values MUST be unique within the contents
> of the
> parent of the namespace element.
> 
> All XML entity open tags contain a name of the form As-Tag:Name. The
> As-Tag
> is the value defined in an AS XML entity inside of a Namespace. To
> resolve
> the As-Tag:Name into a properly formatted URI replace "As-Tag:" with
> the URI
> provided in the Ref that the AS was defined with. Also note that AS
> value
> also applies to any URIs defined in a Ref inside of Namespace.
> 
> For example,
> 
> <XML>
>         <XML:Namespace><Ref>http://blah;DAV/</><AS>B</></>
>         <XML:Namespace><Ref>B:(B:)/</><AS>C</></>
>         <C:Moo></>
> </>
> 
> So B:(B:) translates to http://blah;DAV/(http:!!blah;DAV!)/ and C:Moo
> translates to http://blah;DAV/(http:!!blah;DAV!)/Moo.
> 
> 12.2.3 Required XML entity
> 
> Name: XML:Required
> Purpose: To indicate that the read MUST understand the associated
> Namespace
> in order to successfully process the XML document.
> Schema: XML
> Parent: XML:Namespace
> Value: None
> 
> 12.2.4 The XML URI and Namespace
> 
> In order to prevent a logical loop the XML namespace is said to be
> declared,
> with the AS value of "XML" as a consequence of the <XML> enclosing
> property.


From w3c-dist-auth-request@www10.w3.org  Mon Jun 16 21:28:32 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id VAA07580 for <w3c-dist-auth@www19.w3.org>; Mon, 16 Jun 1997 21:28:32 -0400 (EDT)
Received: from maildeliver0.tiac.net (maildeliver0.tiac.net [199.0.65.19]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id VAA16102 for <w3c-dist-auth@w3.org>; Mon, 16 Jun 1997 21:28:31 -0400 (EDT)
Received: from mailnfs0.tiac.net (mailnfs0.tiac.net [199.0.65.17]) by maildeliver0.tiac.net (8.8.0/8.8) with ESMTP id VAA31031; Mon, 16 Jun 1997 21:28:31 -0400 (EDT)
Received: from sankar (p13.gw3.littl.MA.tiac.com [207.60.148.110]) by mailnfs0.tiac.net (8.8.0/8.8) with SMTP id VAA15119; Mon, 16 Jun 1997 21:28:29 -0400 (EDT)
Message-Id: <3.0.32.19970616213156.006d1c9c@207.221.172.194>
X-Sender: sv@207.221.172.194
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 16 Jun 1997 21:31:58 -0400
To: Jim Whitehead <ejw@rome.ICS.UCI.EDU>, w3c-dist-auth@w3.org
>From: Sankar Virdhagriswaran <sv@hunchuen.crystaliz.com>
Subject: Re: New properties (metadata) draft
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

I am a little confused about the following in your note:

<<This draft also makes use of the Extended Markup Language (XML) as an
on-the-wire representation for property names and values.  Due to the
recent release of the Meta Content Framework (MCF) draft, and the
similarity between MCF and the XML representation given in this draft,
there is currently debate within the Design Team over whether the
on-the-wire representation should use MCF.>>

I thought the Netscape submission of Guha's work to W3C
(http://developer.netscape.com/mcf.html) did indeed use XML as the on the
wire protocol. Am I confused or is the question confusing. If I understand
your question correctly, you would like to hear reactions about using MCF
in XML as a way of representing typed properties. I fully support this
approach. MCF and XML are very strong foundations built on the basis of
many years of solid work for typed and structured data and we should use
them instead of inventing our variation that will not extend.











From w3c-dist-auth-request@www10.w3.org  Mon Jun 16 21:36:31 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id VAA07624 for <w3c-dist-auth@www19.w3.org>; Mon, 16 Jun 1997 21:36:31 -0400 (EDT)
Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id VAA16122 for <w3c-dist-auth@w3.org>; Mon, 16 Jun 1997 21:36:31 -0400 (EDT)
Received: from sub.sonic.net (sub.sonic.net [208.201.224.8])
          by marine.sonic.net (8.8.5/8.8.5) with ESMTP
	  id SAA13604 for <w3c-dist-auth@w3.org>; Mon, 16 Jun 1997 18:36:52 -0700
Received: from bolt.sonic.net (tallen@bolt.sonic.net [208.201.224.36]) by sub.sonic.net (8.8.5/8.8.5) with ESMTP id RAA08596; Mon, 16 Jun 1997 17:58:29 -0700
X-envelope-info: <tallen@bolt.sonic.net>
Received: (from tallen@localhost) by bolt.sonic.net (8.8.5/8.7.3) id RAA30753; Mon, 16 Jun 1997 17:59:40 -0700
Date: Mon, 16 Jun 1997 17:59:40 -0700
>From: Terry Allen <tallen@sonic.net>
Message-Id: <199706170059.RAA30753@bolt.sonic.net>
To: ejw@rome.ICS.UCI.EDU, w3c-dist-auth@w3.org
Subject: Re: New properties (metadata) draft
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

Jim Whitehead writes:
| Enclosed is the text of a new draft which satisfies the requirements
| for attributes (Section 5.1 of the requirements document), linking
| (Section 5.2 of the requirements), and retrieval of unprocessed source
| (Requirements Section 5.5).  In this draft, an instance of a piece of
| metadata is known as a property.  This draft differs from the previous
| draft on metadata operations (the GETMETA, ADDMETA, DELMETA draft) in
| that it uses GET to retrieve properties, and employs new PATCH method
| to add and delete property values.  A SEARCH method provides the
| capability to search properties.

This is interesting but needs some XML work.  On quick perusal:

| This draft also makes use of the Extended Markup Language (XML) as an

Extensible, not Extended.

| on-the-wire representation for property names and values.  Due to the
| recent release of the Meta Content Framework (MCF) draft, and the
| similarity between MCF and the XML representation given in this draft,
| there is currently debate within the Design Team over whether the
| on-the-wire representation should use MCF.  The primary affect of this
| debate is limited to Section 2.7, Visualizing a Property Tree Using
| XML, which gives an algorithm for converting properties to an XML
| representation, although it would also affect the examples throughout.


| 2.7 Visualizing a Property Tree Using XML
| 
| While it is possible to visualize tree structures in many ways, for use by
| WebDAV, this specification defines a linear visualization of property trees
| using the Extensible Markup Language (XML) [Bray, 1997] suitable for
| transmission as part of an HTTP protocol stream.
|
| A sketch of an algorithm for creating an XML linearization of a property
| tree is given below.
| 
| Begin by printing an "<XML>" element, if this is a standalone document.

You really want a Document Type Definition for what you're doing here,
even though XML allows documents that don't have a DTD.  In any event,
XML is not a particularly good name for the root element; the XML folks 
are likely to preempt it.  How about WEBDAVTREE, etc.

| Next, perform a traversal of the property tree, collecting the set of all
| schemas used by all properties. Print one "<XML:Namespace>" ... "<AS>" XML

Despite the fact that the MCF spec uses element type names that include
colons, my testing (with James Clark's JADE 0.7) and my reading of the spec
suggest that the colon is not a valid character here.  However, the spec
is fluid, and you should ask for advice on this score, e.g., by posting
to the XML-DEV list.

| entity pair for each schema in use, ensuring that unique tags are used in

I am not sure that "XML entity pair" means anything.  I think you mean
"two start-tags".

| the "<AS>" XML entities. Save the mapping between schema names.
|
| Next, perform a preorder traversal of the tree. For each node, print its
| name as "<"{unique schema tag}":"{property URI which is relative to the
| schema's URI}">", then print its value, then print "</>". Note that the

</> is not in XML; you need to use a full end-tag, e.g., 
<WEBDAVTREE.Namespace> ... </WEBDAVTREE.Namespace>.  

| process is recursive for values which contain properties. Whitespace may be
| printed between XML entities for prettyprinting.
| 
| Print a closing "</>" (to close the "<XML>") if the document is standalone.

Again, you need the full end-tag.

| For example, the following properties are defined on
| http://somewhere.com/resource.
| 
| <XML>
|  <Namespace><Ref>http://www.w3.org/standards/z39.50/</><AS>Z</></>

should be 

<Namespace><Ref>http://www.w3.org/standards/z39.50/</Ref><AS>Z</AS></Namespace>

What does the "Z" mean?

|  <Namespace><Ref>AIIM:Dublin:</><AS>D</>
|  <Z:Author><D:PersonalName>Shirley</><D:FamilyName>Mansai</></>
| </>

I see.  You are trying to write a DTD on the fly.  There is no way of
validating this structure, of knowing that you have constructed it
correctly.  Arbitrary extensibility of syntax is nice, but so is
validatability.  Why not construct 

<!doctype webdavtree.mine [
...
<!element PersonalName (#PCDATA)>
<!attlist PersonalName semantic CDATA "AIIM:Dublin">
...
]>
<webdavtree>
...
<PersonalName>Shirley</PersonalName>
...
</webdavtree>

?  Then you can parse with a validating XML parser to see that your
element definition structure and document body are correctly constructed.
Further, "AIIM:Dublin" can be a URL or URN.

| To create a reference to the value "Mansai" one would perform the following
| steps.
| 
|   1. Add the DAV parameter to the base URI,
|      http://somewhere.com/resource;DAV.
|   2. Add "/" to refer to the root of the resource's property namespace,
|      http://somewhere.com/resource;DAV/.
|   3. Change the author attribute's name into parameter format by changing
|      the "/" to "!" and encasing it in parenthesis. We must encase it in
|      parenthesis in order to indicate that we have made the "/" to "!"
|      translation. We make the translation in order to prevent confusion over
|      where segments are and to make sure that relative URIs will continue to
|      work.
|      http://somewhere.com/resource;DAV/(http:!!www.w3.org!standards!z39.50!author).
|   4. Next we continue the path by adding the family name attribute. Because
|      it does not include any "/" it does not require encoding.
|      http://somewhere.com/resource;DAV/(http:!!www.w3.org!standards!z39.50!author)/AIIM:Dublin:FamilyName.

If FamilyName is in the AIIM:Dublin spec, why not just assign a normal URL
(or URN) to that semantic, exactly as you do below?  It would require the
cooperation of the spec maintainers, but that would be a real good thing
for interoperability.

| 4 DAV Schema
| 
| The DAV Schema is specified as http://www.ietf.org/standards/dav/. This
| schema is used to indicate support for properties that can be defined on a
| resource and XML entities that can be returned in responses.

If you don't include a version number in that URL you *will* regret it.

| 4.1 Properties
| 
| 4.1.1 Live Property
| 
| Name: http://www.ietf.org/standards/dav/live
| Purpose: To indicate that the parent property has its syntax and semantics
| enforced by the resource on which it is recorded.
| Schema: http://www.ietf.org/standards/dav/
| Parent: Any property
| Values: None
| Description: This property is used exclusively in a response to indicate if
| the resource a property is recorded on is enforcing the syntax and semantics
| of the property. The absence of the Live property tells the client that the
| corresponding property does not have its syntax and semantics enforced by
| the resource on which it is recorded.

Very nice; this is the right approach.  This info could be marked up according 
to an XML DTD too.

| 5.3 Link Property
| 
| Name: http://www.ietf.org/standards/dav/link
| Purpose: To indicate the existence of a link associated with the parent
| property.
| Schema: http://www.ietf.org/standards/dav/
| Parent: Any property that needs to have a link associated with it.
| Values: Src 1*Dst
| Description: Link is used to provide the source and one or more destinations
| of the link. The parent property provides the type. Link is a multivalued
| property so multiple Links may be used together to indicate multiple links
| with the same type.

You might want to synch this up with XML-link, once it's frozen.
(Or again, not, depending on how it turns out.)

| 8.1 Syntax

This really ought to be an XML DTD unless there are technical reasons
it can't be.  XML-lang has the EBNF in it already; there's nothing
to be gained by reinventing it here. 


Regards,

  Terry Allen    Electronic Publishing Consultant    tallen[at]sonic.net
                   http://www.sonic.net/~tallen/
    Davenport and DocBook:  http://www.ora.com/davenport/index.html
          T.A. at Passage Systems:  terry.allen[at]passage.com 


From w3c-dist-auth-request@www10.w3.org  Mon Jun 16 22:52:14 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id WAA08229 for <w3c-dist-auth@www19.w3.org>; Mon, 16 Jun 1997 22:52:14 -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 WAA16295 for <w3c-dist-auth@w3.org>; Mon, 16 Jun 1997 22:52:14 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa13250;
          16 Jun 97 19:49 PDT
X-Sender: ejw@paris.ics.uci.edu
Message-Id: <afcbacd90e021004432d@[128.195.21.209]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 16 Jun 1997 19:56:03 -0700
To: w3c-dist-auth@w3.org
>From: Jim Whitehead <ejw@ics.uci.edu>
Subject: Re: Maps for DMA and WebDAV meetings
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring


>Attached is a list of hotels (Provo Park is the best and has a block of
>rooms available at a corporate rate). Tell them that you are with the
>WebDAV/DMA conference at Novell.
>
>Also a map showing how to get from the airport to here and a map of the Orem
>campus.

FYI, I have made the maps and the hotel information available from the
following URL:

http://www.ics.uci.edu/~ejw/authoring/orem/

Please do preregister with Steve Carter <srcarter@novell.com> if you are
planning on attending this meeting.

- Jim



From w3c-dist-auth-request@www10.w3.org  Tue Jun 17 18:18:44 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id SAA18704 for <w3c-dist-auth@www19.w3.org>; Tue, 17 Jun 1997 18:18:44 -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 SAA20436 for <w3c-dist-auth@w3.org>; Tue, 17 Jun 1997 18:18:43 -0400 (EDT)
Received: from rome.ics.uci.edu by paris.ics.uci.edu id aa04124;
          17 Jun 97 15:12 PDT
To: w3c-dist-auth@w3.org
Subject: Namespace Draft
Date: Tue, 17 Jun 1997 15:12:05 -0700
>From: Jim Whitehead <ejw@rome.ICS.UCI.EDU>
Message-ID:  <9706171512.aa04124@paris.ics.uci.edu>
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring


Enclosed, please find a text version of a draft for how to perform
namespace operations via HTTP.  This draft meets the requirements for
name space manipulation (copy, move/rename) in Section 5.7 of the
requirements document, for collections (Requirements Section 5.8),
retrieval of unprocessed source for editing (Requirements Section 5.5),
and for partial write (Requirements Section 5.6).

This draft is available in HTML format at URL:

http://www.ics.uci.edu/~ejw/authoring/proposals/namespace.html


This proposal, in combination with the locking draft and the properties
draft, form a consistent proposal which meets Sections 5.1-5.8 of
the WebDAV Requirements Document, i.e., all distributed authoring
requirements.

Note that this proposal, like all proposals put before this working
group, must receive the rough consensus of the working group (i.e.,
the members of the mailing list) before it can leave the working
group.  Your comments and questions on the proposals are instrumental
in determining problem areas, and areas on which there is agreement.

- Jim


A Proposal for Collections of Web Resources and Name Space Operations

                          Draft v0.6, June 6, 1997

1 Observations on the HTTP Object Model

As a prerequisite for specification of collections and name space operations
for the Web, a model for collection resources and for namespace topology
must be given. This section describes a new type of Web resource, the
collection resource, and provides a model for discussing the relationship
between the resources that are generated as the result of a data-producing
process, and the source resources that describe the process.

1.1 Collection Resources

A collection is a Web resource type whose primary state is a set of URIs and
associated values that are recorded as properties on the resource. The URIs
identify the resources that are members of the collection. The values
associated with each URI include information such as the Last Modified Date,
Entity Tag, Creation Date, Content Type, Display Name, and whether the
member is a collection.

A member of a collection is either an internal member resource, which MUST
have a URI that is relative to the base URI of the collection, or an
external member resource, which has a URI which is not relative to the base
URI of the collection. External member resources are further subdivided into
propagate members, which have recursive method invocations propagated to
them, and no-propagate members, which do not.

A collection resource may be viewed and used as a compound resource in which
the collection is a container for a group of related resources that,
together, form a larger logical unit. For example, a collection of HTML
resources where each resource is the chapter of a book can be viewed as a
compound resource representing the entire book.

Some methods, when invoked on a collection, affect the entire collection.
For example, it is possible to copy an entire collection and its contents
with just a single copy method request. The model for performing these
operations is a tree traversal. The method is invoked on the collection,
which then performs the method on itself before propagating the method to
all its internal members and propagate external members. If these are
non-collection resources, the request method is processed. However, if the
request is propagated to another collection, then the propagation begins
again. This sequence of actions causes the method to be propagated as a tree
traversal of the members of the collections.

1.2 Creation and Retrieval of Collection Resources

Since the existing HTTP methods for creating (PUT, POST) and retrieving
(GET) a resource were defined for non-collection resources, it is not
surprising that the semantics of these methods do not transfer well to
collections. For example, the PUT method is defined to store the request
entity under the Request-URI. While a description format for a collection
can readily be constructed that could be used with PUT, the implications of
sending such a description to the server are undesirable. For example, if a
description of a collection was PUT to the server which omitted some
existing resources, this might be interpreted as a command to remove those
members. However, this would extend PUT to perform DELETE functionality,
which is undesirable since it changes the semantics of PUT, and makes it
difficult to control DELETE functionality with an access control scheme
based on methods.

While the POST method is sufficiently open-ended that a "create a
collection" POST command could be constructed, this is undesirable because
it would be difficult to provide separate access control for collection
creation and other uses of POST if they both use the same method.

The GET method when applied to collections is also problematic. While it
might seem desirable to have GET return a listing of the members of a
collection, this is foiled by the existence of the "index.html" de-facto
standard namespace redirection, in which a GET request on a collection is
automatically redirected to the index.html resource.

Because of the difficulty of reusing existing HTTP/1.1 methods for
collections, two new resource creation/retrieval methods are needed. This
proposal introduces the MKCOL method for creating collection resources, and
the INDEX method for retrieving the contents of a collection.

The exact definition of the behavior of GET and PUT on collections is
defined later in this draft.

1.3 Source Resources and Output Resources

For many resources, the entity returned by GET exactly matches the
persistent state of the resource, for example, a GIF file stored on a disk.
For this simple case, the URL at which a resource is accessed is identical
to the URL at which the source (the persistent state) of the resource is
accessed. This is also the case for HTML source files that are not processed
by the server prior to transmission.

However, HTML files can sometimes be processed by the server before being
transmitted as a return entity body. Server-side-include directives within
an HTML file instruct a server to replace the directive with another value,
such as the current date. In this case, what is returned by GET (HTML plus
date) differs from the persistent state of the resource (HTML plus
directive). Typically there is no way to access the HTML file containing the
unprocessed directive.

Sometimes the entity returned by GET is the output of a data-producing
process that is described by one or more source resources (that may not even
have a location in the URL namespace). A single data-producing process may
dynamically generate the state of a potentially large number of output
resources. An example of this is a CGI script that describes a "finger"
gateway process that maps part of the namespace of a server into finger
requests, such as http://www.foo.bar.org/finger_gateway/user@host.

In the absence of distributed authoring capability, the fact that the source
resource(s) for server generated output do not have a mapping to the URI
namespace is not a problem, and has desirable security benefits. However, if
remote editing of the source resource(s) is desired, they should be given a
location in the URI namespace. This source location should not be one of the
locations at which the generated output is retrievable, since in general it
is impossible for the server to differentiate requests for source resources
from requests for process output resources. There is often a many-to-many
relationship between source resources and output resources.

Within the HTTP URL namespace managed by servers which implement the DAV
property functionality, all resources which have a single source resource,
and that source resource has a URI, the URI of the source resource SHOULD be
stored in a single link with type Source. Note that by storing the source
URI in links on the output resources, the burden of discovering the source
is placed on the authoring client.

In the general case, a large number of source resources can comprise a
data-producing process that generates many output resources, creating a
many-to-many relationship between output resources and source resources. If
each output resource had links back to every source resource in the
data-producing process, there can be a potentially large number of such
links. Due to the potentially large number of links, and the lack of a
policy for ordering access to multiple sources, explicit storage of source
relationships is limited to cases with only a single source resource.

2 Terms

Collection - A resource that contains member resources.

Member Resource - a resource referred to by a collection. There are two
types of member resources: external and internal.

Internal Member Resource - the name given to a member resource of a
collection whose URI is relative to the URI of the collection.

External Member Resource - a member resource with an absolute URI that is
not relative to its parent's URI.

Properties - Also known as small-chunk metadata, a hierarchical set of
name/value pairs that describe a resource.

Live Properties - Properties whose semantics and syntax are enforced by the
server. For example, a live "read-only" property that is enforced by the
server would disallow PUTs to the associated resource.

Dead properties - Properties whose semantics and syntax are not enforced by
the server. A dead "read-only" property would not be enforced by the server
and thus would not be used by the server as a reason to disallow a PUT on
the associated resource.

3 Collection Requirements

The requirements for collections are given below, reprinted from [DAVREQ]:

3.1. List Collection.

A listing of all resources in a specific collection must be accessible.

3.2. Make Collection.

It must be possible to create a new collection.

3.3. Add to Collection.

It must be possible to add a resource to a collection directly or by
reference.

3.4. Remove from Collection.

It must be possible to remove a resource from a collection.

4 MKCOL Method

4.1 Problem Description

The client needs a way to create a collection.

4.2 Solution Requirements

The solution:

   * Must ensure that a collection has been made (i.e. that it responds to
     the INDEX method) as opposed to a non-collection resource. If a
     collection could not be made, it must indicate a failure to the
     principal.
   * The server MAY, if necessary, create any intermediate collections so
     that the underlying storage medium is consistent.

4.3 Request

The MKCOL method creates a new collection resource at the location specified
by the Request-URI, overwriting any existing resource at Request-URI.

A MKCOL request message MAY contain a message body that specifies additional
characteristics or behavior of the collection. However, a server which
supports MKCOL is not required to support any MKCOL request entity types. If
the server receives a MKCOL request entity type it does not support or
understand, it MUST respond with a 415 (Unsupported Media Type) status code.

During MKCOL processing, a server MAY add the Request-URI to one or more
collections within the server's controlled namespace.

4.3.1 Creating Multiple Collections

The server MAY create intermediate collections if they do not already exist.
For example, if the collection http://server/a/ already exists in the
server's namespace, then while performing a MKCOL to create
http://server/a/b/c/ the server may also create a collection at
http://server/a/b/.

4.4 Response

Responses from a MKCOL request are not cacheable, since MKCOL has
non-idempotent semantics.

201 (Created) - The structured resource was created in its entirety.

403 (Forbidden) - The server does not allow the creation of collections at
the given location in its namespace.

415 (Unsupported Media Type) - The server does not support the request type
of the body.

416 (Unprocessable Entity) - A new status code. The server understands the
content type of the request entity, but was unable to process the contained
instructions.

4.5 Example

This example creates a container collection called /webdisc/xfiles/ on the
server www.server.org.

MKCOL /webdisc/xfiles/ HTTP/1.1
Host: www.server.org

HTTP/1.1 201 Created

5 INDEX Method

5.1 Problem Description

A mechanism is needed to discover if a resource is a collection and if so,
list its members.

5.2 Solution Requirements

The solution:

   * must allow a client to discover the members of a collection
   * must always provide a machine-readable description of the membership of
     a collection

5.3 The Request

The INDEX method returns a machine-readable representation of the membership
of the resource at the Request-URI. For a collection, INDEX returns a
machine-readable list of its members. For other resources, the information
returned by INDEX is undefined, and MAY vary. The request message body of an
INDEX request SHOULD be ignored.

The Depth header can be used to indicate how much of a result can be
generated for the response. The specific values allowed for the depth header
when used with the INDEX method are 1 and infinity. The 1 value indicates
that the immediate member resources should be reported in the result,
infinity indicates that all internal descendant resources should be in the
result. If the Depth header is not given, then 1 is assumed. Servers MUST
honor a depth of 1. Servers MAY honor infinity.

5.4 The Response

200 (OK) - The server MUST send an application/xml response entity which
describes the collection.

404 (Not Found) - Same behavior as HTTP 1.1. The server never had the
resource, or the server permanently deleted the resource and has no
knowledge that it ever existed. This error code implies that, essentially,
the server has no information about the Request URI.

5.5 Response Message Body

The default INDEX response for a resource is an application/xml HTTP entity
(i.e., an Extensible Markup Language (XML) document) that contains a single
XML entity called collectionresource which describes the collection, and a
set of XML entities called memberesource which describe the members of the
collection.

The response from INDEX is cacheable, and MUST be accompanied by an ETag
header. If GET and INDEX return different entities for the same resource
state, they MUST return different entity tags.

The server MUST transmit the following XML entities for each member resource
of a collection: Ref, IsCollection, Content-Type, External. The server MUST
transmit the following XML entities if it can generate any meaningful values
for them: Creation-Date, Last-Modified, ETag, DisplayName.

The value of content-type, last-modified, and etag XML entities MUST be
identical to the value of the response header field of the same name in the
HTTP/1.1 specification. Since the HTTP/1.1 header fields are described in
terms of the on-the-wire entity, the values presented by INDEX are those
that would be generated if the resource was accessed using the GET method
without content negotiation.

5.5.1 CollectionResource

Name: http://www.ietf.org/standards/dav/index/collectionresource
Purpose: Describes a collection
Schema: http://www.ietf.org/standards/dav/
Parent: <XML>
Value: MemberResource

5.5.2 MemberResource

Name: http://www.ietf.org/standards/dav/index/memberresource
Purpose: Describes a member of a collection
Schema: http://www.ietf.org/standards/dav/
Parent: CollectionResource
Value: Ref, IsCollection, Content-Type, External, Creation-Date,
Last-Modified, ETag, DisplayName (other XML entities MAY also be present)

5.5.3 Ref

See XML definition.

5.5.4 IsCollection

Name: http://www.ietf.org/standards/dav/index/iscollection
Purpose: This is a boolean value which is set to "true" if the entry is a
collection
Schema: http://www.ietf.org/standards/dav/
Parent: MemberResource
Value: ("true" | "false")

5.5.5 Content-Type

Name: http://www.ietf.org/standards/dav/index/content-type
Purpose: The content-type of the member resource.
Schema: http://www.ietf.org/standards/dav/
Parent: MemberResource
Value: media-type ; defined in Section 3.7 of [HTTP11] If no meaningful
content-type can be generated, then an empty value MUST be given.

5.5.6 External

Name: http://www.ietf.org/standards/dav/index/external
Purpose: If present, this element indicates the resource is an external
member of the collection. If the value is "propagate," it is a propagate
member, if the value is "no-propagate," it is a no-propagate member.
Schema: http://www.ietf.org/standards/dav/
Parent: MemberResource
Value: ("propagate" | "no-propagate")

5.5.7 Creation-Date

Name: http://www.ietf.org/standards/dav/index/creation-date
Purpose: The date the resource was created.
Schema: http://www.ietf.org/standards/dav/
Parent: MemberResource
Value: The date MUST be given in RFC 1123 format (rfc-1123 production,
defined in section 3.3.1 of [HTTP11]

5.5.8 Last-Modified

Name: http://www.ietf.org/standards/dav/index/last-modified
Purpose: The date the resource was last modified.
Schema: http://www.ietf.org/standards/dav/
Parent: MemberResource
Value: The date MUST be given in RFC 1123 format (rfc-1123 production,
defined in section 3.3.1 of [HTTP11]

5.5.9 ETag

Name: http://www.ietf.org/standards/dav/index/etag
Purpose: The entity tag of the resource.
Schema: http://www.ietf.org/standards/dav/
Parent: MemberResource
Value: entity-tag ; defined in Section 3.11 of [HTTP11]

5.5.10 DisplayName

Name: http://www.ietf.org/standards/dav/index/displayname
Purpose: A name for the resource that is suitable for presentation to a
person
Schema: http://www.ietf.org/standards/dav/
Parent: MemberResource
Value: Any valid XML character data (from XML specification)

5.6 Example

INDEX /user/yarong/dav_drafts/ HTTP/1.1
Host: www.microsoft.com
Depth: 1

HTTP/1.1 200 OK
Content-Type: application/xml
Content-Length: xxx
Last-Modified: xxx
ETag: "fooyyybar"

<XML>

<XML:Namespace><Ref>http://www.ietf.org/standards/dav/index/</><As>I</></>
<I:CollectionResource>
        <MemberResource>
                <XML:Ref>namespace.doc</>
                <IsCollection>false</>
                <Content-Type>application/msword</>
                <External>false</>
                <Creation-Date>Thu, 20 Mar 1997 23:05:25 GMT</>
                <Last-Modified>Fri, 22 Aug 1997 18:22:56 GMT</>
                <Etag>8675309</>
                <DisplayName>WebDAV Name Spe Operations Draft</>
</>     </>
</>

This example shows the result of the INDEX method applied to the collection
resource http://www.microsoft.com/er/yarong/dav_drafts/. It returns a
response body in XML format, which gives information about the container's
sole member, http://www.microsoft.com/users/yarong/dav_drafts/namespace.doc.

6 Behavior of RFC 2068 Methods on Collections

With the introduction of the collection resource type to the HTTP object
model, it is necessary to define the behavior of the existing methods
(defined in RFC 2068) when invoked on a collection resource to avoid
ambiguity. While some methods, such as OPTIONS and TRACE behave identically
when applied to collections, GET, HEAD, POST, PUT, and DELETE require some
additional explanation.

6.1 GET, HEAD for Collections

The semantics of GET are unchanged when applied to a collection, since GET
is defined as, "retrieve whatever information (in the form of an entity) is
identified by the Request-URI" [HTTP11]. GET when applied to a collection
MAY return the contents of an "index.html" resource, a human-readable view
of the contents of the collection, or something else altogether, and hence
it is possible the result of a GET on a collection will bear no correlation
to the state of the collection.

Similarly, since the definition of HEAD is a GET without a response message
body, the semantics of HEAD do not require any modification when applied to
collection resources.

6.2 POST for Collections

Since by definition the actual function performed by POST is determined by
the server and often depends on the particular resource, the behavior of
POST when applied to collections cannot be modified because it is largely
undefined. Thus the semantics of POST do not require any modification when
applied to a collection.

6.3 PUT for Collections

In HTTP/1.1, PUT stores the request entity under the Request-URI, and hence
its semantics are limited to non-collection resources. If a PUT is invoked
on a collection, the collection has the DELETE method invoked on it, and
then PUT processing proceeds as specified in [HTTP11].

When the PUT operation creates a new non-collection resource, a server MAY
add that resource's URI to one or more collections within the server's
controlled namespace.

6.4 DELETE for Collections

When DELETE is applied to a collection resource, all internal members MUST
be recursively deleted. The dav:link/propagate members MUST be deleted and
their links must be removed. dav:link/nopropagate members MUST have only
their link removed; the resources MUST not be deleted.

The Depth header does not apply to the DELETE method. It cannot be used to
limit the extent of the operation. If it is present and has a value other
than "Infinite", the request MUST fail with a 412 (Precondition Failed).

When applied to any resource, the DELETE method deletes all properties on
the Request-URI.

During DELETE processing, a server MAY remove the URI of the deleted
resource(s) from collections within its controlled namespace.

6.4.1 New Response Codes

207 (Partial Success) Only some of the member resources were deleted. The
response entity will describe any errors.

500 (Server Error) The resource was in such a state that it could not be
deleted. The response entity will describe reason for the error.

7 COPY Method

7.1 Problem Description

Currently, in order to create a copy of a resource, the client must GET an
entity and then PUT that entity to the desired destination. This requires
(1) an entity to be transmitted to and from the server and (2) that the
resource be expressible as an entity with complete fidelity.

This is problematic because of the network traffic involved in making a
copy, and because there is often no way to fully express a resource as an
entity without a loss of fidelity.

7.2 Solution Requirements

The solution:

   * MUST allow a principal to create a copy of a resource without having to
     transmit the resource to and from the server.

7.3 The Request

The COPY method creates a duplicate of the source resource, given by the
Request-URI, in the destination resource, given by the Destination header.
The Destination header MUST be present. The exact behavior of the COPY
method depends on the type of the source resource.

7.3.1 COPY for HTTP/1.1 resources

When the source resource is not a collection, and is not a property, the
body of the destination resource MUST be octet-for-octet identical to the
body of the source resource. Alterations to the destination resource do not
modify the source resource. Alterations to the source resource do not modify
the destination resource. Thus, all copies are performed "by-value".

If the Duplicate-Properties header is "false," then properties SHOULD NOT be
copied to the destination resource. If the Duplicate-Properties header is
"false" and the Enforce-Live-Properties header is also present, the request
MUST fail with a 412 (Precondition Failed) status code.

Properties SHOULD be duplicated on the destination resource by performing
the equivalent actions as a logical copy of the root property on the source
to the root property on the destination, following the definition for
copying properties.

7.3.2 COPY for Properties

Live properties SHOULD be duplicated as identically behaving live properties
at the destination resource. Since they are live properties, the server
determines the syntax and semantics (hence value) of these properties.
Properties named by the Enforce-Live-Properties header MUST be live on the
destination resource, or the method MUST fail. If a property is not named by
Enforce-Live-Properties and cannot be copied live, then its value MUST be
duplicated in an identically named, dead resource on the destination
resource.

For every dead property defined on the source resource, there SHOULD be an
octet-for-octet identical dead property on the destination resource.

Duplicated properties MUST maintain the ordering of properties on the
destination, and MUST maintain the tree structure of properties.

7.3.3 COPY for Collections

The Depth and Overwrite headers govern the behavior of COPY for collections.

When performing a recursive copy, all HTTP/1.1 request headers are
duplicated on the propagated method request except for the precondition
headers If-Modified-Since, If-Match, If-None-Match, If-Range,
If-Unmodified-Since, which should only be applied to the Request-URI to
determine if the operation should be performed. The Destination header MUST
be rewritten to preserve the membership of the destination collection, i.e.,
by appending the relative URI of the member to the URI of the destination
collection.

A Depth of "0" indicates the collection MUST duplicate all of its external
members in a new collection at the Destination. Since the COPY method is not
propagated to its members, no internal member resource is duplicated.

A Depth of "1" indicates the collection MUST propagate the COPY to all
internal, non-collection members and to all non-collection propagate
external members. If the Overwrite header is "true" the COPY method
duplicates all of its external members in a new collection at the
Destination. If the Overwrite header is "false" and the destination resource
is a collection, the COPY method does not duplicate its external members,
but is propagated to all internal, non-collection members.

A Depth of "infinity" indicates the collection MUST propagate the COPY
method to all internal members and all propagate external members. If the
Overwrite header is "true," the COPY method MUST duplicate all of its
external members in a new collection at the Destination. If the Overwrite
header is "false" and the destination resource is a collection, then the
COPY method does not duplicate its external members, but is propagated to
all internal members.

A copy operation on a collection should behave as if it were performed
atomically.

7.3.4 Type Interactions

If the destination resource identifies a property and the source resource is
not a property, then the copy SHOULD fail.

If the destination resource identifies a collection and the Overwrite header
is "true," prior to performing the copy, a DELETE operation MUST be
performed on the collection.

7.4 The Response

200 (OK) The source resource was successfully copied to a pre-existing
destination resource.

201 (Created) The source resource was successfully copied. The copy
operation resulted in the creation of a new resource.

207 (Partial Success) Only some of the member resources were copied. The
return entity body describes the status code for each resource.

412 (Precondition Failed) This status code MUST be returned if the server
was unable to maintain the liveness of the properties listed in the
Enforce-Live-Properties header, or if the Overwrite header is false, and the
state of the destination resource is non-null.

500 (Server Error) The resource was in such a state that it could not be
copied. This may occur if the Destination header indicated an external (from
the point of view of the server) resource and the server has no capability
to copy to an external resource.

502 (Bad Gateway) - This may occur when copying to external resources and
the destination server refused to accept the resource.

7.5 Examples

7.5.1 Overwrite Example

This example shows resource http://www.ics.uci.edu/~fielding/index.html
being copied to the location
http://www.ics.uci.edu/users/f/fielding/index.html. The contents of the
destination resource were overwritten, if non-null.

COPY /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html
Overwrite: "true"

HTTP/1.1 200 OK

7.5.2 No Overwrite Example

The following example shows the same copy operation being performed, except
with the Overwrite header set to "false." A response of 412, Precondition
Failed, is returned because the destination resource has a non-null state.

COPY /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html

HTTP/1.1 412 Precondition Failed

8 MOVE Method

8.1 Problem Description

The move operation on a resource is the logical equivalent of a copy
followed by a delete.

In HTTP 1.1, the procedure could be performed in several steps. First, the
client could issue a GET to retrieve a representation of a resource, issue a
DELETE to remove the resource from the server, then use PUT to place the
resource on the server with a new URI. As is the case for COPY, because of
the network traffic involved in making a move, and because there is often no
way to fully express a resource as an entity without a loss of fidelity,
server move functionality is preferable.

With a DAV server, a principal may accomplish this task by issuing a COPY
and then DELETE. Network load decreases, but the server load may still be
significant because the server must create a duplicate resource. If a server
knew beforehand that a principal intends to perform COPY and DELETE
operations in succession, it can avoid the creation of a duplicate resource.

8.2 Solution Requirements

The solution:

   * Must prevent the unneeded transfer of entity bodies from and to the
     server.
   * Must prevent the unneeded creation of copies by the server.

8.4 The Request

The MOVE method is defined as the logical equivalent of a COPY followed by a
DELETE of the source resource, performed atomically.

8.5 The Response

200 (OK) - The resource was moved. A successful response must contain the
Content-Location header, set equal to the URI in source. This lets caches
properly flush any cached entries for the source. Unfortunately the
Content-Location header only allows a single value so it is not possible for
caches unfamiliar with the MOVE method to properly clear their caches.

207 (Partial Success) Only some of the member resources were moved. The
return entity body will give the status code for each resource.

412 (Precondition Failed) This status code MUST be returned if the server
was unable to maintain the liveness of the properties listed in the
Enforce-Live-Properties header, or if the Overwrite header is false, and the
state of the destination resource is non-null.

501 (Not Implemented) - This may occur if the Destination header specifies a
resource which is outside its domain of control (e.g., stored on another
server) resource and the server either refuses or is incapable of moving to
an external resource.

502 (Bad Gateway) - This may occur when moving to external resources and the
destination server refused to accept the resource.

8.6 Examples

8.6.1 Overwrite Example

This example shows resource http://www.ics.uci.edu/~fielding/index.html
being moved to the location
http://www.ics.uci.edu/users/f/fielding/index.html. The contents of the
destination resource were overwritten, if non-null.

MOVE /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html
Overwrite: true

HTTP/1.1 200 OK
Content-Location: http://www.ics.uci.edu/users/f/fielding/index.html

9 Multi-Status Response

9.1 Problem Definition

When certain methods (COPY, MOVE, and DELETE) are applied to a collection,
they may end up being recursively applied to all sub-members of the
collection. In this case, it is possible that the operation will succeed on
some member resources, while it will fail on others, thus generating a 207
(Partial Success) status code. A user-agent needs to know for which members
of the collection the method succeeded and for which it failed.

9.2 Solution Requirements

The solution must:

- communicate the status code and reason

- give the URI of the resource on which the method was invoked

- be consistent with other return body formats

9.3 Multi-Status Response

The default multi-status response body is an application/xml HTTP entity
that contains a single XML entity called multiresponse, which contains a set
of XML entities called response, one for each 200, 300, 400, and 500 series
status code generated during the method invocation. 100 series status codes
MUST NOT be recorded in a response XML entity. Each response XML entity
contains two sub-entities, ref, the URI of the resource on which the method
was invoked, and status, which holds the status-line from the method
invocation.

A multi-status response MUST be present when a 207 (Partial Success) status
code is returned by the initial method invocation.

9.3.1 MultiResponse

Name: http://www.ietf.org/standards/dav/multiresponse/multiresponse
Purpose: Contains multiple response messages.
Schema: http://www.ietf.org/standards/dav/multiresponse/
Parent: <XML>
Value: 1*Response

9.3.2 Response

Name: http://www.ietf.org/standards/dav/multiresponse/response
Purpose: Holds a single response
Schema: http://www.ietf.org/standards/dav/multiresponse/
Parent: MultiResponse
Value: Ref, Status

9.3.3 Status

Name: http://www.ietf.org/standards/dav/multiresponse/status
Purpose: Holds a single HTTP status-line
Schema: http://www.ietf.org/standards/dav/multiresponse/
Parent: Response
Value: status-line ;status-line defined in [HTTP11]

9.4 Example

COPY /users/jdoe/collection/ HTTP/1.1
Host: www.doecorp.com
Destination: http://www.doecorp.com/users/jdoe/othercollection/
Depth: infinity
Overwrite: false

HTTP/1.1 207 Partial Success
Content-Type: application/xml
Content-Length: xxx

<XML>
<XML:Namespace><Ref>http://www.ietf.org/standards/dav/multiresponse/</><As>R</></>
<R:MultiResponse>
        <Response>
                <XML:Ref>http://www.doecorp.com/users/jdoe/collection/index.html</>
        <Status>HTTP/1.1 412 Precondition Failed</>
        </>
        <Response>
                <XML:Ref>http://www.doecorp.com/users/jdoe/collection/report.html</>
                <Status>HTTP/1.1 200 OK</>
        </>
</>
</>

10 PATCH Method

10.1 Problem Definition

At present, if a principal modifies a resource, they must issue a GET
against the resource, modify their local copy of the resource, and then
issue a PUT to place the modified resource on the server. This procedure is
inefficient because the entire entity for a resource must be transmitted to
and from the server in order to make even small changes. Ideally, the update
entity transmitted to the server should be proportional in size to the
modifications.

10.2 Solution Requirements

The solution must:

   * allow partial modification of a resource without having to transmit the
     entire modified resource
   * allow byte-range patching
   * allows extensions so that patches can be done beyond simple byte-range
     patching
   * allow ranges to be deleted, inserted, and replaced

10.3 The Request

The PATCH method contains a list of differences between the original version
of the resource identified by the Request-URI and the desired content of the
resource after the PATCH action has been applied. The list of differences is
in a format defined by the media type of the entity (e.g.,
"application/diff") and must include sufficient information to allow the
server to convert the original version of the resource to the desired
version.

Since the semantics of PATCH are non-idempotent, responses to this method
are not cacheable.

If the request appears (at least initially) to be acceptable, the server
MUST transmit an interim 100 response message after receiving the empty line
terminating the request headers and continue processing the request.

While server support for PATCH is optional, if a server does support PATCH,
it MUST support at least the application/xml diff format defined below.
Support for the VTML difference format [VTML] is recommended, but not
required.

10.4 application/xml entities for PATCH

The resourceupdate XML entity contains a set of XML sub-entities that
describe modification operations. The name and meaning of these XML entities
is given below. Processing of these directives MUST be performed in the
order encountered within the XML document.

10.4.1 ResourceUpdate

Name: http://www.ietf.org/standards/dav/patch/resourceupdate
Purpose: Contains an ordered set of changes to a non-collection,
non-property resource. Schema: http://www.ietf.org/standards/dav/patch/
Parent: <XML>
Value: *(Insert | Delete | Replace)

10.4.2 Insert

Name: http://www.ietf.org/standards/dav/patch/insert
Purpose: Insert the XML entity's contents starting exactly at the specified
octet.
Schema: http://www.ietf.org/standards/dav/patch/
Parent: ResourceUpdate
Value: The insert XML entity MUST contain an octet XML entity that specifies
an octet position within the body of a resource. A value of "end" specifies
the end of the resource. The body of the insert XML entity contains the
octets to be inserted.

10.4.3 Delete

Name: http://www.ietf.org/standards/dav/patch/delete
Purpose: Removes the specified range of octets.
Schema: http://www.ietf.org/standards/dav/patch/
Parent: ResourceUpdate
Value: The Delete XML entity MUST contain an octet-range XML entity. The
value of this XML entity is empty. Discussion: The octets which are deleted
are removed, which meams the resource is collapsed and the length of the
resource is decremented by the size of the octet range. It is not
appropriate to replace deleted octets with zeroed-out octets, since zero is
a valid octet value.

10.4.5 Replace

Name: http://www.ietf.org/standards/dav/patch/replace
Purpose: Replaces the specified range of octets with the contents of the XML
entity. If the number of octets in the XML entity is different from the
number of octets specified, the update MUST be rejected. Schema:
http://www.ietf.org/standards/dav/patch/ Parent: ResourceUpdate Value: The
Replace XML entity MUST contain an octet-range XML entity. The contents of
the entity are the replacement octets.

10.4.6 Octet-Range Attribute

Name: http://www.ietf.org/standards/dav/patch/octet-range
Purpose: Specifies a range of octets which the enclosing property effects.
Schema: http://www.ietf.org/standards/dav/patch/ Parent: Insert, Delete,
Replace
Value: number ["-" (number | "end")]
Number = 1*Digit
Description: Octet numbering begins with 0. If the octet contains a single
number then the operation is to begin at that octet and to continue for a
length specified by the operation. In the case of a delete, this would mean
to delete but a single octet. In the case of an insert this would mean to
begin the insertion at the specified octet and to continue for the length of
the included value, extending the resource if necessary. In the case of
replace, the replace begins at the specified octet and overwrites all that
follow to the length of the included value. Octet values MUST specify
locations in the state of the resource prior to the processing of the PATCH
method.

10.5 The Response

200 (OK) - The request entity body was processed without error, resulting in
an update to the state of the resource.

409 (Conflict) - If the update information in the request message body does
not make sense given the current state of the resource (e.g., an instruction
to delete a non-existent line), this status code MAY be returned.

415 (Unsupported Media Type) - The server does not support the content type
of the update instructions in the request message body.

416 (Unprocessable Entity) - A new status code. The server understands the
content type of the request entity, but was unable to process the contained
instructions.

10.6 Examples

10.6.1 HTML file modification

The following example shows a modification of the title and contents of the
HTML resource http://www.example.org/hello.html.

Before:

<HTML>
<HEAD>
<TITLE>Hello world HTML page</TITLE>
</HEAD>
<BODY>
<P>Hello, world!</P>
</BODY>
</HTML>

PATCH Request:

PATCH hello.html HTTP/1.1
Host: www.example.org
Content-Type: application/xml
Content-Length: xxx

Interim response:

HTTP/1.1 100 Continue

Request continues (it was never interrupted, the 100 response came in while
the response was being sent).

<XML>
<XML:Namespace><ref>http://www.ietf.org/standards/dav/patch/</><AS>D</></>
<D:ResourceUpdate>
        <Replace><octet-range>14</>&003CTITLE&003ENew Title&003C/TITLE&003E</>
        <Delete><octet-range>38-50</>
        <Insert><octet-range>86</>&003CP&003ENew paragraph&003C/P&003E
</>
</></>

Final response

HTTP/1.1 200 OK

After:

<HTML>
<HEAD>
<TITLE>New Title</TITLE>
</HEAD>
<BODY>
<P>Hello, world!</P>
<P>New paragraph</P>
</BODY>
</HTML>

11 Headers

11.1 Depth

The Depth header determines the depth to which a method is propagated on a
resource's children.

Depth = "Depth" ":" DepthToken
DepthToken = "0" | "1" | "infinity" | token

The optional token allows for extension. A server MUST ignore a Depth header
with an unknown value.

11.2 Destination

The Destination header specifies a destination resource for methods such as
COPY and MOVE which take two URIs as parameters.

Destination= "Destination" ":" URI

11.3 Enforce-Live-Properties

The Enforce-Live-Properties header specifies properties that MUST be "live"
after they are copied (moved) to the destination resource of a copy (or
move). If the value "*" is given for the header, then it designates all live
properties on the source resource.

EnforceLiveProperties = "Enforce-Live-Properties:" "*" | 1#( Property-Name )
Property-Name = <"> URI <">

11.4 Duplicate-Properties

The Duplicate-Properties header instructs the server whether to duplicate
the source resource's properties onto the destination resource during a COPY
or MOVE. A value of "false" states that the server MUST NOT duplicate on the
destination resource any properties which are defined on the source
resource. By default, the value of this header is "true," and a client MAY
omit this header from a request when its value is "true."

Duplicate-Properties = "Duplicate-Properties" ":" ("true" | "false")

11.5 Overwrite

The Overwrite header specifies whether the server should overwrite the state
of a non-null destination resource during a COPY or MOVE. A value of "false"
states that the server MUST NOT perform the COPY or MOVE operation if the
state of the destination resource is non-null. By default, the value of
Overwrite is "false," and a client MAY omit this header from a request when
its value is "false." While the Overwrite header appears to duplicate the
functionality of the If-Match: * header of HTTP/1.1, If-Match applies only
to the Request-URI, and not to the Destination of a COPY or MOVE.

Overwrite = "Overwrite" ":" ("true" | "false")

11.6 Destroy Header

When deleting a resource the client often wishes to specify exactly what
sort of delete is being enacted. The Destroy header, used with PEP, allows
the client to specify the end result they desire. The Destroy header is
specified as follows:

DestroyHeader = "Destroy" ":" #Choices
Choices = "VersionDestroy" | "NoUndelete" | "Undelete" | Token

The Undelete token requests that, if possible, the resource should be left
in a state such that it can be undeleted. The server is not required to
honor this request.

The NoUndelete token requests that the resource MUST NOT be left in a state
such that it can be undeleted.

The VersionDestroy token includes the functionality of the NoUndelete token
and extends it to include having the server remove all versioning references
to the resource that it has control over.

12 Links

A collection is stored as a set of links. Internal members of the
collection, and external propagate members are links of type propagate.
External non-propagate members of the collection are links of type
nopropagate.

12.1 Propagate Link Type

Name: http://www.ietf.org/standards/dav/link/propagate
Purpose: A propagate link holds a member of a collection that has recursive
method invocations propagated to it.
Schema: http://www.ietf.org/standards/dav/link/
Parent: Any.
Value: src, dst (See the definition of links in the companion draft, "A Data
Model and Operations for DAV Properties").
Discussion: The source of the link (src) must be the URI of the collection,
and there must be only one destination (dst) of the link, which is the URI
of the propagate member. If the URI is relative to the URI of the
collection, then this link describes an internal member of a collection,
otherwise the link describes an external, propagate member of the
collection.

12.2 NoPropagate Link Type

Name: http://www.ietf.org/standards/dav/link/nopropagate
Purpose: A no-propagate link holds an external member of a collection that
does not have recursive method invocations propagated to it.
Schema: http://www.ietf.org/standards/dav/link/
Parent: Any.
Value: src, dst
Discussion: The source of the link (src) must be the URI of the collection,
and there must be only one destination (dst) of the link, which is the URI
of the external, no-propagate member.

12.3 Source Link Type

Name: http://www.ietf.org/standards/dav/link/source
Purpose: The destination of the source link identifies the resource which
contains the unprocessed source of the link's source.
Schema: http://www.ietf.org/standards/dav/link/
Parent: Any.
Value: src, dst
Discussion: The source of the link (src) is typically the URI of the
resource on which the link is defined, and there is typically only one
destination (dst) of the link, which is the URI where the unprocessed source
of the resource may be accessed.

13 References

[DAVREQ] J. A. Slein, F. Vitali, E. J. Whitehead, Jr., and D. G. Durand.
"Requirements for Distributed Authoring and Versioning on the World Wide
Web" Internet Draft, work-in-progress,
<draft-ietf-webdav-requirements-00.txt>, May, 1997.

[HTTP11] R. T. Fielding, J. Gettys, J. C. Mogul, H. F. Nielsen, and T.
Berners-Lee. "Hypertext Transfer Protocol -- HTTP/1.1" RFC 2068. U.C.
Irvine, Digital Equipment Corp., MIT/LCS. January, 1997.

[NEWURL] T. Berners-Lee, R. Fielding, L. Masinter. "Uniform Resource
Locators (URL): Generic Syntax and Semantics." Internet-draft,
work-in-progress. <draft-fielding-url-syntax-05.txt>, May 2, 1997.

[VTML] F. Vitali, D. Durand. "VTML: Technical Description." Unpublished
manuscript. <http://www.cs.unibo.it/~fabio/bio/Working/Versioning/VTML.html

A Appendix A - Open Issues

The following are open issues.

  1. Can you have multiple source links on a single resource?
  2. Whether Depth = 1 header values should be allowed for COPY on
     collections
  3. Should Patch octet references by cumulative or must all absolutely
     refer to the previous state of the resource? (I (YYG) personally
     believe they should be cumulative)


From w3c-dist-auth-request@www10.w3.org  Tue Jun 17 19:01:05 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id TAA18940 for <w3c-dist-auth@www19.w3.org>; Tue, 17 Jun 1997 19:01:05 -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 TAA20567 for <w3c-dist-auth@w3.org>; Tue, 17 Jun 1997 19:01:04 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa08920;
          17 Jun 97 16:00 PDT
X-Sender: ejw@paris.ics.uci.edu
Message-Id: <afccc82f1c0210042fd3@[128.195.21.209]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 17 Jun 1997 16:06:57 -0700
To: w3c-dist-auth@w3.org
>From: Jim Whitehead <ejw@ics.uci.edu>
Subject: FYI, Design Team Meeting
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

FYI, there will be a meeting of the WebDAV Design Team on June 23-24, 1997,
held at the offices of Netscape Corporation, in Mountain View, California.
Expected attendees at this meeting are Steve Carter, Novell, Asad Faizi,
Netscape, Yaron Goland, Microsoft, Del Jensen, Novell, Jim Whitehead, U.C.
Irvine.  The purpose of this meeting is to review the proposals, correcting
minor technical errors, and identifying issues which need discussion at the
Orem, Utah meeting July 14-15.

- Jim



From w3c-dist-auth-request@www10.w3.org  Wed Jun 18 18:39:17 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id SAA02093 for <w3c-dist-auth@www19.w3.org>; Wed, 18 Jun 1997 18:39:17 -0400 (EDT)
Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id SAA25259 for <w3c-dist-auth@w3.org>; Wed, 18 Jun 1997 18:39:17 -0400 (EDT)
Received: from sub.sonic.net (sub.sonic.net [208.201.224.8])
          by marine.sonic.net (8.8.5/8.8.5) with ESMTP
	  id PAA11169 for <w3c-dist-auth@w3.org>; Wed, 18 Jun 1997 15:39:43 -0700
Received: from bolt.sonic.net (tallen@bolt.sonic.net [208.201.224.36]) by sub.sonic.net (8.8.5/8.8.5) with ESMTP id PAA00179; Wed, 18 Jun 1997 15:39:15 -0700
X-envelope-info: <tallen@bolt.sonic.net>
Received: (from tallen@localhost) by bolt.sonic.net (8.8.5/8.7.3) id PAA09371; Wed, 18 Jun 1997 15:38:51 -0700
Date: Wed, 18 Jun 1997 15:38:51 -0700
>From: Terry Allen <tallen@sonic.net>
Message-Id: <199706182238.PAA09371@bolt.sonic.net>
To: ejw@rome.ICS.UCI.EDU, w3c-dist-auth@w3.org
Subject: Re: Namespace Draft
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

My comments re XML usage are the same as for the previous draft.
This document provokes several other thoughts.

1.1 Collection resources.  I would invert the order of the first
3 paras.  State the general description of the concept before the
specifics.

Separately, it is important to clarify whether a collection is
the entirely of a literary work or whether a literary work
may consists of multiple collections ("larger logical units").
For publishing, as distinct from WEBDAV's particular interests,
we need to be able to say that some list of resources constitutes
*all and only* a particular literary work.  In this case, I see
no reason why a book might not consist of multiple collections
(perhaps one covering chapters 1, 2, and 5, contributed by author
A, and another covering chapters 3 and 4, contributed by author B).
Please indicate which of these views you have in mind (or some other).

5.3, para 2, Depth header.  This has been tried in SGML, Hytime,
Hytime-as-revised, and simply does not work to define any but
arbitrary limits in a web of documents, because documents may be deep 
in some places and shallow in others, and the shallow parts may link to 
external documents not a part of the literary work in which the 
links reside.  Consider a collection that consists of a central
work (a collection of its own) with multiple sets of annotations
linked to from it.  Unless you manipulate the structure of the
central work so that it is evenly deep throughout, it's hard to
ask for N levels of depth and get all of the central work with
none of the annotations.  


Regards,

  Terry Allen    Electronic Publishing Consultant    tallen[at]sonic.net
                   http://www.sonic.net/~tallen/
    Davenport and DocBook:  http://www.ora.com/davenport/index.html
          T.A. at Passage Systems:  terry.allen[at]passage.com 


From w3c-dist-auth-request@www10.w3.org  Wed Jun 18 18:47:33 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id SAA02180 for <w3c-dist-auth@www19.w3.org>; Wed, 18 Jun 1997 18:47:33 -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 SAA25305 for <w3c-dist-auth@w3.org>; Wed, 18 Jun 1997 18:47:33 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa12363;
          18 Jun 97 15:46 PDT
X-Sender: ejw@paris.ics.uci.edu
Message-Id: <afce164b120210049840@[128.195.21.209]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 18 Jun 1997 15:52:54 -0700
To: w3c-dist-auth@w3.org
>From: Jim Whitehead <ejw@ics.uci.edu>
Subject: Re: Namespace Draft
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring


Thank you for your comments on the namespace draft, and also on the
properties draft.  Just a couple notes of clarification.

>My comments re XML usage are the same as for the previous draft.
>This document provokes several other thoughts.

I have been in contact with Tim Bray, a co-editor of the XML draft, who
states that there will be a new XML draft available on or close to July 1.


>5.3, para 2, Depth header.  This has been tried in SGML, Hytime,
>Hytime-as-revised, and simply does not work to define any but
>arbitrary limits in a web of documents, because documents may be deep
>in some places and shallow in others, and the shallow parts may link to
>external documents not a part of the literary work in which the
>links reside.  Consider a collection that consists of a central
>work (a collection of its own) with multiple sets of annotations
>linked to from it.  Unless you manipulate the structure of the
>central work so that it is evenly deep throughout, it's hard to
>ask for N levels of depth and get all of the central work with
>none of the annotations.

Agreed, which is why the Depth header can take the value 0 (the collection
itself), 1 (the immediate non-collection members of the collection),
infinity (go as deep as you can).  Do you see problems with this approach?

- Jim



From w3c-dist-auth-request@www10.w3.org  Wed Jun 18 19:15:39 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id TAA02312 for <w3c-dist-auth@www19.w3.org>; Wed, 18 Jun 1997 19:15:39 -0400 (EDT)
Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id TAA25378 for <w3c-dist-auth@w3.org>; Wed, 18 Jun 1997 19:15:38 -0400 (EDT)
Received: from sub.sonic.net (sub.sonic.net [208.201.224.8])
          by marine.sonic.net (8.8.5/8.8.5) with ESMTP
	  id QAA19302 for <w3c-dist-auth@w3.org>; Wed, 18 Jun 1997 16:16:05 -0700
Received: from bolt.sonic.net (tallen@bolt.sonic.net [208.201.224.36]) by sub.sonic.net (8.8.5/8.8.5) with ESMTP id QAA07493; Wed, 18 Jun 1997 16:15:36 -0700
X-envelope-info: <tallen@bolt.sonic.net>
Received: (from tallen@localhost) by bolt.sonic.net (8.8.5/8.7.3) id QAA10924; Wed, 18 Jun 1997 16:15:11 -0700
Date: Wed, 18 Jun 1997 16:15:11 -0700
>From: Terry Allen <tallen@sonic.net>
Message-Id: <199706182315.QAA10924@bolt.sonic.net>
To: ejw@ics.uci.edu, w3c-dist-auth@w3.org
Subject: Re: Namespace Draft
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

>Agreed, which is why the Depth header can take the value 0 (the collection
itself), 1 (the immediate non-collection members of the collection),
infinity (go as deep as you can).  Do you see problems with this approach?
          
That's not what the spec says s.v. 5.3; it lists only 1 and infinity,
and I see I misread, thinking that values in between were allowed.
I am confused by the terms "immediate member resources" (what is
the force of "immediate") and "internal descendant resources"
(not in 2. Terms).

In either case it would appear that External Member Resources
would not be listed, yet their only sin is that they possess
an absolute URI not relative to their parent's (the collection's?)
URI.  So INDEX will not give a complete listing of the contents
of a collection if some are differently URI'd than the collection
itself, even if they are on the same server.  Is that right
or am I missing something?  (And did you intend to allow integers
between 1 and infinity?)

And what is a "noncollection member of the collection"?  An
internal member resource that is not itself a collection?  

Regards,

  Terry Allen    Electronic Publishing Consultant    tallen[at]sonic.net
                   http://www.sonic.net/~tallen/
    Davenport and DocBook:  http://www.ora.com/davenport/index.html
          T.A. at Passage Systems:  terry.allen[at]passage.com 


From w3c-dist-auth-request@www10.w3.org  Wed Jun 18 19:35:53 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id TAA02483 for <w3c-dist-auth@www19.w3.org>; Wed, 18 Jun 1997 19:35: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 TAA25451 for <w3c-dist-auth@w3.org>; Wed, 18 Jun 1997 19:35:53 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa15505;
          18 Jun 97 16:31 PDT
X-Sender: ejw@paris.ics.uci.edu
Message-Id: <afce1e8d140210048917@[128.195.21.209]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 18 Jun 1997 16:37:48 -0700
To: Terry Allen <tallen@sonic.net>, w3c-dist-auth@w3.org
>From: Jim Whitehead <ejw@ics.uci.edu>
Subject: Re: Namespace Draft
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

>>Agreed, which is why the Depth header can take the value 0 (the collection
>itself), 1 (the immediate non-collection members of the collection),
>infinity (go as deep as you can).  Do you see problems with this approach?
>
>That's not what the spec says s.v. 5.3; it lists only 1 and infinity,
>and I see I misread, thinking that values in between were allowed.
>I am confused by the terms "immediate member resources" (what is
>the force of "immediate") and "internal descendant resources"
>(not in 2. Terms).

Right.  INDEX is defined to return a listing of the members of a
collection.  In the example below:

  A
 / \
J   K
|
Z

Depth of 0 would be just A (and hence a very boring listing).  Depth of 1
is A, J, K.  Depth Infinity is A, J, K, Z.  So, INDEX was limited to Depth
1 and Infinity so it would actually return something (Depth 0 would only
report information about the collection itself, perhaps its human-readable
title).

The intent of "immediate member resources" is the Depth 1 non-collection
resources, but the proposal should be more explicit in its language.

>In either case it would appear that External Member Resources
>would not be listed, yet their only sin is that they possess
>an absolute URI not relative to their parent's (the collection's?)
>URI.  So INDEX will not give a complete listing of the contents
>of a collection if some are differently URI'd than the collection
>itself, even if they are on the same server.  Is that right
>or am I missing something?  (And did you intend to allow integers
>between 1 and infinity?)

Urrr, I think this is a problem with the wording of the proposal.  The
intent is certainly to return a listing of external members during an
INDEX, but I agree with you, the proposal does not clearly indicate this is
the desired behavior.


>And what is a "noncollection member of the collection"?  An
>internal member resource that is not itself a collection?

Yes.  I agree, "noncollection member of the collection" is a really awkward
term.

- Jim



From w3c-dist-auth-request@www10.w3.org  Wed Jun 18 19:59:58 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id TAA02554 for <w3c-dist-auth@www19.w3.org>; Wed, 18 Jun 1997 19:59: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 TAA25486 for <w3c-dist-auth@w3.org>; Wed, 18 Jun 1997 19:59:57 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa17266;
          18 Jun 97 16:54 PDT
X-Sender: ejw@paris.ics.uci.edu
Message-Id: <afce21f31502100455b7@[128.195.21.209]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 18 Jun 1997 17:00:36 -0700
To: w3c-dist-auth@w3.org
>From: Jim Whitehead <ejw@ics.uci.edu>
Subject: Re: Open Requirements Issues
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

OK, I'm going to take a stab at the i18n requirement again.

On June 5, Terry Allen wrote:
>How about "nothing in this specification shall be interpreted to
>inhibit internationalization".  As for the character set, the IAB
>view is ISO 10646.

Well, the only problem with this is that it's a negative requirement, and
it is hard to determine when it has been satisfied.

On the other hand...

On June 6, Dylan Barrell wrote:

1)  The server should support the notion of document language versions
(similar in concept to renditions) and should always produce the language
version corresponding to the language of the user's client, the explicit
language version requested by the client (i.e. it should be possible to
explicitly address a particular language version) or the default language.
2)  The client should be able to specify its preferred languages in order
of preference and the server should present from the existing language
versions the one highest on the client's list. Failing this the default
language should be presented.
3)  It should be possible to specify to the server which language version
is the default (master version)
4)  When asking for a list of objects in a collection it should be possible
to obtain a list of all the different language versions of each resource
(the default should simply return the list of default language resources)
5)  It should be possible to lock only a particular language version of a
resource or all languages
6)  There must be a way of indicating which nodes in the version graph for
each language can be considered equivalent (there might be a different
number of versions for each language version)


First, #1, #2, and #3 are already provided by HTTP/1.1 (although there is
currently some debate on this issue).  Since we're building on top of
HTTP/1.1, this can be considered base capability.

#4 is interesting, perhaps Content-Language should be returned by INDEX, if
it is defined for a resource.

As for #5, the view so far has been to assume that every variant of a
resource is itself a resource, and hence has a URI.  If it has a URI, then
it can be locked.   So this capability is provided for by the locking
proposal.

#6 can be accomplished using links between resources.  Links are discussed
in the properties draft.

---

To me, the areas within WebDAV which require i18n support are the value
fields for properties and version comments, since these will be displayed
to human operators of WebDAV clients.   As a result, I think that the
following requirement could satisfy WebDAV i18n needs:

Internationalization:  All attribute values and version comments must have
provisions for storing one or more of the encoding formats specified in
ISO10646.

Another way might be to leave it more general, and have a statement like:

Internationalization:  All attribute values and version comments must have
provisions for storing a representation in any human character set.

Although I'm not sure that ISO10646 and "any human character set" are
identical.  I prefer referring to ISO10646 since it's more concrete, and
avoid the issue of which character sets to support.

- Jim



From w3c-dist-auth-request@www10.w3.org  Thu Jun 19 03:53:59 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id DAA07157 for <w3c-dist-auth@www19.w3.org>; Thu, 19 Jun 1997 03:53:59 -0400 (EDT)
Received: from go.opentext.ch (go.opentext.ch [195.48.77.130]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id DAA26689 for <w3c-dist-auth@w3.org>; Thu, 19 Jun 1997 03:53:56 -0400 (EDT)
Received: (from root@localhost) by go.opentext.ch (8.7.3/GO-3a) id JAA02749; Thu, 19 Jun 1997 09:39:53 +0200 (MET DST)
Received: from gammon.opentext.ch(195.48.77.115) by go.opentext.ch via smap (V1.3)
	id sma002747; Thu Jun 19 09:39:53 1997
Received: from cassius.opentext.ch (cassius.opentext.ch [195.48.77.23]) by gammon.opentext.ch (8.6.12/8.6.9) with SMTP id JAA14019; Thu, 19 Jun 1997 09:56:39 +0100
Received: by cassius.opentext.ch with Microsoft Mail
	id <01BC7C63.FC2F5C20@cassius.opentext.ch>; Thu, 19 Jun 1997 03:50:53 -0400
Message-ID: <01BC7C63.FC2F5C20@cassius.opentext.ch>
>From: Dylan Barrell <dbarrell@opentext.ch>
To: "'Jim Whitehead'" <ejw@ics.uci.edu>,
        "w3c-dist-auth@w3.org"
	 <w3c-dist-auth@w3.org>
Subject: RE: Open Requirements Issues
Date: Thu, 19 Jun 1997 03:50:51 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

With regard to i18n requirements

RFC 2068 does not specify the structure of the URI tree (i.e. does not =
specify that the german version of text.html is text.gr.html or =
gr/text.html or anything else) it is therefore not possible to write an =
authoring tool which hides this structure from the author unless we make =
additional specifications w.r.t #1, #3, #4, #5 and #6.

Cheers
Dylan


From w3c-dist-auth-request@www10.w3.org  Thu Jun 19 06:13:52 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id GAA08750 for <w3c-dist-auth@www19.w3.org>; Thu, 19 Jun 1997 06:13:51 -0400 (EDT)
Received: from josef.ifi.unizh.ch (josef.ifi.unizh.ch [130.60.48.10]) by www10.w3.org (8.8.5/8.7.3) with SMTP id GAA27064 for <w3c-dist-auth@w3.org>; Thu, 19 Jun 1997 06:13:50 -0400 (EDT)
Received: from ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) 
          id <06423-0@josef.ifi.unizh.ch>; Thu, 19 Jun 1997 12:08:23 +0200
Date: Thu, 19 Jun 1997 12:08:22 +0200 (MET DST)
>From: "Martin J. Duerst" <mduerst@ifi.unizh.ch>
Sender: mduerst@enoshima
To: Dylan Barrell <dbarrell@opentext.ch>
cc: "'Jim Whitehead'" <ejw@ics.uci.edu>,
        "w3c-dist-auth@w3.org" <w3c-dist-auth@w3.org>
Subject: RE: Open Requirements Issues
In-Reply-To: <01BC7C63.FC2F5C20@cassius.opentext.ch>
Message-ID: <Pine.SUN.3.96.970619120623.6897r-100000@enoshima>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

On Thu, 19 Jun 1997, Dylan Barrell wrote:

> With regard to i18n requirements
> 
> RFC 2068 does not specify the structure of the URI tree (i.e. does not
> specify that the german version of text.html is text.gr.html or gr/text.html
> or anything else) it is therefore not possible to write an authoring tool
> which hides this structure from the author unless we make additional
> specifications w.r.t #1, #3, #4, #5 and #6.

Up to now, it was assumed that this structure is an implementation issue
of the server. For usual HTTP use (serving documents), this is certainly
the case. It may be that this is different for WEBDAV issues.

Regards,	Martin.

P.S.: German is "de", not "gr"!


From w3c-dist-auth-request@www10.w3.org  Thu Jun 19 06:18:25 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id GAA08788 for <w3c-dist-auth@www19.w3.org>; Thu, 19 Jun 1997 06:18:24 -0400 (EDT)
Received: from josef.ifi.unizh.ch (josef.ifi.unizh.ch [130.60.48.10]) by www10.w3.org (8.8.5/8.7.3) with SMTP id GAA27079 for <w3c-dist-auth@w3.org>; Thu, 19 Jun 1997 06:18:17 -0400 (EDT)
Received: from ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) 
          id <06688-0@josef.ifi.unizh.ch>; Thu, 19 Jun 1997 12:17:20 +0200
Date: Thu, 19 Jun 1997 12:17:19 +0200 (MET DST)
>From: "Martin J. Duerst" <mduerst@ifi.unizh.ch>
Sender: mduerst@enoshima
To: Jim Whitehead <ejw@ics.uci.edu>
cc: w3c-dist-auth@w3.org
Subject: Re: Open Requirements Issues
In-Reply-To: <afce21f31502100455b7@[128.195.21.209]>
Message-ID: <Pine.SUN.3.96.970619120829.6897s-100000@enoshima>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

On Wed, 18 Jun 1997, Jim Whitehead wrote:

> On June 6, Dylan Barrell wrote:
> 
> 1)  The server should support the notion of document language versions
> (similar in concept to renditions) and should always produce the language
> version corresponding to the language of the user's client, the explicit
> language version requested by the client (i.e. it should be possible to
> explicitly address a particular language version) or the default language.
> 2)  The client should be able to specify its preferred languages in order
> of preference and the server should present from the existing language
> versions the one highest on the client's list. Failing this the default
> language should be presented.
> 3)  It should be possible to specify to the server which language version
> is the default (master version)
> 4)  When asking for a list of objects in a collection it should be possible
> to obtain a list of all the different language versions of each resource
> (the default should simply return the list of default language resources)
> 5)  It should be possible to lock only a particular language version of a
> resource or all languages
> 6)  There must be a way of indicating which nodes in the version graph for
> each language can be considered equivalent (there might be a different
> number of versions for each language version)
> 
> 
> First, #1, #2, and #3 are already provided by HTTP/1.1 (although there is
> currently some debate on this issue).  Since we're building on top of
> HTTP/1.1, this can be considered base capability.

It's true that #1 and #2 are provided. #3 is not really provided.
On many servers, it's realized by a (Unix file system) link from
document.html to document.en.html, or vice versa. Other conventions exist.
I don't know if it's possible to tell the server to make a link using HTTP/1.1,
and the mechanisms differ from server to server, so it's not
satisfied in a way that would allow to build webdav clients offering
this functionality easily.


> #4 is interesting, perhaps Content-Language should be returned by INDEX, if
> it is defined for a resource.
> 
> As for #5, the view so far has been to assume that every variant of a
> resource is itself a resource, and hence has a URI.  If it has a URI, then
> it can be locked.   So this capability is provided for by the locking
> proposal.
> 
> #6 can be accomplished using links between resources.  Links are discussed
> in the properties draft.

These are some kind of "semantic links", not links in e.g. an Unix
file system?


> ---
> 
> To me, the areas within WebDAV which require i18n support are the value
> fields for properties and version comments, since these will be displayed
> to human operators of WebDAV clients.   As a result, I think that the
> following requirement could satisfy WebDAV i18n needs:
> 
> Internationalization:  All attribute values and version comments must have
> provisions for storing one or more of the encoding formats specified in
> ISO10646.
> 
> Another way might be to leave it more general, and have a statement like:
> 
> Internationalization:  All attribute values and version comments must have
> provisions for storing a representation in any human character set.
> 
> Although I'm not sure that ISO10646 and "any human character set" are
> identical.  I prefer referring to ISO10646 since it's more concrete, and
> avoid the issue of which character sets to support.

I think for a requirements document, it is enough to address the question
of the character repertoire, without reference to encoding issues.
So how about:

All attribute values and version comments must have provisions for
storing all characters from the Universal Character Set (ISO 10646).

As for actual implementation, using UTF-8 is probably the best solution.
Having several encoding formats complicates things a lot.


Regards,	Martin.


From w3c-dist-auth-request@www10.w3.org  Thu Jun 19 06:23:05 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id GAA08855 for <w3c-dist-auth@www19.w3.org>; Thu, 19 Jun 1997 06:23:05 -0400 (EDT)
Received: from go.opentext.ch (go.opentext.ch [195.48.77.130]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id GAA27091 for <w3c-dist-auth@w3.org>; Thu, 19 Jun 1997 06:23:04 -0400 (EDT)
Received: (from root@localhost) by go.opentext.ch (8.7.3/GO-3a) id MAA01283; Thu, 19 Jun 1997 12:09:07 +0200 (MET DST)
Received: from gammon.opentext.ch(195.48.77.115) by go.opentext.ch via smap (V1.3)
	id sma001281; Thu Jun 19 12:09:04 1997
Received: from cassius.opentext.ch (cassius.opentext.ch [195.48.77.23]) by gammon.opentext.ch (8.6.12/8.6.9) with SMTP id MAA00444; Thu, 19 Jun 1997 12:25:39 +0100
Received: by cassius.opentext.ch with Microsoft Mail
	id <01BC7C78.CAB7E3A0@cassius.opentext.ch>; Thu, 19 Jun 1997 06:19:49 -0400
Message-ID: <01BC7C78.CAB7E3A0@cassius.opentext.ch>
>From: Dylan Barrell <dbarrell@opentext.ch>
To: Dylan Barrell <dbarrell@opentext.ch>,
        "'Martin J. Duerst'"
	 <mduerst@ifi.unizh.ch>
Cc: "'Jim Whitehead'" <ejw@ics.uci.edu>,
        "w3c-dist-auth@w3.org"
	 <w3c-dist-auth@w3.org>
Subject: RE: Open Requirements Issues
Date: Thu, 19 Jun 1997 06:19:48 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
X-See-Also: http://www.ics.uci.edu/~ejw/authoring

>P.S.: German is "de", not "gr"!

Not if the server decides to implement it otherwise :)

Cheers
Dylan



From w3c-dist-auth-request@www10.w3.org  Thu Jun 19 15:48:21 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id PAA17928 for <w3c-dist-auth@www19.w3.org>; Thu, 19 Jun 1997 15:48:21 -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 PAA29617 for <w3c-dist-auth@w3.org>; Thu, 19 Jun 1997 15:48:21 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa01355;
          19 Jun 97 12:44 PDT
X-Sender: ejw@paris.ics.uci.edu
Message-Id: <afcf3db8050210041049@[128.195.21.209]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 19 Jun 1997 12:50:27 -0700
To: w3c-dist-auth@w3.org
>From: Jim Whitehead <ejw@ics.uci.edu>
Subject: Re: Open Requirements Issues


On June 19, Martin J. Duerst wrote:
>> #6 can be accomplished using links between resources.  Links are discussed
>> in the properties draft.
>
>These are some kind of "semantic links", not links in e.g. an Unix
>file system?

Yes.  In the current proposal, a link is an item of metadata which has a
source URI, one or more destination URIs, and a type (which is a name in
the URI namespace).  They are not symbolic links in the Unix file system
sense.


>> To me, the areas within WebDAV which require i18n support are the value
>> fields for properties and version comments, since these will be displayed
>> to human operators of WebDAV clients.   As a result, I think that the
>> following requirement could satisfy WebDAV i18n needs:
>>
>> Internationalization:  All attribute values and version comments must have
>> provisions for storing one or more of the encoding formats specified in
>> ISO10646.
>>
>> Another way might be to leave it more general, and have a statement like:
>>
>> Internationalization:  All attribute values and version comments must have
>> provisions for storing a representation in any human character set.
>>
>> Although I'm not sure that ISO10646 and "any human character set" are
>> identical.  I prefer referring to ISO10646 since it's more concrete, and
>> avoid the issue of which character sets to support.
>
>I think for a requirements document, it is enough to address the question
>of the character repertoire, without reference to encoding issues.
>So how about:
>
>All attribute values and version comments must have provisions for
>storing all characters from the Universal Character Set (ISO 10646).

I like this wording.


>As for actual implementation, using UTF-8 is probably the best solution.
>Having several encoding formats complicates things a lot.

I don't have any experience with implementing a system that uses ISO10646
character set encodings, but in ISP10646 it lists several escape sequences
which can designate which character encoding is being used.  At least on
the surface, it would appear relatively easy to write code that read the
escape sequence, called the appropriate decoder based on the escape
sequence, and then stored everything internally in UCS-4 format. These same
escape sequences are described in Appx. E of the XML spec. -- if we're
going to have simple XML parsers in WebDAV clients and servers, then
implementation of multiple character sets comes along with this.

Or is there some technical difficulty here that would make it desirable to
only use UTF-8?

- Jim



From w3c-dist-auth-request@www10.w3.org  Thu Jun 19 17:25:06 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id RAA19599 for <w3c-dist-auth@www19.w3.org>; Thu, 19 Jun 1997 17:25:06 -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 RAA00020 for <w3c-dist-auth@w3.org>; Thu, 19 Jun 1997 17:25:05 -0400 (EDT)
Received: from nma.com by paris.ics.uci.edu id ae09657; 19 Jun 97 14:20 PDT
Received: from paris.ics.uci.edu by norn.nma.com id aa20443; 19 Jun 97 14:09 PDT
To: Jim Whitehead <ejw@ics.uci.edu>
Cc: w3c-dist-auth@w3.org
Subject: Re: Open Requirements Issues 
>From: Einar Stefferud <stef=webdav@nma.com>
Reply-to: stef=webdav@nma.com
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <20439.866754544.1@nma.com>
Date: Thu, 19 Jun 1997 14:09:05 -0700
Message-ID: <20441.866754545@nma.com>
Sender: stef@nma.com

Given your WG position on "other than HTTP", I find that my interst in
the WG has dimisinshed to the point of not paying attention any
longer, as it is clear that you do not want to be concerned with
anything other than HTTP.

So, I am going away to help you achieve consensus by asddig a loud bit
of silance.  But, remember that "I told you so", as I will not be the
one to remind you when you wake up to the hard reality of not being
able to interwork via EMail, or anything other than HTTP.

Just one note at this point.  The obvious solution to future
enablement of EMail support for WEBDAV (not WEBDAV support for EMail)
is to focus on plaicing all you PDUs inside MIME envelopes.  With that
done, transoprt no longer remains a key issue for WEBDAV.

However, since you are all so fully focused on HTTP TRANSPORT to the
exclusion of any alternative transports, I have nothing more to
contribute, and I will stand aside and make no further comment.

Enjoy...\Stef

>From your message Thu, 5 Jun 1997 17:48:36 -0700:
}
}I'd like to start a dialog on the last remaining open issues in the
}requirements document, since I feel that for most issues, a little bit of
}discussion will resolve the issue.
}
}The requirements document lists the following issues as still being under
}discussion:
}
}*       Whether support for multi-resource locking is needed
}*       Whether reservations should be treated as shared or advisory locks
}*       What requirements there should be for access control
}*       What requirements there should be for internationalization
}*       How far WebDAV should be concerned about compatibility with other
}transport protocols besides HTTP
}
}My views on these issues are as follows:
}
[SNIP]...
}
}*       How far WebDAV should be concerned about compatibility with other
}transport protocols besides HTTP
}
}Well, since our charter limits us to discussion on HTTP and Email as
}transport protocols, this open issue really concerns email access.  The
}sense I have been receiving from the list is the current, "don't shoot,
}don't spec." (don't shoot ourselves in the foot by making it impossible to
}do an email mapping in the future, but don't actually write a spec. for
}this right now) is how most would prefer to proceed.
}
}If my reading of the sense of the working group is correct, then we should
}not have a requirement on this topic, and can declare the issue closed.  If
}there is strong support for writing a spec. on email access, then Gregory
}Woodhouse, who has volunteered to look into this, needs to write up some
}requirements, which may or may not end up in future versions of
}draft-ietf-webdav-requirements.
}
}
}Comments?
}
}- Jim
}


From w3c-dist-auth-request@www10.w3.org  Thu Jun 19 17:25:08 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id RAA19603 for <w3c-dist-auth@www19.w3.org>; Thu, 19 Jun 1997 17:25:07 -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 RAA00022 for <w3c-dist-auth@w3.org>; Thu, 19 Jun 1997 17:25:06 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa09827;
          19 Jun 97 14:22 PDT
X-Sender: ejw@paris.ics.uci.edu
Message-Id: <afcf53b40c0210043b3e@[128.195.21.209]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 19 Jun 1997 14:29:04 -0700
To: w3c-dist-auth@w3.org
>From: Jim Whitehead <ejw@ics.uci.edu>
Subject: Upcoming meetings

There are two upcoming meetings of the WEBDAV Working Group:

* July 14-15, 1997.  Novell Campus, Orem, Utah.
<http://www.ics.uci.edu/~ejw/authoring/orem/>
This is a two day meeting whose purpose is a detailed review of the latest
proposals, as well as the requirements document.  Note that the DMA
Technical Committee will be meeting at the same site on July 16-17.
Registration for both meetings: email Steve Carter <srcarter@novell.com>

* August 11, 1997.  IETF Meeting, Munich, Germany
<http://www.ietf.org/meetings/meetings.html>
This is a 2 hour meeting, where there will be discussion of the latest
proposals, as well as the requirements document.
Registration: fill out form at: <http://www.ietf.org/meetings/rsvp-info.html>

- Jim



From w3c-dist-auth-request@www10.w3.org  Thu Jun 19 21:49:00 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id VAA21762 for <w3c-dist-auth@www19.w3.org>; Thu, 19 Jun 1997 21:49:00 -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 VAA00754 for <w3c-dist-auth@w3.org>; Thu, 19 Jun 1997 21:49:00 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa01396;
          19 Jun 97 18:42 PDT
X-Sender: ejw@paris.ics.uci.edu
Message-Id: <afcf915502021004b85c@[128.195.21.209]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 19 Jun 1997 18:48:50 -0700
To: w3c-dist-auth@w3.org
>From: Jim Whitehead <ejw@ics.uci.edu>
Subject: RE: Access Control Preliminary Draft

On June 16, Dylan Barrell wrote:
>>5.2 Access Inheritance
>>
>>It must be possible to assign an access attribute to a collection
>>(such as a directory).  By default, resources contained in a collection
>>must inherit access attributes from their parent resource.
>>
>>5.2.1 Rationale
>>
>>Inheritance of security information between directories and files
>>within most file systems behave in this manner.  This promotes an
>>orthagonal implementation on the Web.
>
>I think that specifying that the access attributes must inherit from the
>parent resource will require us to specify too many details regarding the
>semantics of changing the permissions of the various resources (eg what
>happens to the children's access attributes when we change those of the
>parent). I think this should be restated as
>
>"5.2 It must be possible to assign an access attribute to a collection
>(such as a directory).  The system must assign appropriate default access
>attributes to resources added to a collection."

Hmm.  I think I like this even better than the original requirement -- I
think this provides a good tradeoff between wanting to assign individual
access permissions to resources, but still have some way for a resource to
receive its initial, default permissions.

- Jim



From w3c-dist-auth-request@www10.w3.org  Fri Jun 20 11:59:30 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id LAA29048 for <w3c-dist-auth@www19.w3.org>; Fri, 20 Jun 1997 11:59:30 -0400 (EDT)
Received: from twaxx.twaxx.com (twaxx.com [205.162.25.89]) by www10.w3.org (8.8.5/8.7.3) with SMTP id LAA02819 for <w3c-dist-auth@w3.org>; Fri, 20 Jun 1997 11:59:29 -0400 (EDT)
X-Authentication-Warning: www10.w3.org: Host twaxx.com [205.162.25.89] claimed to be twaxx.twaxx.com
Received: by twaxx.twaxx.com (940816.SGI.8.6.9/940406.SGI.AUTO)
	 id JAA01169; Fri, 20 Jun 1997 09:00:12 -0700
>From: "-=jack=-" <jack@twaxx.com>
Message-Id: <9706200900.ZM1167@twaxx.com>
Date: Fri, 20 Jun 1997 09:00:08 -0700
In-Reply-To: Jim Whitehead <ejw@ics.uci.edu>
        "RE: Access Control Preliminary Draft" (Jun 19,  6:48pm)
References: <afcf915502021004b85c@[128.195.21.209]>
X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail)
To: Jim Whitehead <ejw@ics.uci.edu>, w3c-dist-auth@w3.org
Subject: Re: Access Control Preliminary Draft
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii

>"5.2 It must be possible to assign an access attribute to a collection
>(such as a directory).  The system must assign appropriate default access
>attributes to resources added to a collection."

Hmm.  I think I like this even better than the original requirement -- I
think this provides a good tradeoff between wanting to assign individual
access permissions to resources, but still have some way for a resource to
receive its initial, default permissions.
------------------------
I like this better also, I must admit there is a good point raised about
the potential complexity.  Having the inheritance provide defaults (or
some similar scheme) seems a good tradeoff to me as well...

-=jack=-

(This text composed by voice)



-- 


From w3c-dist-auth-request@www10.w3.org  Mon Jun 23 13:48:14 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id NAA04334 for <w3c-dist-auth@www19.w3.org>; Mon, 23 Jun 1997 13:48:14 -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 NAA12251 for <w3c-dist-auth@w3.org>; Mon, 23 Jun 1997 13:48:13 -0400 (EDT)
Received: from bronze.parc.xerox.com ([13.1.100.114]) by alpha.xerox.com with SMTP id <23688(6)>; Mon, 23 Jun 1997 09:54:43 PDT
Message-ID: <33AEAA43.B05@parc.xerox.com>
Date: Mon, 23 Jun 1997 09:54:27 PDT
>From: Larry Masinter <masinter@parc.xerox.com>
Organization: Xerox PARC
X-Mailer: Mozilla 3.01Gold (Win95; U)
MIME-Version: 1.0
To: Jim Whitehead <ejw@ics.uci.edu>
CC: w3c-dist-auth@w3.org
Subject: Re: Open Requirements Issues
References: <afcf3db8050210041049@[128.195.21.209]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I think there will soon enough be a 'policy' statement from
the IAB based on, but different from, the report of the IAB
charset workshop, such that it is not necessary for WEBDAV
to have an explicit policy on charsets. However, support for
authoring multi-lingual documents, and documents with variants
in multiple languages, and support for versioning thereof,
could usefully be addressed in the WEBDAV requirements; however,
I also think it will be difficult to get consensus on anything
that is meaningful, because individual's perceptions of requirements
in this area are widely varying.

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


From w3c-dist-auth-request@www10.w3.org  Tue Jun 24 00:35:12 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id AAA10081 for <w3c-dist-auth@www19.w3.org>; Tue, 24 Jun 1997 00:35:12 -0400 (EDT)
Received: from novell.com (orm-mail20.orem.novell.com [151.155.174.10]) by www10.w3.org (8.8.5/8.7.3) with SMTP id AAA14606 for <w3c-dist-auth@w3.org>; Tue, 24 Jun 1997 00:35:12 -0400 (EDT)
X-Authentication-Warning: www10.w3.org: Host orm-mail20.orem.novell.com [151.155.174.10] claimed to be novell.com
Received: from INET-ORM-Message_Server by novell.com
	with Novell_GroupWise; Mon, 23 Jun 1997 22:35:05 -0600
Message-Id: <s3aefa19.049@novell.com>
X-Mailer: Novell GroupWise 4.1
Date: Mon, 23 Jun 1997 22:32:08 -0600
>From: Steve Carter <SRCARTER@novell.com>
To: ejw@ics.uci.edu, w3c-dist-auth@w3.org
Subject: Current Registration for the Orem WebDAV meeting
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline

This is the current list of attendees for the Orem WebDAV meeting to be held
July 14-15, 1997:

 1. Asad Faizi, Netscape
 2. Sankar Virdhagriswaran
 3. Judith Slein, Xerox
 4. Jon Radoff
 5. Henry Sanders, Microsoft
 6. Yaron Goland, Microsoft
 7. Steve Carter, Novell
 8. Del Jensen, Novell
 9. Gary Ashton, Novell
10. Jerry Jaworski, Eastman Software
11. Lasantha Jayasinghe
12. Saveen Reddy, Microsoft
13. Dennis Hamilton, Xerox
14. T. Grannan
15. Alec Dun, Microsoft
16. Karen MacArthur, Crystaliz, Inc.
17. Dan Whelan, FileNet
18. Chuck Fay, FileNet
19. Alan Babich, FileNet
20. Jim Green, FileNet
21. Lee Farrell, Cannon Information Systems
22. Jim Whitehead, University of California, Irvine

Please note that I need all attendees to preregister.

thanks  -src
 


From w3c-dist-auth-request@www10.w3.org  Wed Jun 25 07:40:10 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id HAA00658 for <w3c-dist-auth@www19.w3.org>; Wed, 25 Jun 1997 07:40:09 -0400 (EDT)
Received: from josef.ifi.unizh.ch (josef.ifi.unizh.ch [130.60.48.10]) by www10.w3.org (8.8.5/8.7.3) with SMTP id HAA21105 for <w3c-dist-auth@w3.org>; Wed, 25 Jun 1997 07:40:09 -0400 (EDT)
Received: from ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) 
          id <27168-0@josef.ifi.unizh.ch>; Wed, 25 Jun 1997 13:40:11 +0200
Date: Wed, 25 Jun 1997 13:40:09 +0200 (MET DST)
>From: "Martin J. Duerst" <mduerst@ifi.unizh.ch>
Sender: mduerst@enoshima
To: Larry Masinter <masinter@parc.xerox.com>
cc: Jim Whitehead <ejw@ics.uci.edu>, w3c-dist-auth@w3.org
Subject: Re: Open Requirements Issues
In-Reply-To: <33AEAA43.B05@parc.xerox.com>
Message-ID: <Pine.SUN.3.96.970625133329.286H-100000@enoshima>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 23 Jun 1997, Larry Masinter wrote:

> I think there will soon enough be a 'policy' statement from
> the IAB based on, but different from, the report of the IAB
> charset workshop, such that it is not necessary for WEBDAV
> to have an explicit policy on charsets.

Agreed!

> However, support for
> authoring multi-lingual documents, and documents with variants
> in multiple languages, and support for versioning thereof,
> could usefully be addressed in the WEBDAV requirements; however,
> I also think it will be difficult to get consensus on anything
> that is meaningful, because individual's perceptions of requirements
> in this area are widely varying.

I think it is one of the core tasks of producing a requirements
document to identify various perceptions and requirements and
see how and how much they vary.

There is definitely some degree of variation as to how much
support, e.g. for parallel documents in various languages, is
needed. But this is something that depends on the application,
and just because one web site doesn't need it doesn't mean
it's not very meaningful, or even crucial, for another site.

Before we try, we don't know.		Regards,	Martin.


From w3c-dist-auth-request@www10.w3.org  Thu Jun 26 18:48:05 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id SAA18461 for <w3c-dist-auth@www19.w3.org>; Thu, 26 Jun 1997 18:48:05 -0400 (EDT)
Received: from go.opentext.ch (go.opentext.ch [195.48.77.130]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id SAA29889 for <w3c-dist-auth@w3.org>; Thu, 26 Jun 1997 18:48:04 -0400 (EDT)
Received: (from root@localhost) by go.opentext.ch (8.7.3/GO-3a) id AAA15713; Fri, 27 Jun 1997 00:33:33 +0200 (MET DST)
Received: from gammon.opentext.ch(195.48.77.115) by go.opentext.ch via smap (V1.3)
	id sma015711; Fri Jun 27 00:33:27 1997
Received: from cassius.opentext.ch (cassius.opentext.ch [195.48.77.23]) by gammon.opentext.ch (8.6.12/8.6.9) with SMTP id AAA13480; Fri, 27 Jun 1997 00:50:39 +0100
Received: by cassius.opentext.ch with Microsoft Mail
	id <01BC8261.067FAB00@cassius.opentext.ch>; Thu, 26 Jun 1997 18:44:49 -0400
Message-ID: <01BC8261.067FAB00@cassius.opentext.ch>
>From: Dylan Barrell <dbarrell@opentext.ch>
To: Jim Whitehead <ejw@ics.uci.edu>,
        "'Larry Masinter'"
	 <masinter@parc.xerox.com>
Cc: "w3c-dist-auth@w3.org" <w3c-dist-auth@w3.org>
Subject: RE: Open Requirements Issues
Date: Thu, 26 Jun 1997 17:48:54 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I don't know where you get the impression that individual's perceptions =
of requirements vary widely on these issues because I am the only one =
who has ever stated what their position is on these issues.=20

Cheers
Dylan

----------
>From:  Larry Masinter[SMTP:masinter@parc.xerox.com]
Sent:  Montag, 23. Juni 1997 12:54
To:  Jim Whitehead
Cc:  w3c-dist-auth@w3.org
Subject:  Re: Open Requirements Issues

I think there will soon enough be a 'policy' statement from
the IAB based on, but different from, the report of the IAB
charset workshop, such that it is not necessary for WEBDAV
to have an explicit policy on charsets. However, support for
authoring multi-lingual documents, and documents with variants
in multiple languages, and support for versioning thereof,
could usefully be addressed in the WEBDAV requirements; however,
I also think it will be difficult to get consensus on anything
that is meaningful, because individual's perceptions of requirements
in this area are widely varying.

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



From w3c-dist-auth-request@www10.w3.org  Thu Jun 26 19:53:41 1997
Received: from www10.w3.org by www19.w3.org (8.8.5/8.6.12) with ESMTP id TAA19089 for <w3c-dist-auth@www19.w3.org>; Thu, 26 Jun 1997 19:53:41 -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 TAA00177 for <w3c-dist-auth@w3.org>; Thu, 26 Jun 1997 19:53:41 -0400 (EDT)
Received: from galileo.ics.uci.edu by paris.ics.uci.edu id aa15662;
          26 Jun 97 16:48 PDT
X-Sender: ejw@paris.ics.uci.edu
Message-Id: <afd8aff409021004dba6@[128.195.21.209]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 26 Jun 1997 16:54:45 -0700
To: w3c-dist-auth@w3.org
>From: Jim Whitehead <ejw@ics.uci.edu>
Subject: Preliminary Orem agenda

WEBDAV Working Group Meeting
July 14-15, 1997
Orem, Utah

Preliminary Agenda

The following is a preliminary agenda for the July 14-15, 1997 WebDAV
Working Group meeting.  If you have any topics you would like to have
added, or have any changes you would like to suggest, please email them to
Jim Whitehead <ejw@ics.uci.edu>.

Monday, July 14

8:30AM - Continental breakfast
9:00AM - Introduction / Confirm agenda
9:10AM - Discussion of metadata/properties
12 Noon - Lunch
1:00PM - Discussion of Locking
4:00PM - Discussion of Open Requirements Issues
5:00PM - Adjourn for the day.

Tuesday, July 15

8:30AM - Continental breakfast
9:00AM - Confirm agenda
9:10AM - Discussion of Namespace/containers issues
12 Noon - Lunch
1:00PM - Discussion of Versioning
3:30PM - Discussion of Access Control
5:00PM - Meeting adjourns.

Breaks as needed during the day.

Details on the Orem meeting can be found at:

http://www.ics.uci.edu/~ejw/authoring/orem/

If you are planning on attending, please email Steve Carter
<srcarter@novell.com> to preregister.  This meeting is open to all who wish
to attend.

- Jim




