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)
| 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. |