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: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 26 Jan 2010 00:25:02 +0100
Message-ID: <4B5E284E.9040601@gmx.de>
To: WebDAV <w3c-dist-auth@w3.org>, Alexey Melnikov <alexey.melnikov@isode.com>
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
>>
> 
> 
Received on Monday, 25 January 2010 23:25:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 25 January 2010 23:25:50 GMT