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:+492512807760