はじめに

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

IANA Considerations for Three Letter Acronyms（3文字略語のIANAに関する考慮事項）

Network Working Group
Request for Comments: 5513
Category: Informational

A. Farrel
Old Dog Consulting
1 April 2009

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

This memo provides information for the Internet community.
It does not specify an Internet standard of any kind.
Distribution of this memo is unlimited.

このメモは、インターネットコミュニティのための情報を提供するものである。
このメモは、いかなる種類のインターネット標準も規定するものではない。
このメモの配布は無制限である。

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Abstract（要約）

Three Letter Acronyms (TLAs) are commonly used to identify components of networks or protocols as designed or specified within the IETF.
A common concern is that one acronym may have multiple expansions.
While this may not have been an issue in the past, network convergence means that protocols that did not previously operate together are now found in close proximity.
This results in contention for acronyms, and confusion in interpretation.
Such confusion has the potential to degrade the performance of the Internet as misunderstandings lead to misconfiguration or other operating errors.

3文字略語(Three Letter Acronyms; TLA)は、IETF で設計または指定されたネットワークまたはプロトコルのコンポーネントを識別するために一般的に使用される。
一般的な懸念は、1つの略語が複数の意味を持つことである。
過去には問題にならなかったかもしれないが、ネットワークの集中によって、以前は一緒に動作しなかったプロトコルが、現在では近接して見られるようになったことを意味する。
その結果、略語の取り合いや解釈の混乱が発生することになる。
このような混乱は、誤解から設定ミスやその他の操作ミスにつながり、インターネットのパフォーマンスを低下させる可能性がある。

Given the growing use of TLAs and the relatively small number available, this document specifies a Badly Construed Proposal (BCP) for the management of a registry of TLAs within the IETF, and the procedures for the allocation of new TLAs from the registry.

TLA の使用が増加し、利用可能な数が比較的少ないことを考慮して、本文書は、IETF 内の TLA のレジストリの管理、およびレジストリからの新しい TLA の割り当て手順に関する「不適切な解釈の提案」(Badly Construed Proposal; BCP)を規定するものである。

1. Introduction（序論）

A Three-Letter Acronym (TLA) is a popular form of abbreviation usually based on the initial letters of a three-word term.
A formal definition of a TLA is provided in Section 2.

3文字略語(Three-Letter Acronym; TLA)とは、通常、3つの単語の頭文字を組み合わせた一般的な略語の一種である。
TLA の正式な定義は2章に記載する。

TLAs are particularly popular within the Internet community where they serve as abbreviations in the spoken and written word.
As their popularity has grown, the measure of the value of an RFC (q.v.) is not only its successful implementation, interoperability, and deployment, but also the number of TLAs included in the text.

TLA は、話し言葉や書き言葉で略語として使用されるインターネットコミュニティで特に人気がある。
その人気が高まるにつれ、RFC (参照) の価値を測る指標は、その実装、相互運用性、展開の成功だけでなく、本文中に含まれる TLA の数にもなっている。

For example, the Transmission Control Protocol (itself a TLA - TCP) [RFC0793] is extremely successful.
The specification contains no fewer than 20 distinct TLAs (although it should be noted that some are simple abbreviations rather than proper acronyms).
On the other hand, the Internet Stream Protocol Version 2 [RFC1819] is ambiguously referred to using the TLA ST2, and also as STII which is clearly not a TLA.
Further, the STII specification contains only 12 distinct TLAs, and it should be no surprise that STII has been far less successful than TCP.

たとえば、Transmission Control Protocol (それ自体がTLAでもある —— TCP) [RFC0793] は非常に成功している。
この仕様には、20以上の異なる TLA が含まれている(ただし、一部は適切な頭字略語ではなく、単純な略語であることに注意する必要がある)。
一方、インターネット・ストリーム・プロトコル・バージョン2 [RFC1819] は、TLA の ST2 を使用して曖昧に参照され、また、明らかに TLA ではない STII としても参照されている。
さらに、STII 仕様はわずか12個の異なる TLA を含んでおり、STII が TCP よりもはるかに低い成功率であることは驚くことではない。

A common concern amongst diligent protocol implementers is that one acronym may have multiple expansions.
While this may not have been an issue in the past, network convergence means that protocols that did not previously operate together are now found in close proximity.
Not only does this result in contention for acronyms, and confusion in interpretation of specification, it also leads to many wasted hours trying to select appropriate and suitably-unique names for variables within source code implementations.
Such confusion has the potential to degrade the performance of the Internet as misunderstandings lead to coding errors, compilation failures, misconfiguration, and other operating errors.

真面目なプロトコルの実装者の共通の懸念は、1つの頭字略語が複数の意味を持つことである。
過去には問題にならなかったかもしれないが、ネットワークの集中により、以前は一緒に動作しなかったプロトコルが、現在では近接して見られるようになったことを意味する。
その結果、略語の取り合いや仕様の解釈の混乱を招くだけでなく、ソースコードの実装において、適切で適切な固有の変数名を選択するために多くの時間を浪費することになる。
このような混乱は、コーディング誤り、コンパイルエラー、設定ミス、その他の操作ミスにつながるため、インターネットのパフォーマンスを低下させる可能性がある。

Furthermore, it should be noted that we are rapidly approaching World Acronym Depletion (WAD).
It has been estimated that, at the current rate of TLA allocation, we will run out by the end of September this year.
This timescale could be worsened if there is the expected growth in demand for mobile acronyms, IP-TLAs, and TLA-on-demand.
According to the definition provided in Section 2, there are 36**3 - 10**3 = 45656 TLAs in total.
This number will so easily be depleted that we must institute some policy for conservation.

さらに、世界的な頭字略語の枯渇(World Acronym Depletion; WAD)が急速に進行していることにも注目すべきである。
現在の TLA 割り当て率では、今年の9月末までに使い果たすと推定される。
今後、モバイル用頭字略語、IP-TLA、TLA-on-demand の需要拡大が予想される場合、このタイムスケールはさらに悪化する可能性がある。
2章の定義によると、$36^3 - 10^3 = 45656$ 個の TLA が存在する。
この数は簡単に枯渇してしまうため、何らかの保全策を講じる必要がある。

The Internet Assigned Numbers Authority (IANA, helpfully, a four-letter acronym - although note that a four-letter acronym is an FLA and hence is, in its own way, a TLA) maintains registries of names and numbers for use within the Internet in order to avoid duplicate allocation of one of those names or numbers and the consequent confusion and failed interoperability that would arise.
It is, therefore, wholly appropriate that the IANA should manage the assignment and use of TLAs within the Internet.

Internet Assigned Numbers Authority(IANA、4文字略語、ただし4文字略語(four-letter acronym)は FLA であり、したがってそれ自体は TLA であることに注意)は、インターネット内で使用する名前と番号のレジストリを管理し、それらの名前または番号の重複した割り当てを回避するため、結果として発生する混乱と相互運用性の問題を回避している。
したがって、IANA がインターネット内の TLA の割り当てと使用を管理することは、まったくもって適切である。

This document specifies a Badly Construed Proposal for the management of a registry of TLAs within the IETF, and the procedures for the allocation of new TLAs from the registry.

本文書は、IETF における TLA のレジストリ管理、およびレジストリからの新規 TLA の割り当て手順に関する BCP を規定するものである。

1.1. RFC Editor Terminology List（RFCエディター用語集）

It is worth observing that the RFC Editor currently maintains a list of common terms, abbreviations, and acronyms.
While this list is highly useful for the construction of documents, it does not provide unambiguous interpretation of acronyms.

RFCエディターが現在、一般的な用語、略語、頭字略語のリストを保持していることは、注目に値する。
このリストは文書を作成する上で非常に有用だが、頭字略語の明確な解釈を提供するものではない。

2. Formal Definition of TLA（TLAの正式定義）

Acronym - a word made up of the initial letters of the words in a phrase.

For example, IETF is an acronym formed from the first letters of the phrase International Essential Tremor Foundation [URL-IETF].

頭字略語 —— フレーズを構成する単語の頭文字を組み合わせて作られた言葉。

例えば、IETF は International Essential Tremor Foundation [URL-IETF] というフレーズの最初の文字から形成された頭字略語である。

Three Letter Acronym (TLA) - an acronym comprising exactly three letters.

For example, RFC is a TLA formed of the first letters of the phrase Rugby Football Club [URL-CARDIFF].

3文字略語 (TLA) - 正確に3文字で構成される頭字略語。

例えば、RFC はラグビー・フットボール・クラブ(Rugby Football Club) [URL-CARDIFF] というフレーズの最初の文字で構成されるTLAである。

For our usage, we also allow digits within a TLA.
Thus, P2P is an acronym meaning Purchase to Pay [URL-P2P].
The digits 2 and 4 are specially used by clever people who have noticed that, when spoken, they sound like the words 'to' and 'for'.
Whether this is helpful may be left as an exercise for the user considering the brief conversation, below.

我々の使い方では、TLA 内に数字も許容している。
したがって、P2P は「購入から支払いまで」(Purchase to Pay) [URL-P2P] を意味する頭字略語である。
2と4という数字は、英語の発音では「to」と「for」という言葉のように聞こえることに気づいた賢人たちによって特別に使われている。
これが役に立つかどうかは、次のような簡単な会話から判断すること。

   A - Do you use the Internet Streams Protocol?
   B - Yes.  Do you use ST, too?
   A - No, I use ST2.
   B - That's interesting.  C uses ST2, too.
   A - I have a car horn application called Toot-toot.
   B - Really? Do you use ST2 to Toot-toot, too?

A「Internet Streams Protocolを使用していますか？」
B「はい。 STも使っていますか？」
A「いいえ、ST2を使っています。」
B「それは面白い。 CもST2を使ってるんだ。」
A「Toot-tootっていう車のクラクションのアプリケーションを持ってるんだ。」
B「そうなんですか？Toot-tootもST2を使っているんですか？」

（訳注：訳文よりも、原文を発音してみた方がわかりやすい）

Note, however, that an acronym made up entirely of digits might be frowned upon.

ただし、数字だけの頭字略語は嫌われるだろう。

Lastly, we must consider case-sensitivity.
Although acronyms often include upper or lowercase letters, no assumptions should be made about the interpretation of the acronym based on the case of its letters, so that both QOS and QoS clearly refer to the Queen of the South football club [URL-QOS] and [URL-QoS].

最後に、大文字と小文字の区別を考慮する必要がある。
頭字略語にはしばしば大文字と小文字が含まれるが、頭字略語の解釈について文字の大文字と小文字を解釈してはならない。
したがって、QOSとQoSはどちらも明らかにサッカークラブのクイーン・オブ・ザ・サウス(Queen of the South)を指している [URL-QOS] [URL-QoS]。

2.1. A Note on Vocalization（発声に関する注意）

Acronyms are often articulated as words in spoken text.
This can be helpful in generating a cosy feel or a marketing buzz around a concept that offers a less-favorable reality.
For example, Claws and Teeth (CAT) can be pronounced "cat" making it seem quite cuddly.

頭字略語はしばしば話し言葉の中で単語として表現される。
これは、あまり好ましくない現実を提供するコンセプトの周りに、居心地の良い感じやマーケティングの話題を生成するために役立つ。
例えば、「爪と歯」(Claws and Teeth; CAT) は、「キャット」(猫)と発音することで、非常にかわいらしい印象を与える。

Other acronyms are always spelled out in order to avoid accidental misinterpretation or litigation.
For example, do not refer to your neighbor's Daughter or Granddaughter as anything other than their D-O-G.

その他の略語は、偶発的な誤解や訴訟を避けるために、常に1文字1文字読むように発音すること。
例えば、隣人の娘や孫娘(Daughter or Granddaughter)を D-O-G(ディー・オー・ジー)以外では呼ばないようにする。

But care should be taken with vocalization, as well.
It will be noted that some letters have more syllables than the words they are used to represent.
In these cases, acronyms are to be avoided.
Thus, the world wide web must never be assigned the acronym WWW.

しかし、発声にも注意が必要である。
文字によっては、その文字が表す言葉よりも音節が多いものがあることに注意しなければならない。
このような場合、頭字略語は避けなければならない。
したがって、ワールドワイドウェブ(world wide web)には決して WWW(ダブリュー・ダブリュー・ダブリュー)という頭文字を当ててはならない。

Finally, a word of caution about attempting to pronounce acronyms as words.
This can lead to serious injury for the inexperienced unless they happen to be native speakers of Czech.
Do not try to say XML in front of your mother-in-law, and don't attempt to talk about Open Office dot Org in polite company.

最後に、頭字略語を単語として発音しようとすることについても注意が必要である。
チェコ語を母国語とする人でない限り、経験の浅い人は大怪我をする可能性がある。
義母の前で XML と言ったり、お上品な会社で Open Office dot Org について話そうとしないようにすること。

3. Backward and Forward Compatibility（後方互換性と前方互換性）

It should be obvious to most RFC readers (MRRs) that TLAs are already widely used in Internet specifications.
This work is not intended to unnecessarily invalidate existing RFCs, although where such invalidation is necessary or desirable, this work can be used for that purpose.

TLA がすでにインターネット仕様で広く使用されていることは、ほとんどの RFC 読者 (most RFC readers; MRR) にとって明白である。
この作業は既存の RFC を不必要に無効にすることを意図していないが、そのような無効化が必要または望ましい場合、この作業をその目的のために使用することは可能である。

In order to support existing documents, IANA is required to search all existing RFCs for every existing acronym usage (EAU), but may filter that search to exclude non-TLAs.

既存の文書をサポートするために、IANA はすべての既存の頭字語の用法(existing acronym usage; EAU)についてすべての既存の RFC を検索することを要求されるが、非 TLA を除外するためにその検索をフィルタリングしてもよい。

It will be noted that, as a result of that search, many duplicate meanings will be discovered.
For example, "OAM" will be found in a large number of RFCs, yet its meaning may be as diverse as "on a mission", "order of Australia medal", and "orbital angular momentum".

その検索の結果、多くの重複する意味が発見されることに注意されたい。
例えば、"OAM" は多くの RFC で見られるが、その意味は "on a mission", "order of Australia medal", "orbital angular momentum" など多様であろう。

This contention is best resolved by the judgement of Solomon -- each acronym usage will be allocated its share of the letters currently in use.
If there are three uses of an acronym, they will get one letter each; two existing uses would get one-and-a-half letters each; etc.

この論争は、「ソロモンの審判」によって最もよく解決される —— それぞれの頭字略語の用法は、現在使用されている文字のシェアを割り当てることになる。
ある頭字略語の使い方が3つあれば、それぞれ1文字ずつ、既存の2つの使い方はそれぞれ1.5文字ずつ、といった具合だ。

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

4.1. New Registry（新しいレジストリ）

The Internet TLA Registry (ITR) should track the following information:

TLA

Unique interpretation

Defining RFC

インターネットTLAレジストリ(Internet TLA Registry; ITR)は、以下の情報を追跡する必要がある。

TLA
一意な解釈
定義するRFC

4.2. Reserved Values（予約済みの値）

Certain key values are reserved.
That is, they are allocated in the registry by this document and may not be used for any other purpose.

所定のキーとバリューは予約されている。
つまり、それらはこのドキュメントによってレジストリに割り当てられ、他の目的に使用することはできない。

  Acronym   Expansion                             Reference
  --------+-------------------------------------+-----------
  TLA       Two Letter Acronym                    [RFC5513]
  TBD       Two Be Deleted                        [RFC5513]
  RFC       Ready for Compost                     [RFC5513]
  PoS       Not particularly good                 [RFC5513]
  VPN       Very possibly no use                  [RFC5513]
  TCP       Totally bad proposal                  [RFC5513]
  USA       Universal Source of Acronyms          [RFC5513]
  NBG       This document                         [RFC5513]
  BCP       Badly construed proposal              [RFC5513]

3文字略語	意味	参照
TLA	2文字略語	[RFC5513]
TBD	削除された2つ	[RFC5513]
RFC	コンポストのための準備	[RFC5513]
PoS	特に良いところがない	[RFC5513]
VPN	使用しない可能性が高い	[RFC5513]
TCP	全くもってダメな提案	[RFC5513]
USA	略語の普遍的な源泉	[RFC5513]
NBG	このドキュメント	[RFC5513]
BCP	不適切な解釈の提案	[RFC5513]

4.3. Allocation Policy（割り当てポリシー）

IANA shall apply the following allocation policies according to [RFC5226].

IANAは、[RFC5226] に従って、以下の割り当て方針を適用するものとする。

Experimental Use（実験的使用）

All TLAs of the form XX* where * is any letter or digit.

XX* 形式のすべてのTLA(*は任意の文字または数字)。

First Come First Served（先着順割り当て）

All TLAs of the form X**, Y**, or Z** where * is any letter or digit.
Excepted from this are the TLAs of the form XX* as above.

X**、Y**、Z**のいずれかの形式のすべての TLA（*は任意の文字または数字）。
ただし、上記の XX* 形式の TLA を除く。

IETF Review

All other TLAs.

その他すべての TLA。

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

Many security algorithms are identified by TLAs.
It is a clear requirement that someone implementing, for example, MD5 should be understood to have encoded the well-known Maybe-Decrypted-Deciphered-Decoded-Disambiguated-and-Degraded algorithm, and not any other security algorithm with the same acronym.

多くのセキュリティアルゴリズムは、TLAによって識別される。
例えば MD5 を実装する人は、よく知られた Maybe-Decrypted-Deciphered-Decoded-Disambiguated-and-Degraded アルゴリズム（訳注：たぶん復号化され、解読され、デコードされ不明瞭で劣化したアルゴリズムの意？）を符号化したと理解されるべきで、同じ頭文字を持つ他のセキュリティアルゴリズムではないことは明らかな要件である。

6. Acknowledgements（謝辞）

I would like to thank the MPLS-TP design team for holding seemingly endless meetings during which the need for this document became apparent.

Thanks to Daniel King for noticing that this document is a BCP.

この文書の必要性が明らかになったとき、終わりの見えないミーティングを開いてくれた MPLS-TP デザインチームに感謝したい。

この文書がBCPであることに気づいてくれた Daniel King に感謝する。

7. References

7.1. Normative References

   [RFC5226]     Narten, T. and H. Alvestrand, "Guidelines for Writing
                 an IANA Considerations Section in RFCs", BCP 26, RFC
                 5226, May 2008.

7.2. Informative References

   [RFC0793]     Postel, J., "Transmission Control Protocol", STD 7, RFC
                 793, September 1981.

   [RFC1819]     Delgrossi, L., Ed., and L. Berger, Ed., "Internet
                 Stream Protocol Version 2 (ST2) Protocol Specification
                 - Version ST2+", RFC 1819, August 1995.

   [URL-IETF]    International Essential Tremor Foundation,
                 http://www.essentialtremor.org/

   [URL-CARDIFF] Cardiff Rugby Football Club, http://www.cardiffrfc.com/

   [URL-P2P]     eProcumentStotl@nd,
                 http://www.eprocurementscotland.com/Home/ePS-
                 Service/P2P

   [URL-QOS]     Queen of the South Football Club, http://www.qosfc.com/

   [URL-QoS]     Queen of the South Football Club, http://www.qosfc.com/

Author's Address

   Adrian Farrel
   Old Dog Consulting
   EMail: adrian@olddog.co.uk