Subject: [VCARDDAV] Minor CardDAV change - query results limiting

From: Cyrus Daboo <[email-masked]>
Date: Fri, 28 Nov 2008 13:32:05 -0500

Hi folks,
I have received a request to make a minor change to CardDAV to help out 
clients. Currently an addressbook-query report is unbounded - results up to 
whatever server limit there may be will be returned. What client authors 
want to do is restrict the result set to a preset limit so that they don't 
get more results than they actually care about (or could present to the 
user in the UI). Similarly clients need to know when the result set has 
been truncated (either as a result of an explicit limit or due to the 
server's own limits).

Proposal is as follows:

1) Add a CARDDAV:limit XML element to the addressbook-query REPORT:

   <!ELEMENT limit (nresults) >
   <!ELEMENT nresults (#PCDATA)> <!-- only digits -->

This copies the same behavior in WebDAV SEARCH [RFC5323].

2) Also copy the behavior from WebDAV SEARCH where a server is able to 
indicate result set truncation by returning a 507 status for the 
DAV:response element with DAV:href set to the request-uri. I would also 
like the response to include a DAV:error element containing 
DAV:number-of-matches-within-limits element to be explicit about the reason 
for the 507.

Comments?

If there are no objections I would like to go ahead and add this and push 
out a new draft which can then be the subject of a WG last call as 
mentioned at the meeting a couple of weeks ago.

-- 
Cyrus Daboo

_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 28 Nov 2008 20:01:41 +0000

Cyrus Daboo wrote:

> Hi folks,
> I have received a request to make a minor change to CardDAV to help 
> out clients. Currently an addressbook-query report is unbounded - 
> results up to whatever server limit there may be will be returned. 
> What client authors want to do is restrict the result set to a preset 
> limit so that they don't get more results than they actually care 
> about (or could present to the user in the UI). Similarly clients need 
> to know when the result set has been truncated (either as a result of 
> an explicit limit or due to the server's own limits).

I like the idea.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 28 Nov 2008 21:10:25 +0100

>> an explicit limit or due to the server's own limits).

Yes.

But beware: the next thing people will ask for is result paging :-)

Been there.

BR, Julian

---

From: Helge Hess <[email-masked]>
Date: Fri, 28 Nov 2008 21:26:20 +0100

> But beware: the next thing people will ask for is result paging :-)

Hm, I wonder, result paging in combination with a ctag might be viable?

Greets,
   Helge
-- 
Helge Hess
http://zideone.com/

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 28 Nov 2008 21:44:43 +0000

Julian Reschke wrote:

>>> What client authors want to do is restrict the result set to a 
>>> preset limit so that they don't get more results than they actually 
>>> care about (or could present to the user in the UI). Similarly 
>>> clients need to know when the result set has been truncated (either 
>>> as a result of an explicit limit or due to the server's own limits).
>>
>> I like the idea.
>
> Yes.
>

Yes, and I have implemented it in other protocols ;-).

---

From: "Anil SRIVASTAVA [mobile]" <[email-masked]>
Date: Sat, 29 Nov 2008 11:40:44 +1300

+1

~ Anil
(sent from an iPhone)

On Nov 29, 2008, at 7:32 AM, Cyrus Daboo <[email-masked]> wrote:

> 2) Also copy the behavior from WebDAV SEARCH where a server is able  
> to indicate result set truncation by returning a 507 status for the  
> DAV:response element with DAV:href set to the request-uri. I would  
> also like the response to include a DAV:error element containing  
> DAV:number-of-matches-within-limits element to be explicit about the  
> reason for the 507.
>
> Comments?
>
> If there are no objections I would like to go ahead and add this and  
> push out a new draft which can then be the subject of a WG last call  
> as mentioned at the meeting a couple of weeks ago.
>
> -- 
> Cyrus Daboo
>