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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
(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
> [hidden email]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>


Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
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
>> [hidden email]
>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>
>
>


Reply | Threaded
Open this post in threaded view
|

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

Werner Donné
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
>>> [hidden email]
>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>>
>

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


Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
Werner Donné wrote:
> 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,
> ...

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

Reply | Threaded
Open this post in threaded view
|

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

Werner Donné
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:

> Werner Donné wrote:
>> 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,
>> ...
>
> 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

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