Re: rfc2223bis draft 07, "updates" clarification

[Julian Reschke <[e-mail]>]

[e-mail] wrote:

> On Fri, 02 Jan 2004 20:43:23 +0100, Julian Reschke said:
> 
> 
>>Well, I was asking because we (the WebDAV working group) are just now 
>>discussing a similar issue. We've got a new spec (the BIND protocol) 
>>which updates parts of RFC2518 and RFC3253, and thus we'd like the RFC 
>>Index to have "forward references" from those to the new spec.
> 
> 
> The RFC Editor should update the rfc-index.txt entries for 2518 and 3253 with a
> '(Updated by NNNN)' when your RFC comes out.  I don't think you need to do
> anything other than make sure the Last Call says it's an update for 2518/3253/
> whatever, the IESG and RFC Editor should make the right things happen after
> that.

OK, so basically the new RFC should state "updates: 2518, 3253", just 
like I thought.

> A quick reading of the 2518 and 3253 tables of contents doesn't seem to show
> that this is likely to result in an 1808/2046 style punchout - for instance,
> you almost certainly can't take section 11 (MERGE feature) out of 3253 and replace
> it with something totally stand-alone (for starters, section 11.1 says:
> 
> 11.1 Additional Checked-Out Resource Properties
> 
>    The merge feature introduces the following REQUIRED properties for a
>    checked-out resource.
> 
> which means you need section 4.2 (Checked-out Resource Properties) (plus any
> other implicit references) for it to make sense.

Yes.

However, RFC3253 uses the term "binding", and in particular introduces 
operations that create additional bindings to the same resource.

On the other hand, RFC2518's description of the DELETE method is deeply 
incompatible to the concept of having multiple bindings (think POSIX 
hard links) to the same resource, because it states that if you remove 
any binding to the resource, all other bindings that refer to the same 
resource must be removed as well.

Thus, a new spec (BIND, 
http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html), 
updates both specs by finally saying what a binding is, how it behaves 
when existing HTTP methods are applied to it (such as MOVE or DELETE) 
and *in addition* defines specific methods/properties/status codes that 
help to deal with multiple bindings (such as determining that two 
bindings refer to the same resource, a method for explicitly creating 
new bindings, and status codes to be used for recursive operations when 
thy encounter bind loops).

>>Basically it will always happen when a particular part of a spec is 
>>"factored out" into a separate spec (like specific URI scheme 
>>registrations in the old URL RFC, or the "binding" functionality in WebDAV).
> 
> 
> Yes, the URI is a case of the 'collection of registrations'.  On the other hand,

Ah, now I understand the term. Thanks.

> rfc3253 has references to binding all over the place - it's totally unclear to me
> that any RFC that factors the binding out will be any less dependent on 3253
> than 3445 or 3442 were dependent on their base RFCs.

Right, and the case of factoring out isn't the one we were discussing 
here (RFC2518 vs RFC3253 bs BIND) - sorry for the confusion.

> What section(s) of 2518/3253 were you planning to update in such a way that
> the result would be standalone and not require 2518/3253 to make sense?

The BIND spec must be used in conjuction with RFC2518 (which is the base 
WebDAV spec), however it does not in any way rely on RFC3253. In this 
particular case, the relations were caused by the fact that the WebDAV 
working group split the base spec into WebDAV (RFC2518), Versioning 
(RFC3253) and several Advanced Collections specs (Redirects, Ordering, 
Bindings), and unfortunately, the latter are getting finished years 
later than they should have (basically, the BIND spec should have been 
in place when RFC3253 was finished).

Regards, Julian




-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:[phone]