Re: [iola-conversion-tool] Incorrect time stamps in the History trail for recently-published RFCs

Ole Laursen <olau@iola.dk> Mon, 05 March 2012 14:50 UTC

Return-Path: <olau@iola.dk>
X-Original-To: iola-conversion-tool@ietfa.amsl.com
Delivered-To: iola-conversion-tool@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC7021F852D for <iola-conversion-tool@ietfa.amsl.com>; Mon, 5 Mar 2012 06:50:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.822
X-Spam-Level:
X-Spam-Status: No, score=-2.822 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjIJiRd6LjB6 for <iola-conversion-tool@ietfa.amsl.com>; Mon, 5 Mar 2012 06:50:21 -0800 (PST)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BECD521F8638 for <iola-conversion-tool@ietf.org>; Mon, 5 Mar 2012 06:50:03 -0800 (PST)
Received: by vbbez10 with SMTP id ez10so3955633vbb.31 for <iola-conversion-tool@ietf.org>; Mon, 05 Mar 2012 06:50:03 -0800 (PST)
Received-SPF: pass (google.com: domain of olau@iola.dk designates 10.52.92.18 as permitted sender) client-ip=10.52.92.18;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of olau@iola.dk designates 10.52.92.18 as permitted sender) smtp.mail=olau@iola.dk
Received: from mr.google.com ([10.52.92.18]) by 10.52.92.18 with SMTP id ci18mr36594733vdb.73.1330959003320 (num_hops = 1); Mon, 05 Mar 2012 06:50:03 -0800 (PST)
Received: by 10.52.92.18 with SMTP id ci18mr31284100vdb.73.1330959003141; Mon, 05 Mar 2012 06:50:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.156.18 with HTTP; Mon, 5 Mar 2012 06:49:43 -0800 (PST)
In-Reply-To: <86AF53FB-F163-4D61-AD50-34264C62CB0E@vigilsec.com>
References: <93C55C1D-6DA3-4446-998F-8C5A72824938@amsl.com> <CANb2OvJyCJM+0oPr8ATBuu6NWCakCyX+pficrhbS7Bk3gxyT5g@mail.gmail.com> <CANb2OvLguHFgVqoG_1D9gGNuVa66HqC_gHAPE8nVLiCgLQNv_A@mail.gmail.com> <1D6BB920-AF31-458F-8BCA-0BA50D20EEF0@vigilsec.com> <CANb2OvL5dgcQGeJEj0=tLVQMH+qPpkjp6gG=0ZD-Lwd-eyriBQ@mail.gmail.com> <86AF53FB-F163-4D61-AD50-34264C62CB0E@vigilsec.com>
From: Ole Laursen <olau@iola.dk>
Date: Mon, 5 Mar 2012 15:49:43 +0100
Message-ID: <CANb2OvK+V+_7Zbesoh-ct1ocQEX6WzpP3kT5aVG8GLO9LcNM_Q@mail.gmail.com>
To: Russ Housley <housley@vigilsec.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkGITOSw9evDDGwmGK53OxbzA3fU1eEuT/BCFmrmq9VeVl3uvlI+CJo3LLPmUkJn1uPn38O
Cc: iola-conversion-tool@ietf.org
Subject: Re: [iola-conversion-tool] Incorrect time stamps in the History trail for recently-published RFCs
X-BeenThere: iola-conversion-tool@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of the IOLA / DB Schema Conversion Tool Project <iola-conversion-tool.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iola-conversion-tool>, <mailto:iola-conversion-tool-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/iola-conversion-tool>
List-Post: <mailto:iola-conversion-tool@ietf.org>
List-Help: <mailto:iola-conversion-tool-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iola-conversion-tool>, <mailto:iola-conversion-tool-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Mar 2012 14:50:22 -0000

2012/3/5 Russ Housley <housley@vigilsec.com>om>:
>> Then it's a <1 hour job to fix it in the Datatracker end. The XML file
>> already says
>>
>>        <date>
>>            <month>March</month>
>>            <year>2011</year>
>>        </date>
>>
>> so a <day>29</day> would fit the purpose nicely. Would it be feasible
>> to do this in a not too distant timeframe?
>
> This data has never included the day.  I think we need to use the messages that are sent to the secretariat to get the day.

Hm, right, I was just wondering who's going to collect the information
in the future.

If there's a database at the RFC Editor's, then it may be easier to
put the information there, even if it requires someone to write an
importer to scan through all the messages (we could scan them and
provide a tab-separated file for the initial import).

But if that's never going to happen and the Datatracker database will
be the main source for this information, then I need to start thinking
about what the script we're currently using should do.


Ole