Subject: rfc2223bis draft 07, "updates" clarification

From: Julian Reschke <[email-masked]>
Date: Fri, 02 Jan 2004 13:14:54 +0100

Hi,

I'd like to see the concept of an RFC "updating" another RFC clarified. 
Currently the draft says:

          Updates

             Specifies an earlier document whose contents are modified or
             augmented by the new document.  The new document cannot be
             used alone, it can only be used in conjunction with the
             earlier document.

The second statement seems to be misleading. For instance, RFC2396 (URI 
syntax) updates previous RFCs that also contained specific URI scheme 
descriptions (such as "ftp"). Thus, it doesn't obsolete them. However, 
RFC2396 clearly can be used without the documents it's updating.

Regards, Julian

---

From: [email-masked]
Date: Fri, 02 Jan 2004 13:15:09 -0500

> RFC2396 clearly can be used without the documents it's updating.

OK.  Maybe I'm just caffeine-deficient today, but I'm totally failing to
understand how you can use the parts of rfc2396 that update the rfc1808
definitions of relative URI's, if you're not using relative URI's as specified
by 1808.

Or is your comment addressing the fact that although some sections of 2396 are
dependent on 1808 and are left dangling if 1808 isn't included, that *other*
sections of 2396 are stand-alone and not dependent on it? (i.e. if your
situation doesn't use relative URI's, you can disregard both 1808 and the
update to it)?

If so, there's likely a little bit of confusion between what the standard
actually specifies (a large number of URI classes), and what any given
application may actually implement.  So while for you *as implementor* large
sections of 2396 may be irrelevant, in order to make the *standard* consistent,
it must be dependent on 1808 (otherwise, some *other* coder who *does* have to
worry about relative URI's will get burnt).

Does that clarify things any?

---

From: Julian Reschke <[email-masked]>
Date: Fri, 02 Jan 2004 19:38:34 +0100

> definitions of relative URI's, if you're not using relative URI's as specified

Relative URIs are fully specified by RFC2396, section 5.

> situation doesn't use relative URI's, you can disregard both 1808 and the

No, RFC2396 doesn't rely in any way on RFC1808.

> Does that clarify things any?

Not at all. IMHO the situation is as follows: RFC2396 completely 
replaces all previous definitions of URI syntax and resolution 
(including the syntax for relative URI references).

However, previous documents *also* contained definitions of particular 
schemes which were not included in RFC2396, thus it doesn't obsolete 
these documents. Nevertheless, RFC2396 can be read without reading the 
previous documents (unless you happen for instance to be interested in 
the "ftp" URI scheme).

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: [email-masked]
Date: Fri, 02 Jan 2004 14:29:27 -0500

> previous documents (unless you happen for instance to be interested in 

OK.. I'm obviously caffeine-deficient today. ;)

I see what you mean now, I had it 100% backwards. ;)  And yes, there's a buglet
in the wording, but I'm not sure how to fix it for what is probably a special
case. I'm pretty sure that it's relatively rare for an updating RFC to do a
wholesale clean replacement of one section in such a way that the new RFC
updates the old but still stands on its own.  Much more common are the cases
like 3445 (updating 2535) or 3442 (updating 2132), where it *really* can't
stand on its own.

As far as I can tell, the text in 2223bis-07 is only inaccurate in the rare
case where the base document is an aggregation of several registration-type
definitions, as is the case for 1808 (or rfc2046 for MIME types), and the
proper classification for the base *would* have been 'obsoletes' if the one
section had been published on its own.  So for instance, RFC2112 was able to
obsolete 1872 (Multipart/Related), and was itself obsoleted by 2387 - but doing
the same for multipart/mixed isn't feasible without either:

a) Doing a full rev of 2046 that 'obsoletes 2046'.
b) Live with the fact that the 2223bis wording says that the new definition
depends on 2046 when it really doesn't.

Are there really enough documents like 1808 or 2046 for it to matter?

And if so, do you have any good verbiage to recommend that will in fact make
things cleared, rather than making it murkier due to special-casing?

---

From: Julian Reschke <[email-masked]>
Date: Fri, 02 Jan 2004 20:43:23 +0100

> like 3445 (updating 2535) or 3442 (updating 2132), where it *really* can't

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.

> Are there really enough documents like 1808 or 2046 for it to matter?

I don't know. But as we have the very situation right now in the WebDAV 
working group, and the same things occured for RFC2396, I'd say yes. 
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).

> things cleared, rather than making it murkier due to special-casing?

Good question. Looking at the current text:

          Updates

I'd say that just removing the second sentence should be fine. May just 
say...:

          Updates

             Specifies an earlier document whose content
             augmented by the new document.

Regards, Julian

---

From: [email-masked]
Date: Fri, 02 Jan 2004 15:12:10 -0500

> 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.

> 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?

---

From: Julian Reschke <[email-masked]>
Date: Fri, 02 Jan 2004 21:31:30 +0100

> whatever, the IESG and RFC Editor should make the right things happen after

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

> 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).

> Yes, the URI is a case of the 'collection of registrations'.  On the other hand,

Ah, now I understand the term. Thanks.

> 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.

> 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

---

From: Geoff Huston <[email-masked]>
Date: Sat, 03 Jan 2004 08:37:41 +1100

[A copy will be posted on the ietf-announce list sometime soon.]

The Internet Society (ISOC) provides organizational and financial
support for the IETF. As part of the arrangements between ISOC and the
IETF, the IETF is called upon to name 3 Trustees to its Board (BoT),
with staggered 3 year terms. This requires that the IETF select one
Trustee each year.

A description of the process for selecting the Trustee each year can
be found in RFC3677.

The timeline the IAB is using this year is as follows: 

  January 2:  Open nominations period 

  February 6: Close of nominations period.
              Publication of list of nominated candidates 
              IAB connences consideration of candidates
 
  On or before
  March 5:    IAB selection delivered to IESG for confirmation 

  On or before
  April 2:    Delivery of final confirmed selection to the ISOC 
              Elections Committee for announcement with the rest
              of the new ISOC BoT slate 

Nominations (including self-nominations) should be sent to the IAB --
[email-masked].

Nomination Details: 

  Nominees should be aware that ISOC Trustees are elected to three
  year terms with approximately one third of the Board of Trustees
  elected each year. The responsibilities of a Trustee include fiscal
  management of the Internet Society, fundraising, and participation
  in 2 to 3 Board meetings per year. The desirable characteristics of
  a candidate that are specific to the IETF's selected ISOC BoT member
  are outlined in section 2 of RFC 3677.

  Nominees will be asked to provide to the IAB: 

    1. Confirmation of their willingness to be considered within this
       process.

    2. Full name and contact information.

    3. A statement confirming willingness and ability to devote an
       appropriate level of time to activities associated with the
       position of Trustee.

    4. A brief biography outlining experience and background.

    5. A statement of interests, concerns about the Internet Society,
       goals as a Trustee and motivation to serve as a Trustee.

    6. Any further information that is relevant to the work of the IAB in
       considering your nomination.

    Care of Personal Information. 

    The following procedures will be used by the IAB in managing this
    process:

      - The candidate's name will be published, with all other
	candidate names, at the close of the nominations period

      - Excerpts of the information provided to the IAB by the
	nominated candidate will be passed to the IESG as part of the
	confirmation process. The IESG will be requested to maintain
	confidentiality of the candidate's information

      - Except as noted above, all information provided to the IAB
	during this process will be kept confidential to the IAB.

Current IETF-Nominated Trustees 

  The current IETF-Appointed ISOC Trustees and their term of
  appointment are:

    Eric Huizer  2002 - 2004 (*) 

    Fred Baker  2002 - 2005 

    Margaret Wasserman  2003 - 2006 

      (*) Current term expires May 2004 

Thanks,

   Geoff Huston
   Executive Director, IAB