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?
pgpqZBlsB4WzT.pgp
Description: PGP signature