RE: Resolution of open issues: JW4/DB4/DB5 (insufficient storage status code)

OK,

I've removed the original section "Example: Result Set Truncation" [1] and
added a new one [2] (in the parent section "The Successful 207 (Multistatus)
Response").

Note that the original argument "507 is currently in conflict with other
specs. Need to avoid collisions." wasn't strong, as 507 indeed *is* defined
in RFC2518. But I think making a truncated result a successful response
makes sense anyway.

Julian

[1]
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html#rf
c.section.del-1>
[2]
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html#rf
c.section.2.4.3>

> -----Original Message-----
> From: www-webdav-dasl-request@w3.org
> [mailto:www-webdav-dasl-request@w3.org]On Behalf Of Babich, Alan
> Sent: Sunday, February 17, 2002 11:23 PM
> To: dasl
> Subject: RE: Resolution of open issues: JW4/DB4/DB5 (insufficient
> storage status code)
>
>
> OK with me.
>
> Alan Babich
>
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Friday, February 15, 2002 8:30 AM
> To: dasl
> Subject: RE: Resolution of open issues: JW4/DB4/DB5 (insufficient
> storage status code)
>
>
> Hi,
>
> I didn't get any feedback at all. Can I take this as "ok, go forward with
> this change"?
>
> > From: www-webdav-dasl-request@w3.org
> > [mailto:www-webdav-dasl-request@w3.org]On Behalf Of Julian Reschke
> > Sent: Sunday, February 03, 2002 5:56 PM
> > To: dasl
> > Subject: Resolution of open issues: JW4/DB4/DB5 (insufficient storage
> > status code)
> >
> >
> > Currently, SEARCH is defined to return a status code of 507
> (Insufficient
> > Storage) when the result set was truncated [1]. The following
> issues were
> > raised:
> >
> > - Don't use 507 for Insufficient Storage. Use a new code, perhaps 208
> > (Partial Results).
> > - When results are truncated, server replies with a 507 and also
> > returns an
> > XML element.
> > - 507 is currently in conflict with other specs. Need to avoid
> collisions.
> >
> > I think an easy way to resolve this would be to consider to use 207
> > (Multi-Status), and then to define how the client would detect
> a truncated
> > result set: this could take the same format as in sectiom 2.5.1
> > (the SEARCH
> > arbiter resource would be reported with a 507 status code *inside* the
> > multistatus response).
> >
> > Feedback appreciated,
> >
> > Julian
> >
> >
> >
> > [1]
> > <http://www.greenbytes.de/tech/webdav/draft-reschke-webdav-search-
> > latest.htm
> > l#rfc.issue.JW4/DB4/DB5>
> >
> >
> >
>

Received on Monday, 18 February 2002 06:10:39 UTC