- From: Jim Whitehead <ejw@cse.ucsc.edu>
- Date: Mon, 9 Apr 2001 18:15:41 -0700
- To: "WebDAV WG" <w3c-dist-auth@w3.org>
These are the minutes recorded at the WebDAV WG meeting at IETF-50. Please
note any errors you find in the minutes -- I need to submit the final
version by this Friday.
An HTML version of these minutes can be found at:
http://www.ics.uci.edu/pub/ietf/webdav/minneapolis01/minutes.html
Big thanks are due John Stracke, who took some *very* detailed minutes of
the WebDAV meeting!
- Jim
WEBDAV WORKING GROUP
Meeting Minutes
IETF-50, Minneapolis, MN
March 22, 2001
The WebDAV WG met on Thursday, March 22, 2001, from 0900-1130, with
approximately 25 people in attendance. The meeting was chaired by Jim
Whitehead, and meeting notes were recorded by John Stracke. Final minutes
were prepared by Jim Whitehead. Note that throughout the meeting, brief
notes and observations on the sense of the room on various issues were
recorded in a slide presentation that was on-screen during the entire
meeting. The final state of these slides can be found at URL:
http://www.ics.uci.edu/pub/ietf/webdav/minneapolis01/meeting.htm
The meeting began with a brief discussion of the agenda:
* Open issues in the ACL specification
* Reviving DASL
* Improved status reporting
* Moving 2518 to Draft status
o Process for moving forward
o Discussion of issues list items
ACL Spec open issues
Does a null resource have an ACL?
Geoff Clemm: does this mean null or lock-null (two separate questions). He
pointed out that, if null resources exist and can be PROPFOUND, then Depth:
infinity becomes ridiculous. He also believes that, for lock-null, it's
cheap to add ACLs, but not necessarily useful. John Stracke pointed out
that it would be nice to be able to take out a lock, set the ACL for
non-world-readable, then create, so that there's no window where the
resource may be world-writable. Geoff noted that her concerned about the
complexity tradeoff. John pointed out that, in his scenario, one could
lock, create with an empty body, set ACL, then write the real content. At
this point, Geoff, Jim Whitehead, and Eric Sedlar started talking about
eliminating lock-null resources altogether at Draft Standard; nobody
objects.
The consensus of the room was that lock-null resources do not have an ACL.
Can an ldap: scheme URL be used for principal identifiers?
In past revisions of the ACL specification, principal identifiers have
always been http: scheme URLs; in San Diego, it was suggested that ldap:
scheme URLs could make sense, since they refer to people. Jim Whitehead
stated that this is a tradeoff between functionality on client and on
server; the current system requires the DAV server to sync with LDAP server
(if using LDAP), while the ldap: scheme URLs require the client to access
the LDAP server directly. A compromise suggested on the list was to define
the ldap-URL property, which points to the principal's LDAP entry.
Larry Masinter asked: are we permitting https:? Why are we using URLs, but
not permitting all schemes?
Lisa Dusseault: if we don't support ldap: at all, are we going to need to
duplicate LDAP functionality in DAV?
Geoff: by having the DAV server do the mapping, we're exposing what we need
(not much) without requiring the client to know LDAP.
Lisa: "what we need" will probably grow, so we should support ldap-URL, to
make sure we have an escape hatch.
Larry: what are these URLs actually used for?
Eric: accessing data about principals via PROPFIND; e.g., making a picklist
for composing an ACL.
Larry: OK, and you can't do PROPFIND on an ldap: URL, so clients would have
to support LDAP.
Geoff: all we want from the principal is grouping, display name, and
username (for, e.g., Digest-Auth).
John: can we require the DAV server to proxy for the ldap: URLs?
Geoff: but then we get about the same functionality as the ldap-URL
property.
Eric: we should get some implementation experience first; nobody's done
this yet.
Larry: maybe implementations should make it a config option? Different
people will care differently about LDAP integration.
Geoff: the person who proposed the ldap: property has agreed that the
ldap-URL property would meet his needs.
Larry: This sounds odd -- what about other URL schemes with similar uses?
Eric: I don't really see other such schemes being commonly used; there's no
good way to map between them.
Babu S*: two issues; one is permitting LDAP integration, and the other is
permitting everything-under-the-sun integration.
Jim Whitehead stated that he doesn't like the property idea; permitting
ldap: URLs would be good enough.
John: but what about LDAP schemas?
Larry: so require that the schema contain certain properties.
John: but, if we want to integrate with existing directories, that won't
work.
Warren: tarpit. [missed some bits]
Geoff: ldap: URLs have interop problems (require clients to implement too
much); the ldap-URL property lets clients get at LDAP data, but does not
require them to do so.
JimW: so that would let the DAV server be a gateway for just the DAV
properties, but not block the other information. How about alt-URL, with an
alternate URL, which may be ldap:?
Geoff: OK; but how about a list?
Eric: does 2518 permit non-http: URLs?
Geoff: yes, but we should strike that.
Eric: Why do we want to limit it like that?
Geoff: for interop; we put constraints on the protocol to improve interop
by keeping it simpler.
Eric: but the client treats the principal URL as non-dereferenceable; why
does it care what the scheme is?
Warren: what are we trying to answer here?
JimW put up two questions: "should the URIs identifying principals be
limited to just http(s)?" and "should principal resources have an optional
property 'alternateURL' that can point off to, e.g., an LDAP accessible
network resource?".
Larry: wait a minute; 2518 says that the principal must be an HTTP
resource. So, OK, the "any scheme" bit is a hole.
Geoff: server-side, non-HTTP resources is more expensive.
Eric: client-side, exposing it as an HTTP resource is supposed to make it
easier for the client; but it doesn't, because it requires the client to
use the DAV server as an LDAP gateway.
Geoff: if we support non-HTTP, then the client may well not be able to get
those principals' data.
Eric: but the server isn't required to make the principal resources respond
to PROPFIND at all.
Geoff: but, if it does expose the data, it's supposed to do it via
PROPFIND.
JimW: The worst-case with HTTP-only is not worse than the worst-case
without; but the best-case with is significantly better than best-case
without. [dropped some bits]
Eric: we should note this as an open issue.
Geoff: at a minimum, we need to fix the inconsistency in 2518 ("it's an
HTTP resource" and "it may be any scheme").
JimW next tries to get a sense of the room on these two questions. Larry
says the first one strongly depends on context, on how the spec gets
written. JimW rewrites the question for clarity: "What URI schemes should
be allowed for identifying principals?" Options listed:
* http(s) only, or a URL that identifies a WebDAV principal resource
* limited set (http(s), ldap(s))
* http(s) and others explicitly defined by additional specs (the first
option was eventually merged into this one, since additional specs can
always be written)
* anything
Chris Kaler: how about making it an opaque URL, and publishing
Informational RFCs for how to work with different schemes?
John: but we should really have some minimal set, that clients can use.
Lisa: There must be some base level of capability that clients can rely on,
without having to implement various approaches for various servers.
Eric: how about this: use anything, but servers SHOULD use http(s), which
is a privileged scheme that points to resources that SHOULD have additional
properties (JimW added this to the list of options for the current
question).
Eric states that he does not want to make the DAV server replicate data
from the LDAP server.
John: but, if you're using LDAP for authentication, then you're doing that
to some extent anyway.
Larry: what if you're using mailto: for principal URLs?
Eric: why would you do that?
Lisa: mailto: URLs are commonly used for Web services, so that you have a
single, verifiable, user ID across services.
Chris: what about privacy issues of exposing the user's real name?
Geoff: well, but you can use access control (or just not expose the data).
Eric: if you don't have the properties, then there's not much point in
making it an http: URL.
Geoff: agreed, so the second SHOULD is OK.
Larry: so what are these properties used for, anyway? Geoff: well, they're
used for display in the GUI; they might be useful.
Larry: what about auth ID, though? How is it tied to auth schemes?
Nobody can really remember a good reason to have it.
JimW: OK, so it seems like we have provisional sentiment to strike it.
Eric: but what harm does it do? Nice for something like Unix's ls -l.
Geoff: it's a potential security weakness (makes it easier to mount a
dictionary attack), recorded as such in our security considerations;
removing it would solve that.
John: maybe we did want it for something like ls -l, where the username is
the only way to find a user in the directory; if we have the alternateURL
property, then we've got that.
Geoff and JimW: agree.
Larry: doesn't want to reach conclusion yet; we should go back and look at
how clients actually use this stuff.
JimW recording: provisionally (subject to the consensus of the list), we
can eliminate the authentication-id property. The alternateURL property can
cover many of the use cases envisioned for authentication-id, and is safer.
However, we should look for more use cases.
JimW recording: provisionally, the answer to the "what URL schemes are
permitted" is "use anything, but servers SHOULD use http(s), which is a
privileged scheme that points to resources that SHOULD have additional
properties".
JimW recording: sense of the room: we should have an alternateURL property.
Babu: we seem to be using the terms interoperability and dependencies, and
they're probably interchangeable (inversely).
Larry raised a general plea: he was sent with the mission to ask that
WebDAV and DeltaV and other specs do a better job than they do now of
dealing with interactions and failure cases. There are too many cases where
there are options whose purposes aren't well specified, and people who
guess differently run into trouble. The alternateURL property is an
example; what alternate information does it point to? Eric replied that we
could put in better use cases; some were removed to keep the text pure, but
the result is less clarity. Maybe there should be a companion document
describing these use cases. Geoff added that there were problems with use
cases in 2518, with people reading use-case text as normative. Putting it
in a clearly non-normative companion document would help with this problem.
Larry stated that explanatory text is not as good as making the normative
text more precise, and Geoff agreed.
JimW recorded the need to provide information in the specification on how a
client might use the alternateURL, and what kind of schemes might be used.
MAY/SHOULD/MUST ACL properties be returned by an allprop PROPIND? (None,
some, all?)
The view on list is that PROPFIND allprop MUST NOT return any ACL
properties, since PROPFIND allprop is already too expensive, since the
server has to compute all the live properties, and "current user privs" is
very expensive to compute. No one in the room disagreed.
Chris asked, how about striking allprop altogether? Lisa replied that it is
too late, since there is at least one client that depends on it. Eric noted
that it is useful for copying resources from server to server. Geoff
replied that a client can use propname to list all the names, then retrieve
all properties explicitly by name. JimW noted that it might be possible to
deprecate it in going to Draft Standard, then strike it when going from
Draft Standard to Standard; but we need to look into it better. Didn't
someone on the list give a rousing defense of allprop? Geoff replied, yes,
but it was because he used it, not because it was the only way; a slow
transition wouldn't be so hard on him. At a minimum, we can make sure that
new specifications state that their new live properties do not come back
from allprop. Larry warned the group to be wary about transitions. Geoff
added that, maybe, when deprecated, it can go down to "all dead
properties". There was some discussion on performance reasons not to have
PROPFIND return live properties. Larry notes that the performance hit only
occurs when PROPFIND allprop is used, and, if it's used, it's because
people want the functionality, and workarounds may be less efficient. Room
seems tentatively pleased with limiting PROPFIND allprop to return only
dead properties.
What is the purpose of the DAV:isprincipal property?
This issue was raised by Larry Masinter. JimW noted that this is a
workaround for the preferred way of expressing this information, which is
in the DAV:resourcetype property. However, one early implementation (MS
WebFolders) considers anything with a non-empty resourcetype to be a
collection, and displays them as collections in the Web Folders UI. Geoff
Clemm noted that a principal collection (a group?) is both a collection and
a principal. Larry then noted that WebFolders won't display the correct
icon anyway, since at present it will make a principal look like a
document. Geoff replied that if a principal looks like a folder in the UI
users will think they can add members to it. There was a brief discussion
over what a GET to a principal URL returns; conclusion seems to be that we
don't have any particular reason to define it. There was agreement to
explicitly note in the ACL specification that GET on a principal resource
is intentionally undefined.
Eric: since we have different types that can be mixed together (e.g.,
collection, principal, versioned), maybe we should be using properties like
DAV:isprincipal. These types aren't unitary types; they're interfaces
implemented by the resources. Discussion on which way is best. Larry stated
that it's a moral argument; either punish the bad implementation or write
the specification around it. Geoff noted that what they did wasn't so
terrible, after all. JimW recorded the (weak) sense of the room to leave
the DAV:isprincipal property in place.
Reviving DASL
There was a brief discussion on reviving the DAV Searching and Locating
(DASL) protocol specification, which currently is in Internet-Draft form,
and is not currently being worked on.
JimW asked:
* Who is interested in seeing it completed? Couple of people raised
hands.
* When should it be completed?
Larry noted that the people who want it are some of the same people
who are working on ACLs and improved status reporting; let's not delay
those. Eric added that there might be synergy with XML Query (XML
Query does searching; DASL would limit it to particular directories,
for example), so we should at least let XML Query people know DASL is
coming. Lisa stated that XML Query isn't so great for searching
properties (as DASL was focused on). Xythos has implemented it; what
were the problems that held back the spec? JimW said that the biggest
one was I18N (e.g., sorting, string matching); somebody needs to look
at it in that light. Might be able to refer to Unicode docs. Larry
suggested that one path forward is to publish the existing DASL
protocol specification as Experimental (with the added note that
Xythos has implemented), so that people can try it; when we get time
to work on it, then there'll be more experience with it. The sense of
the room agreed that this was a good approach.
* Who is willing to work on it? This question was not asked after all.
Moving 2518 to Draft status
Four-part process:
* Resolve issue list items on mailing list
o Goal: handle 2/week
o Document solutions with pros/cons
* Hold face-to-face interoperability b*ke-off
o Flush out new issues
o Develop test plan doc on mailing list
o Aim for late May/early June.
* Develop an online form to gather initial implementation and testing
data
o Used successfully for HTTP/1.1
o Can be done before the b*ke-off
* Create a farm of significant server implementations for ongoing
interop testing
o JimW can host and administer machines at UC Santa Cruz, but
cannot afford the machines/software. (Easier to put machines on
open Internet at university than in most companies.) Probably not
beta software, though.
o Donations needed.
Warren asked whether it would it be useful for potential customers to get
the results of this testing? Larry noted that there are two types of
interop events. The first kind is closed, usually with prerelease products,
to get the products enhanced to be interoperable; the second is
interoperability demos at trade shows, once the vendors know the results
are good. We need the first before we can do the second. Survey of the
room: 4-5 people interested in attending the b*ke-off.
Advanced Status Reporting (ASR)
Lisa Dusseault next led a discussion on advanced status reporting within
WebDAV. Lisa asked who has read the advanced status reporting I-D? No hand
raised. Lisa then stated, "Don't worry about it; it hasn't changed
significantly from the proposal, which people liked." Larry noted (looking
at the draft on his laptop) that the Accept-Error: header looks like a
general HTTP extension, and Lisa agreed. Larry then stated that
"Accept-Error: text/xml" isn't actually generic XML; it implies this
specification's XML DTD. Maybe it should be text/xml-rfcXXXX, or some such,
so that some future Even More Advanced Status Reporting can define its own
format. Lisa replied that, really, the spec is open, it just has to have a
particular root element. Geoff added that it would be pretty nasty to wind
up creating a new namespace of error type specs. Eric suggested that we
define an XML namespace URI for this version.
JimW: why not just always send the ASR?
John: but then the existing clients don't have HTML to show to the user.
JimW: how about putting it in a header?
Lisa: not enough information.
JimW: what is the goal? Improve the message to the user, or enable better
machine-comprehensible error handling? He says it's more for the user;
e.g., 423 Locked can give more information on what was locked and how.
Geoff: machine-comprehensible error handling does improve the message to
the user.
Lisa: the server could already send a more detailed HTML message to the
user; structuring it makes it possible for the UI to assist the user in
dealing with the error.
Larry: how about embedding XML in HTML?
Lisa: lots of people said that was too messy.
Larry: how about multipart/alternative?
Lisa: was considered, but bandwidth costs.
Larry: servers also have to worry about CPU cost of computing the response.
Lisa: but servers aren't likely to implement ASR at all unless they know
the clients are asking for it. More discussion.
JimW: Accept-Error: means bandwidth costs, too, on every request.
Larry: investigate: can browsers accept multipart/alternative anyway?
JimW: maybe we should narrow this down; add it to base WebDAV (for better
interoperability), but not expose it for general HTTP. Or even just improve
the specification of error cases, not necessarily bundle up all the data
into XML.
*** Meeting adjourned ***
Received on Monday, 9 April 2001 21:17:12 UTC