Re: [apps-discuss] Last Call: <draft-ietf-appsawg-rfc3536bis-02.txt> (Terminology Used in Internationalization in the IETF) to BCP

Mykyta Yevstifeyev <> Fri, 17 June 2011 03:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA54011E807D; Thu, 16 Jun 2011 20:20:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.489
X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VEe+PjKO3FO2; Thu, 16 Jun 2011 20:20:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6ABDA11E8079; Thu, 16 Jun 2011 20:20:46 -0700 (PDT)
Received: by fxm15 with SMTP id 15so1697426fxm.31 for <multiple recipients>; Thu, 16 Jun 2011 20:20:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WdV6NsnjeBCPj6HnqIZIrKgZb44FJN13AQkKC5ssCpE=; b=NRiwqGnqLDDT2E1c1Ir2UaY7hr7PN3zUJsjCzcawZ1vqCw/uzhgQ6wV77v96ENXHgI MWLIizMdrSqs6N+9WSFuzTy7VWPFuGWOU4gYlZaoVEtoPevLjQ+1dY7pYC8ZB45dHPNV wK7czNCp8rO9TKn77esUF1Kgqkz7rQJ1hZcgc=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=cY3U5Miiuh3GLUdC3QtoBNVocEXi6Tbn+vL1hTpKx+gXD7Fq2KBDJc088TQwzcnukt DCeR7hMR7QvtBp52bmTRE12nF69uvg2y6Yc03UiQsixiOiioAJP+2QQ4RYovhw1SUh2P GH5oDa7ZDr2YvF1qUGIQxjSCbtU9lBbvVP4rw=
Received: by with SMTP id g16mr1894230fad.125.1308280845518; Thu, 16 Jun 2011 20:20:45 -0700 (PDT)
Received: from [] ([]) by with ESMTPS id o23sm1105859faa.33.2011. (version=SSLv3 cipher=OTHER); Thu, 16 Jun 2011 20:20:44 -0700 (PDT)
Message-ID: <>
Date: Fri, 17 Jun 2011 06:21:30 +0300
From: Mykyta Yevstifeyev <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv: Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: iesg <>,
Subject: Re: [apps-discuss] Last Call: <draft-ietf-appsawg-rfc3536bis-02.txt> (Terminology Used in Internationalization in the IETF) to BCP
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Jun 2011 03:20:48 -0000

Hello all,

I have an only concern with regard to this document which I expressed 
before, during WG discussions, and which I'd like to bring to IESG's 
attention now.

For a number of times I proposed improving the "control character" 
definition in Section 4.1:

>     control character
>        The 65 characters in the ranges U+0000..U+001F and U+007F..U+009F.
>        The basic space character, U+0020, is often considered as a
>        control character as well, making the total number 66.  They are
>        also known as control codes.  In terminology adopted by Unicode
>        from ASCII and the ISO 8859 standards, these codes are treated as
>        belonging to three ranges: "C0" (for U+0000..U+001F), "C1" (for
>        U+0080...U+009F), and the single control character "DEL" (U+007F).
>        <UNICODE>
My proposals included 
and  The 
main justification I provided is that, in accordance with Abstract: 
"This document provides a glossary of terms [...]" so we need to specify 
"what does the control character mean" but not "what Unicode codepoints 
are assigned for control characters".  Yet, on the apps-discuss mailing 
list there were some concerns regarding the fact that control characters 
are unfamiliar to internalization so my proposed definition is not an 
option (one of the authors shares this opinion).  Thus, why does it 
occur in its current form?  So, there are two possible variants, I 
think: (1) remove the "control character" definition from the document 
as irrelevant to internalization or (2) produce a really good definition 
of this term (consider we're trying to give the terms normative meaning 
within IETF, since the intended status is BCP).  I didn't manage to 
persuade the authors or WG to undertake any of the aforementioned 
options and I hope IESG should decide on this.

Also, as a minor remark on references.  The document makes normative 
reference to an obsolete document - ISO/IEC 10646:2003 whereas ISO/IEC 
10646:2011 is published.  The reference should be corrected.

Mykyta Yevstifeyev

16.06.2011 16:04, The IESG wrote:
> The IESG has received a request from the Applications Area Working Group
> WG (appsawg) to consider the following document:
> - 'Terminology Used in Internationalization in the IETF'
>    <draft-ietf-appsawg-rfc3536bis-02.txt>  as a BCP
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> mailing lists by 2011-06-30. Exceptionally, comments may be
> sent to instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> Abstract
>     This document provides a glossary of terms used in the IETF when
>     discussing internationalization.  The purpose is to help frame
>     discussions of internationalization in the various areas of the IETF
>     and to help introduce the main concepts to IETF participants.
> The file can be obtained via
> IESG discussion can be tracked via
> No IPR declarations have been submitted directly on this I-D.
> _______________________________________________
> apps-discuss mailing list