Re: [EAI] State of the core documents

Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com> Tue, 25 October 2011 09:08 UTC

Return-Path: <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C6F21F8BAC for <ima@ietfa.amsl.com>; Tue, 25 Oct 2011 02:08:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.792
X-Spam-Level:
X-Spam-Status: No, score=-102.792 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 RVSyafhEptF5 for <ima@ietfa.amsl.com>; Tue, 25 Oct 2011 02:08:13 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B0AEC21F8BA7 for <ima@ietf.org>; Tue, 25 Oct 2011 02:08:12 -0700 (PDT)
Received: by wyh22 with SMTP id 22so322379wyh.31 for <ima@ietf.org>; Tue, 25 Oct 2011 02:08:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Naq2TCAkT7hVPnWnQwpDVA8bGSE9KZmMLNE9AmIbuB4=; b=iGodR/XnQKs58GQI/GUWpU6ODtDC0Nkn53CL6JvzMkMF8EeQ+3TcpEZXkFNqQA1jsy LVWWg4Bk0q6yB8WaxVbNvcctpAeC45Jym2ebkNFyqeutoeyDregv1i2BB+sxJUSj0JCM 9qS8+Czmt0LdfWl1k/0EcFO0U/mhAsUMi4bh4=
Received: by 10.216.221.157 with SMTP id r29mr4716095wep.66.1319533565099; Tue, 25 Oct 2011 02:06:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.80.134 with HTTP; Tue, 25 Oct 2011 02:05:24 -0700 (PDT)
In-Reply-To: <6176C39A9E52DA71C816F24B@PST.JCK.COM>
References: <6176C39A9E52DA71C816F24B@PST.JCK.COM>
From: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>
Date: Tue, 25 Oct 2011 11:05:24 +0200
Message-ID: <CAHhFybpfX5VYtnBtrmAEecRZ2RnQWfaTtfH=S=TCbc4a3H9wmw@mail.gmail.com>
To: John C Klensin <klensin@jck.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Joseph Yee <jyee@ca.afilias.info>, ima@ietf.org
Subject: Re: [EAI] State of the core documents
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Oct 2011 09:08:13 -0000

On 24 October 2011 21:22, John C Klensin wrote:

> (2) We failed to say explicitly that the new
> documents should cause the experimental ones to
> be reclassified as Historic.

The IESG ION^D^D^Dhow-to is very new; no one could
foresee that "obsoletes" is not more good enough.
If a PS obsoletes an experiment I'd consider the
experiment as implicitly finished.  If that SHOULD
be now done explicitly it's also fine, but in that
case I'd also like to see this SHOULD in an RFC,
not only in a "how-to".   As it happens I stumbled
over the link in a "daily dose" just this morning,
but missed that it's related to the EAI Last Call.

> given the nature of the experimental specs and the
> care we have taken to make sure that implementations
> of them cannot interfere with the final versions, it
> really doesn't make a lot of difference, at least
> IMO.

If "historic" offers you the opportunity to recycle
the term UTF8SMTP instead of UTF8SMTPBIS I'd like it.

> I'm quite sure that, if they start editing, they
> will find the references and everything will go into
> "Missref hold".  That, from my point of view, would
> be a disaster.

Maybe you could replace the "missrefs" by vague words
in AUTH84, e.g., instead of "<I-D.POP-EAI>" how about
"a successor of <RFC.POP.EAI.experimental>"?

> We reopen 4952bis to eliminate the normative
> dependences on documents that aren't finished (or
> written), clean up the change descriptions a bit,
> and update references before someone whines about
> those.

That sounds slightly more convoluted than my idea...

What's wrong with the (approved) status of 4952bis,
why do you think it needs to be on standards track?

Just in case, I'm not against a status change, but I
don't see the purpose yet, it sounds like more work
than necessary.  (((If I could pick a -bis where you
spend your time it would start with 5..., not 4...)))

> And, please, in the interest of WG progress, please
> do not use this as an excuse to revisit old issues:

Apropos, I liked the "duck or grouse" in the shepherd
summary.  And (ab)used it as an excuse for posting no
additional comment about said "old issues" in the LC.

-Frank