Subject: PROPFIND returning *more* than expected, and other questions

From: Chris Knight <[email-masked]>
Date: Thu, 16 Jan 2003 11:43:47 -0800

I'd like to discuss these questions (hopefully not at length, they 
should be fairly easy to answer) at the Interim WG meeting...But I 
thought I'd throw out the e-mail so people could ponder it first.

I'm working on a project that is providing rich searching capabilities 
to DAV properties. One feature we'd like to provide is keyword searching 
behaviors for properties. Say, for example, you requested <foo:author> 
and the resource had <foo:author>, <foo:author_name>, and <foo:authors> 
the server's response would contain all of these properties.

It appears that clients should expect to get fewer properties than they 
request and I would assume they'd accept more but I'd like to get the 
opinion of the community to ensure that we aren't doing something to 
break the protocol.

Second question, can a server respond to a PROPFIND for a particular 
property with multiple values for that property?

Thirdly, if a property has a rich XML structure as it's value, we'd like 
to return any matching XML tag in that structure.  (So if the 
<foo:authors> tag contained <foo:author>Chris</foo:author> 
<foo:author>David</foo:author> it would return all the <foo:authors> and 
each of the <foo:author> values separately.)

Anyways, see many of you next Monday!

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 16 Jan 2003 23:15:58 +0100

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Chris Knight
> Sent: Thursday, January 16, 2003 8:44 PM
> To: [email-masked]
> Subject: PROPFIND returning *more* than expected, and other questions
>
>
>

Did you consider

a) a new DASL grammar or
b) a new REPORT?

> the server's response would contain all of these properties.

If you do this upon PROPFIND/prop, that's illegal.

> opinion of the community to ensure that we aren't doing something to

Upon PROPFIND/prop, clients should expect to get entries for all properties
that were requested (not more, not less), possibly with non-200 status codes
(such as 404 for property not found).

> property with multiple values for that property?

No. A property has exactly one value.

> each of the <foo:author> values separately.)

I don't understand what this is good for. It's certainly not-compliant
behaviour.

> Anyways, see many of you next Monday!

See you!

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Chris Knight <[email-masked]>
Date: Thu, 16 Jan 2003 16:42:13 -0800

Julian Reschke wrote:
 > Chris Knight wrote:

Point taken.

> If you do this upon PROPFIND/prop, that's illegal.

I thought this too but I didn't find anything in the RFC that would make 
such behavior illegal. I don't think it's worthy of inclusion in the RFC 
but a clarification of this would be worthwhile.  (Clarification being 
must the server only respond with the values requested?)

> (such as 404 for property not found).

Ah yeah I mis-read the RFC on this one. Ok. I reverse my assumption 
(assuming, instead, that requesting property foo should only return 
property foo's value, not property foobar's as well.)

> No. A property has exactly one value.

I should have known this one, yeah that's true.

> I don't understand what this is good for. It's certainly not-compliant

Agreed.

---

From: Joe Orton <[email-masked]>
Date: Fri, 17 Jan 2003 08:32:19 +0000

> must the server only respond with the values requested?)

I asked this very same question a few years ago - Yaron said it's
perfectly legal for the server to return extra properties since the
client must ignore unknown/unexpected elements.

http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0196.html

Regards,

joe

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 17 Jan 2003 13:35:46 +0100

> [mailto:[email-masked]]On Behalf Of Joe Orton
> Sent: Friday, January 17, 2003 9:32 AM
> To: [email-masked]
> Subject: Re: PROPFIND returning *more* than expected, and other
> questions
>
>
>

I have to say that I disagree. It's correct that unknown protocol elements
should be ignored, but the contents of DAV:prop is one of the few places
where there *cannot* be unknown elements. Each child element of DAV:prop
identifies a property, so this has nothing to do with the extensibility
rules defined in the RFC2518 appendices.

Currently section 8.1 says:

"A client may submit a propfind XML element in the body of the request
method describing what information is being requested. It is possible to
request particular property values, all property values, or a list of the
names of the resource's properties. A client may choose not to submit a
request body. An empty PROPFIND request body MUST be treated as a request
for the names and values of all properties.

All servers MUST support returning a response of content type text/xml or
application/xml that contains a multistatus XML element that describes the
results of the attempts to retrieve the various properties."

I agree that this is a bit inprecise and should be clarified (right now,
most of the wording is in the examples which isn't a good thing).

However:

1) If a server returns more properties than requested, I'd really like to
understand why. In the example you posted back then, it certainly seems to
be a bug in the server. Does anybody really have a use case?

2) I'd claim that a conforming client may reject the response because it
does contain properties that weren't requested. So for the sake of
interoperability, servers MUST NOT return properties that weren't requested.

Julian

---

From: "Jim Whitehead" <[email-masked]>
Date: Fri, 17 Jan 2003 16:51:16 -0800

> I don't understand what this is good for. It's certainly not-compliant

While a WebDAV property's "value" is marshalled as a sequence of well-formed
XML. If a property contains a list of authors, it would be OK to marshall
this as

<foo:authors>
 <foo:author>Chris</foo:author>
 <foo:author>Julian</foo:author>
</foo:authors>

In this way WebDAV handles "multi-valued" properties.

- Jim