Re: [Tools-discuss] Replaced-by inconsistencies

Adam Roach <adam@nostrum.com> Sat, 18 July 2009 22:17 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: tools-discuss@core3.amsl.com
Delivered-To: tools-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C0153A67A1 for <tools-discuss@core3.amsl.com>; Sat, 18 Jul 2009 15:17:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfZpDD2UtoEy for <tools-discuss@core3.amsl.com>; Sat, 18 Jul 2009 15:17:40 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id A1C413A63CB for <tools-discuss@ietf.org>; Sat, 18 Jul 2009 15:17:39 -0700 (PDT)
Received: from hydra-3.local (ppp-70-249-149-101.dsl.rcsntx.swbell.net [70.249.149.101]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n6IMHZEp026766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Jul 2009 17:17:35 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <4A6249FF.6030206@nostrum.com>
Date: Sat, 18 Jul 2009 17:17:35 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: Henrik Levkowetz <henrik@levkowetz.com>
References: <4A61A8D9.5010607@nostrum.com> <4A622A13.4090701@levkowetz.com>
In-Reply-To: <4A622A13.4090701@levkowetz.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 70.249.149.101 is authenticated by a trusted mechanism)
Cc: tools-discuss@ietf.org
Subject: Re: [Tools-discuss] Replaced-by inconsistencies
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Tools Discussion <tools-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tools-discuss>
List-Post: <mailto:tools-discuss@ietf.org>
List-Help: <mailto:tools-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 18 Jul 2009 22:17:41 -0000

Thanks for the explanation! That makes perfect sense. And I'm glad it's 
being fixed.

/a

Henrik Levkowetz wrote:
> Hi Adam,
>
> The explanation is that the generated html files aren't always up-to-date,
> and the reason for that in turn is a bit more complex:  
>
>    1) The load (number of accesses) on the html converted drafts and
>    RFCs is sufficiently high that the 4 servers currently available
>    wouldn't be able to handle it if the html version was dynamically
>    generated in order to be fully up-to-date,
>
>    2) I try to keep the update frequency low, as I don't want search
>    engines to believe that they have to check the whole 65,000+ corpus
>    every day in order to catch changes...
>
> This means that 
>
>    a) I have a very long re-generation period of ~3 months -- unless
>    something about the document state changes, a document is only re-
>    generated if it is older than 3 months.  That re-generation is done
>    mainly to catch updates to the conversion tool, which happens now
>    and then (see http://tools.ietf.org/tools/rfcmarkup/changelog).
>
>    b) In order to catch status changes in documents, an explicit re-
>    generation has to be triggered when something changes which should
>    be reflected in the html document.  Re-generation is now triggered
>    when a new version of a draft appears, when a draft appears in the
>    datatracker, when a document is published as an RFC, and in some
>    other cases.
>
> However, regeneration when new replaced-by information appears has not
> up to now been triggered.  Which I'm now about to fix :-)
>
>
> Best,
>
> 	Henrik
>    
>    
>
> On 2009-07-18 12:50 Adam Roach said the following:
>   
>> It looks to me like the replaced-by information in drafts is being 
>> applied inconsistently.
>>
>> For example, if you look at:
>>
>>   http://tools.ietf.org/html/draft-holmberg-sipping-199-04
>>
>> The "Versions" line reads "00 01 02 03 04 draft-ietf-sip-199", which is 
>> correct -- that is, because draft-ietf-sip-199 replaced 
>> draft-holmberg-sipping-199, it appears after all the versions.
>>
>> If you click on the draft-ietf-sip-199 link, you get taken here:
>>
>>   http://tools.ietf.org/html/draft-ietf-sip-199-08
>>
>> The "Versions" line links back to the draft that it replaced. Great!
>>
>> Now, lets look at:
>>
>>   
>> http://tools.ietf.org/html/draft-ietf-sipcore-presence-scaling-requirements-01
>>
>> It correctly links back to 
>> draft-ietf-sipping-presence-scaling-requirements, which it replaced. So 
>> far, so good. However, if you go to 
>> draft-ietf-sipping-presence-scaling-requirements:
>>
>>   
>> http://tools.ietf.org/html/draft-ietf-sipping-presence-scaling-requirements-03
>>
>> There's no link forward to the sipcore draft! The "Versions" line just 
>> goes up to 03, and stops.
>>
>> Certainly the tools should understand that the "replaces"/"replaced by" 
>> relationship is reciprocal. Is this database corruption, or incomplete 
>> data entry? It doesn't appear to be an isolated incident (cf., 
>> http://tools.ietf.org/html/draft-ietf-sipcore-keep-00) -- I would 
>> propose that an audit of the "replaces"/"replaced by" relationship data 
>> is in order...
>>
>> /a
>>
>> _______________________________________________
>> Tools-discuss mailing list
>> Tools-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/tools-discuss
>>
>>