- From: Lisa Dusseault <lisa@xythos.com>
- Date: Sun, 15 Sep 2002 12:09:37 -0700
- To: "Webdav WG" <w3c-dist-auth@w3c.org>
Interim WebDAV Meeting 2002-09-09 Session Held at the University of California at Santa Cruz during the September 2000 interoperability-confirmation tests Last Updated 2002-09-10-13:05 -0700 (pdt) _____ Attendance <file:///A:\2002-09-09-WebDAV.htm#AttendancePreliminaries#AttendancePrel iminaries> and Preliminaries Action <file:///A:\2002-09-09-WebDAV.htm#ActionItems#ActionItems> Items 1. Agenda <file:///A:\2002-09-09-WebDAV.htm#Agenda#Agenda> 2. ACL <file:///A:\2002-09-09-WebDAV.htm#ACLSpecificationStatus#ACLSpecificatio nStatus> Status 3. DASL <file:///A:\2002-09-09-WebDAV.htm#DASLSpecificationStatus#DASLSpecificat ionStatus> Status 4. Property <file:///A:\2002-09-09-WebDAV.htm#PropertyRegistration#PropertyRegistrat ion> Registration 5. RFC 2518 bis <file:///A:\2002-09-09-WebDAV.htm#2518bis#2518bis> Issues _____ Attendance and Preliminaries Attendees: * Lisa Dusseault, co-chair * Jim Whitehead, co-chair [enter names from list circulated in the meeting] We met upstairs from the Interop event, starting shortly after 3pm. Dennis Hamilton agreed to take notes for this session. Dan Brotsky requested that the group acknowledge the contribution that Jason Crawford has made in managing the issues list. There was nodded ascent. At the end, based on the amount of discussion and speed on the agenda, it was agreed to change the September 10 session from 3-6pm to 1pm - 6pm. The session ended promptly at 6pm. Action Items [who?] Communicate the working group's appreciation to Jason Crawford. Dennis Hamilton: turn over notes from this session before he leaves on 09-10. Lisa Dusseault: * Provide links to her latest drafts of 2518bis for people to be able to review. [done by e-mail to the list, 09-10] * Circulate paragraph on what behavior for PropFind for members of a collection MUST be implemented. Jim Whitehead: Contact Ned Freed about the workings of registration procedures via IETF/IANA (re feasibility for use in Property <file:///A:\2002-09-09-WebDAV.htm#PropertyRegistration#PropertyRegistrat ion> Registration) Dan Brotsky: Send out a note on clarifying lock <file:///A:\2002-09-09-WebDAV.htm#LockDiscovery#LockDiscovery> discovery and that this not be defeated by servers refusing to disclose the necessary information for lock discovery to be meaningful. Ilya : Write the paragraph on forcing <file:///A:\2002-09-09-WebDAV.htm#ForcingAuthentication#ForcingAuthentic ation> authentication that will go to the list and into RFC 1518 bis. 1. Agenda In creating the agenda, Lisa remarks that the working group needs to review its charter. We agreed to carry this to the September 10 session. Also there is a topic on Interoperability Process and what does 2 by 2 interoperability mean? This was added in under the RFC 2518 bis <file:///A:\2002-09-09-WebDAV.htm#2518bis#2518bis> discussion. 1. Kudos for Jason <file:///A:\2002-09-09-WebDAV.htm#ActionItems#ActionItems> - 2. Status of the ACL <file:///A:\2002-09-09-WebDAV.htm#ACLSpecificationStatus#ACLSpecificatio nStatus> Specification and of DASL <file:///A:\2002-09-09-WebDAV.htm#DASLSpecificationStatus#DASLSpecificat ionStatus> (Search) 3. Property Registration (15 minutes) 4. RFC 2518 bis <file:///A:\2002-09-09-WebDAV.htm#2518bis#2518bis> issues o Start with the ones on the board in the interoperability work o Litmus tests o Continue with others 2. ACL Status The ACL Status was summarized by Jim and Lisa: 1. The specification is in the hands of the Area Director for review. 2. The review process is slow and WebDAV is in spin-wait until it is sent back for changes or posted as approved. 3. All known issues have been resolved in the document that is under review. 3. DASL Status The DASL history was reviewed. The DASL working group had been disbanded after going inactive. Since then, Julian Reschke has been maintaining the specification and posts versions as Internet Drafts, providing an informal process on the side of WebDAV. In the discussion: 1. Lisa mentions that there are open problems around character sets and languages that DASL will also bump into. She provided a little background on how difficult it is to make a successful specification anywhere that there are character strings intended for human interpretation. Sorting is also a big concern, because collating sequences have such variability at the international level. 2. The topic of how to advance more rapidly was raised, but no suggestions came forth, beyond to continue encouraging Julian and promote people working on it. 4. Property Registration Jim Whitehead provided an overview of the situation, raised by * So many properties being defined in 2518, and the allied specifications, etc. * People wanting to have a way to add properties and have them be standardized in some sense Dennis provided some background on how this became a project on AIIM (that he has been sandbagging for well over a year now). The purpose is provided on DMware site project description (http://DMware.info/projects/P010100.htm). Dennis summarized the levels that seem to be of concern, and he came to ask which level do people see as appropriate, and if that is the answer, what is the problem that is being solved: * That a property identification is taken and has been used * That a property identification has been taken and the authority on the property is so-and-so. * That a property identification has been taken by so-and-so and here is how to find a description of the property intended for human comprehension * That a property identification ... and here's a description intended for computer processing Dennis assumes that the last bullet is over the edge for the WebDAV community, although it matters for managed documents when we look at metadata discovery requirements and even model discovery requirements (e.g., finding the rules for playing nice in manipulation of coordinated WebDAV resources). Dennis has been operating on the assumption that there is room enough in WebDAV for there to be private or specific-community (i.e., vertical) agreements on properties (just like there are so many flavors of XML agreements). But there is also a sense that some fundamental registration approach be agreed in the overall community. Jim Whitehead described his initial assumption that something like IANA MIME-type registration could work for WebDAV properties. Dennis said that the requirement to put MIME-type specifications through the Informational RFC process seemed particularly heavyweight and he thought the community would want something easier to use. In the discussion, it was suggested that once an overall procedure is established, making additional submissions could be as simple as filling out a form and then going through a registration process that gave rise to an Informational RFC by a very simple process, along with appearance on an IANA registry. One benefit of using an IETF/IANA scheme is the persistence of the IETF repository of rfcs, and its likely long-term stability in contrast with anything that is maintained separately or by a small group. There was inconclusive discussion on how to follow up with IETF/IANA on this. Dennis said he had enough to put something on the list and widen the discussion. Jim Whitehead is going to do check with Ned Freed on the IETF/IANA protocol for having their agreement to register property registrations. It is also felt that the registry is needed for even the DAV: properties, because there are so many and their status needs to be maintained over time. The registry mechanism is not exclusively for the DAV: properties, but it is important to handle them. The following explosion of topics was identified. It became clear in the discussion that creating a registration procedure and (especially) agreeing on what to register about a property will push back on places where the property model is not adequately or clearly specified. 1. Registry for the DAV namespace and the rules for what are these, which ones are being deprecated, and what to do with them. The registry is something that can be used to normalize the DAV namespace. 2. What to do about provisional, anticipatory, and experimental ones that don't end up in a final specification. 3. Discussion of grandfathering and/or deprecating the stray DAV: properties that aren't in the specification, or put (some) in the specification 4. Discussion about DAV: as a reserved namespace and the business of the URI of the namespace, DAV: as a URI prefix, etc. 5. Say what are the rules for the DAV namespace. 6. Dan Brotsky: The model for properties is not circumscribed enough, but people want to know what the rules are -- o when can I be sure that a property will be dead, o how I can find out if values have changed, and o can the server enumerate this or that about the properties. o The property model may not be tight enough. There is also the problem of the syntax of the values. 7. Jim Whitehead thinks that property access (read) interoperability can come with some ease and property creation/setting interoperability might take more. We might want to take the easy case first. 8. Jim Whitehead knows Ned Freed and this game would then work. Then for us the question is what does the form look like and what kind of things might not be OK to handle this way. Needs to be discussed on the mailing list. 9. What are the reasonable questions to answer on a property registration questionnaire: o Protected versus writable o Name and namespace * XML 1.1 recommendations on element and attribute names. Any XML language rules work o Static or dynamic o Live or dead * Great discussion about the distinctions live and dead, etc., and what is going on here. o authority defining the property o syntax of values o under what conditions will the property change o configuration versus not o syntax enforced versus not o is it searchable? o responds to PROPFIND ALL? o cacheable? o dependencies among properties o notes - things not covered in other questions o resource type that property defined on * collection only? o conditions under which property can be written o terms and conditions of use, legal conditions o questions about permanence of properties and invariance, invariance of the definition - we must take a stand on this one way or the other. o inheritability -- it is a form of liveness o date of definition o software it appears in - who implements it o review authority and acceptance of the definition * DAV namespace properties * Use of namespace * Namespace registrations? 10. The work on this will drive tightening of the property model. 11. This list may not be complete, and what do we do? Do we understand enough to have a strawman list. 12. Dependent properties? 13. Semantics and syntax of the property We ended declaring that we had done enough (in much more than 15 minutes). 5. 2518 bis Issues 5.1 Meta-discussion We had a meta-discussion on the word "bis." Lisa had assumed the word is German. Dennis thought it was French (because the ISO uses it). We concluded that this usage is probably from Latin. [Checking a very laptop translator dictionary: In Italian it is an adjective for "second" and it is also used for "encore." In French it has that and the sense of "repeat" as well as being an adjective for a color (grayish-brown) and an adverb for "twice." In German it is the preposition for "until, by, through." --dh:] 5.1.1 Interoperability Process This conversation was in "bullets": * Need a quick breakage list * Availability of free software (regarding testing and confirmation) * More clients in test * Always-online clients * Litmus and Litmus-like test suites available as clients * Ways for servers to request tests from a client. 5.1.2 Defining 2 by 2 interoperability Question on what the IETF community definition is for this. More bullets: * WebDAV has done due diligence in that regard * As much as has been done, the interoperability story isn't that great o pairwise confirmation of features is not the same as pairwise confirmation of the feature set, and this leaves lots of disconnects * Let's not make more work with the IETF * But let's get to where it says WebDAV on the box means there are not any material problems that an user would have to deal with 5.2 "Board" Issues During the interoperability sessions on the first day, a number of topics for breakage came up. 5.2.1 Breakage Involving Presumably-Resolved Issues These are issues that are thought to have been resolved and disambiguated in the specification, yet implementations are still deviating. These are areas where more is required, either in being clear or in having more to a facility for it to work properly. 5.2.1.1 Having lock information be discoverable Clients need untampered ownership of a lock that the server does not monkey with it, and in bis, servers are not supposed to muck with the owner value, so what about servers being free to withhold elements of lock discovery? Either get all the information but be forbidden to discover the lock. Brotsky to send out a note on this one. 5.2.1.2 How can clients force authentication? The problem of not being made to authenticate until trying to write. This leaves users in the awkward position of doing lots of work and then, when it is time to put something, an unanticipated authentication requirement comes up. Question about how to force authentication at the beginning of a "session" so that user doesn't do a lot of work and then be confronted with an authentication requirement Lisa likes the idea of using the header and working there. Also, don't want to break the practice of forcing users to be authenticated from the get-go. Options that force authentication to write are desired. Methods have special fire-wall implications, and we got lost in hilarity about methods prefixed by X-. We fell back to Options. Brotsky offered the example of PROPPATCH of a read-only property, as a roundabout way to provoke authentication. We came back to Options. Prefer something like the connect specification. Want to ask Julian to write the rfc. Ilya will write the paragraph that goes to the list and into the spec. 5.2.1.3 Collections without the slash All places where a URL is returned, if it is for a collection, the specification says "should" provide the slash, not must. When you say PropFind, the returned URLs should always have a slash after the segment for a collection. This segued into the overall problem of PropFind responses for collections: 5.2.1.4 PropFind Responses for Collections Are relative URLs allowed in propfind responses? Jim W: So is this a spec language issue or is something needed in the protocol? Brotsky: Servers must not be confusing to clients and we need to see how to do that. We probably ought to do relatives more, it needs to be relative to the URI in the request: relative, absolute, or fully qualified (anything not fully qualified is considered a relative URI in the specification) -- we have to be really careful about the specification language Difficulties are with the client handling the different cases of what comes back. Brotsky says that servers must use proper internal URIs, and it is strictly defined, in terms of internal member URI. The question is can the top level URI be different than the one the client offered. Lots of discussion on prefixes of URIs, how to get around this. And whether servers are allowed to optimize the client's future behavior. Brotsky wants the server to be gentle with the client. In the case at hand, the client is asking "tell me what the internal members of this collection are." If the server can return whatever it wants, the client is under a terrible burden. Lisa has some language for a MUST to add to the specification based on presence of a content location header. In the absence of a content location header, there is discussion about not having the same level of MUST-ness for the request URL. Conversation about what a client is, and Brotsky says that HTTP says. Needs more discussion, and RFC 2518 may need to be more emphatic that it is relying on the HTTP 1.1 definition of client and have people be clear about the implications. 5.3 New Open Issues We didn't get that far. The September 10 meeting will begin at 1pm and continue to 6pm to ensure coverage of more issues.
Received on Sunday, 15 September 2002 15:10:19 UTC