[要約] RFC 8771は、国際化された意図的に読みにくいネットワーク表記（I-DUNNO）に関する規格であり、その目的は、ネットワークデータの可読性を低下させることで、セキュリティとプライバシーを向上させることです。
Independent Submission A. Mayrhofer
Request for Comments: 8771 nic.at GmbH
Category: Experimental J. Hague
ISSN: 2070-1721 Sinodun
1 April 2020
The Internationalized Deliberately Unreadable Network NOtation (I-DUNNO)
国際化された意図的に読めないネットワーク表記（I-DUNNO）
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"）について説明していますアクティビティ。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
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 Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。
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.
著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。
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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
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
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は「ユーザー」について何度か言及しており、「人間」という言葉も含まれていますが、「あいまい」と「大混乱」のコンテキストで完全に理解できますが、少し残念ながら位置付けられています（セクション5.2.3を参照）。 [RFC1034]）。それにもかかわらず、これはドメイン名が人間が使用するために作成され、IPアドレスがマシンが使用するために作成されたことを示すもう1つの明確な指標です。
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アドレスをいじってはならないことが明らかに望ましいです。そのため、IPアドレスの人間が読める（テキスト）表現が[RFC1123]のセクション2.1で非常に漠然と指定されていたのは非常に論理的であるように思われます。その後、IPアドレスをさらに混乱させることによって人間の使用をさらに阻止するための指示された取り組みが[RFC1883]で導入され（[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アドレスを読み取ったり、変更したり、その他の方法で操作したりすることを効率的に阻止するアドレス表記の緊急の必要性は明らかです。この分野の研究は、人間が「文化的手法」（「スクリプト」としても知られている）と呼んでいる複雑さと不正確さ、および無秩序な無秩序をab ^ H ^ Hperusingすることの潜在的可能性を認識し、特定の不可抗力を伴いました[UNICODE]の住所表記としての見事な混乱（したがって落胆）の可能性に最近焦点を当てています。セクション4では、すぐに理解できるように、または天国のようにアドレスを変更できないように設計された形式で表記法を作成する際のUnicodeベースのスキームの有効性を評価する助けとして、混乱レベルのフレームワークを紹介します。そのため、望ましい混乱と落胆をもたらします。
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:
したがって、このドキュメントでは、Unicodeベースの代替表記である国際化された意図的に読み取り不能なネットワーク表記（I-DUNNO）を指定します。この表記は、上で概説した各懸念事項に対応しています。
* I-DUNNO can generate Minimum, Satisfactory, or Delightful levels of confusion.
* I-DUNNOは、最小、満足、または楽しいレベルの混乱を引き起こす可能性があります。
* As well as emoji, it takes advantage of other areas of Unicode confusion.
* 絵文字だけでなく、Unicodeの混乱の他の領域を利用します。
* It can be used with IPv4 and IPv6 addresses.
* 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は、Unicodeに隣接するコードポイントの相互作用の全範囲を開きます。これは、I-DUNNOがより高いレベルの混乱を達成できるようにする上で重要な要素です。 I-DUNNOは、現在のUnicodeコードポイントのサイズを変更する必要もないため、採用および実装の可能性は（わずかに）高くなります。
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.
Media Access Control（MAC）アドレスは完全に問題外です。
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]の追加の用語が適用される場合があります。
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
表1
I-DUNNO uses that structure to convey addressing information as follows:
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を形成するには、次の手順を実行します。
1. The octets of the IP address are written as a bitstring in network byte order.
1. IPアドレスのオクテットは、ネットワークバイトオーダーのビット文字列として書き込まれます。
2. 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:
2. 左から右に作業して、ビット文字列（IPv4の場合は32ビット、IPv6の場合は128ビット）を使用して、有効なUTF-8オクテットシーケンスのリストを生成します。単一のUTF-8シーケンスを割り当てるには：
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.
a. 1、2、3、または4オクテットのUTF-8シーケンスを生成するかどうかを選択します。十分な最小混乱レベル（セクション4.1）を生成するための要件に基づいて選択する必要があります（最小満足レベル（セクション4.2）と混同しないでください）。特定のビット文字列に対して有効なオクテットシーケンスの長さを識別するには、表1の文字番号の範囲を参照してください。たとえば、2オクテットのUTF-8シーケンスでは、次の11ビットに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.
b. ビットストリングからビットを割り当てて、UTF-8シーケンス（表1を参照）の空の位置「x」を左から右に埋めます。
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.
c. 1、2、3、および4オクテットのUTF-8シーケンスでは、ビットストリングからそれぞれ7、11、16、および21ビットが必要です。正確に32ビットまたは128ビットに対応するUTF-8シーケンスの組み合わせの数は限られているため、必要なビット数が使用可能なビット数と正確に一致しないシーケンスでは、最終的なUTF-8シーケンスに追加のビットを1回埋め込む必要があります使用可能なアドレスビットがすべて使用されています。したがって、シーケンスには最大20ビットのパディングが必要になる場合があります。パディングの内容は、結果として生じる混乱レベルを最大化するように選択する必要があります（SHOULD）。
3. 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.
3. ビット文字列のビットがなくなると、変換は完了です。アドレスのI-DUNNO表現は、生成されたUTF-8シーケンスのリストによって記述されたUnicodeコードポイントで構成されており、疑いを持たない人間に提示される場合があります。
This section is intentionally omitted. The machines will know how to do it, and by definition humans SHOULD NOT attempt the process.
このセクションは意図的に省略されています。マシンはそれを行う方法を知っているでしょう、そして定義上、人間はプロセスを試みるべきではありません。
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.
未割り当てのコードポイントは回避する必要があります。現時点では大きな混乱の力があるように見えるかもしれませんが、有用で読みやすいキャラクターへの将来の割り当てによって、この容量が大幅に減少する可能性はわずかです。さらに悪いことに、コードポイントがIDNA2008 [RFC5894]のDISALLOWEDプロパティを失うという（ありそうではないが、不可能ではない-セクション3.1.3を参照）イベントでは、既存のI-DUNNOは、悲惨な結果。
The following Confusion Levels are defined:
次の混同レベルが定義されています。
As a minimum, a valid I-DUNNO MUST:
少なくとも、有効なI-DUNNOは次の条件を満たす必要があります。
* Contain at least one UTF-8 octet sequence with a length greater than one octet.
* 1オクテットより長い、少なくとも1つのUTF-8オクテットシーケンスが含まれています。
* 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.
* IDNA2008で禁止されている文字が少なくとも1つ含まれている。コードポイントはありません！これにより、マシンはI-DUNNOを国際化ドメイン名ラベルから区別できるようになることに注意してください。
I-DUNNOs on this level will at least puzzle most human users with knowledge of the Legacy Notation.
このレベルのI-DUNNOは、レガシー表記法の知識で、ほとんどの人間のユーザーを少なくとも困惑させます。
An I-DUNNO with Satisfactory Confusion Level MUST adhere to the Minimum Confusion Level, and additionally contain two of the following:
満足のいく混乱レベルのI-DUNNOは、最小の混乱レベルを遵守する必要があり、さらに次の2つが含まれている必要があります。
* At least one non-printable character.
* 少なくとも1つの印刷できない文字。
* Characters from at least two different Scripts.
* 少なくとも2つの異なるスクリプトの文字。
* 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を変形させないようにするのに十分であると考えられています。
An I-DUNNO with Delightful Confusion Level MUST adhere to the Satisfactory Confusion Level, and additionally contain at least two of the following:
楽しい混乱レベルのI-DUNNOは、満足のいく混乱レベルに準拠している必要があり、さらに次の少なくとも2つが含まれている必要があります。
* Characters from scripts with different directionalities.
* 方向性の異なるスクリプトの文字。
* Character classified as "Confusables".
* 「Confusables」に分類されるキャラクター。
* One or more emoji.
* 1つ以上の絵文字。
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.
このレベルに準拠するI-DUNNOは、idna-updateメーリングリストに登録されているものを除いて、ほとんどすべての人間にU + 1F926を引き起こします。
(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.)
（また、暫定的に「BReak EXaminatIon or Twiddling」または「BREXIT」レベルの混乱と題された、さらに高い混乱レベルも検討しましたが、現在、実際にそれを実装する方法についてはわかりません。）
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
表2
The resulting string MUST be evaluated against the Confusion Level Requirements before I-DUNNO can be declared. Given the example above:
結果の文字列は、I-DUNNOを宣言する前に、混乱レベル要件に対して評価する必要があります。上記の例の場合：
* There is at least one UTF-8 octet sequence with a length greater than 1 (U+04A4) .
* 長さが1（U + 04A4）を超えるUTF-8オクテットシーケンスが少なくとも1つあります。
* There are two IDNA2008 DISALLOWED characters: U+000C (for good reason!) and U+04A4.
* 2つのIDNA2008 DISALLOWED文字があります。U+ 000C（正当な理由による！）とU + 04A4です。
* There is one non-printable character (U+000C).
* 印刷できない文字が1つあります（U + 000C）。
* There are characters from two different Scripts (Latin and Cyrillic).
* 2つの異なるスクリプト（ラテン語とキリル語）の文字があります。
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を構成します。特にU + 000Cは、I-DUNNOがプリンターに送信される環境で大きな可能性を秘めています。
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は、楽しい混乱レベルの少なくとも1つのI-DUNNOを許可しないすべての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）はレターとして宣言する必要があります。
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の他のセキュリティ面の評価は読者のための演習として残されています。
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<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>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<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>.
[RFC5894] Klensin、J。、「アプリケーションの国際化ドメイン名（IDNA）：背景、説明、および理論的根拠」、RFC 5894、DOI 10.17487 / RFC5894、2010年8月、<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>.
[RFC6919] Barnes、R.、Kent、S。、およびE. Rescorla、「RFCで使用して要件レベルを示すためのその他のキーワード」、RFC 6919、DOI 10.17487 / RFC6919、2013年4月、<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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、DOI 10.17487 / RFC0791、1981年9月、<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>.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、DOI 10.17487 / RFC1034、1987年11月、<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>.
[RFC1123] Braden、R。、編、「インターネットホストの要件-アプリケーションとサポート」、STD 3、RFC 1123、DOI 10.17487 / RFC1123、1989年10月、<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>.
[RFC1883] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 1883、DOI 10.17487 / RFC1883、1995年12月、<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>.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<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>.
[RFC5513]ファレル、A。、「3文字の頭字語に関するIANAの考慮事項」、RFC 5513、DOI 10.17487 / RFC5513、2009年4月、<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>.
[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>.
[RFC8200] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487 / RFC8200、2017年7月、<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>.
[RFC8369] Kaplan、H。、「Internationalizing IPv6 Using 128-Bit Unicode」、RFC 8369、DOI 10.17487 / RFC8369、2018年4月、<https://www.rfc-editor.org/info/rfc8369>。
[UNICODE] The Unicode Consortium, "The Unicode Standard (Current Version)", 2019, <http://www.unicode.org/versions/latest/>.
[UNICODE] Unicodeコンソーシアム、「The Unicode Standard（Current Version）」、2019、<http://www.unicode.org/versions/latest/>。
Authors' Addresses
著者のアドレス
Alexander Mayrhofer nic.at GmbH
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/