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

Carl Malamud <carl@media.org> Sat, 11 September 2004 20:58 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 QAA10016; Sat, 11 Sep 2004 16:58:06 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6F14-0007Vf-80; Sat, 11 Sep 2004 17:02:38 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6EuJ-000572-M2; Sat, 11 Sep 2004 16:55:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6Eor-0003ad-M0 for ietf@megatron.ietf.org; Sat, 11 Sep 2004 16:50:01 -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 QAA09689 for <ietf@ietf.org>; Sat, 11 Sep 2004 16:49:59 -0400 (EDT)
Received: from bulk.resource.org ([192.101.98.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6EtA-0007LR-4u for ietf@ietf.org; Sat, 11 Sep 2004 16:54:31 -0400
Received: from bulk.resource.org (localhost.resource.org [127.0.0.1]) by bulk.resource.org (8.12.2/8.12.2) with ESMTP id i8BKmm6Y013592; Sat, 11 Sep 2004 13:48:48 -0700 (PDT)
Received: (from carl@localhost) by bulk.resource.org (8.12.2/8.12.2/Submit) id i8BKmm6r013591; Sat, 11 Sep 2004 13:48:48 -0700 (PDT)
From: Carl Malamud <carl@media.org>
Message-Id: <200409112048.i8BKmm6r013591@bulk.resource.org>
In-Reply-To: <Pine.HPX.4.58.0409111311540.20199@wells.cisco.com>
To: Ole Jacobsen <ole@cisco.com>
Date: Sat, 11 Sep 2004 13:48:48 -0700
Organization: Memory Palace Press
X-Winch: Warn 9.5i
X-Mailer: ELM [version 2.4ME+ PL94 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Content-Transfer-Encoding: 7bit
Cc: scott bradner <sob@harvard.edu>, ietf@ietf.org
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: 4b800b1eab964a31702fa68f1ff0e955
Content-Transfer-Encoding: 7bit

Ole -

I agree that the IETF has a special responsibility to properly present
the archive ... we can't simply lay a big ftp directory out there and
make no efforts to show how a particular file fits in context.

On the other hand, ietf.org could certainly beg/borrow/steal some of 
the work being done in places like potaroo.net and watersprings.org.  
Some things that could be done include:

1. Add some clear text that explains the role of the i-d historical
repository

2. Link to previous and future versions of a draft (including any resulting 
RFC)

3. Link to any relevant mailing list discussions

4. Find related drafts or place the draft in the context of a working group

5. Add a very clear indication that the particular document in question is
"Expired"

As to citing work-in-progress instead of the final standard, well, hmmm ...
if we don't have our own repository, there isn't much we can do.  On the
other hand, if a customer/reader/journalist were able to go to ietf.org
and pull up the document in question, perhaps it could be really clear
what the status is?  If we want to make clear that a document is expired,
it is much better to say so rather than pretend it doesn't exist.

Regards,

Carl

> 
> - Vendors are "stupid" and will claim compliance with a work-in-progress
>   document instead of a final standard. This is "very bad"
> 
> - Drafts often change along the way (including being completely discarded
>   as "bad ideas") and we should discard such snapshots in case someone
>   gets the wrong idea from reading one.
> 
> Needless to say, I don't really buy these arguments. As someone who
> publishes articles where the only existing reference might be an ID at
> the time of writing, I believe there are better mechanisms we could
> use (as we do with RFCs and the "Obsoletes/Obsoleted by" tags).
> 
> Ole
> 
> 
> 
> Ole J. Jacobsen
> Editor and Publisher,  The Internet Protocol Journal
> Academic Research and Technology Initiatives, Cisco Systems
> Tel: +1 408-527-8972   GSM: +1 415-370-4628
> E-mail: ole@cisco.com  URL: http://www.cisco.com/ipj
> 
> 
> 
> 
> _______________________________________________
> 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