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

Sandra Murphy <Sandra.Murphy@sparta.com> Tue, 19 July 2011 21:21 UTC

Return-Path: <Sandra.Murphy@cobham.com>
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 7770F11E8087 for <sidr@ietfa.amsl.com>; Tue, 19 Jul 2011 14:21:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.958
X-Spam-Level:
X-Spam-Status: No, score=-101.958 tagged_above=-999 required=5 tests=[AWL=0.641, BAYES_00=-2.599, 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 zHndl0Zb2d6z for <sidr@ietfa.amsl.com>; Tue, 19 Jul 2011 14:21:03 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8213711E807F for <sidr@ietf.org>; Tue, 19 Jul 2011 14:21:02 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p6JLKdbD016765; Tue, 19 Jul 2011 16:20:39 -0500
Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p6JLKcUZ012357; Tue, 19 Jul 2011 16:20:39 -0500
Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.116]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Jul 2011 17:20:37 -0400
Date: Tue, 19 Jul 2011 17:20:37 -0400
From: Sandra Murphy <Sandra.Murphy@sparta.com>
To: Terry Manderson <terry.manderson@icann.org>
In-Reply-To: <CA4C2E36.17F9E%terry.manderson@icann.org>
Message-ID: <Pine.WNT.4.64.1107191714120.6484@SMURPHY-LT.columbia.ads.sparta.com>
References: <CA4C2E36.17F9E%terry.manderson@icann.org>
X-X-Sender: sandy@mailbin.sparta.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-OriginalArrivalTime: 19 Jul 2011 21:20:37.0623 (UTC) FILETIME=[B433D070:01CC4659]
Cc: Rob Austein <sra@isc.org>, "draft-ietf-sidr-repos-struct@tools.ietf.org" <draft-ietf-sidr-repos-struct@tools.ietf.org>, "sidr@ietf.org" <sidr@ietf.org>, "sidr-chairs@tools.ietf.org" <sidr-chairs@tools.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: Tue, 19 Jul 2011 21:21:03 -0000

On Tue, 19 Jul 2011, Terry Manderson wrote:

> On 20/07/11 1:02 AM, "Sandra Murphy" <Sandra.Murphy@sparta.com> wrote:
>
>>
>> There was a brief discussion of the use of file names extensions when the
>> repos-struct document came up for last call.  See the following messages:
>>
>> http://www.ietf.org/mail-archive/web/sidr/current/msg02281.html
>> http://www.ietf.org/mail-archive/web/sidr/current/msg02282.html
>> http://www.ietf.org/mail-archive/web/sidr/current/msg02283.html
>> http://www.ietf.org/mail-archive/web/sidr/current/msg02284.html
>>
>> To summarize: George Michaelson spoke against extensions when we were
>> considering a registry (and Terry mildly supports them), I asked George if
>
> What I said was "and hint nicely". So happy to see it as the hint. That

That's the "mildly" part.  George was speaking against file extensions at 
all, you said they had "special meaning" and were in favor of a registry.

--Sandy, explaining a former message sent when speaking as wg chair

> hasn't changed, and create a registry if you so desire. I'm still not
> comfortable in leading to a point where it is the
> way (and it seems only way) an objects validation regime is chosen.
>
> 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.
>
> T.
>
>