W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2010

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

From: Werner Donné <werner.donne@re.be>
Date: Tue, 26 Jan 2010 09:30:23 +0100
Cc: WebDAV <w3c-dist-auth@w3.org>, Alexey Melnikov <alexey.melnikov@isode.com>
Message-Id: <DAD25B9B-82E7-4514-9108-FFDD12F966BA@re.be>
To: Julian Reschke <julian.reschke@gmx.de>
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.
> 
> 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
> 
> 
> Julian Reschke wrote:
>> (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
>>> IETF-Announce@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>> 
> 

--
http://www.pincette.biz/
Handling your documents with care, wherever you are.
Received on Tuesday, 26 January 2010 08:30:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 26 January 2010 08:30:59 GMT