RE: archives (was The other parts of the report....

"Steve Crocker" <steve@stevecrocker.com> Tue, 14 September 2004 16:02 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20659; Tue, 14 Sep 2004 12:02:15 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7Fpz-0000rH-K2; Tue, 14 Sep 2004 12:07:23 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7FYL-00050q-1f; Tue, 14 Sep 2004 11:49:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7FVH-0004MF-J9 for ietf@megatron.ietf.org; Tue, 14 Sep 2004 11:45:59 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19445 for <ietf@ietf.org>; Tue, 14 Sep 2004 11:45:57 -0400 (EDT)
Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7FaD-0000VH-5m for ietf@ietf.org; Tue, 14 Sep 2004 11:51:05 -0400
Received: from [66.93.106.226] (HELO SCROCKER) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7569086; Tue, 14 Sep 2004 11:45:17 -0400
From: Steve Crocker <steve@stevecrocker.com>
To: erosen@cisco.com, ietf@ietf.org
Date: Tue, 14 Sep 2004 11:45:52 -0400
Message-ID: <005701c49a71$eadcfe30$6a147e41@SCROCKER>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-reply-to: <200409141449.i8EEnJH7015772@rtp-core-2.cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2742.200
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Content-Transfer-Encoding: 7bit
Subject: RE: archives (was The other parts of the report....
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Content-Transfer-Encoding: 7bit

Eric, you specified exactly the right answer:

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

This is very feasible and should be done.

Steve

> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On 
> Behalf Of Eric Rosen
> Sent: Tuesday, September 14, 2004 10:49 AM
> To: ietf@ietf.org
> Subject: Re: archives (was The other parts of the report.... 
> 
> 
> 
> 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
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf