[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnu-arch-users] address@hidden: Re: archives (was The other parts of th

From: Tom Lord
Subject: [Gnu-arch-users] address@hidden: Re: archives (was The other parts of the report....]
Date: Tue, 14 Sep 2004 16:55:14 -0700 (PDT)

No, I'm not kidding.   We collectively have something to offer here
and I certainly don't have time to pounce on this.   Are there no IETF
fanpersons on the list besides me?

IETF, in it's proud tradition, should bootstrap archival work by
layering on simple standards (e.g., tar, diff, patch, ftp, etc.) 

In other words, a (high quality) "<Ahem><cough><cough>" from the arch
community would not be inappropriate here.   Preferably, multiply

(This particular forwarded message is wrangling with namespace,
ancestry, and cataloging issues.)


------- Start of forwarded message -------
Subject: Re: archives (was The other parts of the report....
X-42-Pre-Check: Attempted
X-BrightmailFiltered: true
To: address@hidden
In-reply-to: Your message of Mon, 13 Sep 2004 15:02:44 -0700.
User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3
        (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3
        (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 14 Sep 2004 10:49:19 -0400
From: Eric Rosen <address@hidden>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Subject: Re: archives (was The other parts of the report.... 
X-BeenThere: address@hidden
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: address@hidden
List-Id: IETF-Discussion <>
List-Unsubscribe: <>,
List-Post: <mailto:address@hidden>
List-Help: <mailto:address@hidden>
List-Subscribe: <>,
Sender: address@hidden
X-Spam-Checker-Version: SpamAssassin 2.64-42mail (2004-01-11) on
X-Spam-DCC: SdV: mail 1179; Body=2 Fuz1=2 Fuz2=2
X-Spam-Status: No, hits=-4.9 required=4.5 tests=BAYES_00 autolearn=ham 
X-42email-MailScanner-Information: Please contact for more information.
X-42email-MailScanner: Found to be clean
X-UIDL: 529a206cf6470692047fdeceb94eb194

I've never  thought that  the IETF  was OBLIGATED to  "hide" old  I-Ds; that
seems a rather far-fetched interpretation of anything in RFC 2026. 

However, I think  there is a real practical problem in  making the old i-d's
be too  readily available.   I frequently get  messages asking  me questions
like "where  is draft-rosen-something-or-other-04.txt,  I can't find  it" to
which the answer is one of the following:

a. you want draft-rosen-something-or-other-23.txt, or

b. you want draft-ietf-somewg-something-or-other-05.txt, or

c. you want RFC 12345. 

What's happened is  that they have found some email  which references a long
outdated draft, and have no clue  how to get to the most up-to-date version,
which is what they really want to see. 

If we make it  too easy to access the old drafts, a  lot of people will just
get the old drafts instead of being forced to look for the more recent work.

Sure, people  who really want to  see the old  drafts should be able  to get
them,  but  people who  really  want to  see  the  most up-to-date  versions
shouldn't get the old drafts just because they only know an old draft name.

In a perfect system, someone would go to the IETF's official I-D page, enter
a draft name,  and get a prominent pointer to the  most recent version (even
if it  is now an RFC  or a draft with  a different name), along  with a less
prominent pointer to the thing they actually asked for. 

If  that can't  be  done, it  might be  better  to keep  the expired  drafts
"officially  hidden".   Not  for  the   reasons  being  given  by  our  more
academically inclined  colleagues, but  for the practical  reasons described
above.  Sure, the expired drafts might be obtainable via Google, but getting
something from  Google is  a bit  different than getting  it via  the IETF's
official web page. 

Ietf mailing list
------- End of forwarded message -------

reply via email to

[Prev in Thread] Current Thread [Next in Thread]