Issues in DASL

Jim Davis

2 June 1999, updated 20 April 2000

Issues whose numbers begin with JW refer to the items in the mail from Jim Whitehead on April 26, 1999. Please refer to that message for details.  Note that the items are not numbered in the mail message, you'll just have to count them for yourself.  Sorry.

Issues numbered DB refer to items in the mail summarizing discussion at the DASL Breakout session at the 46th IETF (Nov. 9, 1999)
 
DASL issues
number summary status
JW1a reference RFC 2376 done
JW1b accept application/xml also done (see 2.2.2)
JW2a Define how arbiter resource responds to all HTTP and WebDAV methods A search arbiter is any resource that supports SEARCH. A search arbiter is not a new resource type. In general, if a resource is a search arbiter, no conclusions can be made concerning what other methods it supports.
JW2b Define the DAV:searcharbiter resource type (property value) Dropped. A search arbiter is not a type of resource.
JW3 Define how a search arbiter responds to searches
JW4 Don't use 507 for Insufficient Storage. Use a new code, perhaps 208 (Partial Results)
JW5 No way to return next set of partial results
JW6 SEARCH should return 102 (Processing) if operation will take a long time Dropped by consent of submitter
JW7 Can a SEARCH return 301/302? If so, then why need arbiter redirection Good point. Redirection gone (17 April 2000)
JW8 Is the response from SEARCH cacheable? No.
JW9 How can a client discover an arbiter?
JW10 (editorial) need example of use of query schma discovery Moot. No QSD in newest draft
JW11 Why does search support only a single scope? This issue refers to BASICSEARCH only (5.4.2) not DASL in general. The authors acknowledge that multiples scopes would be desirable, but also recognize that in the general case, supporting more than one scope requires the arbitery to do query merging is the two scopes have different schema. This is difficult, so we think it better to keep BASICSEARCH, well, basic
JW12 Allowing relative URIs isn't very useful Accepted 24 April 2000.
JW13 (editorial) need separate section for description of ascending and descending
JW14a how does xml:space affaect DAV:literal
JW14b The semantics of DAV:literal should not change inside a DAV:like
JW15 Wildcard BNF admits </d:literal>
JW16a (editorial) Provide textual descriptions for DAV:lt, DAV:lte, etc. Meanings may not be clear to non-native speakers of Fortran. Done.
JW16b Define how comparisons on strings work, esp for i18n
JW17 5.13 should discuss handling of queries when character set differs
JW18 5.16 should provide guidance on how case sensitivity handled in non-latin sets
JW19 In 5.18, provide rationale for DAV:iscollection done
JW20 (edit) 5.19.2 (propdesc) hard to follow Moot. QSD removed from protocol.
JW21 URN in 5.19.3 is too long Mooot. QSD removed from protocol. Also We didn't chose this URN, it's the one from XML Data
JW22 types in 5.19.3 underspecified Moot. QSD removed from protocol.
JW23 (edit) Add some examples taken from the scenarios document
JW24a Need policy statement about sort order in various national languages. (JW said "non-Latin" but it's an issue even in languages that use the latin char set.)
JW24b Some text on handling character sets would be helpful
JW24c How do string equality and language tag interact. Cross-language comparison should work at least when the two languages are dialects, e.g. en-us vs en-uk
JW24d Where does xml:lang go in a query?
JW25 In Security Considerations, copy XML considerations from webDAV spec Wouldn't it be better to just cite the XML document, so that if that document is updated, we won't have stale information?
JW26 In Security Considerations, mention privacy risks of queries. Okay
DB1: What to return if there are no matches empty multistatus
DB2: Dates (HTTPDate in getlastmodified). Agreement that it is OK to submit isodate to search HTTPDate (i.e., it's a marshalling issue only)
DB3: What should the default Depth value be for SEARCH? Agreement that Depth must be sent with SEARCH.
DB4: When results are truncated, server replies with a 507 and also returns an XML element. Agreement that the XML element is redundant and can be removed.
DB5: 507 is currently in conflict with other specs. Need to avoid collisions.
DB6: d:like does not allow for case insensitivity. Why? Agreement: don't change.
DB7: Searches on XML chunks that include namespaces. Need to expand out the XML namespace when doing the search (i.e., do search on DAV:foo, not X:foo xmlns:X="DAV:") Also an issue for expressing searches on XML sub-elements of properties.
DB8: Booleans appear to be underspecified in the specification. How is a boolean tested, and what are the behavior of operators like less than, greater than, etc.