Subject: More issue resolution: OVERLAP_5.3_AND_8.7.2, XML_LANG_CLARIFY, COPY_LIVE_PROPS

From: "Lisa Dusseault" <[email-masked]>
Date: Sun, 22 Jun 2003 10:55:17 -0700

OVERLAP_5.3_AND_8.7.2: This issue is redundant with issue REMOVE_SECTION_5.3.  Section 5.3 is removed so this issue must also be closed.

XML_LANG_CLARIFY: This issue can be marked as "inBis" if not CLOSED.  I believe the current language arouses no further objections:
"XML's support for multiple human languages, using the “xml:lang” attribute, handles cases where the same character set is employed by multiple human languages. Note that xml:lang scope is recursive, so a xml:lang attribute on any element containing a property name element applies to the property value unless it has been overridden by a more locally scoped attribute."

COPY_LIVE_PROPS:  This issue can be marked as "inBis" if not CLOSED.  A "COPY/MOVE behaviour" section was added to each property definition in 03 and changes made to section 8.10, and there have been no objections to this.

302_AND_MULTISTATUS: This issue can be marked as "inBis" if not CLOSED.  Section 12 of draft -03 contains an explanation of how the Location header may appear on a Multistatus response and how the client must handle that.

Lisa

---

From: "Julian Reschke" <[email-masked]>
Date: Sun, 22 Jun 2003 20:53:37 +0200

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Sunday, June 22, 2003 7:55 PM
> To: Jason Crawford; 'Webdav WG'
> Subject: More issue resolution: OVERLAP_5.3_AND_8.7.2, XML_LANG_CLARIFY,
> COPY_LIVE_PROPS
> 
> 
> 
> 
> OVERLAP_5.3_AND_8.7.2: This issue is redundant with issue 
> REMOVE_SECTION_5.3.  Section 5.3 is removed so this issue must 
> also be closed.

Agreed.

> XML_LANG_CLARIFY: This issue can be marked as "inBis" if not 
> CLOSED.  I believe the current language arouses no further objections:
> "XML's support for multiple human languages, using the “xml:lang” 
> attribute, handles cases where the same character set is employed 
> by multiple human languages. Note that xml:lang scope is 
> recursive, so a xml:lang attribute on any element containing a 
> property name element applies to the property value unless it has 
> been overridden by a more locally scoped attribute."

Agreed.

> COPY_LIVE_PROPS:  This issue can be marked as "inBis" if not 
> CLOSED.  A "COPY/MOVE behaviour" section was added to each 
> property definition in 03 and changes made to section 8.10, and 
> there have been no objections to this.

Agreed (should be closed when the next draft is available).

> 302_AND_MULTISTATUS: This issue can be marked as "inBis" if not 
> CLOSED.  Section 12 of draft -03 contains an explanation of how 
> the Location header may appear on a Multistatus response and how 
> the client must handle that.

This currently says:

"When the 302 and 303 status codes are returned as the only status code for a response, HTTP1.1 uses the Location response header to indicate where the client should make the request.  The Multi-Status response syntax does not allow for the Location header information to be included in an unambiguous way, so servers MAY choose not to use these status codes in Multi-Status responses. If a clients receives this status code in Multi-Status, the client MAY reissue the request to the individual resource, so that the server can issue a response with a Location header for each resource."

What's the rationale for allowing servers not to return 3xx response status in multistatus? And what should they return *instead*? I think this needs more discussion...

Julian

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

---

From: "Lisa Dusseault" <[email-masked]>
Date: Wed, 25 Jun 2003 17:38:33 -0700

> This currently says:
> 
> "When the 302 and 303 status codes are returned as the only 
> status code for a response, HTTP1.1 uses the Location 
> response header to indicate where the client should make the 
> request.  The Multi-Status response syntax does not allow for 
> the Location header information to be included in an 
> unambiguous way, so servers MAY choose not to use these 
> status codes in Multi-Status responses. If a clients receives 
> this status code in Multi-Status, the client MAY reissue the 
> request to the individual resource, so that the server can 
> issue a response with a Location header for each resource."
> 
> What's the rationale for allowing servers not to return 3xx 
> response status in multistatus? And what should they return 
> *instead*? I think this needs more discussion...
> 

The server *can* return 3xx response status in multi-status, or it can try to avoid that.  This paragraph attempts to do two things:
 - to suggest to the server implementor that 3xx response codes are somewhat problematic in Multi-Status.  Since I'm not entirely sure what 3xx response codes in Multi-Status would accomplish or why they would be used, it's hard to say whether it's possible to choose 3xx or some other error code that doesn't take a Location header.  We'd have to discuss specific scenarios.
 - to suggest to the client implementor how a 3xx response code in a Multi-Status can be dealt with in the existing set of functionality.

I'm currently happy with this because it ought to improve interoperability without making any new requirements or defining any new syntax -- it explains how it's possible already.  But everything is of course up for discussion, which is what we're doing.  This was first published back in March, FWIW.

I can't find exactly where I got this suggestion, but I think it may have been from you, Julian.  This change went into RFC2518bis after our in-person interim meeting at Apple early this year.  The notes for that meeting said that you were going to suggest language for this.

http://www.sharemation.com/~milele/public/dav/minutes/wg-notes-jan-2003.
txt

Lisa

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 26 Jun 2003 13:19:23 +0200

> Sent: Thursday, June 26, 2003 2:39 AM
> To: 'Julian Reschke'; 'Jason Crawford'; 'Webdav WG'
> Subject: RE: More issue resolution: OVERLAP_5.3_AND_8.7.2,
> XML_LANG_CLARIFY, COPY_LIVE_PROPS
> 
> 
> 
> 
> > This currently says:
> > 
> The server *can* return 3xx response status in multi-status, or 
> it can try to avoid that.  This paragraph attempts to do two things:
>  - to suggest to the server implementor that 3xx response codes 
> are somewhat problematic in Multi-Status.  Since I'm not entirely 
> sure what 3xx response codes in Multi-Status would accomplish or 
> why they would be used, it's hard to say whether it's possible to 
> choose 3xx or some other error code that doesn't take a Location 
> header.  We'd have to discuss specific scenarios.
>  - to suggest to the client implementor how a 3xx response code 
> in a Multi-Status can be dealt with in the existing set of functionality.

The issue that I see here is that this is a *change* to RFC2518 that will make a subsequent WebDAV redirect ref spec harder than it needs to be.

PROPFIND on a collection is specific way to marshall information about it's internal members. Unless explicitly otherwise stated, it should faithfully reproduce what I'd get if I did a HEAD request on the internal member.

Thus, return a 2xx status in PROPFIND although a HEAD on the resource will return a 3xx is inconsistent and will make it harder for redirect-aware clients to distinguish between "simple" resources and redirects (when browsing collections via PROPFIND).

This paragraph only affects servers that both support redirects *and* make them visible through WebDAV. As far as I know, there's only one implementation doing this (ours), and we certainly would prefer that clients can rely on getting the 3xx status codes (instead of leaving that to the server).

> I'm currently happy with this because it ought to improve 
> interoperability without making any new requirements or defining 
> any new syntax -- it explains how it's possible already.  But 
> everything is of course up for discussion, which is what we're 
> doing.  This was first published back in March, FWIW.
> 
> I can't find exactly where I got this suggestion, but I think it 
> may have been from you, Julian.  This change went into RFC2518bis 
> after our in-person interim meeting at Apple early this year.  
> The notes for that meeting said that you were going to suggest 
> language for this.
> 

I honestly don't remember. However it's true thatg I volunteered to propose marshalling for the Location information, and I'll try to do that ASAP.

Julian