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

Preliminary minutes, LA IETF

From: Jim Whitehead <ejw@ics.uci.edu>
Date: Wed, 22 Apr 1998 15:23:38 -0700
Message-ID: <01BD6E02.A0BD6A80.ejw@ics.uci.edu>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:46 GMT