- From: Elias Sinderson <elias@cse.ucsc.edu>
- Date: Sat, 25 Jan 2003 18:05:23 -0800
- To: w3c-dist-auth@w3c.org
The following notes were taken on the first day of the interim WebDAV working group meeting held 20 Jan, 2003. There are undoubtedly portions of the discussion that were not recorded, my apologies for the occasional ommision. If anyone recalls things that I have missed, please mention them. Elias _____________________________ Julian Reshke led the following discussion on datatypes for WebDAV properties The basic idea is that a PROPFIND would provide type information for dead and non-RFC2518 live properties. PROPATCH would similarly allow one to specify data types in conjunction with setting property values. The approach uses the W3C XML schema type library and instance type attribute to indicate types. This has the advantage of using a standard and extensible type library (also used in many other vocabularies). (Lisa Dusseault) It would be desirable to add information the the OPTIONS response to indicate whether the server supports this. Further, a PROPATCH response should indicate whether or not the type attribute was recognized by the server. Additional property information to be considered includes: * 'hidden' flag * 'protected' flag * 'display name' attribute Open issues to be resolved: * marshaling of display name * relationship to document types and schema definitions of required property sets Are we ready to think about schema definitions of property sets? of resources allowed in collections? There was a general acknowledgment that this would primarily affect DASL, but would likely have some impact on othe WebDAV specs as well. Two types of questions this proposal would address are "I want to create a resource, what properties do I need to set?" and "I have a resource, how do I treat the values of properties?" As an example of a possible approach to server implementation, it was noted that Sharepoint allows any resource to be put into a typed collection and then checks the type constraints when a CHECKIN is done. Another option would be to do type checking upon an UNLOCK... General discussion brought up the following concerns (paraphrased): Is the proposal sufficient fo DASL? How does this work with PROPFIND allprop? What are the driving requirements? Should this be a WG item then? (general approval) Should we then link its progress to the DASL spec? Should it also be connected with schema discovery? Another related topic is schema registration. General discussion on how best to proceed lead to a concensus on initially developing the high-level requirements, then move further discussion to a separate (new) mailing list. --- ACL discussion led by Lisa Dusseault and Eric Sedlar Lisa Dusseault presented feedback received from the IESG on ACL: * Basic authenticaiont over SSL/TLS is a MUST level requirement * Methods should be mapped to specific permissions (in a table) * Flexibility in te secification is a source of risk. Humans will err and poorly written clients will help them. Eric Sedlar then led further discussion on the spec. The semantics of ordering wrt granting/denying permissions needs to be worked out. Proposal to use the NFSv4 approach. Also need to specify how custom priveleges are expressed. The spec will be clearer and easier to implement correctly if the language is stronger - use MUST level requirements wherever possible. <I missed recording some of the discussion at this point> (Lisa Dusseault) Can we make it explicit in the spec that we are making no attempt to map ACL to *nix permissions. Also moved to drop the informational RFC from the WG milestones. (Jim Whitehead) Should we specify what is returned when tere is an ACL problem? We should constrain what is possible. (Lisa Dusseault) 404 MUST be returned if the client doesn't have read permission, and 401/403 otherwise. --- Dennis Hamilton led the following discussion on property registration. There is a recognized need to record authoratative info on properties and namespaces such as where to go (spec., company, etc.) for more detail. There is also a desire to reduce the complexity of the spec as much as possible. The focus of this effort is not machine-readable discovery of properties, but future work may address this. On namespace registration and authority: * Namespaces SHOULD be registered and * namespaces SHOULD be resolvable. * Just anyone should not be able to register a property within a given namespace. (Julian Reschke) This problem exists across all XML efforts... (Dennis Hamilton) We can likely refer to oter docs or source of information on this issue and make sensible recommendations where appropriate. (Jim Whitehead) Someone needs to make a list of questions that we want to know the answers to about WebDAV properties. Host this example documet on webav.org after its complete. --- DASL discussion led by Julian Reschke. Current issue list: * Error marshaling - proposal to align the sepc with RFC3253 * 'next n' results * type handling in query literals - proposal to add DAV:typed-literal operad carrying xsi:type attribute * language handling for queries on txt props - proposal not to do this * Collation sequence for text comparisons On 'next-n' results: (Julian Reschke) Previous discussion on list about persisting search results to a URL. (Jim Whitehead) How is this currently done with DBs? (Erc Sedlar) Depends on the DB, some save state, some redo te query and throw away the first n results. <some discussion on implementation> Summary: Next n results is something we want in the spec, no clear agreement on how best to implement it. There are issues related to authentication and caching search resiults to be explored as well. (EricSedlar) Caching is crucial in large repositories, just getting the first results back can be expensive. General agreement that servers should be allowed to generate static results at some URL, but should not be required to do so. (Lisa Dusseault) It is possible to use the range header for getting m-n results.. On type handling: QSD needs to handle DAV:typed-literal. (Jim Whitehead) Would making QSD a MUST help this issue? Concensus reached among those attending to add DAV:typed-literal and make QSD a MUST level requirement. On language handling: (Summary) If a user wants a language sensitive comparison, then they should specify that with a language operator. Spoec. should be silent on this when discussing other operators. Those in attendance agreed this is the case. On collation sequence: (Jim Whitehead) The Unicode documet that generaaly covers this issue is not complete. It may not be a valuable use of time to try and do better. (Eris Sedlar) Collation in DBs can be set with lang+territory but has impact on performance, and one may need multiple indices. (Lisa Dusseault) Java allows a collation to be specified, shouldn't be dificult to implement [in java]. (Julian Reschke) Intend to use language from XPath/XQery, allowing lang to be passed in and a URL to refer to collation info. Proposal to change nae of casesensitive comparison operator to caseinsensitive, which describes the behavior more accurately. No objections from those present. On dates: (Julian Reschke) Would support using only ISO dates in DASL spec. (Lisa Dusseault) RFC2518 only supported other format for compatibility with RFC2616. There was an extended discussion on typing of operands vs. typing of operators - further discussion pushed back to list as no concensus could be reached. We need a thorough comparison to make any decision. On error marshaling: General concensus to follow RFC3253 approach/definitions. Other items: (Jim Whitehead) What does lte mean? can we be more specific in te spec? Why is the use of "_ _" prohibited in a query? It shouldn't be a problem to implement. The like syntax should conform to SQL'92 definition. Discussion and agreement among those present that ordering on mixed-content is undefined. (Eric Sedlar) The contains operator should work on properties... it is the most frequently used search. (Julian Reschke) To support that we would need to relax wording in the definition of 'contains'. Maybe extending basicsearch is the correct way to accomplish this? Julian will be submitting another draft of the DASL spec.
Received on Saturday, 25 January 2003 21:01:29 UTC