Subject: RE: [newtrk] Re: Question about Obsoleted vs. Historic

From: <[email-masked]>
Date: Tue, 12 Jul 2005 09:02:19 +0300

Brian,

> Sure, but the logic is nevertheless a bit contorted - but rather than
> debating what the current system *means* could be concentrate
> on what we should do in future?
> 
> Incidentally 3596 (a DS) obsoletes 3152 (a BCP). That's unusual,
> but it isn't illogical. However, 3152 isn't shown as Obsolete
> in http://www.rfc-editor.org/rfcxx00.html#BCPbyBCP.
> 
>      Brian
> 
> Eliot Lear wrote:
> > I would point out that it is historically useful to be able to track
> > changes between draft and full or proposed and draft and we don't list
> > status information in the RFCs...

What I would like is that the RFC Index would accurately convey the current
status of any RFC.  So, if I needed to check the status of a protocol which
I am not intimately familiar with, I would not need to subscribe to a WG
mailing list or ask an IESG/IAB/WG chair to interpret the RFC List for me.

Its past the new draft cut-off, but if the RFC Editor was willing & a Tools
Team member was willing (& at least a few people thought it was useful) perhaps
we (together) could mock-up an improved RFC Index.

John

.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Larry Masinter <[email-masked]>
Date: Mon, 11 Jul 2005 23:28:11 -0700

> we (together) could mock-up an improved RFC Index.

I think the path we've taken in the "tools team" is to write up
what we think the requirements are for new tools, and then leave
the details of the design to the implementation team.

Perhaps we can find some time during the IETF meeting to talk
about requirements for an RFC index? A mockup is of course
a useful thing to have, too, but writing down the goals will
help establish what parts of the mock-up are essential.

Personally, I think that what most non-IETFers want from
knowing "standards status" is "what do I have to implement
to be interoperable with most other systems". 
That's why I've suggested that implementation reports be
an important part of the "RFC status tool".

I haven't gotten much positive feedback on this from "newtrk",
though, so perhaps others disagree that this is important
or useful information to maintain?

Larry
-- 
http://larry.masinter.net

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 12 Jul 2005 03:40:33 -0500

Dear Larry,

> to be interoperable with most other systems".

Yeah, I think this is the problem *I've* been trying to solve with 
ISDs (YMMV)...

> or useful information to maintain?

Fair enough - I thought about your earlier posting when I saw it, but 
didn't respond (do I EVER do that? well, at least once this year):

> One of the basic reasons why RFCs should be considered
> together in a relationship is because they tend to occur
> in the same IMPLEMENTATION.
>
> So, consider the possibility of building up the relationship
> of RFCs through IMPLEMENTATION/INTEROPERABILITY reports.

It's not that I DISAGREE, it's that I'm having a difficult time 
visualizing where one "implementation" stops and the next one starts. 
My impression is that, especially in APPS (where I note that I haven't 
worked seriously in several years), "implementations" turn into larger 
and larger lumps every year, but not all of the functionality is 
present in all parts of the "implementation", so that saying 
"somewhere in the code I shipped, there is software that implements 
IPv6 literal addresses in URLs" (say) may not tell you very much about 
how many mail implementations support them, vs. how many browsers, vs. 
how many other things.

(And maybe this example sucks, but it's very vaguely what I'm thinking 
about)

If this wasn't what you were talking about, I apologize for my 
confusion. But that's why I didn't respond previously.

Thanks,

Spencer

.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Jul 2005 14:56:18 +0200

(ietf list deleted)

> we (together) could mock-up an improved RFC Index.

Can't be done until this WG gets its act together about whether STD means
anything and whether a new PS really supersedes an ancient S. Example:

0822 Standard for the format of ARPA Internet text messages. D.
      Crocker. Aug-13-1982. (Format: TXT=109200 bytes) (Obsoletes RFC0733)
      (Obsoleted by RFC2822) (Updated by RFC1123, RFC1138, RFC1148,
      RFC1327, RFC2156) (Also STD0011) (Status: STANDARD)

This is *accurate* and accurately reflects the confusion in our process.
It is simultaneously a Standard and obsoleted by a PS. Go figure :-)

     Brian

.

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 12 Jul 2005 08:38:54 -0700 (PDT)

On Tue, 12 Jul 2005, Brian E Carpenter wrote:
> > Its past the new draft cut-off, but if the RFC Editor was
> > willing & a Tools Team member was willing (& at least a few
> > people thought it was useful) perhaps we (together) could
> > mock-up an improved RFC Index.
> 
> Can't be done until this WG gets its act together about whether
> STD means anything and whether a new PS really supersedes an
> ancient S. Example:
> 
> This is *accurate* and accurately reflects the confusion in our
> process. It is simultaneously a Standard and obsoleted by a PS.
> Go figure :-)

Yet another reason to adopt a one-step standards process!

//cmh

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 13 Jul 2005 10:19:04 -0500

Well, since you asked...

> Yet another reason to adopt a one-step standards process!

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

Title : A Single-Stage Standards Process
Author(s) : J. Loughney, S. Dawkins
Filename : draft-loughney-newtrk-one-size-fits-all-00.txt
Pages : 8
Date : 2005-7-13

   This document proposes several changes of principle to the Internet
   standards process, specifically a reduction from three stages to a
   single stage in the standards track.  This does not effect the
   Informational, Experimental or BCP designations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-loughney-newtrk-one-size-fits-all-00.txt

.