Re: [I18nrp] Additional input needed for i18nRP BOF

John C Klensin <john-ietf@jck.com> Wed, 06 June 2018 20:58 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: i18nrp@ietfa.amsl.com
Delivered-To: i18nrp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48715130DD6 for <i18nrp@ietfa.amsl.com>; Wed, 6 Jun 2018 13:58:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHrIesw68qYn for <i18nrp@ietfa.amsl.com>; Wed, 6 Jun 2018 13:58:34 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 866F2130DD1 for <i18nrp@ietf.org>; Wed, 6 Jun 2018 13:58:34 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1fQfVp-000C9W-4g; Wed, 06 Jun 2018 16:58:33 -0400
Date: Wed, 06 Jun 2018 16:58:26 -0400
From: John C Klensin <john-ietf@jck.com>
To: Adam Roach <adam@nostrum.com>, i18nrp@ietf.org
Message-ID: <4DA478C4C99396556E1B3EF1@PSB>
In-Reply-To: <9ecf8b7a-d086-1c56-03fb-6773aed332c6@nostrum.com>
References: <f997170c-3062-0241-e58d-7a3415fba983@nostrum.com> <CE6F76BB323F1555D6B217A5@PSB> <9ecf8b7a-d086-1c56-03fb-6773aed332c6@nostrum.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18nrp/UEGY_HRpdJSJ-8a0Mp3gI3S3jZw>
Subject: Re: [I18nrp] Additional input needed for i18nRP BOF
X-BeenThere: i18nrp@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Internationalization Review Procedures <i18nrp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i18nrp>, <mailto:i18nrp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i18nrp/>
List-Post: <mailto:i18nrp@ietf.org>
List-Help: <mailto:i18nrp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i18nrp>, <mailto:i18nrp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jun 2018 20:58:39 -0000

Adam,

Understood and appreciated.

I will try to generate a scenario or two and post them within
the next week, but don't want to make promises.   Others should
post their own ideas.  

To put one stake in the ground I believe is logically necessary,
one of those scenarios is that the IETF formally goes out of the
i18n business.  That includes not only not processing the
documents we have not been processing, including not processing
IDNA or PRECIS updates, but not processing (or even chartering
or continuing WGs to produce) any protocol spec that requires
internationalization provisions (including but not limited to
non-ASCII characters) that cannot be satisfied by simple "do
what it says there" references to existing specs like IDNA2008
or PRECIS.  Even that exception is questionable if some
mechanism is needed to look at new versions of Unicode and we
don't have a working one of those.

That is fairly close to reductio ad absurdum and I hope no one
will actually support it.  On the other hand, it could be close
to where we end up if specification authors (or WGs) identify
internationalization considerations or the human rights effort
identifies internationalization requirements and an effort is
organized to appeal the announcement of an IETF Last Call on any
specification with those considerations on the grounds that the
IETF has no mechanism to competently review it.

Brian's suggestion is more realistic and I hope more palatable
but my personal view is that, without significantly more details
and framework, such a Directorate would turn into another
example of something we've tried before and that has failed.

I think there are other options, but those two should be
sufficient to start at least a semi-focused discussion.

   john

--On Wednesday, June 6, 2018 13:23 -0500 Adam Roach
<adam@nostrum.com> wrote:

> On 6/6/18 8:58 AM, John C Klensin wrote:
>> I had hoped to see an open discussion in the weeks between now
>> and the start of the IETF meeting but, while I have some
>> ideas, the absence of specific proposals in the BOF proposal
>> was deliberate.
> 
> 
> I'd like to add two points of clarification, to make sure
> we're not talking past each other.
> 
>  1. This is not a request to revise the BOF request itself. We
> are
>     looking for concrete process proposals within the next
> week on this
>     mailing list.
> 
>  2. The proposals that are developed within the next week do
> not
>     necessarily need to be those that are presented in
> Montreal. We are
>     looking for a guarantee that there will be at least one
> concrete
>     proposal going into the BOF. If a more preferred idea is
> proposed
>     between next Wednesday and the meeting, it could be used
> as the
>     basis for conversation instead of the initial proposals.
> 
> Thanks.
> 
> /a
>