Subject: Re: Document Action: 'Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)' to Experimental RFC

From: Julian Reschke <[email-masked]>
Date: Mon, 25 Jan 2010 15:33:22 +0100

(FYI)

The IESG wrote:
> The IESG has approved the following document:
> 
> - 'Binding Extensions to Web Distributed Authoring and Versioning 
>    (WebDAV) '
>    <draft-ietf-webdav-bind-27.txt> as an Experimental RFC
> 
> This document has been reviewed in the IETF but is not the product of an
> IETF Working Group. 
> 
> The IESG contact person is Alexey Melnikov.
> 
> A URL of this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-webdav-bind-27.txt
> 
>       Technical Summary
> 
>    The WebDAV BIND extensions adds the ability for a client to create
> different "bindings" between URIs and resources on a WebDAV server. This
> is similar to file system "hard linking" or "aliases". Clients can also
> discover bindings on the server even in cases where they cannot create
> them. Additionally this specification clarifies some aspects of RFC3253
> (Delta-V) that rely on the BIND model.
> 
>       Working Group Summary
> 
>    Discussion has taken place on the WebDAV mailing list over a long
> period of time as the document has evolved. There have been three
> "informal" last calls on the document during this time.
>    However this document is not a WG document, as WebDAV has concluded
> since.
> 
>       Document Quality
> 
>    Several implementations of this specification already exist (Apache
> Jackrabbit, Apache Slide, SAP Netweaver KM). Additionally Java Content
> Repository (JCR) 2.0 ('shareable nodes' feature) and Content Management
> Interoperability Services (CMIS) ('multifiling' feature) specs both
> specify identical concepts which need BIND in order to be exposed via
> WebDAV. Discussion of how this extension might be used in CalDAV and
> CardDAV to implement "shared" calendars or address books is also on-going.
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 26 Jan 2010 00:25:02 +0100

Hi,

so just when we thought we were done with this after all these years, 
IANA notices that we took a status code (506) that's already in use.

Which raises two questions:

1) How could this happen?

Status 506 is defined in RFC 2295 (Experimental), which was published in 
1998. For some reason, it wasn't registered with IANA until 2007 (see 
<http://web.archive.org/web/20070922210635/http://www.iana.org/assignments/http-status-codes>).

At that time the spec had been stable for a long time, and apparently 
nobody cared to check status code assignments again.

2) What do we do?

That appears to be trivial: the status code 506 was added for a subset 
of servers that would be able to detect the loop status upfront, which 
requires not to stream the multistatus response in the first place. As 
far as I know, no implementation currently does this, so we should be 
able to just use the next free 5xx status code (which would be 508).

Best regards, and feedback appreciated,

Julian

---

From: Werner Donné <[email-masked]>
Date: Tue, 26 Jan 2010 09:30:23 +0100

Hi,

I use 506 for the MOVE method, but it's trivial to change that of course. Since there is no big dependency on the code, switching to 508 seems indeed to be the easiest approach.

Best regards,

Werner.

On 26 Jan 2010, at 00:25, Julian Reschke wrote:

> Hi,
> 
> so just when we thought we were done with this after all these years, IANA notices that we took a status code (506) that's already in use.
> 
> Status 506 is defined in RFC 2295 (Experimental), which was published in 1998. For some reason, it wasn't registered with IANA until 2007 (see <http://web.archive.org/web/20070922210635/http://www.iana.org/assignments/http-status-codes>).
> 
> At that time the spec had been stable for a long time, and apparently nobody cared to check status code assignments again.
> 
> 2) What do we do?
> 
> That appears to be trivial: the status code 506 was added for a subset of servers that would be able to detect the loop status upfront, which requires not to stream the multistatus response in the first place. As far as I know, no implementation currently does this, so we should be able to just use the next free 5xx status code (which would be 508).
> 
>>> - 'Binding Extensions to Web Distributed Authoring and Versioning    (WebDAV) '

--
http://www.pincette.biz/
Handling your documents with care, wherever you are.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 26 Jan 2010 09:37:48 +0100

Werner Donné wrote:
> ...

Hi Werner,

thanks for the feedback.

Question: you are returning this when it is attempted to MOVE (/REBIND) 
a tree that contains a bind loop? Why don't you just move the tree as-is?

Best regards, Julian

---

From: Werner Donné <[email-masked]>
Date: Tue, 26 Jan 2010 09:57:12 +0100

Hi Julian,

I use it when the move of a collection would lead to the creation of a loop somewhere. A couple of years ago I brought this up in the following thread:

http://lists.w3.org/Archives/Public/w3c-dist-auth/2007OctDec/0022.html

Best regards,

Werner.

On 26 Jan 2010, at 09:37, Julian Reschke wrote:

> Question: you are returning this when it is attempted to MOVE (/REBIND) a tree that contains a bind loop? Why don't you just move the tree as-is?
> 
> Best regards, Julian