Re: [regext] draft-ietf-regext-bundling-registration and characters representation

Patrick Mevzek <pm@dotandco.com> Sun, 04 November 2018 17:20 UTC

Return-Path: <pm@dotandco.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 536E2130DCA for <regext@ietfa.amsl.com>; Sun, 4 Nov 2018 09:20:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dotandco.com header.b=rUyTT594; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TVN0FXlX
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 Be-Ng7FtPjhu for <regext@ietfa.amsl.com>; Sun, 4 Nov 2018 09:20:12 -0800 (PST)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43A141288BD for <regext@ietf.org>; Sun, 4 Nov 2018 09:20:11 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id AF1FB22398 for <regext@ietf.org>; Sun, 4 Nov 2018 12:20:10 -0500 (EST)
Received: from web6 ([10.202.2.216]) by compute3.internal (MEProxy); Sun, 04 Nov 2018 12:20:10 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dotandco.com; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:date:in-reply-to:subject:references; s=fm1; bh=mnj IlqjIgv3JsQhpwyl/AF6Y+PvtjHSNB8vaAR3p4wQ=; b=rUyTT594e0kBk2oTXah SeiJCmSSDcnLEFjbdyEnpMyTB2I/yuP+5BApgh0P2r9r47rFLUGx1KiP+qP4tDBA LtqlXvXMib3nBScq5A3aW/avZqbBcXguTkmC1oRUdcepiflAc4XQty3Tjz4dF+Hd 6uW5IJyESw+lG6H7qKO4l/JcnP1mr+VDHnVV5+XzvF9oZaWlS0YLYfv3/GY7qiwj K1NWYSOjHUSNM5hsB2xeim6xG1cL7sgxfmFDVo/l1bxARRkZp0W3Y4ByUC2xfYje CpQ5Sbgk7macKkjlDh0nVkjGG4bEpc0X5SoXCTpi7o+Av/Y4+HMmca/Fu6sdoFTV +8Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=mnjIlqjIgv3JsQhpwyl/AF6Y+PvtjHSNB8vaAR3p4 wQ=; b=TVN0FXlXhqTrEUrpFPPs/y9SROEzwUg7FuABkonFxnt4JT47U1KSZvxn8 2V55waLFVBiWZNbT5ir3hVVaPg0u1+uJdABGI4VvG18I7rFt7nzzEKDLxGElgfgk GpnbMuGVTt9Ln/X6MsPupHu4kVvEq2i4cs6f3NBASaVn5e4itQDzsevOjLt5fXY7 Wfu61XQtj+9Cap1cvL9w6t8mqxohFoXt+52SS7lFLOB4wjw36vkSFSc/JDPTrJar gHWdDTqUx3hJVZVyoEvoglZlXilwAU8sjOTf39TVwsOJAcTA66Qy3kOw3/PCQ8jF 9GSZS/k6wh84HejzYwI8iJSgjspAQ==
X-ME-Sender: <xms:SirfW5xFx5JtP_waukN2fU0gw6H8Lva96UDCRPXmIOUTxjQBWqeZ8tltJPE>
X-ME-Proxy: <xmx:SirfW_PWPmV6B03xjLwj1TsZReDQdSmkIkwJQRRiZZNZfEhbQFa3GQ> <xmx:SirfW0rMxUeBC7JfJJwTHEY57nnd8Ze2f_ZTlZMVUgwQcqDxsVSwXg> <xmx:SirfWyT6xGYA3t8l094MU4ybRel1uU_46BfEK52Ldz_b39ZwCbp3hA> <xmx:SirfW0YlZ8izDLAgrloemH22dasWgBVuOaPJ2Ab2dKcAaKsdF8vrkA> <xmx:SirfW2MoELT-_ooXJoyx5qVNLoo-KQUOt-Non-v07pKQ3T7je6C85A> <xmx:SirfW6zg8RgoN960kU_U2d_3vpG9I32Rp_4WBuChGnTc2Bm7nFE55g>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 555D641D8; Sun, 4 Nov 2018 12:20:10 -0500 (EST)
Message-Id: <1541352010.1290889.1565202560.71D12941@webmail.messagingengine.com>
From: Patrick Mevzek <pm@dotandco.com>
To: regext@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-21384fa2
Date: Sun, 04 Nov 2018 18:20:10 +0100
In-Reply-To: <5e99188d.7e7.166deced010.Coremail.yaojk@cnnic.cn>
References: <1541134477.2549895.1563050056.54421396@webmail.messagingengine.com> <5e99188d.7e7.166deced010.Coremail.yaojk@cnnic.cn>
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/BC_i04lciDK44z62BB15yIzGbxA>
Subject: Re: [regext] draft-ietf-regext-bundling-registration and characters representation
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Nov 2018 17:20:16 -0000


On Sun, Nov 4, 2018, at 13:59, Jiankang Yao wrote:
>    Your suggestion is very good.   RFC7997 is an informational RFC, and 
> shows a direction. 

Not just a direction but possible things right now.
Because other formats than text are possible now, like PDF.

>    Because the popular form of RFC is TXT, the TXT can not display non 
> ASCII very well.

No, see RFC 7990 and 7995.

>    I can use the natvie unicode characters in draft, but many readers 
> will not display it correctly.

The RFC cited says how things can be dealt with and the difference between
the txt and PDF format for example.

If someone has to deal with internationalization and hence is interested
by your document, I guess he knows how to deal with that and properly display characters.

>    According to my current understanding,  U+XXXX is still the proper 
> way to be easily understood by most readers.

I still feel your document to be difficult to read, just because of that.

Things like:
<b-dn:rdn uLabel="U+5B9E""U+4F8B".example>xn--fsq270a.example</b-dn:rdn>

are not easy, besides being invalid XML.
(I pity the document shepherd that will need to validate all XML
snippets, this can NOT be just copied and pasted in some validtor)

Which is exactly why the RFC7997 says that directly using the unicode characters
as is is permissible in examples.

>    Many years ago, IETF EAI WG also discussed this related issue.
>    I still do not see which rfc uses the natvie unicode characters 
> directly.

RFC8187 for one.

>    If possilbe, I may suggest to add some texts in the draft, which says 
> "in future, the natvie unicode characters instead of U+XXXX notation are 
> suggested to use in the document"

As outlined, it is not in the future (hence this sentence is not necessary),
you can do it today already with RFC7997 guidance.

If you do not want to do it, then I do not recommend adding such a sentence.
And if you want to do it (apply RFC 7997 guidance) then you do not need
this sentence either, but you can put one explaining that examples contains
unicode characters, as permissible by section such and such of RFC7997.

If your draft goes further in the process, I guess this issue will come again
at various last calls and reviews.

-- 
  Patrick Mevzek
  pm@dotandco.com