Nabble - w3.org - www-webdav-dasl

Re: Charset mismatch

2009-10-30T08:32:27Z

On 10/30/09 8:03 AM, "Julian Reschke" <julian.reschke@...> wrote:

> Short answer: in practice, every body uses UTF-8. So fix the client. :-)

Thanks! Will do.

> PS: this doesn't appear to be a DASL question. The generic WebDAV
> mailing list (w3c-dist-auth@...) might be a better place to ask.

Sorry about that; I will use that list next time.

Charset mismatch

2009-10-29T08:27:46Z

Charset mismatch Set up:
- Apache2 running on Windows XP, with mod_dav installed
- Custom dav client

The client polls the server with HEAD for each element of this URL:
//dav_dir/business_unit/eastern/clients/Étude Studios

The encoding sends “Étude” as “%C9tude”. This is valid in Latin 1 through 9 (ISO-8859-1..9).

Apache responds with a 403. I expected 20x or 404.

Using a Windows dav client, which succeeds, the wireshark reports the encoding as “%C3%89”. I believe this is UTF-8.

In second test, we added Tomcat to the mix and the custom dav client worked just fine.

Does this sound familiar to anyone?

What are good approaches to resolving this mismatch?

TIA,

- Mark

Re: Setting PR_CONVERSATION_INDEX using WebDav

2009-04-15T01:00:14Z

Hi Nitin,

this is really the wrong mailing list -- it's about the WebDAV SEARCH
specification.

I guess what you need is a support forum for Microsoft Exchange.

BR, Julian

Setting PR_CONVERSATION_INDEX using WebDav

2009-04-14T21:18:37Z

Hi all,

I'm trying to do a seemingly simple task of setting the PR_CONVERSATION_INDEX (PidTagConversationIndex) on my item before I send my email out. However, due to my environment and other issues, this is becoming a pretty tough task. Our application is written in completely in Java and we use the Apache Jakarta Slide library to make WebDav requests and essentially, that's how we communicate with exchange. Now Jakarta Slide has a very restrictive method signature for the proppatch method such that it requires that the value of the MAPI property you're setting must be a string. This works OK for MAPI properties like PR_COVERSATION_TOPIC but for PR_CONVERSATION_INDEX this doesn't quite fly since that property is of type PT_BINARY. Can anyone help out and let me know of a way to tackle this issue?

One alternative that I was considering was to use Exchange Web Services (EWS). Does anyone know if the same end can be achieved by using EWS? And if so, how should I go about it?

All responses will be greatly appreciated.

Thanks,

Nitin

Re: somewhat off topic: managing Win32 limits in WebDAV

2008-12-15T08:52:31Z

On 12/11/08 1:18 AM, "Bjoern Hoehrmann" <derhoermi@...> wrote:

>
> * Julian Reschke wrote:
>> Mark Phillips wrote:
>>> I am dealing with a server side limitation. Our set up is Apache 2.2 on
>>> Windows XP Pro for the moment.
>>>
>>> In our tests, Apache reports a 403 error but that appears to be misleading.
>>> Further testing reveals a "magic" limit where URI's between 249 and 260
>>> characters in length fail on the MKCOL command.
>>
>> I guess it depends on what APR (Apache Portable Runtime) supports on
>> Windows. It's quite possible that it doesn't take advantage of the more
>> modern Windows APIs that do not suffer from these length restrictions.
>
> If APR is compiled with APR_HAS_UNICODE_FS it supports APR_PATH_MAX long
> paths on Windows, the latter being set to 8192 by default. Note that the
> individual components have file system specific limits, as I recall, and
> as http://en.wikipedia.org/wiki/NTFS seems to confirm, it's 255 for NTFS
> so you cannot have file names or directory names longer than that.

As a follow up, the issue appears to be addressed in Apache 2.2.6, in which
a modification to the apr library enforces the use of the unicode path
scheme. Refer to <http://marc.info/?l=apr-dev&m=120084184128491&w=2> for
more information.

Thank you for your comments; they definitely helped us get closer to a
resolution.

- Mark

Re: somewhat off topic: managing Win32 limits in WebDAV

2008-12-11T01:18:54Z

* Julian Reschke wrote:

>Mark Phillips wrote:
>> I need to join the other list.
>>
>> I am dealing with a server side limitation. Our set up is Apache 2.2 on
>> Windows XP Pro for the moment. We wrote our own client and the URL limit is
>> 10,000,000. Probably excessive but there you go.
>>
>> In our tests, Apache reports a 403 error but that appears to be misleading.
>> Further testing reveals a "magic" limit where URI's between 249 and 260
>> characters in length fail on the MKCOL command.
>>
>> So our supposition is the ever-popular MAX_PATH constraint. Of course, that
>> may not be the issue and we open to new info.
>> ...
>
>I guess it depends on what APR (Apache Portable Runtime) supports on
>Windows. It's quite possible that it doesn't take advantage of the more
>modern Windows APIs that do not suffer from these length restrictions.

If APR is compiled with APR_HAS_UNICODE_FS it supports APR_PATH_MAX long
paths on Windows, the latter being set to 8192 by default. Note that the
individual components have file system specific limits, as I recall, and
as http://en.wikipedia.org/wiki/NTFS seems to confirm, it's 255 for NTFS
so you cannot have file names or directory names longer than that. Other
systems http://en.wikipedia.org/wiki/Comparison_of_file_systems#Limits
tend to have similar limits, so I am not sure that is the problem here.
The httpd also has its own limits for e.g. request header line length.
--
Björn Höhrmann · mailto:bjoern@... · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Re: somewhat off topic: managing Win32 limits in WebDAV

2008-12-11T00:36:03Z

Mark Phillips wrote:

> I need to join the other list.
>
> I am dealing with a server side limitation. Our set up is Apache 2.2 on
> Windows XP Pro for the moment. We wrote our own client and the URL limit is
> 10,000,000. Probably excessive but there you go.
>
> In our tests, Apache reports a 403 error but that appears to be misleading.
> Further testing reveals a "magic" limit where URI's between 249 and 260
> characters in length fail on the MKCOL command.
>
> So our supposition is the ever-popular MAX_PATH constraint. Of course, that
> may not be the issue and we open to new info.
> ...

I guess it depends on what APR (Apache Portable Runtime) supports on
Windows. It's quite possible that it doesn't take advantage of the more
modern Windows APIs that do not suffer from these length restrictions.

BR, Julian

Re: somewhat off topic: managing Win32 limits in WebDAV

2008-12-10T13:04:47Z

I need to join the other list.

I am dealing with a server side limitation. Our set up is Apache 2.2 on
Windows XP Pro for the moment. We wrote our own client and the URL limit is
10,000,000. Probably excessive but there you go.

In our tests, Apache reports a 403 error but that appears to be misleading.
Further testing reveals a "magic" limit where URI's between 249 and 260
characters in length fail on the MKCOL command.

So our supposition is the ever-popular MAX_PATH constraint. Of course, that
may not be the issue and we open to new info.

thanks for the reply,

- Mark

On 12/10/08 9:33 AM, "Julian Reschke" <julian.reschke@...> wrote:

>
> Mark Phillips wrote:
>> I would be most grateful for information and/or links to articles that
>> describe how others have dealt with the 260 character path limit in
>> Windows. The product manager I work with feels we must support Windows
>> as a backend for the DAV enable product we are developing. Testing with
>> a few clients has exposed the Win32 limitation in a rather stark way.
>>
>> Thank you, in advance.
>>
>> Mark Phillips
>
> Hi Mark,
>
> it seems to be you selected a non-optimal list for this question :-) --
> w3c-dist-auth@... (the generic WebDAV mailing list) seems to be a
> better choice.
>
> That being said -- are you referring to a limit on the client or on the
> server?
>
> In general, Windows can deal with longer paths, you just need to use the
> correct API for that. If course, many Windows *applications*, such as
> Explorer, don't.
>
> BR, Julian
>
>

Re: somewhat off topic: managing Win32 limits in WebDAV

2008-12-10T09:33:01Z

Mark Phillips wrote:
> I would be most grateful for information and/or links to articles that
> describe how others have dealt with the 260 character path limit in
> Windows. The product manager I work with feels we must support Windows
> as a backend for the DAV enable product we are developing. Testing with
> a few clients has exposed the Win32 limitation in a rather stark way.
>
> Thank you, in advance.
>
> Mark Phillips

Hi Mark,

it seems to be you selected a non-optimal list for this question :-) --
w3c-dist-auth@... (the generic WebDAV mailing list) seems to be a
better choice.

That being said -- are you referring to a limit on the client or on the
server?

In general, Windows can deal with longer paths, you just need to use the
correct API for that. If course, many Windows *applications*, such as
Explorer, don't.

BR, Julian

somewhat off topic: managing Win32 limits in WebDAV

2008-12-10T09:22:05Z

somewhat off topic: managing Win32 limits in WebDAV I would be most grateful for information and/or links to articles that describe how others have dealt with the 260 character path limit in Windows. The product manager I work with feels we must support Windows as a backend for the DAV enable product we are developing. Testing with a few clients has exposed the Win32 limitation in a rather stark way.

Thank you, in advance.

Mark Phillips

WebDAV SEARCH published as RFC 5323

2008-11-17T14:53:50Z

Hi,

WebDAV SEARCH has finally been published as RFC 5323 (a Proposed Standard).

ASCII versions can be found in the usual places, HTML and XML versions can be found at http://greenbytes.de/tech/webdav/#rfc5323.

Best regards, Julian
--
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

Last minute changes to WebDAV SEARCH, was: WebDAV SEARCH approved as Proposed Standard

2008-11-09T07:51:14Z

Hi,

I've been working with the RFC Editor on the publication of this
specification, and some disagreements surfaced with respect how to cite
historic Internet Drafts, and what type of URLs are (or should be)
acceptable in an RFC. People interested in the discussion itself may
want to read the archives of the rfc-interest mailing list (starting
with
<http://mailman.rfc-editor.org/pipermail/rfc-interest/2008-October/000888.html>).

To get the issue resolved, I have moved the historic references to the
Contributors section, and changed the document URLs to use purl.org as
indirection mechanism (the RFC Editor was concerned with the stability
of URLs on www.webdav.org...).

So Section 1.1 now starts with:

1.1. DASL

This document defines Web Distributed Authoring and Versioning
(WebDAV) SEARCH, an application of HTTP/1.1 forming a lightweight
search protocol to transport queries and result sets that allows
clients to make use of server-side search facilities. It is based on
earlier work done in the IETF DASL Working Group (see Section 10).
In this specification, the terms "WebDAV SEARCH" and "DASL" are used
interchangeably. --
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html#rfc.section.1.1>,

and the Contributors Section now reads:

10. Contributors

This document is based on prior work on the DASL protocol done by the
WebDAV DASL working group until the year 2000 -- namely by Alan
Babich, Jim Davis, Rick Henderson, Dale Lowry, Saveen Reddy, Surendra
Reddy, and Judith Slein (see <http://www.webdav.org/dasl/> for the
working group's web site,
<http://purl.org/NET/webdav/dasl-references/reqs> for a requirements
document, and
<http://purl.org/NET/webdav/dasl-references/dasl-protocol-00> for an
early version of the specification). --
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html#rfc.section.10>

If somebody feels this change is not ok, or need to get re-reviewed by
the community, please speak up soon.

Best regards, Julian

Julian Reschke wrote:

>
> (FYI)
>
> The IESG wrote:
>> The IESG has approved the following document:
>>
>> - 'Web Distributed Authoring and Versioning (WebDAV) SEARCH '
>> <draft-reschke-webdav-search-18.txt> as a Proposed Standard
>>
>> This document has been reviewed in the IETF but is not the product of an
>> IETF Working Group.
>> The IESG contact person is Chris Newman.
>>
>> A URL of this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-reschke-webdav-search-18.txt
>> ...

WebDAV SEARCH: Implementation in file-sharing tool p300

2008-10-03T08:07:50Z

Hello,

WebDAV SEARCH [1] is a good standard to implement all kinds of search
activities on remote servers, based on the WebDAV standards.

p300 [2] is a file-sharing tool for private networks and VPNs, created
by Markus Götz, implemented by Markus and me. It's written in Java.
Its features include:
- Multiplatform
- HTML GUI, Swing GUI, WebDAV access
- Auto discovery of hosts
- Chat
- Download manager
- and more

In its latest release, version 876, released today [3], it implements
parts of the WebDAV SEARCH standard to facilitate file searches on peer
machines. The usage of Your standard makes it possible to use the search
functionality from clients different to p300, although this possibility
has not been utilized yet.

We thought You might be interested in hearing of this new implementation
of the WebDAV SEARCH standard. If You have the possibility, please try
out p300 yourself, it's Free Software.

If there are any comments or questions concerning our implementation or
p300 in general, don't hesitate to contact us. Note that we are not
subscribed to the www-webdav-dasl list.

Thank You for Your time.

Greetings,
Sebastian Breier.

[1]
http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html
[2] http://p300.eu/
[3]
http://blog.guruz.de/2008/10/03/version-876-of-p300-has-been-released/

signature.asc (844 bytes) Download Attachment

WebDAV SEARCH approved as Proposed Standard, was: Protocol Action: 'Web Distributed Authoring and Versioning (WebDAV) SEARCH' to Proposed Standard

2008-09-24T07:51:34Z

(FYI)

The IESG wrote:

> The IESG has approved the following document:
>
> - 'Web Distributed Authoring and Versioning (WebDAV) SEARCH '
> <draft-reschke-webdav-search-18.txt> as a Proposed Standard
>
> This document has been reviewed in the IETF but is not the product of an
> IETF Working Group.
>
> The IESG contact person is Chris Newman.
>
> A URL of this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-reschke-webdav-search-18.txt
>
> Technical Summary
>
> This document specifies a set of methods, headers and properties
> composing WebDAV SEARCH, an application of the HTTP/1.1 protocol
> to efficiently search for DAV resources based upon a set of
> client-supplied criteria.
>
> Working Group Summary
>
> This was the product of an individual submittor. However, it is
> based on a draft developed by the concluded DASL WG and technical
> discussions have occured on the DASL mailing list. Some issues that
> were discussed as candidates for the base specification are covered
> in Appendix B and are believed suitable for future protocol
> extensions. There was some discussion of whether query schema
> discovery should be mandatory or optional, there is believed to be
> community rough consensus to keep it an optional feature.
>
> Document Quality
>
> The framework defined in SEARCH (method, grammar discover via
> OPTIONS, response format) is supported at least in six
> implementations of which four support the DAV:basicsearch grammar and
> the other two expose only custom grammars. There has been at least
> one proposal for an additional documented query language
> (draft-godoy-webdav-xmlsearch).
>
> Personnel
>
> The responsible area director is Chris Newman who reviewed this
> specification in detail. The specification was also reviewed by
> multiple participants of the www-webdav-dasl@... mailing list
> (formerly used by the DASL WG) as well as the w3c-dist-auth@...
> (formerly WebDAV WG). During IETF last call, support was
> expressed by Tobias Schlauch and Javier Godoy on the IETF list.
> Additional review comments were provided by John Barone and Cyrus
> Daboo on the webdav lists during last call. Gonzalo Camarillo
> was the GEN-ART reviewer, Radia Perlman was the sec-dir reviewer.
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@...
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

WebDAV SEARCH draft 18 submitted, was: WebDAV SEARCH Last Call over

2008-08-30T02:54:09Z

FYI:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> Title : Web Distributed Authoring and Versioning (WebDAV) SEARCH
> Author(s) : J. Reschke, et al.
> Filename : draft-reschke-webdav-search-18.txt
> Pages : 62
> Date : 2008-08-30
>
> This document specifies a set of methods, headers and properties
> composing WebDAV SEARCH, an application of the HTTP/1.1 protocol to
> efficiently search for DAV resources based upon a set of client-
> supplied criteria.Editorial Note (To be removed by RFC Editor before
> publication)
>
> Please send comments to the Distributed Authoring and Versioning
> (WebDAV) DASL mailing list at <mailto:www-webdav-dasl@...>, which
> may be joined by sending a message with subject "subscribe" to
> <mailto:www-webdav-dasl-request@...>. Discussions of the WebDAV
> DASL mailing list are archived at
> <http://lists.w3.org/Archives/Public/www-webdav-dasl/>.
>
> An issues list and XML and HTML versions of this draft are available
> from <http://greenbytes.de/tech/webdav/#draft-reschke-webdav-search>.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-reschke-webdav-search-18.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@...
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

>> ...
>> With respect to point 3, I'm willing to follow John's proposal to
>> relax the MUST to a SHOULD. Feedback on this one appreciated, in
>> particular if somebody feels strongly about it and doesn't want it to
>> be changed.
>> ...
>
> For now I have changed the text to say "SHOULD", see
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html#rfc.section.5.17.1>.
>
>
> In absence of other feedback I'll submit this one as draft 18 sometime
> next week.
>
> Best regards, Julian
>

Re: WebDAV SEARCH Last Call over

2008-08-17T12:39:38Z

Julian Reschke wrote:
> ...
> With respect to point 3, I'm willing to follow John's proposal to relax
> the MUST to a SHOULD. Feedback on this one appreciated, in particular if
> somebody feels strongly about it and doesn't want it to be changed.
> ...

For now I have changed the text to say "SHOULD", see
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html#rfc.section.5.17.1>.

In absence of other feedback I'll submit this one as draft 18 sometime
next week.

Best regards, Julian

WebDAV SEARCH Last Call over

2008-08-12T13:02:42Z

Hi,

the IETF Last Call for WebDAV SEARCH ended yesterday, and the following
points were raised:

1) some editorial nits ("SHOULD not" instead of "SHOULD NOT", an XML
namespace using a domain name not reserved for examples)

2) missing statement about safeness of SEARCH method

3) John Barone's proposal to relax the server requirement for sorting
truncated results (see thread starting at
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2008JulSep/0016.html>).

I have fixed 1) and 2) in my "latest" version; here are the diffs:

-- snip --

Section 2.2., paragraph 0:
OLD:

2.2. The Request

NEW:

SEARCH is a safe method; it does not have any significance other than
executing a query and returning a query result (see [RFC2616],
Section 9.1.1).

2.2. The Request

Section 5.19.9., paragraph 1:
OLD:

<D:basicsearchschema xmlns:D="DAV:"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<D:properties>
<D:propdesc>
<D:prop><D:getcontentlength/></D:prop>
<D:datatype><xs:nonNegativeInteger/></D:datatype>
<D:searchable/><D:selectable/><D:sortable/>
</D:propdesc>
<D:propdesc>
<D:prop><D:getcontenttype/><D:displayname/></D:prop>
<D:searchable/><D:selectable/><D:sortable/>
</D:propdesc>
<D:propdesc>
<D:prop><fstop xmlns="http://jennicam.org"/></D:prop>
<D:selectable/>
</D:propdesc>
<D:propdesc>
<D:any-other-property/>
<D:searchable/><D:selectable/>
</D:propdesc>
</D:properties>
<D:operators>
<D:opdesc>
<D:like/><D:operand-property/><D:operand-literal/>
</D:opdesc>
<D:opdesc allow-pcdata="yes">
<D:contains/>
</D:opdesc>
</D:operators>
</D:basicsearchschema>

NEW:

<D:basicsearchschema xmlns:D="DAV:"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<D:properties>
<D:propdesc>
<D:prop><D:getcontentlength/></D:prop>
<D:datatype><xs:nonNegativeInteger/></D:datatype>
<D:searchable/><D:selectable/><D:sortable/>
</D:propdesc>
<D:propdesc>
<D:prop><D:getcontenttype/><D:displayname/></D:prop>
<D:searchable/><D:selectable/><D:sortable/>
</D:propdesc>
<D:propdesc>
<D:prop><fstop xmlns="http://ns.example.org"/></D:prop>
<D:selectable/>
</D:propdesc>
<D:propdesc>
<D:any-other-property/>
<D:searchable/><D:selectable/>
</D:propdesc>
</D:properties>
<D:operators>
<D:opdesc>
<D:like/><D:operand-property/><D:operand-literal/>
</D:opdesc>
<D:opdesc allow-pcdata="yes">
<D:contains/>
</D:opdesc>
</D:operators>
</D:basicsearchschema>

Section 8., paragraph 1:
OLD:

Query grammars are identified by URIs. Applications SHOULD not
attempt to retrieve these URIs even if they appear to be retrievable
(for example, those that begin with "http://")

NEW:

Query grammars are identified by URIs. Applications SHOULD NOT
attempt to retrieve these URIs even if they appear to be retrievable
(for example, those that begin with "http://")

-- snip --

...see also
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html>
and
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest-from-previous.diff.html>.

With respect to point 3, I'm willing to follow John's proposal to relax
the MUST to a SHOULD. Feedback on this one appreciated, in particular if
somebody feels strongly about it and doesn't want it to be changed.

BR, Julian

RE: "Starts with" comparison in search

2008-08-11T08:37:41Z

Err... True. Disregard my +1

-John

-----Original Message-----
From: w3c-dist-auth-request@... [mailto:w3c-dist-auth-request@...]
On Behalf Of Cyrus Daboo
Sent: Monday, August 11, 2008 8:09 AM
To: Julian Reschke
Cc: w3c-dist-auth@...; www-webdav-dasl@...
Subject: Re: "Starts with" comparison in search

Hi Julian,

--On August 11, 2008 5:00:33 PM +0200 Julian Reschke
<julian.reschke@...> wrote:

> are we talking about properties, or about content?
>
> For properties, you can use DAV:like, with something like "prefix%"
> (see
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-17.html#
> rfc
> .section.5.15>).

Ah yes. That is probably sufficient for the vast majority of use cases I
can think of.

--
Cyrus Daboo

This email and any attachments may contain confidential and proprietary
information of Blackboard that is for the sole use of the intended
recipient. If you are not the intended recipient, disclosure, copying,
re-distribution or other use of any of this information is strictly
prohibited. Please immediately notify the sender and delete this
transmission if you received this email in error.

RE: "Starts with" comparison in search

2008-08-11T08:36:24Z

+1 would be nice

-John

-----Original Message-----
From: w3c-dist-auth-request@... [mailto:w3c-dist-auth-request@...]
On Behalf Of Cyrus Daboo
Sent: Monday, August 11, 2008 7:35 AM
To: w3c-dist-auth@...; www-webdav-dasl@...
Subject: "Starts with" comparison in search

Hi,
Is it too late to consider adding a "startswith" comparison operation to
the basicsearch grammar in the SEARCH extension? I think that is a key
string match operation to have in addition to "contains".

--
Cyrus Daboo

This email and any attachments may contain confidential and proprietary
information of Blackboard that is for the sole use of the intended
recipient. If you are not the intended recipient, disclosure, copying,
re-distribution or other use of any of this information is strictly
prohibited. Please immediately notify the sender and delete this
transmission if you received this email in error.

Re: "Starts with" comparison in search

2008-08-11T08:00:33Z

Cyrus Daboo wrote:
>
> Hi,
> Is it too late to consider adding a "startswith" comparison operation to
> the basicsearch grammar in the SEARCH extension? I think that is a key
> string match operation to have in addition to "contains".

Hi Cyrus,

are we talking about properties, or about content?

For properties, you can use DAV:like, with something like "prefix%" (see
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-17.html#rfc.section.5.15>).

BR, Julian

Re: getting WebDAV SEARCH ready for the IESG

2008-08-04T11:49:38Z

John Barone wrote:
> Yes, that would be fine.
>
> I wasn't privy to the original discussion that resulted in the MUST.
> So, I don't know if there are some client requirements/concerns that
> would be stepped on by changing it to a SHOULD.
> ...

I would assume that any query that DAV:limits itself, or results in
server-enforced truncation, is unlikely to be useful in a programmatic
client. So I wouldn't expect this to be a problem.

BR, Julian

RE: getting WebDAV SEARCH ready for the IESG

2008-08-04T11:39:07Z

Yes, that would be fine.

I wasn't privy to the original discussion that resulted in the MUST.
So, I don't know if there are some client requirements/concerns that
would be stepped on by changing it to a SHOULD.

Regards,

-John

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@...]
Sent: Monday, August 04, 2008 11:35 AM
To: John Barone
Cc: w3c-dist-auth@...; www-webdav-dasl@...
Subject: Re: getting WebDAV SEARCH ready for the IESG

John Barone wrote:
> First and foremost I would be in favor of wording that is consistent
> with what's outlined in section 2.3.1, for truncation. From a client
> perspective, I would think that the MUST wording in section 5.17.1 is
> most desirable. However, from a practical (and admittedly
> self-serving) point of view, simply stating that the results MUST
> ordered as the client directed, would be preferred. Section 2.3.1
goes on to say:
>
> "... the partial results returned MAY be any subset of the result set
> that would have satisfied the original query".
>
> Perhaps in section 5.17.1 the additional sentence could be phrased:
>
> "... the results that are included in the response document SHOULD be
> those that order highest"

So, to be precise, the single change you're proposing is to relax the
"must" to a "should"?

I'd be ok with that.

BR, Julian

This email and any attachments may contain confidential and proprietary
information of Blackboard that is for the sole use of the intended
recipient. If you are not the intended recipient, disclosure, copying,
re-distribution or other use of any of this information is strictly
prohibited. Please immediately notify the sender and delete this
transmission if you received this email in error.

Re: getting WebDAV SEARCH ready for the IESG

2008-08-04T11:34:44Z

John Barone wrote:

> First and foremost I would be in favor of wording that is consistent
> with what's outlined in section 2.3.1, for truncation. From a client
> perspective, I would think that the MUST wording in section 5.17.1 is
> most desirable. However, from a practical (and admittedly self-serving)
> point of view, simply stating that the results MUST ordered as the
> client directed, would be preferred. Section 2.3.1 goes on to say:
>
> "... the partial results returned MAY be any subset of the result set
> that would have satisfied the original query".
>
> Perhaps in section 5.17.1 the additional sentence could be phrased:
>
> "... the results that are included in the response document SHOULD be
> those that order highest"

So, to be precise, the single change you're proposing is to relax the
"must" to a "should"?

I'd be ok with that.

BR, Julian

RE: getting WebDAV SEARCH ready for the IESG

2008-08-04T11:19:22Z

First and foremost I would be in favor of wording that is consistent
with what's outlined in section 2.3.1, for truncation. From a client
perspective, I would think that the MUST wording in section 5.17.1 is
most desirable. However, from a practical (and admittedly self-serving)
point of view, simply stating that the results MUST ordered as the
client directed, would be preferred. Section 2.3.1 goes on to say:

"... the partial results returned MAY be any subset of the result set
that would have satisfied the original query".

Perhaps in section 5.17.1 the additional sentence could be phrased:

"... the results that are included in the response document SHOULD be
those that order highest"

Regards,

-John

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@...]
Sent: Monday, August 04, 2008 10:39 AM
To: John Barone
Cc: w3c-dist-auth@...; www-webdav-dasl@...
Subject: Re: getting WebDAV SEARCH ready for the IESG

John Barone wrote:
> The Xythos server currently doesn't implement the limit feature. The
> server does truncate results based on a server setting. Making sure
> the truncated results are globally ordered is difficult, for the
> reasons you outlined and particularly when the search spans multiple
data stores.

...another good point I forgot.

> Implementing the limit feature would pose the same ordering
challenges.
> I think making 5.17.1 a MUST places a heavy burden on the server
> implementation.

One alternative would be "SHOULD", another one would be just stating
that DAV:limit is optional, and servers that can't do the MUST level
requirement should reject the query.

Any preference?

BR, Julian

This email and any attachments may contain confidential and proprietary
information of Blackboard that is for the sole use of the intended
recipient. If you are not the intended recipient, disclosure, copying,
re-distribution or other use of any of this information is strictly
prohibited. Please immediately notify the sender and delete this
transmission if you received this email in error.

Re: getting WebDAV SEARCH ready for the IESG

2008-08-04T10:39:29Z

John Barone wrote:
> The Xythos server currently doesn't implement the limit feature. The
> server does truncate results based on a server setting. Making sure the
> truncated results are globally ordered is difficult, for the reasons you
> outlined and particularly when the search spans multiple data stores.

...another good point I forgot.

> Implementing the limit feature would pose the same ordering challenges.
> I think making 5.17.1 a MUST places a heavy burden on the server
> implementation.

One alternative would be "SHOULD", another one would be just stating
that DAV:limit is optional, and servers that can't do the MUST level
requirement should reject the query.

Any preference?

BR, Julian

RE: getting WebDAV SEARCH ready for the IESG

2008-08-04T09:39:37Z

The Xythos server currently doesn't implement the limit feature. The
server does truncate results based on a server setting. Making sure the
truncated results are globally ordered is difficult, for the reasons you
outlined and particularly when the search spans multiple data stores.
Implementing the limit feature would pose the same ordering challenges.
I think making 5.17.1 a MUST places a heavy burden on the server
implementation.

-John

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@...]
Sent: Monday, August 04, 2008 9:24 AM
To: John Barone
Cc: w3c-dist-auth@...; www-webdav-dasl@...
Subject: Re: getting WebDAV SEARCH ready for the IESG

John Barone wrote:

>> However, it seems to me that the text in 2.3.1 was phrased this way
>> on
> purpose
>> -- there may be cases where it's not possible to first sort, then
>> truncate. For instance, when searching can be delegated to an
> underlying
>> SQL store, but ordering can not, how would you implement that?
>> Thus, I'm hesitant doing any change over here.
>
> Completely understood. I'm just saying a client may not want results
> that aren't ordered over the entire result set. It might be preferred

> to get no results (and have to further refine the search) than to get
> truncated results that aren't "globaly" ordered.

I do agree that this may be more useful. I'm just skeptic about making
this change many years after people have written implementations.

>> If you feel strongly about that, we *could* add a statement into the
> "future extensions" appendix.
>
> I don't feel that strongly about this, just a nice-to-have for some
> clients.
>
>
>> And yes, the inconsistency with 5.17.1 is a bit awkward, but I'm
> really not
>> sure we can change this at this point of time.
>
> This I think is a bigger deal. If you acknowledge that some servers
> cannot (at least easily) order a global result set and then limit the
> results returned, then how can this be a MUST? Seems like the same
> issue to me.

I just checked the document's history, and that particular requirement
was added in 2003, see the thread around
<http://lists.w3.org/Archives/Public/www-webdav-dasl/2002OctDec/0033.htm
l>.
Back then we probably did not realize that we're introducing an
inconsistency between truncation (server enforced) and limiting (on
behalf of the client).

If this is a minor problem, we should just state it somewhere. If it's a
major problem, we could try to fix it. The server I worked on didn't
truncate, so I don't have a strong preference. That being said, it would
be interesting to know how the other servers (Xythos, Catacomb,
Slide...?) behave...

BR, Julian

This email and any attachments may contain confidential and proprietary
information of Xythos that is for the sole use of the intended
recipient. If you are not the intended recipient, disclosure, copying,
re-distribution or other use of any of this information is strictly
prohibited. Please immediately notify the sender and delete this
transmission if you received this email in error.

Re: getting WebDAV SEARCH ready for the IESG

2008-08-04T09:23:40Z

John Barone wrote:

>> However, it seems to me that the text in 2.3.1 was phrased this way on
> purpose
>> -- there may be cases where it's not possible to first sort,
>> then truncate. For instance, when searching can be delegated to an
> underlying
>> SQL store, but ordering can not, how would you implement that?
>> Thus, I'm hesitant doing any change over here.
>
> Completely understood. I'm just saying a client may not want results
> that aren't ordered over the entire result set. It might be preferred
> to get no results (and have to further refine the search) than to get
> truncated results that aren't "globaly" ordered.

I do agree that this may be more useful. I'm just skeptic about making
this change many years after people have written implementations.

RE: getting WebDAV SEARCH ready for the IESG

2008-08-04T08:57:35Z

> However, it seems to me that the text in 2.3.1 was phrased this way on
purpose
> -- there may be cases where it's not possible to first sort,
> then truncate. For instance, when searching can be delegated to an
underlying
> SQL store, but ordering can not, how would you implement that?
> Thus, I'm hesitant doing any change over here.

Completely understood. I'm just saying a client may not want results
that aren't ordered over the entire result set. It might be preferred
to get no results (and have to further refine the search) than to get
truncated results that aren't "globaly" ordered.

> If you feel strongly about that, we *could* add a statement into the
"future extensions" appendix.

I don't feel that strongly about this, just a nice-to-have for some
clients.

> And yes, the inconsistency with 5.17.1 is a bit awkward, but I'm
really not
> sure we can change this at this point of time.

This I think is a bigger deal. If you acknowledge that some servers
cannot (at least easily) order a global result set and then limit the
results returned, then how can this be a MUST? Seems like the same
issue to me.

-John

John Barone wrote:

> Some comments:
>
> In section 2.3.1 Result Set Truncation
>
> - Would be nice to indicate what the search limit is (after what
> number of results was the query truncated)
>
> - Partial results: I read this to mean whatever partial results you
> send back, they must be ordered (within themselves) as the client
> requested. In many cases the client wants the full list ordered, and
> then send back the partial results.
> Any way to indicate this in the request; i.e. if you have to send back

> partial results (a 507 condition) I want them fully ordered, not just
> within themselves? Perhaps the server can send back a 507 response
> for the arbiter URI and no results, if it can't comply with ordering
> the full result set, and sending back partial results.
>
>
> In section 5.17.1 Relationship to Result Ordering
>
> - I read this to mean that the full results should first be ordered by

> the server, and then send back the requested limit. This seems to
> contradict what's specified in section 2.3.1, where the results are
> limited and then ordered (if I'm reading it correctly). I think these

> 2 sections should be consistent with each other.
>
>
> Regards,
>
> -John
>
>
> -----Original Message-----
> From: w3c-dist-auth-request@...
> [mailto:w3c-dist-auth-request@...]
> On Behalf Of Julian Reschke
> Sent: Wednesday, July 02, 2008 9:12 AM
> To: w3c-dist-auth@...
> Cc: WebDAV
> Subject: getting WebDAV SEARCH ready for the IESG
>
>
> Hi,
>
> we recently made some progress on getting WebDAV SEARCH ready for
> publication.
>
> We received some feedback from Chris Newman, and the latest edits on
> the draft
> (<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.
> ht
> ml>,
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest-f
> ro
> m-previous.diff.html>)
> take those into account.
>
> Unless there's new feedback, I'm planning to submit this as draft 16,
> which, if all goes well, will then by last called.
>
> Feedback appreciated,
>
> Julian
>
>
>
>
> This email and any attachments may contain confidential and
> proprietary information of Blackboard that is for the sole use of the
> intended recipient. If you are not the intended recipient,
> disclosure, copying, re-distribution or other use of any of this
> information is strictly prohibited. Please immediately notify the
> sender and delete this transmission if you received this email in

error.
>

This email and any attachments may contain confidential and proprietary
information of Blackboard that is for the sole use of the intended
recipient. If you are not the intended recipient, disclosure, copying,
re-distribution or other use of any of this information is strictly
prohibited. Please immediately notify the sender and delete this
transmission if you received this email in error.

Re: getting WebDAV SEARCH ready for the IESG

2008-08-04T08:47:12Z

Hi John,

thanks for the comments.

The server I worked on a long time ago never truncated results, so I
don't have any preference.

However, it seems to me that the text in 2.3.1 was phrased this way on
purpose -- there may be cases where it's not possible to first sort,
then truncate. For instance, when searching can be delegated to an
underlying SQL store, but ordering can not, how would you implement
that? Thus, I'm hesitant doing any change over here.

If you feel strongly about that, we *could* add a statement into the
"future extensions" appendix.

And yes, the inconsistency with 5.17.1 is a bit awkward, but I'm really
not sure we can change this at this point of time.

BR, Julian

John Barone wrote:

> Some comments:
>
> In section 2.3.1 Result Set Truncation
>
> - Would be nice to indicate what the search limit is (after what number
> of results was the query truncated)
>
> - Partial results: I read this to mean whatever partial results you send
> back, they must be ordered (within themselves)
> as the client requested. In many cases the client wants the full list
> ordered, and then send back the partial results.
> Any way to indicate this in the request; i.e. if you have to send back
> partial results (a 507 condition) I want them fully ordered, not just
> within themselves? Perhaps the server can send back a 507 response for
> the arbiter URI and no results, if it can't comply with ordering the
> full result set, and sending back partial results.
>
>
> In section 5.17.1 Relationship to Result Ordering
>
> - I read this to mean that the full results should first be ordered by
> the server, and then send back the requested limit. This seems to
> contradict what's specified in section 2.3.1, where the results are
> limited and then ordered (if I'm reading it correctly). I think these 2
> sections should be consistent with each other.
>
>
> Regards,
>
> -John
>
>
> -----Original Message-----
> From: w3c-dist-auth-request@... [mailto:w3c-dist-auth-request@...]
> On Behalf Of Julian Reschke
> Sent: Wednesday, July 02, 2008 9:12 AM
> To: w3c-dist-auth@...
> Cc: WebDAV
> Subject: getting WebDAV SEARCH ready for the IESG
>
>
> Hi,
>
> we recently made some progress on getting WebDAV SEARCH ready for
> publication.
>
> We received some feedback from Chris Newman, and the latest edits on the
> draft
> (<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.ht
> ml>,
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest-fro
> m-previous.diff.html>)
> take those into account.
>
> Unless there's new feedback, I'm planning to submit this as draft 16,
> which, if all goes well, will then by last called.
>
> Feedback appreciated,
>
> Julian
>
>
>
>
> This email and any attachments may contain confidential and proprietary
> information of Blackboard that is for the sole use of the intended
> recipient. If you are not the intended recipient, disclosure, copying,
> re-distribution or other use of any of this information is strictly
> prohibited. Please immediately notify the sender and delete this
> transmission if you received this email in error.
>

Re: safeness of SEARCH method, Re: Last Call: draft-reschke-webdav-search (Web Distributed Authoring and Versioning (WebDAV) SEARCH) to Proposed Standard

2008-08-03T09:28:53Z

Julian Reschke wrote:
>
> Hi,
>
> here's a LC comment by myself: the specification should state that
> SEARCH is a safe method (see
> <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.1.1>).
>
> BR, Julian

Fixed in -latest, adding:

"SEARCH is a safe method; it does not have any significance other than
executing a query and returning a query result (see [RFC2616], Section
9.1.1)."

(<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html#rfc.section.2.1>).

BR, Julian

safeness of SEARCH method, Re: Last Call: draft-reschke-webdav-search (Web Distributed Authoring and Versioning (WebDAV) SEARCH) to Proposed Standard

2008-08-02T01:05:50Z

Hi,

here's a LC comment by myself: the specification should state that
SEARCH is a safe method (see
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.1.1>).

BR, Julian

Re: Last Call: draft-reschke-webdav-search (Web Distributed Authoring and Versioning (WebDAV) SEARCH) to Proposed Standard

2008-07-16T13:39:17Z

It would be helpful if people who have reviewed this and support
advancement were to respond to the last call on the IETF list (or to
iesg@...) saying so.

The current IESG is a bit skeptical about any individual submission, so
it's helpful to have positive feedback during the last call to counter that.

Thanks,
- Chris

--On July 14, 2008 21:14:38 +0200 Julian Reschke <julian.reschke@...>
wrote:

>
> (FYI)
>
> The IESG wrote:
>> The IESG has received a request from an individual submitter to consider
>> the following document:
>>
>> - 'Web Distributed Authoring and Versioning (WebDAV) SEARCH '
>> <draft-reschke-webdav-search-17.txt> as a Proposed Standard
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> ietf@... mailing lists by 2008-08-11. Exceptionally,
>> comments may be sent to iesg@... instead. In either case, please
>> retain the beginning of the Subject line to allow automated sorting.
>>
>> The file can be obtained via
>> http://www.ietf.org/internet-drafts/draft-reschke-webdav-search-17.txt
>>
>>
>> IESG discussion can be tracked via
>> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
>> 8611&rfc_flag=0
>>
>> _______________________________________________
>> IETF-Announce mailing list
>> IETF-Announce@...
>> https://www.ietf.org/mailman/listinfo/ietf-announce

Re: Last Call: draft-reschke-webdav-search (Web Distributed Authoring and Versioning (WebDAV) SEARCH) to Proposed Standard

2008-07-14T12:14:38Z

(FYI)

The IESG wrote:

> The IESG has received a request from an individual submitter to consider
> the following document:
>
> - 'Web Distributed Authoring and Versioning (WebDAV) SEARCH '
> <draft-reschke-webdav-search-17.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@... mailing lists by 2008-08-11. Exceptionally,
> comments may be sent to iesg@... instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-reschke-webdav-search-17.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=8611&rfc_flag=0
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@...
> https://www.ietf.org/mailman/listinfo/ietf-announce

Re: Security considerations, was Re: Area Director feedback on draft-reschke-webdav-search-15 re supported query complexity

2008-07-12T13:14:34Z

Javier Godoy wrote:
> Julian, your recent posting of draft version 17 reminded me about this
> thread.
> Sorry for my late reply, this week have been too complicated for me.
>
> In order to not delay the Last Call, I think it can be closed with no
> action
> (other than changes already applied in version 16).

Ok. If you think that something needs to be done, you can still make a
proposal now (and also raise the point during LC, that's what it's for,
after all).

> ...
>> Honestly, I don't think so.
>>
>> The text you're referring to was put in because the original feature
>> discovery in DASL was broken (in that the DASL header uses URIs, while
>> the
>> request body uses expanded names), so this was put as an afterthought for
>> "modern" servers.
>
> I'm not following you. Do you mean it is broken because "[although] the
> URIs
> can be used to identify each supported search grammar, there is not
> necessarily a direct relationship between the URI and the XML element name
> that can be used in XML based SEARCH requests"?

Yes. In theory there could be an expanded name without an equivalent
URI, and also there's no 1-to-1 relationship between URIs and expanded
names.

> Identifying a grammar by URI, when it could be identified by namespace and
> element name is an unnecessary complication, but something we could live
> with: if a client doesn't know the URI, likely it will not know about the
> identified grammar, then providing the element name does not help (it
> cannot
> write a query using that grammar);
> conversely, if it knows the grammar it will know the URI.

Right. It's mainly a notation problem, caused by the fact that the
original authors didn't realize that there's no direct mapping between
URI and expanded name. The right fix would have been to drop the DASL
header, or to use expanded names or URIs instead. But even back then, we
didn't want to break existing servers.

> Other thing I don't understand is why DAV:supported-query-grammar-set is
> REQUIRED when RFC 3744 is supported. If it comes to fix a flaw with the
> DASL
> header, it is useful despite of whether RFC 3744 is supported or not. I
> guess it may be because "old" servers, implementing only the DASL header,
> didn't know about 3744, then the requirement only applies to newer servers
> (?)

The idea was that if a server implements RFC3253 or RFC3744, it's
"modern" enough to implement the additional live property.

>>> SEARCH (at least, basicsearch) already defines it own
>>> mechanism for advertising privileges in QSD responses. A property for
>>> which the clien has no privileges is neither DAV:selectable,
>>> DAV:searchable nor DAV:sortable... and that should be enough.
>>
>> Which of course raises the question whether the result of QSD should
>> reflect privileges; this may be very hard to implement.
>
> Not only hard to implement, but probably a bad idea... Even though my
> first
> though was that they should (not at a requirement level, but as a hint
> about a
> restriction which is not described anywhere else), analyzing it
> carefully, now I
> realize that QSD property descriptions and privileges are very
> different: QSD
> describes the properties of all the resources searchable through the
> arbiter, or
> the properties of all the resources within the specified scopes, while
> privileges are defined on a per-resource basis.

Right.

> ...
> Lack of RFC 3744 privileges is one possible interpretation of the actual
> wording: "the client does not have read access".
>
> If one want to be explicit, one could say "Read access may be determined by
> Access Control Protocol [RFC 3744], or other server-specific
> mechanisms." But
> i'm afraid it is very very obvious.

+1.

BR, Julian

Re: Security considerations, was Re: Area Director feedback on draft-reschke-webdav-search-15 re supported query complexity

2008-07-12T12:21:23Z

Julian, your recent posting of draft version 17 reminded me about this thread.
Sorry for my late reply, this week have been too complicated for me.

In order to not delay the Last Call, I think it can be closed with no action
(other than changes already applied in version 16).

On Wed, 02 Jul 2008 21:24:16 +0200, Julian Reschke wrote:

>
> Javier Godoy wrote:
>> ...
>>> o Query constraints on content (as with DAV:contains, defined in
>>> Section 5.16) for which the client does not have read access need
>>> to be evaluated as if a GET would return a 4xx status code.
>>
>> And is the result of this evaluation FALSE? or is it UNKNOWN?
>> I would expect the latter because expressions on properties evaluate as
>> UNKNOWN when the property is not defined, but Section 5.16 states that [[
>> The DAV:contains operator (...) evaluates to TRUE if the content of the
>> resource satisfies the search. Otherwise, it evaluates to FALSE.
>> ]]
>
> Would that be a problem?

I think it is a detail, not a problem.

IMHO it would be more correct to define UNKNOWN as the result of
non-evaluable operands about the content, instead of FALSE, but I also think it
has no practical implication.

When "not contains" is applied to a resource for which the client has no read
access,
it would evaluate as TRUE (instead of UNKNOWN) .

Then a query criteria specifying "other_condition AND not contains" would be
evaluated as:
other_condition AND not FALSE = other_condition
instead of
other_condition AND not UNKNOWN
which may be FALSE (if the other condition is false) or UNKNWON (if
other_condition is UNKNOWN or TRUE)

But criteria like "other_condition AND not contains" seems not to be very
useful (e.g., Content-Length <=1024 AND not contains "foobar").

(Just out of curiosity I asked Google for "not contains foobar" and it found 2
results: http://tinyurl.com/6ajobc ;-)

> I personally do not have a preference, and the DASL implementation I did a
> few years back did not support DAV:contains anyway.

As explained above, I do not see a reason for evaluating as FALSE, and I think
an implementation
doing so would be faulty, but that fault would be (almost) imperceptible.

The truth value UNKNOWN is explained in detail in Appendix A, and that
explanation is consistent with the case under discussion.

>>> I'm not too enthusiastic to add more RFC3744 related language; after
>>> all, some of the SEARCH implementations do not support RFC3744 anyway,
>>
>> IMHO, if the DAV:supported-query-grammar-set property is REQUIRED when
>> both RFC 3744 and SEARCH are supported, then the interaction between both
>> extensions should have been regarded as important at some point in the
>> developement of DASL / SEARCH.
>
> Honestly, I don't think so.
>
> The text you're referring to was put in because the original feature
> discovery in DASL was broken (in that the DASL header uses URIs, while the
> request body uses expanded names), so this was put as an afterthought for
> "modern" servers.

I'm not following you. Do you mean it is broken because "[although] the URIs
can be used to identify each supported search grammar, there is not
necessarily a direct relationship between the URI and the XML element name
that can be used in XML based SEARCH requests"?

Identifying a grammar by URI, when it could be identified by namespace and
element name is an unnecessary complication, but something we could live
with: if a client doesn't know the URI, likely it will not know about the
identified grammar, then providing the element name does not help (it cannot
write a query using that grammar);
conversely, if it knows the grammar it will know the URI.

Other thing I don't understand is why DAV:supported-query-grammar-set is
REQUIRED when RFC 3744 is supported. If it comes to fix a flaw with the DASL
header, it is useful despite of whether RFC 3744 is supported or not. I
guess it may be because "old" servers, implementing only the DASL header,
didn't know about 3744, then the requirement only applies to newer servers
(?)

>> SEARCH (at least, basicsearch) already defines it own
>> mechanism for advertising privileges in QSD responses. A property for
>> which the clien has no privileges is neither DAV:selectable,
>> DAV:searchable nor DAV:sortable... and that should be enough.
>
> Which of course raises the question whether the result of QSD should
> reflect privileges; this may be very hard to implement.

Not only hard to implement, but probably a bad idea... Even though my first
though was that they should (not at a requirement level, but as a hint about a
restriction which is not described anywhere else), analyzing it carefully, now I
realize that QSD property descriptions and privileges are very different: QSD
describes the properties of all the resources searchable through the arbiter, or
the properties of all the resources within the specified scopes, while
privileges are defined on a per-resource basis.

The client may have read access for some property in a sub-scope of the scope
being described by QSD, then the server should look up ACLs for every resource
within scope before considering some property as "not searchable" (it will be
easy if the client is never allowed to read that property, otherwise I think it
may be too much computation for nothing).

Other caveat: "If a property does not have such a description, or is not
described at all, then the server MAY still allow the property to be used in
the corresponding section." (section 5.9.12). The interpretation of omitted
descriptions is up to the client (which I think will suppose the query is
allowed, or will not care about the QSD at all) .

>> However, a brief statement about RFC 3744 in Section 7 should not harm
>> anyone (just a suggestion, it is up to you, +1 anyway)
> Any proposals?

Lack of RFC 3744 privileges is one possible interpretation of the actual
wording: "the client does not have read access".

If one want to be explicit, one could say "Read access may be determined by
Access Control Protocol [RFC 3744], or other server-specific mechanisms." But
i'm afraid it is very very obvious.

Best Regards

Javier