Re: [iola-conversion-tool] "Intended std level" on Add/Edit screen

Henrik Levkowetz <> Wed, 22 February 2012 14:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5B06D21F8795 for <>; Wed, 22 Feb 2012 06:18:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id C196Cjqp1qy8 for <>; Wed, 22 Feb 2012 06:18:53 -0800 (PST)
Received: from ( [IPv6:2a01:3f0:1:2::30]) by (Postfix) with ESMTP id A43C921F8794 for <>; Wed, 22 Feb 2012 06:18:53 -0800 (PST)
Received: from [2a01:3f0:1:0:21e:c2ff:fe13:7e3e] (port=52764 by with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.77) (envelope-from <>) id 1S0D1k-0004GW-V1; Wed, 22 Feb 2012 15:18:45 +0100
Message-ID: <>
Date: Wed, 22 Feb 2012 15:18:40 +0100
From: Henrik Levkowetz <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Ole Laursen <>
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.3.5
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 2a01:3f0:1:0:21e:c2ff:fe13:7e3e
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on
Cc: Amy Vezza <>, Cindy Morgan <>,
Subject: Re: [iola-conversion-tool] "Intended std level" on Add/Edit screen
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of the IOLA / DB Schema Conversion Tool Project <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Feb 2012 14:18:58 -0000

Hi Cindy, Amy, Ole,

On 2012-02-22 13:55 Ole Laursen said:
> 2012/2/21 Cindy Morgan <>:
>> On the Add/Edit screen (e.g., was the "Intended status" field (in the production version) changed to "Intended std level" for a reason?  Because I read that as "Intended Standard level," but not all I-Ds/RFC are on the standards track.
> Hm, the name of the underlying attribute changed and it appears that
> changed the form, too.
> Regarding the name, I read it as "intended standardization level". The
> reason we're going with it in the database is that "status" is a vague
> word - for a draft/RFC we've consolidated several entities ending up
> with a bunch of different states/statuses so it ends up being
> important that we have descriptive names.
> And it appears we have no good word for standards track maturity level
> + non-standards track maturity levels + BCP, so that's why it ended up
> being standardization level. Does that make sense?
> I can easily change the form back to say intended status, but if you
> think it's okay, I'd prefer if the interface uses the same terminology
> as the database?

As Ole says, since we are moving in the direction of displaying many
different status fields (WG status, IESG status, RFC-Ed status, and
more (including the (Internet Std/Proposed Std/Informational/Experimental/...))
status, we need to be more explicit than saying just "Intended status".

Any appropriately descriptive term for the intended standardization level
is OK, as long as it can be understood and is distinct from all the other
status fields we show ...

Best regards,