[I18ndir] Fwd: Re: Working Group Last Call: Structured Headers for HTTP

Asmus Freytag <asmusf@ix.netcom.com> Wed, 05 February 2020 22:51 UTC

Return-Path: <asmusf@ix.netcom.com>
X-Original-To: i18ndir@ietfa.amsl.com
Delivered-To: i18ndir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5468120827 for <i18ndir@ietfa.amsl.com>; Wed, 5 Feb 2020 14:51:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ix.netcom.com; domainkeys=pass (2048-bit key) header.from=asmusf@ix.netcom.com header.d=ix.netcom.com
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 HY5FCBFAvu1z for <i18ndir@ietfa.amsl.com>; Wed, 5 Feb 2020 14:51:00 -0800 (PST)
Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BF4B120131 for <i18ndir@ietf.org>; Wed, 5 Feb 2020 14:50:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ix.netcom.com; s=dk12062016; t=1580943060; bh=e/3w5sh9wjgrmZO0b0b1ZoOvRB/ZtE3WxKGY IqThQcg=; h=Received:Subject:References:To:From: X-Forwarded-Message-Id:Message-ID:Date:User-Agent:MIME-Version: In-Reply-To:Content-Type:Content-Language:X-ELNK-Trace: X-Originating-IP; b=dWCdRckovjHnNUSnH9NweSH+GGFlbSo+5jamijaTaoiuK1 ZlOeaqJ7s9S14C+G7bvqZk+uVE4Ck8pHDXbeOMLKMGElJVs86ENtP4/ltGCTe4oQJMY P/ER+9W4OXyUVLI1c+yDWX4znxOf0FRGcf1PXXkCvzwFMKT3Rlc+xxmZsQ80B47WDCf xC6mov/P6yu6Ma5vI4HL+9W6ynAYNOldkkLc2nyNEnG5vlYJ5Z2Jhvtwkb3PhrzBtUN U3MlItJXKIcYky2KPujuq3CsifvmdpIl7B0t9krSfNTKApKwIX3QzDLvnWnj7niWzy7 HFv0qkuL19UFpf2CTCmA27L3Faqw==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=ix.netcom.com; b=FLRoeohb9k7EWsX9UUSwjSs78LlA9l+yK5mGMw/zqPBaFfAYb0K5QmkMgN0M9EBSR+S+qUSf1q3Hl/QtGzQbtZlfRjk4KSJzcVSv7B06LIwetsaWGXiGxyYkzw6NY905Z4d/zsAk6DkZj3CQqR6BEfzhQQagO39fo0cgtTic+PD2skDIXGK9ZNN5XfCkXAU+O5brF1/cVdsFFxZc39xgIBTb1hRbvrDB17JhVab0EjUE6FKpRWJ+P/LkKAQLRRqWjHKK9JCkJxYuMrkLQDrkI/bndyLm5WJHwNkoKjB3KHY4xMxVeRxCYyHiq3zZuT+hWdpO+m8i0VS2HKYweK9ddQ==; h=Received:Subject:References:To:From:X-Forwarded-Message-Id:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language:X-ELNK-Trace:X-Originating-IP;
Received: from [75.172.116.119] (helo=[192.168.1.106]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from <asmusf@ix.netcom.com>) id 1izTVa-000E5G-M7 for i18ndir@ietf.org; Wed, 05 Feb 2020 17:50:58 -0500
References: <fd66eb72-2777-3f34-026b-00f4084b88ea@ix.netcom.com>
To: i18ndir@ietf.org
From: Asmus Freytag <asmusf@ix.netcom.com>
X-Forwarded-Message-Id: <fd66eb72-2777-3f34-026b-00f4084b88ea@ix.netcom.com>
Message-ID: <a7652163-6815-457b-b6b4-96affe237a32@ix.netcom.com>
Date: Wed, 05 Feb 2020 14:50:58 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2
MIME-Version: 1.0
In-Reply-To: <fd66eb72-2777-3f34-026b-00f4084b88ea@ix.netcom.com>
Content-Type: multipart/alternative; boundary="------------95959F925E94BE33FBEB0087"
Content-Language: en-US
X-ELNK-Trace: 464f085de979d7246f36dc87813833b26976a2cdabd2db7adae6c9f412f772c46fe76b59561aadd3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 75.172.116.119
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18ndir/QiE51ZrSbveYtUEJ61NsYMkNMB4>
Subject: [I18ndir] Fwd: Re: Working Group Last Call: Structured Headers for HTTP
X-BeenThere: i18ndir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Internationalization Directorate <i18ndir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i18ndir/>
List-Post: <mailto:i18ndir@ietf.org>
List-Help: <mailto:i18ndir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Feb 2020 22:51:02 -0000

(didn't go out to the list when I first sent it)

When I read the word "exception" I always think of this:

When we built the first Unicode-enabled OS (Windows NT), we had a long 
discussion of which "strings" in the OS needed to be Unicode.

Some thought that there was a clear dividing line between data and what 
would be called "protocol values" in another context.

Some of the latter did look like they were easily limited to ASCII; but 
everywhere we found "exceptions". There might be a set of enumerable 
tokens, but it allowed extended values that were network or file 
identifiers.

After exhaustively researching everything, the conclusion was that every 
single string in the OS had to be Unicode (and making any exceptions was 
either not possible, or not worth the effort).

However, while all strings were encoded in Unicode, not all string 
values were allowed. While file names could be localized (within the 
limits of file system syntax), some of the enumerated strings were left 
limited to the ASCII set in repertoire (even if encoded in Unicode).

Reading this discussion (and I'm sorry I don't have the time right now 
to properly delve into the details) it seems that a natural 
recommendation would be to require Unicode for any native representation 
and, if necessary (or possible), limit the repertoire.

This also requires a definition of the matching protocol for all strings 
that are to be matched as part of the protocol (or should be 
searchable). For any format, that would cover issues of casing, white 
space handling etc., but for Unicode, by necessity, that also requires 
defining the normalization form to be used.

A./

PS: given how few systems these days natively operate in any character 
set other than Unicode, I am always astonished at the length to which 
people go to justify not making something native Unicode. They just pick 
up conversion issues when they use platform libraries to do any work or 
display.