- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 15 Jun 2001 16:17:44 +0200
- To: <Tim_Ellison@uk.ibm.com>, "WebDAV WG" <w3c-dist-auth@w3.org>
> From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Tim_Ellison@uk.ibm.com > Sent: Friday, June 15, 2001 2:05 PM > To: WebDAV WG > Subject: RE: Proposal for marshalling property type information > > > > > "Julian Reschke" <julian.reschke@gmx.de> 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 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. > 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. 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). > > 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. Well, unless somebody suggests a better approach, I'll have to live with that.
Received on Friday, 15 June 2001 10:18:20 UTC