Re: [sidr] draft-ietf-sidr-repos-struct to Standards Track

Rob Austein <sra@isc.org> Wed, 20 July 2011 16:15 UTC

Return-Path: <sra@hactrn.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F029621F84E8 for <sidr@ietfa.amsl.com>; Wed, 20 Jul 2011 09:15:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.283
X-Spam-Level:
X-Spam-Status: No, score=-100.283 tagged_above=-999 required=5 tests=[AWL=-0.331, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhU0n8R252i3 for <sidr@ietfa.amsl.com>; Wed, 20 Jul 2011 09:15:17 -0700 (PDT)
Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [IPv6:2001:418:1::19]) by ietfa.amsl.com (Postfix) with ESMTP id 44C3E21F84E5 for <sidr@ietf.org>; Wed, 20 Jul 2011 09:15:17 -0700 (PDT)
Received: from minas-ithil.hactrn.net (c-66-30-16-106.hsd1.ma.comcast.net [66.30.16.106]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by adrilankha.hactrn.net (Postfix) with ESMTPS id DE318B86D; Wed, 20 Jul 2011 16:15:15 +0000 (UTC)
Received: from minas-ithil.hactrn.net (localhost [127.0.0.1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 3A5A13431A2; Wed, 20 Jul 2011 12:15:15 -0400 (EDT)
Date: Wed, 20 Jul 2011 12:15:15 -0400
From: Rob Austein <sra@isc.org>
To: Terry Manderson <terry.manderson@icann.org>
In-Reply-To: <CA4C2E36.17F9E%terry.manderson@icann.org>
References: <Pine.WNT.4.64.1107191043540.6484@SMURPHY-LT.columbia.ads.sparta.com> <CA4C2E36.17F9E%terry.manderson@icann.org>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20110720161515.3A5A13431A2@minas-ithil.hactrn.net>
Cc: draft-ietf-sidr-repos-struct@tools.ietf.org, sidr-chairs@tools.ietf.org, sidr@ietf.org
Subject: Re: [sidr] draft-ietf-sidr-repos-struct to Standards Track
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jul 2011 16:15:18 -0000

At Tue, 19 Jul 2011 14:03:18 -0700, Terry Manderson wrote:
> 
> Rob's observation that the extension exists in the manifest file name is a
> close approximation provided words exist as highlighted which gives clear
> instruction to implementers as to
> 1) make the first approximation of validation regime on the filename in the
> _manifest_
> 2) then try all others
> 3) give up.

Sorry, wrong.  Attempt validation based on the filename type; if that
fails, the object is toast regardless of whether the filename appears
in the manifest or not.  Don't expect the RP to play guessing games.