- From: Jim Whitehead <ejw@ics.uci.edu>
- Date: Wed, 22 Apr 1998 15:23:38 -0700
- To: "'WEBDAV WG'" <w3c-dist-auth@w3.org>
These are the preliminary minutes from the WebDAV WG meeting held at the LA
IETF. I'm a bit late on these due to WWW7, and I have to submit them this
Friday. If you have any comments, please submit them by the end of the day
Thursday to get them into the official minutes. I'll update the minutes on
the WebDAV web site with any corrections after this date.
- Jim
--------------------------
Minutes
WEBDAV WG Meeting
Los Angeles IETF, April 2, 1998
A WEBDAV WG meeting was held at the Los Angeles IETF, on April 2, 1998,
with approximately 45 people in attendance. Jim Whitehead chaired the
meeting, Rohit Khare, Del Jensen, and Jim Davis were notetakers. Final
minutes were prepared by Jim Whitehead from these notes. The meeting began
with a review of the agenda, followed by a presentation on WG status by Jim
Whitehead. The WEBDAV Distributed Authoring Protocol document will be
revised based on comments from the second working group last call,
producing revision -08, and will be sent to the IESG for Last Call and
review as soon as the -08 draft is in the Internet-Drafts directory. A
WEBDAV interim working group meeting will take place June 15-17, 1998, in
Redmond, WA, to discuss advanced collections functionality, versioning, and
access control. Many thanks to Yaron Goland and Microsoft for hosting this
meeting.
Following the WG status report, Keith Swenson, <kswenson@netscape.com>,
<URL:http://people.netscape.com/kswenson/http_workflow>, gave a brief
presentation on an HTTP-based workflow standardization effort that is just
starting up. The purpose of this effort is develop an interoperability
protocol for invoking and controlling an asynchronous process via HTTP.
Elements of the protocol include simple process control (e.g., start,
pause, resume), and the ability to start external systems, such as a backup
process. A key element of the proposal is that it doesn't have to hold open
a connection, since the initial design idea is to start a process,
receiving in return an identifier URL for the process, which can then be
used in subsequent operations. There will be an initial open meeting for
interested participants on May 4, 5, 1998, in Costa Mesa, California. The
group's initial goal is to release a preliminary specification in six
months.
After Keith's presentation, the question was asked, "How is this different
from telnet?" The reply was this protocol does not require an open
connection, and isn't intended to be a login-based protocol. The
siimilarity between this work and IPP was noted, since IPP also uses HTTP,
and isn't login-based. Following this question, there was brief discussion
on the similarity between the notifications being discussed in IPP, PIPR,
and the notifications being discussed for workflow support.
Jim Davis next led a discussion of the advanced collections requirements
document, and this discussion lasted for the remainder of the session. The
goals of the discussion were to generate shared understanding, and
hopefully consensus on the requirements (goals), but not to do any design
work. The presentation began with a review of terminology, then launched
into a step by step overview of each requirement in the advanced
collections requirements draft, draft-ietf-webdav-acreq-01.txt. The notes
below are organized by requirement number.
A few questions were asked during the discussion which don't neatly fit
underneath an existing requirement. These are:
- Can one have a reference to a reference?
- Can a reference have more than one target (e.g., this might be useful in
the context of content negotiation)?
Requirements-related discussion and outcome. Agreement represents the
rough consensus of the attendees at the meeting, and this consensus is
provisional pending discussion on the mailing list.
Requirements for Referential Collection Members:
3.1.1 The same resource may be referenced by referential members of
multiple collections.
Agreed.
3.1.2 The same resource may be referenced by more than one referential
member of the same collection.
Agreed.
3.1.3 It is possible for the same resource to be an internal member of
a collection and also to be referenced by one or more referential
members of that same collection.
Agreed.
Requirement 3.1.3 sparked a discussion on circular references.
Specifically, should WebDAV allow, disallow, or be silent about circular
references? It was noted that a reference can point to any other resource,
including a collection. Early WebDAV drafts do exempt servers from having
to detect circular refereces.
3.1.4 Operations on a referential member do not affect the resource it
references.
Agreed.
Discussion of 3.1.4 led to one suggested new requirement:
N.1 Operations on a target do not affect the reference(s)
No consensus was recorded on this new requirement.
Requirement 3.1.4 also led to a discussion of preserving referential
integrity of references. Participants asked whether deleting a referenced
resource would result in deletion of the reference. Similarly for a move,
would the reference be updated if its destination were moved? It was noted
that in the general case, where the referred-to resource is on a different
server, maintaining referential integrity is impossible. However, some
participants expressed a desire for a reference whose integrity would be
guaranteed, even if that meant the server would limit the potential
destinations of the reference. The two kinds of references were called
"strong" (integrity-enforced) and "weak" (no integrity enforcement).
3.1.5 For any referential member of a collection, it is possible to
obtain the URI of the resource it references.
Agreed.
3.1.6 It is possible to add a referential member to a collection.
Agreed.
3.1.7 It is possible to remove a referential member from a collection.
Agreed.
3.1.8 It is possible for a referential member of a collection to carry its
own properties, distinct from those of the resource it refers to.
An example of this is the author, or "who added" property.
Agreed.
3.1.9 A referential member of a collection also inherits the
properties of the resource it refers to.
There was wide opposition to this, on the following grounds:
1. Assuming that the properties are copied when the reference is
created, it is unclear what access rights to use when doing the
PROPFIND. Documents and references have different access rights,
and sometimes one is wider than the other.
2. After the properties are copied, the owner of the target resource
no longer has means to control access on the properties.
3. ACAP has had problems with 'inheritance'.
4. Referential members are like symbolic links. But symbolic links
do not in general have the 'properties' of their target. Their
owner, size, and date modified all differ.
In addition:
4. If the properties are copied, they could be become out of date
afterwards. In particular, one participant vehemently complained
that inherit-by-lookup is out since it requires one server to
track another.
Another participant raised the question: isn't this easily excisable --
since no other requirements build up on it, the minimum set of requirements
could exclude it safely.
3.1.10 A listing of the members of a collection shows both the
internal members and the referential members.
Agreed.
3.1.11 Servers are encouraged to maintain referential integrity for
referential members as far as possible, but are not required to do so.
No agreement. This requirement led to a re-opening of the integrity issues
of 3.1.4. One participant noted that this requirement is like a "should"
maintain integrity, but isn't should too weak to be useful? Some
applications really care whether referential integrity will be maintained.
The issue of cross-server integrity maintenance was raised, and what this
implies for the scope of integrity maintenance. The discussion led to the
following requirement:
N.2 It is possible to request creation of a referential member that
the server will guarentee to have referentially integrity.
Some ideas on how this might be implemented were raised during the
discussion, and include using a header to inform the server to create the
reference only if it could guarantee the integrity. A property can be used
to query the integrity maintenance capabilities of the reference.
There was agreement on this new requirement.
N.3 It is possible to discover whether or not a referential member has such
'integrity protection'.
Proposed, but no agreement reached. Needs discussion.
N.4 Is is possible to discover whether a resource is the target of
such a 'protected referential member'.
Proposed, but no agreement reached. Needs discussion.
3.1.12 For any member of a collection, it is possible to discover
whether it is an internal or a referential member.
Agreed.
Requirements for Ordered Collections:
3.2.1 The ordering mechanism is sufficiently standardized that
different applications and servers can operate on the same ordering
without private agreement.
Agreed, with change in wording: "Ordering is sufficiently
standardized..." (i.e., remove "the" and "mechanism"), due to concern over
the word 'mechanism', and its precise meaning and implications.
3.2.2 The semantics of an ordering are discoverable.
Agreed, but only after much discussion. There was general concern over the
meaning of "ordering semantics", since it can be read pretty broadly. There
was discussion of proposals to replace "semantics" with "operational
characteristics" or with "ordering methodology", but in the end the
original wording prevailed. However, an action item was recorded to discuss
the meaning of "ordering semantics" on the list.
3.2.3 When a client requests a listing of the members of a collection,
it can specify the ordering to be applied, and the server will apply
that ordering to its response.
Agreed, with the addition that "The server may decline to support the
requested ordering".
3.2.4 It is possible to order the members of a collection in an
arbitrary way, not necessarily based on property values.
Agreed, with the word "arbitrary" changed to "client-specified". One
way we got into trouble here is that since the ordering might well be
stored in a property, it's hard to think of an ordering that is NOT
based on a property value. Also, there was much sentiment that DASL
should support sorting on property values, and that orderings based on
property values alone should be left to DASL and not addressed here.
There were some dissenting comments which noted that this feature should be
optional, and not required. Also, some parts of a server may not be able
to support ordering.
3.2.5 Internal and referential members may by intermixed in the same
ordering.
Agreed.
3.2.6 It is possible to impose multiple orderings on the same collection.
No agreement. No one at the meeting was able to propose a scenario
that actually requires more than one ordering. The scenario in the
requirements document was discredited, on the claim that the two
instructors should instead each create their own collections, using
referential members, and impose the ordering they wished.
There was general agreement with a proposal to remove 3.2.6. As a result of
this change, 3.2.4 becomes a labeling issue, and there was strong sentiment
that 3.2.3 and 3.2.7 should be removed as well, since this preserves a
model where there are collections with preserved order and DASL capability
for sorting. Furthermore, there was some discussion about whether 3.2.8
should also be removed.
3.2.7 An ordering is not required to contain all members of the collection.
No agreement, for the same reasons discussed in 3.2.6.
3.2.8 A collection member may belong to the same ordering more than once.
No agreement, for the same reasons discussed in 3.2.6.
3.2.9 It is possible to modify an existing ordering efficiently.
No agreement. One participant noted that this seemed strange, since it's
like a "motherhood" statement.
There was significant participant uncertainty from the discussion of 3.2.6
until the end of the session.
There was insufficient time to discuss the "Issues" from the advanced
collections requirements draft.
*** Meeting Adjourned ***
Received on Wednesday, 22 April 1998 18:26:27 UTC