Subject: RE: Proposal for marshalling property type information

From: [email-masked]
Date: Fri, 15 Jun 2001 13:05:12 +0100

"Julian Reschke" <[email-masked]> wrote:

> Understood. So would it possibly make sense to to change
> the wording to "he property's data type is defined in [RFC2518]"
> (leaving other specifications out)? I still think we don't
> need to return the types for RFC2518 defined properties...

The RFC2518 defined properties are:
creationdate
displayname
getcontentlanguage
getcontentlength
getcontenttype
getetag
getlastmodified
lockdiscovery
resourcetype
source
supportedlock

So the only ones that I believe would return type info (using the xs:string
- exclusion rule) are
creationdate -> dateTime
getContentLength -> nonNegativeInteger
getLastModified -> dateTime

So although I don't think it would be a great overhead for servers to
return these each time, I don't really care either way.

> > It was generally agreed on this list a while back that total
> > success may be condensed to a simple 200 OK response.  Your
> > suggestion would require a further modification to these servers.
>
> I see. Maybe this should be put onto the issues list then (for
> resolution in RFC2518).

What is the issue? I don't think that there is any great harm to interop if
some servers respond with 200OK and others return 207MultiStatus with 200OK
for each response.

> Do you think it would be a problem to require the 207 <multistatus>
> response in this case?

You may get pushback from some server writers.

Tim

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 15 Jun 2001 16:17:44 +0200

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of [email-masked]
> Sent: Friday, June 15, 2001 2:05 PM
> To: WebDAV WG
> Subject: RE: Proposal for marshalling property type information
>
>
>
>

Tim, thanks for the summary.

Now I'm tempted to agree that these should be returned. A minor issue is
with DAV:getlastmodified, because it's format isn't xs:dateTime, meaning
that we have to define a datatype for it in the spec. That's why I'd still
prefer to leave them out.

> some servers respond with 200OK and others return 207MultiStatus

The issue is that after reading the spec (and tracing IIS), authors of
client software might think that they'll always get a 207 which apparently
isn't the case (so I think this should be clarified).

> You may get pushback from some server writers.

Well, unless somebody suggests a better approach, I'll have to live with
that.