はじめに

この文書は RFC8771 を勉強と好奇心のため適当に訳したものです。
翻訳の正確さは全く保証しません。
誤字誤訳等の指摘はいつでも大歓迎です。

The Internationalized Deliberately Unreadable Network NOtation (I-DUNNO)（国際化された意図的に読めないネットワーク表記法）

Independent Submission
Request for Comments: 8771
Category: Experimental
ISSN: 2070-1721

A. Mayrhofer
nic.at GmbH
J. Hague
Sinodun
1 April 2020

Abstract（要約）

Domain Names were designed for humans, IP addresses were not.
But more than 30 years after the introduction of the DNS, a minority of mankind persists in invading the realm of machine-to-machine communication by reading, writing, misspelling, memorizing, permuting, and confusing IP addresses.
This memo describes the Internationalized Deliberately Unreadable Network NOtation ("I-DUNNO"), a notation designed to replace current textual representations of IP addresses with something that is not only more concise but will also discourage this small, but obviously important, subset of human activity.

ドメインネームは人間のために設計されたもので、IPアドレスはそうではない。
しかし、DNSの導入から30年以上が経過しても、少数の人類は、IPアドレスを読み、書き、スペルを間違え、記憶し、並べ替え、混同することによって、機械対機械通信の領域に侵入している。
このメモでは、現在のIPアドレスのテキスト表現を、より簡潔なだけでなく、この小さいが明らかに重要な人間活動のサブセットを阻止するものに置き換えるために設計された表記法、I-DUNNO (Internationalized Deliberately Unreadable Network NOtation) ¹ について説明する。

Status of This Memo（このメモの位置づけ）

This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.

この文書はインターネット標準化過程の仕様ではなく、検討、実験的な実装、評価のために公開されるものである。

This document defines an Experimental Protocol for the Internet community.
This is a contribution to the RFC Series, independently of any other RFC stream.
The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment.
Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.

この文書は、インターネットコミュニティのための実験的なプロトコルを定義する。
この文書は、他のいかなるRFCストリームとも無関係に、RFCシリーズに貢献するものである。
RFCエディターは自らの裁量でこの文書の公開を選択し、その実装や配備の価値について何ら表明するものではない。
RFCエディターによって発行が承認された文書は、どのレベルのインターネット標準の候補にもならない。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8771.

この文書の現在の状態、正誤表、それに対するフィードバックの提供方法に関する情報は、 https://www.rfc-editor.org/info/rfc8771 で得ることができる。

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Table of Contents

   1.  Introduction
   2.  Terminology
   3.  The Notation
     3.1.  Forming I-DUNNO
     3.2.  Deforming I-DUNNO
   4.  I-DUNNO Confusion Level Requirements
     4.1.  Minimum Confusion Level
     4.2.  Satisfactory Confusion Level
     4.3.  Delightful Confusion Level
   5.  Example
   6.  IANA Considerations
   7.  Security Considerations
   8.  References
     8.1.  Normative References
     8.2.  Informative References
   Authors' Addresses

1. Introduction（導入）

In Section 2.3 of [RFC0791], the original designers of the Internet Protocol carefully defined names and addresses as separate quantities.
While they did not explicitly reserve names for human consumption and addresses for machine use, they did consider the matter indirectly in their philosophical communal statement: "A name indicates what we seek."
This clearly indicates that names rather than addresses should be of concern to humans.

[RFC0791] の2.3節では、インターネットプロトコルのオリジナルの設計者は、名前とアドレスを別々の物として注意深く定義した。
彼らは、名前を人間が使用するために、アドレスを機械が使用するために明確に予約したわけではないが、哲学的な共同声明で間接的にこの問題を考慮した：「名前は我々が求めるものを示す」
これは、人間にとって重要なのはアドレスではなく名前であることを明確に示している。

The specification of domain names in [RFC1034], and indeed the continuing enormous effort put into the Domain Name System, reinforces the view that humans should use names and leave worrying about addresses to the machines.
RFC 1034 mentions "users" several times, and even includes the word "humans", even though it is positioned slightly unfortunately, though perfectly understandably, in a context of "annoying" and "can wreak havoc" (see Section 5.2.3 of [RFC1034]).
Nevertheless, this is another clear indication that domain names are made for human use, while IP addresses are for machine use.

[RFC1034] におけるドメイン名の仕様、および実際にドメインネームシステムに注がれた継続的な膨大な努力は、人間は名前を使うべきで、アドレスの心配は機械に任せるべきという見解を補強している。
RFC 1034 は "users" について何度も言及しており、"human" という単語も含んでいる。この単語は、完全に理解できるものの、少し残念なことに、"unsing" と "can wreak havoc" という文脈で置かれている([RFC1034]の5.2.3項を参照)。
とはいえ、これもドメイン名は人間が使うために作られ、IPアドレスは機械が使うためのものであることを明確に示している。

Given this, and a long error-strewn history of human attempts to utilize addresses directly, it is obviously desirable that humans should not meddle with IP addresses.
For that reason, it appears quite logical that a human-readable (textual) representation of IP addresses was just very vaguely specified in Section 2.1 of [RFC1123].
Subsequently, a directed effort to further discourage human use by making IP addresses more confusing was introduced in [RFC1883] (which was obsoleted by [RFC8200]), and additional options for human puzzlement were offered in Section 2.2 of [RFC4291].
These noble early attempts to hamper efforts by humans to read, understand, or even spell IP addressing schemes were unfortunately severely compromised in [RFC5952].

このことと、人間がアドレスを直接利用しようとした長い間違いだらけの歴史を考えると、人間がIPアドレスに干渉しないことが明らかに望ましい。
このため、[RFC1123] の2.1節において、人間が読めるIPアドレスの（テキスト）表現が非常に曖昧に規定されたことは、非常に論理的であると思われる。
その後、[RFC1883] ではIPアドレスをより分かりにくくすることで、人間の利用をさらに抑制しようとする試みが導入され（[RFC8200] で廃止）、[RFC4291] の2.2節では人間が困惑するための追加のオプションが提供された。
しかしながら、これらの人間がIPアドレス体系を読み、理解し、あるいは綴る努力を妨げるこれらの高貴な初期の試みは、残念ながら [RFC5952] で大きく損なわれた。

In order to prevent further damage from human meddling with IP addresses, there is a clear urgent need for an address notation that replaces these "Legacy Notations", and efficiently discourages humans from reading, modifying, or otherwise manipulating IP addresses.
Research in this area long ago recognized the potential in ab^H^Hperusing the intricacies, inaccuracies, and chaotic disorder of what humans are pleased to call a "Cultural Technique" (also known as "Script"), and with a certain inexorable inevitability has focused of late on the admirable confusion (and thus discouragement) potential of [UNICODE] as an address notation.
In Section 4, we introduce a framework of Confusion Levels as an aid to the evaluation of the effectiveness of any Unicode-based scheme in producing notation in a form designed to be resistant to ready comprehension or, heaven forfend, mutation of the address, and so effecting the desired confusion and discouragement.

人間がIPアドレスに干渉することによる被害の拡大を防ぐために、これらの「レガシー記法」に代わるアドレス記法を用意することが明らかに急務であり、人間がIPアドレスを読んだり、変更したり、その他の操作をすることを効率的に阻止することが必要である。
この分野の研究は、人間が「文化的技巧」（「スクリプト」とも呼ばれる）と喜んで呼ぶものの複雑さ、不正確さ、および無秩序さを探ることの可能性を以前より認識しており、ある不可避な必然性をもって、アドレス表記法と同様な [UNICODE] の見事な混乱（と挫折）の可能性に最近焦点を合わせている。
4章では、すぐに理解することができないように設計された表記法を生み出すニコードベースのスキームの有効性評価のために、またそんなことがあってはならないが、アドレスの変異が起きたときには望ましい混乱と落胆がもたらされるように、「混乱レベル」フレームワークを紹介する。

The authors welcome [RFC8369] as a major step in the right direction.
However, we have some reservations about the scheme proposed therein:

著者らは [RFC8369] を正しい方向への大きな一歩として歓迎する。

しかし、そこで提案されているスキームには、いくつかの留意点がある：

Our analysis of the proposed scheme indicates that, while impressively concise, it fails to attain more than at best a Minimum Confusion Level in our classification.

Humans, especially younger ones, are becoming skilled at handling emoji. Over time, this will negatively impact the discouragement factor.

The proposed scheme is specific to IPv6; if a solution to this problem is to be in any way timely, it must, as a matter of the highest priority, address IPv4. After all, even taking the regrettable effects of RFC 5952 into account, IPv6 does at least remain inherently significantly more confusing and discouraging than IPv4.

提案方式を分析した結果、非常に簡潔でありながら、分類における最小混乱レベル以上を達成することができないことが判明した。
人間、特に若者は絵文字の扱いに長けてきている。このことは、時間の経過とともに、落胆の要因にマイナスの影響を与えるだろう。
本提案方式は IPv6 に特化したものであり、本問題に対する解決策が何らかの形で適時であるならば、最優先事項として IPv4 への対応が必要である。結局のところ、RFC 5952 の残念な影響を考慮しても、少なくとも IPv6 は IPv4 よりも本質的に著しく混乱し、落胆させられることに変わりはない。

This document therefore specifies an alternative Unicode-based notation, the Internationalized Deliberately Unreadable Network NOtation (I-DUNNO).
This notation addresses each of the concerns outlined above:

そこで、この文書では、代替のユニコードベースの表記法である国際化された意図的に読めないネットワーク表記法(I-DUNNO)を指定する。
この表記法は、上に概説した各懸念に対処している。

I-DUNNO can generate Minimum, Satisfactory, or Delightful levels of confusion.

As well as emoji, it takes advantage of other areas of Unicode confusion.

It can be used with IPv4 and IPv6 addresses.

I-DUNNO は、最小、満足、または愉快レベルの混乱を発生させることができる。
絵文字と同様に、それはユニコードの混乱する他の領域を利用する。
それは IPv4 と IPv6 アドレスで使用することができる。

We concede that I-DUNNO notation is markedly less concise than that of RFC 8369.
However, by permitting multiple code points in the representation of a single address, I-DUNNO opens up the full spectrum of Unicode-adjacent code point interaction.
This is a significant factor in allowing I-DUNNO to achieve higher levels of confusion.
I-DUNNO also requires no change to the current size of Unicode code points, and so its chances of adoption and implementation are (slightly) higher.

明らかに I-DUNNO の表記が RFC 8369 の表記よりも簡潔でないことは認める。
しかし、一つのアドレスの表現に複数のコードポイントを許可することで、I-DUNNOはユニコードに隣接するコードポイントの相互作用を全面的に開放している。
これは I-DUNNO がより高いレベルの混乱を達成するための重要な要素である。
また、I-DUNNO は現在のユニコードコードポイントのサイズに変更を加える必要がないため、採用や実装の可能性が（少し）高くなるだろう。

Note that the use of I-DUNNO in the reverse DNS system is currently out of scope.
The occasional human-induced absence of the magical one-character sequence U+002E is believed to cause sufficient disorder there.

逆引きDNSシステムでの I-DUNNO の使用は現在範囲外であることに注意すること。
魔法の1文字シーケンス U+002E （訳注：ピリオド）が時折人為的に欠落することが、そこに十分な無秩序を引き起こすと考えられている。

Media Access Control (MAC) addresses are totally out of the question.

MAC(Media Access Control) アドレスは全く問題外である。

2. Terminology（用語説明）

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

本文書におけるキーワード「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「NOT RECOMMENDED」「MAY」「OPTIONAL」は、ここに示すようにすべて大文字で現れるときのみ BCP 14 [RFC2119] [RFC8174] に記載されているように解釈するものとする。

Additional terminology from [RFC6919] MIGHT apply.

[RFC6919] の追加用語が適用されるかもしれない。

3. The Notation（表記法）

I-DUNNO leverages UTF-8 [RFC3629] to obfuscate IP addresses for humans.
UTF-8 uses sequences between 1 and 4 octets to represent code points as follows:

I-DUNNO は、UTF-8 [RFC3629] を利用して、人間に対してIPアドレスを難読化する。
UTF-8 は、以下のように1〜4オクテットのシーケンスでコードポイントを表現する。

      +-----------------------+-------------------------------------+
      | Char. number range    | UTF-8 octet sequence                |
      +-----------------------+-------------------------------------+
      | (hexadecimal)         | (binary)                            |
      +=======================+=====================================+
      | 0000 0000 - 0000 007F | 0xxxxxxx                            |
      +-----------------------+-------------------------------------+
      | 0000 0080 - 0000 07FF | 110xxxxx 10xxxxxx                   |
      +-----------------------+-------------------------------------+
      | 0000 0800 - 0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx          |
      +-----------------------+-------------------------------------+
      | 0001 0000 - 0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx |
      +-----------------------+-------------------------------------+

                                  Table 1

I-DUNNO uses that structure to convey addressing information as follows:

I-DUNNOはその構造を利用して、以下のようにアドレス情報を伝える。

3.1. Forming I-DUNNO（I-DUNNO の形成）

In order to form an I-DUNNO based on the Legacy Notation of an IP address, the following steps are performed:

レガシー表記に基づくIPアドレスから I-DUNNO を形成するために、以下の手順を実行する。

The octets of the IP address are written as a bitstring in network byte order.

Working from left to right, the bitstring (32 bits for IPv4; 128 bits for IPv6) is used to generate a list of valid UTF-8 octet sequences. To allocate a single UTF-8 sequence:

a. Choose whether to generate a UTF-8 sequence of 1, 2, 3, or 4 octets. The choice OUGHT TO be guided by the requirement to generate a satisfactory Minimum Confusion Level (Section 4.1) (not to be confused with the minimum Satisfactory Confusion Level (Section 4.2)). Refer to the character number range in Table 1 in order to identify which octet sequence lengths are valid for a given bitstring. For example, a 2-octet UTF-8 sequence requires the next 11 bits to have a value in the range 0080-07ff.

b. Allocate bits from the bitstring to fill the vacant positions 'x' in the UTF-8 sequence (see Table 1) from left to right.

c. UTF-8 sequences of 1, 2, 3, and 4 octets require 7, 11, 16, and 21 bits, respectively, from the bitstring. Since the number of combinations of UTF-8 sequences accommodating exactly 32 or 128 bits is limited, in sequences where the number of bits required does not exactly match the number of available bits, the final UTF-8 sequence MUST be padded with additional bits once the available address bits are exhausted. The sequence may therefore require up to 20 bits of padding. The content of the padding SHOULD be chosen to maximize the resulting Confusion Level.

Once the bits in the bitstring are exhausted, the conversion is complete. The I-DUNNO representation of the address consists of the Unicode code points described by the list of generated UTF-8 sequences, and it MAY now be presented to unsuspecting humans.

IPアドレスのオクテットは、ネットワークバイトオーダーでビットストリングとして記述される。
左から右に向かって、ビット文字列（IPv4 では32ビット、IPv6 では128ビット）を使って、有効な UTF-8 オクテット配列のリストを生成する。1つの UTF-8 シーケンスを割り当てるには、次のようにする。
1. 1、2、3、4 オクテットのUTF-8シーケンスを生成するかどうかを選択する。この選択は、満足できる最小混乱レベル (4.1節) (最小満足混乱レベル (4.2節) と混同しないように) を生成するという要求によって導かれなければならない(OUGHT TO)。あるビット列に対してどのオクテット列長が有効であるかを特定するために、表1の文字番号範囲を参照する。例えば、2 オクテットの UTF-8 シーケンスでは、次の 11 ビットが 0080-07ff の範囲にあることが必要である。
2. UTF-8シーケンス（表1参照）の空いている位置「x」を埋めるために、ビットストリングからビットを左から右へ割り当てる。
3. 1、2、3、4オクテットのUTF-8配列は、ビット列からそれぞれ7、11、16、21ビットを必要とする。 UTF-8 シーケンスのうち、32 ビットと 128 ビットの組み合わせは限られているので、必要なビット数と利用可能なビット数が一致しないシーケンスでは、利用可能なアドレスビットを使い切った時点で、最終的な UTF-8 シーケンスは追加のビットでパディングされなければならない(MUST)。したがって、シーケンスは最大で20ビットのパディングを必要とする可能性がある。パディングの内容は、結果として生じる混乱レベルを最大化するように選択されるべきである(SHOULD)。
ビット文字列のビットを使い切ったら、変換は完了する。アドレスの I-DUNNO 表現は、生成された UTF-8 シーケンスのリストによって記述されたユニコードコードポイントからなり、それは今疑っていない人間に提示されてもよい(MAY)。

3.2. Deforming I-DUNNO（I-DUNNO の逆形成）

This section is intentionally omitted.
The machines will know how to do it, and by definition humans SHOULD NOT attempt the process.

このセクションは意図的に省略している。
機械はその方法を知っているだろうし、定義上、人間はそのプロセスを試みるべきではないだろう(SHOULD NOT)。

4. I-DUNNO Confusion Level Requirements（I-DUNNO 混乱レベルの必要要件）

A sequence of characters is considered I-DUNNO only when there's enough potential to confuse humans.

一連の文字が I-DUNNO とみなされるのは、人間を混乱させるだけの可能性がある場合のみである。

Unallocated code points MUST be avoided.
While they might appear to have great confusion power at the moment, there's a minor chance that a future allocation to a useful, legible character will reduce this capacity significantly.
Worse, in the (unlikely, but not impossible -- see Section 3.1.3 of [RFC5894]) event of a code point losing its DISALLOWED property per IDNA2008 [RFC5894], existing I-DUNNOs could be rendered less than minimally confusing, with disastrous consequences.

未割り当てのコードポイントは避けなければならない(MUST)。
現時点では大きな混乱力を持つように見えるかもしれないが、将来有用で読みやすい文字に割り当てられることで、この能力が著しく低下する可能性が少なからずある。
さらに悪いことに、IDNA2008 [RFC5894] に従ってコードポイントが DISALLOWED プロパティを失った場合(可能性は低いが、不可能ではない —— [RFC5894] の3.1.3項参照)、既存の I-DUNNO は最小限の混乱をもたらさない状態になり、破壊的な結果をもたらす可能性がある。

The following Confusion Levels are defined:

以下の混乱レベルが定義されている。

4.1. Minimum Confusion Level（最小混乱レベル）

As a minimum, a valid I-DUNNO MUST:

Contain at least one UTF-8 octet sequence with a length greater than one octet.

Contain at least one character that is DISALLOWED in IDNA2008. No code point left behind! Note that this allows machines to distinguish I-DUNNO from Internationalized Domain Name labels.

I-DUNNOs on this level will at least puzzle most human users with knowledge of the Legacy Notation.

最低限、有効なI-DUNNOは以下のものでなければならない(MUST)。

1オクテット以上の長さの UTF-8 オクテット列を少なくとも1つ含むこと。
IDNA2008 で DISALLOWED とされている文字が少なくとも1つ含まれていること。コードポイントを残してはいけません。これにより、マシンが I-DUNNO と国際化ドメイン名ラベルを区別することができることに注意すること。

このレベルの I-DUNNO は、少なくともレガシー記法の知識を持つほとんどの人間のユーザーを困惑させるだろう。

4.2. Satisfactory Confusion Level（満足混乱レベル）

An I-DUNNO with Satisfactory Confusion Level MUST adhere to the Minimum Confusion Level, and additionally contain two of the following:

At least one non-printable character.

Characters from at least two different Scripts.

A character from the "Symbol" category.

The Satisfactory Confusion Level will make many human-machine interfaces beep, blink, silently fail, or any combination thereof.
This is considered sufficient to discourage most humans from deforming I-DUNNO.

満足混乱レベルである I-DUNNO は、最小混乱レベルを遵守し、さらに以下のうち2つを含まなければならない(MUST)：

少なくとも1つの印字不可能な文字。
少なくとも2つの異なるスクリプトからの文字。
"Symbol" カテゴリの文字。

満足混乱レベルは、多くのヒューマンマシンインターフェースのビープ音、点滅、無音故障、またはそれらの組み合わせを引き起こす。
これは、ほとんどの人間が I-DUNNO を変形するのを阻止するのに十分であると考えられる。

4.3. Delightful Confusion Level（愉快混乱レベル）

An I-DUNNO with Delightful Confusion Level MUST adhere to the Satisfactory Confusion Level, and additionally contain at least two of the following:

Characters from scripts with different directionalities.

Character classified as "Confusables".

One or more emoji.

An I-DUNNO conforming to this level will cause almost all humans to U+1F926, with the exception of those subscribed to the idna-update mailing list.

(We have also considered a further, higher Confusion Level, tentatively entitled "BReak EXaminatIon or Twiddling" or "BREXIT" Level Confusion, but currently we have no idea how to go about actually implementing it.)

愉快混乱レベルの I-DUNNO は、満足混乱レベルを満たした上で、さらに以下のうち2つ以上を含まなければならない：

異なる方向性を持つスクリプトから文字。
"Confusables" と分類される文字。
1つ以上の絵文字。

このレベルに適合する I-DUNNO は、idna-update メーリングリストを購読している人を除いて、ほとんどすべての人間に U+1F926 (🤦; Face Palm) を起こさせるだろう。

(さらに上位の混乱レベルとして、「BReak EXaminatIon or Twiddling」または「BREXIT」混乱レベルという仮称も検討したが、現在のところ実際にどのように実装していくかは考えていない)。

5. Example（例）

An I-DUNNO based on the Legacy Notation IPv4 address "198.51.100.164" is formed and validated as follows: First, the Legacy Notation is written as a string of 32 bits in network byte order:

レガシー記法の IPv4 アドレス 198.51.100.164 に基づく I-DUNNO は、以下のように形成され、検証される。
まず、レガシー表記をネットワークバイトオーダーで32ビットの文字列として記述する：

                     11000110001100110110010010100100

Since I-DUNNO requires at least one UTF-8 octet sequence with a length greater than one octet, we allocate bits in the following form:

I-DUNNO では1オクテット以上の長さの UTF-8 オクテット列を少なくとも1つ必要とするので、次のような形でビットを割り当てる。

                   seq1  |   seq2  |   seq3  |   seq4
                 --------+---------+---------+------------
                 1100011 | 0001100 | 1101100 | 10010100100

This translates into the following code points:

これは、次のようなコードポイントに変換される：

        +-------------+-------------------------------------------+
        | Bit Seq.    | Character Number (Character Name)         |
        +=============+===========================================+
        | 1100011     | U+0063 (LATIN SMALL LETTER C)             |
        +-------------+-------------------------------------------+
        | 0001100     | U+000C (FORM FEED (FF))                   |
        +-------------+-------------------------------------------+
        | 1101100     | U+006C (LATIN SMALL LETTER L)             |
        +-------------+-------------------------------------------+
        | 10010100100 | U+04A4 (CYRILLIC CAPITAL LIGATURE EN GHE) |
        +-------------+-------------------------------------------+

                                  Table 2

The resulting string MUST be evaluated against the Confusion Level Requirements before I-DUNNO can be declared.
Given the example above:

There is at least one UTF-8 octet sequence with a length greater than 1 (U+04A4) .

There are two IDNA2008 DISALLOWED characters: U+000C (for good reason!) and U+04A4.

There is one non-printable character (U+000C).

There are characters from two different Scripts (Latin and Cyrillic).

Therefore, the example above constitutes valid I-DUNNO with a Satisfactory Confusion Level.
U+000C in particular has great potential in environments where I-DUNNOs would be sent to printers.

得られた文字列は、I-DUNNO であると宣言する前に、混乱レベルの必要要件を評価されなければならない(MUST)。
上記の例では：

長さが1より大きいUTF-8オクテット列が少なくとも1つ存在する（U+04A4）。
IDNA2008 で DISALLOWED とされている文字が2つある。U+000C (正当な理由による!) と U+04A4。
印字不可能な文字が1つある(U+000C)。
2つの異なるスクリプト（ラテン語とキリル語）の文字がある。

したがって、上記の例は、満足混乱レベルの有効な I-DUNNO となる。
特に U+000C は I-DUNNO がプリンターに送られるような環境では大きなポテンシャルを持っている。

6. IANA Considerations（IANA に関する考慮事項）

If this work is standardized, IANA is kindly requested to revoke all IPv4 and IPv6 address range allocations that do not allow for at least one I-DUNNO of Delightful Confusion Level.
IPv4 prefixes are more likely to be affected, hence this can easily be marketed as an effort to foster IPv6 deployment.

この作業が標準化された場合、IANAは愉快混乱レベルのI-DUNNOを少なくとも1つ許可しないIPv4およびIPv6アドレス範囲の割り当てをすべて取り消すよう、親切に要請する。
IPv4 プレフィックスが影響を受ける可能性が高いため、これは IPv6 普及のための努力として簡単にマーケティングすることができる。

Furthermore, IANA is urged to expand the Internet TLA Registry [RFC5513] to accommodate Seven-Letter Acronyms (SLA) for obvious reasons, and register 'I-DUNNO'.
For that purpose, U+002D ("-", HYPHEN-MINUS) SHALL be declared a Letter.

さらに、IANAは明白な理由により、インターネットTLAレジストリ [RFC5513] を拡張して7レター頭字語（SLA）を収容し、「I-DUNNO」を登録するよう強く要請される。
そのために、U+002D ("-", HYPHEN-MINUS)を Letter として宣言しなければならない(SHALL)。

7. Security Considerations（セキュリティに関する考慮事項）

I-DUNNO is not a security algorithm.
Quite the contrary -- many humans are known to develop a strong feeling of insecurity when confronted with I-DUNNO.

I-DUNNOはセキュリティ・アルゴリズムではない。
それどころか、多くの人間は I-DUNNO に直面すると強い不安感を抱くことが知られている。

In the tradition of many other RFCs, the evaluation of other security aspects of I-DUNNO is left as an exercise for the reader.

他の多くのRFCの伝統に従って、I-DUNNOの他のセキュリティ側面の評価は読者のための練習として残されている。

8. References

8.1. Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, <https://www.rfc-editor.org/info/rfc3629>.

   [RFC5894]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Background, Explanation, and
              Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010,
              <https://www.rfc-editor.org/info/rfc5894>.

   [RFC6919]  Barnes, R., Kent, S., and E. Rescorla, "Further Key Words
              for Use in RFCs to Indicate Requirement Levels", RFC 6919,
              DOI 10.17487/RFC6919, April 2013,
              <https://www.rfc-editor.org/info/rfc6919>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.2. Informative References

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,
              <https://www.rfc-editor.org/info/rfc791>.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/info/rfc1034>.

   [RFC1123]  Braden, R., Ed., "Requirements for Internet Hosts -
              Application and Support", STD 3, RFC 1123,
              DOI 10.17487/RFC1123, October 1989,
              <https://www.rfc-editor.org/info/rfc1123>.

   [RFC1883]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 1883, DOI 10.17487/RFC1883,
              December 1995, <https://www.rfc-editor.org/info/rfc1883>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/info/rfc4291>.

   [RFC5513]  Farrel, A., "IANA Considerations for Three Letter
              Acronyms", RFC 5513, DOI 10.17487/RFC5513, April 2009,
              <https://www.rfc-editor.org/info/rfc5513>.

   [RFC5952]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
              Address Text Representation", RFC 5952,
              DOI 10.17487/RFC5952, August 2010,
              <https://www.rfc-editor.org/info/rfc5952>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

   [RFC8369]  Kaplan, H., "Internationalizing IPv6 Using 128-Bit
              Unicode", RFC 8369, DOI 10.17487/RFC8369, April 2018,
              <https://www.rfc-editor.org/info/rfc8369>.

   [UNICODE]  The Unicode Consortium, "The Unicode Standard (Current
              Version)", 2019,
              <http://www.unicode.org/versions/latest/>.

Authors' Addresses

   Alexander Mayrhofer
   nic.at GmbH

   Email: alexander.mayrhofer@nic.at
   URI:   https://i-dunno.at/


   Jim Hague
   Sinodun

   Email: jim@sinodun.com
   URI:   https://www.sinodun.com/

おそらく I don't know. に掛けているとおもわれる。たぶん。 ↩