[I18nrp] draft-faltstrom-unicode11-04.txt
"Patrik Fältström " <paf@frobbit.se> Sun, 07 October 2018 05:53 UTC
Return-Path: <paf@frobbit.se>
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 819E6129AB8
for <i18nrp@ietfa.amsl.com>; Sat, 6 Oct 2018 22:53:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.722
X-Spam-Level:
X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_LOW=-0.7,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key)
header.d=frobbit.se
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 sB_wcNBYGGYB for <i18nrp@ietfa.amsl.com>;
Sat, 6 Oct 2018 22:53:55 -0700 (PDT)
Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id 5E7C3129C6A
for <i18nrp@ietf.org>; Sat, 6 Oct 2018 22:53:55 -0700 (PDT)
Received: from [192.165.72.241] (unknown [192.165.72.241])
by mail.frobbit.se (Postfix) with ESMTPSA id 60BAE1FE41;
Sun, 7 Oct 2018 07:53:52 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=frobbit.se; s=mail;
t=1538891632; bh=vstNwLSbv0bPUOjp8z3H9CgacYRQp8qsh5ef3Nb69Mg=;
h=From:To:Subject:Date:From;
b=S+uX8QpezfaFUZUugHcdvUTQxvJTE2t6ZOTG2bh1mFsDQxEhmSh8m8ZCPETSneUsx
neTTEG8qMLoD1wr7r1/96hODXOjwWDk7fvUxrVt7QeDnfkRsw2OVkTUjbuQt5hw8CQ
wyAbG3KK63hnxHSnNcaQWwk75fRs5qqZhbiX2jrs=
From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" <paf@frobbit.se>
To: i18nrp@ietf.org, iab@iab.org
Date: Sun, 07 Oct 2018 07:53:51 +0200
X-Mailer: MailMate (1.12r5533)
Message-ID: <A23EC543-5DEB-4044-96B7-C983A1BF1E23@frobbit.se>
MIME-Version: 1.0
Content-Type: multipart/signed;
boundary="=_MailMate_459B7FC1-117D-4F45-A94F-ACBD7CE2B7C4_=";
micalg=pgp-sha1; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18nrp/YWD9YqJ2PGR_mULiCZiKS6_l7qw>
Subject: [I18nrp] draft-faltstrom-unicode11-04.txt
X-BeenThere: i18nrp@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 07 Oct 2018 05:53:57 -0000
All, Version -04 of this draft was just posted. Background: As we all know IDNA2008 is an algorithm that applied to Unicode gives a subset of code points which are permissible for in turn registries and others to create subsets from to be used in their respective policies. Being the appointed expert for the IANA registry I have flagged for IAB changes made to Unicode that I feel must be discussed in IETF, and here is the document with my proposal (details are in the draft). In short the draft proposes (just like RFC 6452) IETF continue to follow Unicode Standard without adding exceptions to the IDNA2008 algorithm, EVEN IF changes are made that are incompatible to earlier versions of Unicode. The choices for IETF when things like this happens are: 1. Keep IDNA2008 with no exceptions 2. Keep IDNA2008 with exceptions 3. Stop referring (directly) to Unicode as it is not stable enough Probably more choices than these... My proposal is [1], together with a more forceful push to strict IDNA2008 adoption. No IDNA2003, no UTS#46, no homebrew mixes. Including that registries really do a careful conservative selection of code points to be used in whatever context it is to be used. The problem though is that this is *my* view. Sure, a few others have randomly and "by pure luck" told me "this is ok". But is this a stable informed decision by IETF? This very fast turn into a process issue where IAB have asked for progress, and IETF is to deliver. And this is where I take a step back, and want IESG and IAB to make up their mind. This group was created for I18N issues, we have a charter, but then what? Is this where drafts like these should be discussed? Maybe... Patrik
- [I18nrp] draft-faltstrom-unicode11-04.txt Patrik Fältström
- Re: [I18nrp] draft-faltstrom-unicode11-04.txt Asmus Freytag
- Re: [I18nrp] draft-faltstrom-unicode11-04.txt Peter Saint-Andre
- Re: [I18nrp] draft-faltstrom-unicode11-04.txt Hollenbeck, Scott
- Re: [I18nrp] draft-faltstrom-unicode11-04.txt Nico Williams
- Re: [I18nrp] draft-faltstrom-unicode11-04.txt Patrik Fältström
- Re: [I18nrp] draft-faltstrom-unicode11-04.txt Asmus Freytag
- Re: [I18nrp] draft-faltstrom-unicode11-04.txt John C Klensin
- Re: [I18nrp] [Idna-update] draft-faltstrom-unicod… Shawn Steele