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. 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. > 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, 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. 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?
Attachment:
pgp00394.pgp
Description: PGP signature