Possible OBF question -- I18n

John C Klensin <john-ietf@jck.com> Wed, 30 May 2018 19:55 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F1212E867 for <ietf@ietfa.amsl.com>; Wed, 30 May 2018 12:55:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 bKUGxkqs3t-M for <ietf@ietfa.amsl.com>; Wed, 30 May 2018 12:55:34 -0700 (PDT)
Received: from bsa2.jck.com (ns.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 CA79012E049 for <ietf@ietf.org>; Wed, 30 May 2018 12:55:33 -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 1fO7Bz-000BWn-BP for ietf@ietf.org; Wed, 30 May 2018 15:55:31 -0400
Date: Wed, 30 May 2018 15:55:24 -0400
From: John C Klensin <john-ietf@jck.com>
To: ietf@ietf.org
Subject: Possible OBF question -- I18n
Message-ID: <E36B38780163C3883E69656A@PSB>
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/ietf/9hVRwEmChQrVlO49vBsc5XCM6c8>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 May 2018 19:55:36 -0000

Hi.

I want to share a question and possible an idea and see if it
gets any traction before Thursday's BOF application cutoff.

Many people seem to think that what has come to be called
"internationalization" ("i18n") of the Internet is important,
both to serving existing users for whom English may not be a
comfortable language or Lain script a comfortable writing system
and to making the Internet accessible to much larger populations
("the next billion").   Some of the issues are related to
identifiers, with examples including IDNA, IRIs, PRECIS, and the
recent work on non-ASCII identifiers in certificates.  Others
are more connected to actual protocol design, such as the
SMTPUTF8 work in the EAI WG.   Still others are related to
content, language selection ins various applications, and so on.


I think there is general recognition that the problems are
difficult.  Human languages have evolved, and evolved
differently, over more centuries than anyone can count, making
extrapolations from one language or writing system to another
difficult and error-prone.  Conventions that evolved to permit
use of typewriters (with mechanically-limited numbers of keys)
with writing systems with more than that many characters haunt
contemporary comparison and matching issues.  Even changes as
recent as the divergence of American from British English,
French as spoken and written in France from French as used in
Quebec, and efforts to simplify the representations of a few
thousand commonly-used Chinese characters can pose serious
problems for computer system designers and implementers who just
want do do something quick, obvious, and straightforward but
still correct (or at least acceptable enough to not be
culturally insulting).

At the same time, the IETF has a problem with expertise, real
energy, and support for internationalization work.  The last WGs
directly focused on the issues have essentially run out of
steam, with a very small number of participants able and willing
to do late-stage analysis and reviews.  Other WGs whose work has
involved important I18n issues have recognized that they don't
have the needed expertise and had some trouble recruiting it or,
when we are less lucky, have not recognized the problem.  The
latter poses a special challenge because, if the work is
specialized, there may be little or no review of the I18n impact
during IETF Last Call unless someone happens to notice, a
sitaution that might pose a real threat to interoperability when
the protocols are actually used.

In addition, pressing problems do show up about which decisions
need to be made if the IETF is going to fulfill its
responsibilities in this area and, because of concerns about
reviews (and probably more), it seems impossible to process work
that is necessarily standards track without a WG and impossible
to create a WG given the absence of manifestations of broad
interest and knowledge and the history, mentioned above, of WGs
running out of steam.

It also probably doesn't help that several of the acknowledged
experts and critically interested parties have little or no
reliable support for attending IETF meetings so, if a group is
to be judged by counting the number of people in the room for a
discussion, it is easy to conclude that there is less interest
than might actually exist.

Some of us have been waiting for the IESG and/or IAB to sort the
situation out and tell us what to do.  That hasn't happened,
possibly because flying pigs are in short supply but more likely
because they understand the problems and don't have any
solutions either.  The IAB's concluding almost a year ago that
its I18n Program was unsustainable and closing it was probably a
benchmark, especially when one notices that no substitute has
emerged, but, even had that not happened, an IAB Program can't
process standards track documents under our current rules (or
any rules I see anyone rushing to propose).

So I'm wondering whether there is sufficient interest to hold a
BOF to discuss how to deal with this situation.   I don't want
to get into the many substantive issues that have been hanging
around, but rather to address the question of how, if there were
drafts, what the review and approval process should be in an
IETF where there will probably never be a huge number of experts
around with time on their hands.  Could we devise something
Directorate-like or even Area-like?  Could that group be counted
on for substantive/ technical reviews to the extent to which,
even if no other reviews addressed the substantive subject
matter and no one on the IESG had special expertise, they could
be approved anyway?  Should we be reaching out to other groups
with general internationalization expertise (not just, or a
focus on, character coding) to see if we would work out joint
review efforts or even if we could comfortably export the topic?
Or have we actually come to the conclusion that the IETF had
best stop claiming any responsibility or authority in this area
and that we are willing to let whatever emerges fill the vacuum?

If this sounds useful and you have anything to contribute,
especially procedural or "where do we find the experts" advice,
please speak up within the next 24-48 hours.  IMO, if we should
give give up, I think it would be better to do that as the
result of a formal discussion than as a decision of a handful of
people meeting more or less in private and without an explicit
opportunity for community input.  

    john

p.s. before someone asks, I'm thinking actual BOF because don't
think there is any point in this unless it has someone from the
IESG willing to take at least some responsibility, produces
minutes, has meetecho coverage, etc.   I don't think dancing
around with Bar BOFs, non-bar Bar BOFs, informal meetings, etc.,
meet those criteria.  I don't thing a presentation in an area
meeting or two would do it either -- we've tried that with no
success and, more important, I'm seeing an increasing number of
WGs being created with i18n implications or necessary
involvement that are not in the ART area.