W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2002

RE: RFC2518 issue: format for multistatus when no property report ed at all

From: Clemm, Geoff <gclemm@rational.com>
Date: Thu, 7 Mar 2002 15:40:38 -0500
Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8B022@SUS-MA1IT01>
To: DAV <w3c-dist-auth@w3.org>
I vote for "not 1" (:-).  I see no reason to break the DTD, with the
potential
for confusing clients/servers that are written to satisfy the DTD (as they
should
have been :-).  Between 2 and 3, I personally prefer 3, because it is
terser,
but I think clients should be prepared to handle either.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Thursday, March 07, 2002 10:06 AM
To: DAV
Subject: RFC2518 issue: format for multistatus when no property reported
at all


Consider a PROPFIND request like:

	<propfind xmlns='DAV:'><prop/></propfind>

I think this is clearly legal (by the DTD) and it can make sense if you're
for instance just getting a list of member URIs for a collection.

What format do we expect for the response body?

1)

<multistatus xmlns="DAV:">
  <response>
    <href>foobar</href>
  </response>
</multistatus>


I think this makes a lot of sense, but it breaks the DTD for the response
element.


2)

<multistatus xmlns="DAV:">
  <response>
    <href>foobar</href>
    <propstat>
      <prop/>
      <status>HTTP/1.1 200 OK</status>
    </propstat>
  </response>
</multistatus>

Conforms to the DTD, but isn't really logical (because in this case you may
expect a 200 propstat element in the case where all queried properties are
reported as 404 NOT FOUND as welll).


3)

<multistatus xmlns="DAV:">
  <response>
    <href>foobar</href>
    <status>HTTP/1.1 200 OK</status>
  </response>
</multistatus>

Conforms to the DTD as well, but isn't very logical. Why would the status
element on response be required, if it is not when properties *are*
reported.


Proposal:

allow format 1).

Julian
Received on Thursday, 7 March 2002 15:41:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:00 GMT