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. 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: * 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. 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. 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 ***