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:
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.
Walter Houser: 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?
Walter: 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:
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.
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:
Four-part process:
Walter 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.
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 ***