[要約] RFC 4122は、UUID（Universally Unique IDentifier）のURN（Uniform Resource Name）名前空間に関する規格であり、UUIDの生成と表現方法を定義しています。その目的は、一意な識別子の生成と使用を標準化し、異なるシステム間でのデータの一貫性を確保することです。
Network Working Group P. Leach
Request for Comments: 4122 Microsoft
Category: Standards Track M. Mealling
Refactored Networks, LLC
R. Salz
DataPower Technology, Inc.
July 2005
A Universally Unique IDentifier (UUID) URN Namespace
ユニバーサルユニークIDentifier（UUID）URN名前空間
Status of This Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（C）The Internet Society（2005）。
Abstract
概要
This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation's (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms.
この仕様は、GUID（Globally Unique IDentifier）とも呼ばれるUUID（Universally Unique IDentifier）のUniform Resource Name名前空間を定義します。 UUIDは128ビット長であり、空間と時間全体の一意性を保証できます。 UUIDは元々Apollo Network Computing Systemで使用され、その後Open Software Foundation（OSF）の分散コンピューティング環境（DCE）で使用され、その後Microsoft Windowsプラットフォームで使用されました。
This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document.
この仕様は、OSF（現在はThe Open Groupとして知られています）の許可を得て、DCE仕様から派生しています。 DCE仕様の以前のバージョンの情報は、このドキュメントに組み込まれています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Namespace Registration Template . . . . . . . . . . . . . . . 3
4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Format. . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. Variant. . . . . . . . . . . . . . . . . . . . . . 6
4.1.2. Layout and Byte Order. . . . . . . . . . . . . . . 6
4.1.3. Version. . . . . . . . . . . . . . . . . . . . . . 7
4.1.4. Timestamp. . . . . . . . . . . . . . . . . . . . . 8
4.1.5. Clock Sequence . . . . . . . . . . . . . . . . . . 8
4.1.6. Node . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.7. Nil UUID . . . . . . . . . . . . . . . . . . . . . 9
4.2. Algorithms for Creating a Time-Based UUID . . . . . . . . 9
4.2.1. Basic Algorithm. . . . . . . . . . . . . . . . . . 10
4.2.2. Generation Details . . . . . . . . . . . . . . . . 12
4.3. Algorithm for Creating a Name-Based UUID. . . . . . . . . 13
4.4. Algorithms for Creating a UUID from Truly Random or
Pseudo-Random Numbers . . . . . . . . . . . . . . . . . . 14
4.5. Node IDs that Do Not Identify the Host. . . . . . . . . . 15
5. Community Considerations . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
8. Normative References . . . . . . . . . . . . . . . . . . . . . 16
A. Appendix A - Sample Implementation . . . . . . . . . . . . . . 18
B. Appendix B - Sample Output of utest . . . . . . . . . . . . . 29
C. Appendix C - Some Name Space IDs . . . . . . . . . . . . . . . 30
This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and requires no central registration process.
この仕様は、GUID（Globally Unique IDentifier）とも呼ばれるUUID（Universally Unique IDentifier）のUniform Resource Name名前空間を定義します。 UUIDは128ビット長で、中央登録プロセスを必要としません。
The information here is meant to be a concise guide for those wishing to implement services using UUIDs as URNs. Nothing in this document should be construed to override the DCE standards that defined UUIDs.
ここの情報は、URNとしてUUIDを使用してサービスを実装したい人のための簡潔なガイドとなることを意図しています。このドキュメントでは、UUIDを定義したDCE標準をオーバーライドするものと解釈してはなりません。
There is an ITU-T Recommendation and ISO/IEC Standard [3] that are derived from earlier versions of this document. Both sets of specifications have been aligned, and are fully technically compatible. In addition, a global registration function is being provided by the Telecommunications Standardisation Bureau of ITU-T; for details see <http://www.itu.int/ITU-T/asn1/uuid.html>.
このドキュメントの以前のバージョンから派生したITU-T勧告とISO / IEC標準[3]があります。仕様の両方のセットが調整され、完全に技術的に互換性があります。さらに、ITU-Tの電気通信標準化局によってグローバル登録機能が提供されています。詳細については、<http://www.itu.int/ITU-T/asn1/uuid.html>を参照してください。
One of the main reasons for using UUIDs is that no centralized authority is required to administer them (although one format uses IEEE 802 node identifiers, others do not). As a result, generation on demand can be completely automated, and used for a variety of purposes. The UUID generation algorithm described here supports very high allocation rates of up to 10 million per second per machine if necessary, so that they could even be used as transaction IDs.
UUIDを使用する主な理由の1つは、UUIDを管理するために一元化された権限が必要ないことです（1つの形式はIEEE 802ノード識別子を使用しますが、他の形式は使用しません）。その結果、オンデマンドでの生成を完全に自動化し、さまざまな目的に使用できます。ここで説明するUUID生成アルゴリズムは、必要に応じてマシンあたり1秒あたり最大1,000万という非常に高い割り当て率をサポートしているため、トランザクションIDとしても使用できます。
UUIDs are of a fixed size (128 bits) which is reasonably small compared to other alternatives. This lends itself well to sorting, ordering, and hashing of all sorts, storing in databases, simple allocation, and ease of programming in general.
UUIDは固定サイズ（128ビット）で、他の代替と比較してかなり小さいです。これは、すべての種類の並べ替え、順序付け、ハッシュ化、データベースへの格納、単純な割り当て、および一般的なプログラミングの容易さに適しています。
Since UUIDs are unique and persistent, they make excellent Uniform Resource Names. The unique ability to generate a new UUID without a registration process allows for UUIDs to be one of the URNs with the lowest minting cost.
UUIDは一意で永続的であるため、優れたUniform Resource Nameになります。登録プロセスなしで新しいUUIDを生成する独自の機能により、UUIDを最小の鋳造コストでURNの1つにすることができます。
Namespace ID: UUID Registration Information: Registration date: 2003-10-01
名前空間ID：UUID登録情報：登録日：2003-10-01
Declared registrant of the namespace: JTC 1/SC6 (ASN.1 Rapporteur Group)
名前空間の登録者として宣言：JTC 1 / SC6（ASN.1 Rapporteur Group）
Declaration of syntactic structure: A UUID is an identifier that is unique across both space and time, with respect to the space of all UUIDs. Since a UUID is a fixed size and contains a time field, it is possible for values to rollover (around A.D. 3400, depending on the specific algorithm used). A UUID can be used for multiple purposes, from tagging objects with an extremely short lifetime, to reliably identifying very persistent objects across a network.
構文構造の宣言：UUIDは、すべてのUUIDの空間に関して、空間と時間の両方で一意の識別子です。 UUIDは固定サイズで時間フィールドが含まれているため、値がロールオーバーされる可能性があります（使用される特定のアルゴリズムによっては、A.D。3400あたり）。 UUIDは、ライフタイムが非常に短いオブジェクトにタグを付けることから、ネットワーク全体で非常に永続的なオブジェクトを確実に識別することまで、さまざまな目的で使用できます。
The internal representation of a UUID is a specific sequence of bits in memory, as described in Section 4. To accurately represent a UUID as a URN, it is necessary to convert the bit sequence to a string representation.
セクション4で説明するように、UUIDの内部表現はメモリ内の特定のビットシーケンスです。UUIDをURNとして正確に表現するには、ビットシーケンスを文字列表現に変換する必要があります。
Each field is treated as an integer and has its value printed as a zero-filled hexadecimal digit string with the most significant digit first. The hexadecimal values "a" through "f" are output as lower case characters and are case insensitive on input.
各フィールドは整数として扱われ、その値はゼロで埋められた16進数の文字列として出力され、最上位の数字が最初に表示されます。 16進値 "a"から "f"は小文字として出力され、入力では大文字と小文字は区別されません。
The formal definition of the UUID string representation is provided by the following ABNF [7]:
UUID文字列表現の正式な定義は、次のABNF [7]によって提供されます。
UUID = time-low "-" time-mid "-"
time-high-and-version "-"
clock-seq-and-reserved
clock-seq-low "-" node
time-low = 4hexOctet
time-mid = 2hexOctet
time-high-and-version = 2hexOctet
clock-seq-and-reserved = hexOctet
clock-seq-low = hexOctet
node = 6hexOctet
hexOctet = hexDigit hexDigit
hexDigit =
"0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" /
"a" / "b" / "c" / "d" / "e" / "f" /
"A" / "B" / "C" / "D" / "E" / "F"
The following is an example of the string representation of a UUID as a URN:
以下は、URNとしてのUUIDの文字列表現の例です。
urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
urn：uuid：f81d4fae-7dec-11d0-a765-00a0c91e6bf6
Relevant ancillary documentation: [1][2] Identifier uniqueness considerations: This document specifies three algorithms to generate UUIDs: the first leverages the unique values of 802 MAC addresses to guarantee uniqueness, the second uses pseudo-random number generators, and the third uses cryptographic hashing and application-provided text strings. As a result, the UUIDs generated according to the mechanisms here will be unique from all other UUIDs that have been or will be assigned.
関連する補助ドキュメント：[1] [2]識別子の一意性に関する考慮事項：このドキュメントでは、UUIDを生成する3つのアルゴリズムを指定します。最初のアルゴリズムは、802 MACアドレスの一意の値を利用して一意性を保証し、2番目は疑似乱数ジェネレータを使用し、3番目は使用します暗号化ハッシュおよびアプリケーション提供のテキスト文字列。その結果、ここでのメカニズムに従って生成されたUUIDは、割り当てられている、または割り当てられる他のすべてのUUIDとは異なります。
Identifier persistence considerations: UUIDs are inherently very difficult to resolve in a global sense. This, coupled with the fact that UUIDs are temporally unique within their spatial context, ensures that UUIDs will remain as persistent as possible.
識別子の永続性に関する考慮事項：UUIDは本質的にグローバルな意味で解決するのが非常に困難です。これは、UUIDが空間コンテキスト内で一時的に一意であるという事実と相まって、UUIDが可能な限り永続的なままであることを保証します。
Process of identifier assignment: Generating a UUID does not require that a registration authority be contacted. One algorithm requires a unique value over space for each generator. This value is typically an IEEE 802 MAC address, usually already available on network-connected hosts. The address can be assigned from an address block obtained from the IEEE registration authority. If no such address is available, or privacy concerns make its use undesirable, Section 4.5 specifies two alternatives. Another approach is to use version 3 or version 4 UUIDs as defined below.
識別子割り当てのプロセス：UUIDを生成するために、登録機関に連絡する必要はありません。 1つのアルゴリズムでは、ジェネレーターごとにスペース全体で一意の値が必要です。この値は通常、IEEE 802 MACアドレスであり、通常、ネットワーク接続されたホストですでに利用可能です。アドレスは、IEEE登録局から取得したアドレスブロックから割り当てることができます。そのようなアドレスが利用できない場合、またはプライバシーの懸念によりその使用が望ましくない場合は、セクション4.5で2つの選択肢を指定します。別のアプローチは、以下に定義されているようにバージョン3またはバージョン4のUUIDを使用することです。
Process for identifier resolution: Since UUIDs are not globally resolvable, this is not applicable.
識別子解決のプロセス：UUIDはグローバルに解決できないため、これは適用されません。
Rules for Lexical Equivalence: Consider each field of the UUID to be an unsigned integer as shown in the table in section Section 4.1.2. Then, to compare a pair of UUIDs, arithmetically compare the corresponding fields from each UUID in order of significance and according to their data type. Two UUIDs are equal if and only if all the corresponding fields are equal.
字句の同等性のルール：セクション4.1.2の表に示すように、UUIDの各フィールドを符号なし整数と見なします。次に、UUIDのペアを比較するために、各UUIDの対応するフィールドを、データの順序に従って、重要度順に算術的に比較します。 2つのUUIDが等しいのは、対応するフィールドがすべて等しい場合だけです。
As an implementation note, equality comparison can be performed on many systems by doing the appropriate byte-order canonicalization, and then treating the two UUIDs as 128-bit unsigned integers.
実装上の注意として、同等の比較は、適切なバイト順の正規化を実行し、2つのUUIDを128ビットの符号なし整数として処理することにより、多くのシステムで実行できます。
UUIDs, as defined in this document, can also be ordered lexicographically. For a pair of UUIDs, the first one follows the second if the most significant field in which the UUIDs differ is greater for the first UUID. The second precedes the first if the most significant field in which the UUIDs differ is greater for the second UUID.
このドキュメントで定義されているUUIDは、辞書式順序で並べることもできます。 UUIDのペアの場合、最初のUUIDのUUIDが異なる最も重要なフィールドが大きい場合、最初のUUIDは2番目のUUIDの後に続きます。 2番目のUUIDのUUIDが異なる最も重要なフィールドが大きい場合、2番目のフィールドが最初のフィールドに先行します。
Conformance with URN Syntax: The string representation of a UUID is fully compatible with the URN syntax. When converting from a bit-oriented, in-memory representation of a UUID into a URN, care must be taken to strictly adhere to the byte order issues mentioned in the string representation section.
URN構文への準拠：UUIDの文字列表現は、URN構文と完全に互換性があります。 UUIDのビット指向のメモリ内表現からURNに変換するときは、文字列表現のセクションで説明したバイトオーダーの問題に厳密に従う必要があります。
Validation mechanism: Apart from determining whether the timestamp portion of the UUID is in the future and therefore not yet assignable, there is no mechanism for determining whether a UUID is 'valid'.
検証メカニズム：UUIDのタイムスタンプ部分が将来のものであり、したがってまだ割り当て可能かどうかを判断すること以外に、UUIDが「有効」かどうかを判断するメカニズムはありません。
Scope: UUIDs are global in scope.
スコープ：UUIDはスコープ内でグローバルです。
The UUID format is 16 octets; some bits of the eight octet variant field specified below determine finer structure.
UUID形式は16オクテットです。以下に指定された8オクテットバリアントフィールドのいくつかのビットは、より細かい構造を決定します。
The variant field determines the layout of the UUID. That is, the interpretation of all other bits in the UUID depends on the setting of the bits in the variant field. As such, it could more accurately be called a type field; we retain the original term for compatibility. The variant field consists of a variable number of the most significant bits of octet 8 of the UUID.
バリアントフィールドは、UUIDのレイアウトを決定します。つまり、UUIDの他のすべてのビットの解釈は、バリアントフィールドのビットの設定に依存します。そのため、より正確にタイプフィールドと呼ぶことができます。互換性のために元の用語を保持します。バリアントフィールドは、UUIDのオクテット8の可変ビットの最上位ビットで構成されます。
The following table lists the contents of the variant field, where the letter "x" indicates a "don't-care" value.
次の表は、バリアントフィールドの内容を示しています。文字「x」は「ドントケア」の値を示しています。
Msb0 Msb1 Msb2 Description
Msb0 Msb1 Msb2説明
0 x x Reserved, NCS backward compatibility.
0 x x予約済み、NCS下位互換性。
1 0 x The variant specified in this document.
1 0 xこのドキュメントで指定されているバリアント。
1 1 0 Reserved, Microsoft Corporation backward compatibility
1 1 0予約済み、Microsoft Corporationの下位互換性
1 1 1 Reserved for future definition.
1 1 1将来の定義のために予約されています。
Interoperability, in any form, with variants other than the one defined here is not guaranteed, and is not likely to be an issue in practice.
ここで定義されているもの以外のバリアントとの相互運用性は、保証されておらず、実際に問題になることはほとんどありません。
To minimize confusion about bit assignments within octets, the UUID record definition is defined only in terms of fields that are integral numbers of octets. The fields are presented with the most significant one first.
オクテット内のビット割り当てに関する混乱を最小限に抑えるため、UUIDレコード定義は、オクテットの整数であるフィールドに関してのみ定義されます。フィールドには、最も重要なフィールドが最初に表示されます。
Field Data Type Octet Note #
フィールドデータタイプオクテットノート＃
time_low unsigned 32 0-3 The low field of the bit integer timestamp
time_low unsigned 32 0-3ビット整数タイムスタンプの低フィールド
time_mid unsigned 16 4-5 The middle field of the bit integer timestamp
time_mid unsigned 16 4-5ビット整数タイムスタンプの中央フィールド
time_hi_and_version unsigned 16 6-7 The high field of the bit integer timestamp multiplexed with the version number
time_hi_and_version unsigned 16 6-7バージョン番号と多重化されたビット整数タイムスタンプの高フィールド
clock_seq_hi_and_rese unsigned 8 8 The high field of the rved bit integer clock sequence multiplexed with the variant
clock_seq_hi_and_rese unsigned 8 8バリアントと多重化された可変ビット整数クロックシーケンスの高フィールド
clock_seq_low unsigned 8 9 The low field of the bit integer clock sequence
clock_seq_low unsigned 8 9ビット整数クロックシーケンスの低フィールド
node unsigned 48 10-15 The spatially unique bit integer node identifier
node unsigned 48 10-15空間的に一意のビット整数ノード識別子
In the absence of explicit application or presentation protocol specification to the contrary, a UUID is encoded as a 128-bit object, as follows:
それとは逆に、明示的なアプリケーションまたはプレゼンテーションプロトコルの仕様がない場合、UUIDは次のように128ビットオブジェクトとしてエンコードされます。
The fields are encoded as 16 octets, with the sizes and order of the fields defined above, and with each field encoded with the Most Significant Byte first (known as network byte order). Note that the field names, particularly for multiplexed fields, follow historical practice.
フィールドは16オクテットとしてエンコードされ、サイズとフィールドの順序は上記で定義され、各フィールドは最初に最上位バイト（ネットワークバイトオーダーと呼ばれる）でエンコードされます。特に多重化されたフィールドのフィールド名は、歴史的な慣例に従っていることに注意してください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time_low |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time_mid | time_hi_and_version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|clk_seq_hi_res | clk_seq_low | node (0-1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| node (2-5) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The version number is in the most significant 4 bits of the time stamp (bits 4 through 7 of the time_hi_and_version field).
バージョン番号は、タイムスタンプの最上位4ビット（time_hi_and_versionフィールドのビット4〜7）にあります。
The following table lists the currently-defined versions for this UUID variant.
次の表に、このUUIDバリアントの現在定義されているバージョンを示します。
Msb0 Msb1 Msb2 Msb3 Version Description
Msb0 Msb1 Msb2 Msb3バージョン説明
0 0 0 1 1 The time-based version specified in this document.
0 0 0 1 1このドキュメントで指定されている時間ベースのバージョン。
0 0 1 0 2 DCE Security version, with embedded POSIX UIDs.
0 0 1 0 2 POSIX UIDが埋め込まれたDCEセキュリティバージョン。
0 0 1 1 3 The name-based version specified in this document that uses MD5 hashing.
0 0 1 1 3このドキュメントで指定されている、MD5ハッシュを使用する名前ベースのバージョン。
0 1 0 0 4 The randomly or pseudo-randomly generated version specified in this document.
0 1 0 0 4このドキュメントで指定されているランダムまたは疑似ランダムに生成されたバージョン。
0 1 0 1 5 The name-based version specified in this document that uses SHA-1 hashing.
0 1 0 1 5このドキュメントで指定されている、SHA-1ハッシュを使用する名前ベースのバージョン。
The version is more accurately a sub-type; again, we retain the term for compatibility.
バージョンはより正確にはサブタイプです。繰り返しになりますが、互換性の用語はそのまま残しています。
The timestamp is a 60-bit value. For UUID version 1, this is represented by Coordinated Universal Time (UTC) as a count of 100- nanosecond intervals since 00:00:00.00, 15 October 1582 (the date of Gregorian reform to the Christian calendar).
タイムスタンプは60ビット値です。 UUIDバージョン1の場合、これは協定世界時（UTC）によって、1582年10月15日の00：00：00.00（キリスト教暦へのグレゴリオ暦の改定の日付）以降の100ナノ秒間隔のカウントとして表されます。
For systems that do not have UTC available, but do have the local time, they may use that instead of UTC, as long as they do so consistently throughout the system. However, this is not recommended since generating the UTC from local time only needs a time zone offset.
UTCは利用できないが現地時間はあるシステムの場合、システム全体で一貫して使用されている限り、UTCの代わりにそれを使用できます。ただし、現地時間からUTCを生成するのに必要なのはタイムゾーンオフセットだけなので、これはお勧めできません。
For UUID version 3 or 5, the timestamp is a 60-bit value constructed from a name as described in Section 4.3.
UUIDバージョン3または5の場合、タイムスタンプは、セクション4.3で説明されている名前から構成される60ビット値です。
For UUID version 4, the timestamp is a randomly or pseudo-randomly generated 60-bit value, as described in Section 4.4.
UUIDバージョン4の場合、タイムスタンプは、セクション4.4で説明されているように、ランダムまたは疑似ランダムに生成された60ビット値です。
For UUID version 1, the clock sequence is used to help avoid duplicates that could arise when the clock is set backwards in time or if the node ID changes.
UUIDバージョン1の場合、クロックシーケンスは、クロックが時間的に逆に設定されている場合、またはノードIDが変更された場合に発生する可能性のある重複を回避するために使用されます。
If the clock is set backwards, or might have been set backwards (e.g., while the system was powered off), and the UUID generator can not be sure that no UUIDs were generated with timestamps larger than the value to which the clock was set, then the clock sequence has to be changed. If the previous value of the clock sequence is known, it can just be incremented; otherwise it should be set to a random or high-quality pseudo-random value.
クロックが逆に設定されている場合、または逆に設定されている可能性がある場合（システムの電源がオフになっている場合など）、UUIDジェネレーターは、クロックが設定された値より大きいタイムスタンプを持つUUIDが生成されなかったことを確認できません。次に、クロックシーケンスを変更する必要があります。クロックシーケンスの以前の値がわかっている場合は、インクリメントできます。それ以外の場合は、ランダムまたは高品質の疑似ランダム値に設定する必要があります。
Similarly, if the node ID changes (e.g., because a network card has been moved between machines), setting the clock sequence to a random number minimizes the probability of a duplicate due to slight differences in the clock settings of the machines. If the value of clock sequence associated with the changed node ID were known, then the clock sequence could just be incremented, but that is unlikely.
同様に、ノードIDが変更された場合（たとえば、ネットワークカードがマシン間で移動されたため）、クロックシーケンスを乱数に設定すると、マシンのクロック設定のわずかな違いによる重複の可能性が最小限に抑えられます。変更されたノードIDに関連付けられたクロックシーケンスの値がわかっている場合、クロックシーケンスはインクリメントされるだけですが、それはありそうもありません。
The clock sequence MUST be originally (i.e., once in the lifetime of a system) initialized to a random number to minimize the correlation across systems. This provides maximum protection against node identifiers that may move or switch from system to system rapidly. The initial value MUST NOT be correlated to the node identifier.
クロックシーケンスは、システム全体の相関を最小限に抑えるために、最初に（つまり、システムの存続期間に1回）乱数に初期化する必要があります。これにより、システムからシステムに急速に移動または切り替わる可能性のあるノード識別子に対する最大の保護が提供されます。初期値はノード識別子と相関してはいけません。
For UUID version 3 or 5, the clock sequence is a 14-bit value constructed from a name as described in Section 4.3.
UUIDバージョン3または5の場合、クロックシーケンスは、セクション4.3で説明されている名前から構築された14ビット値です。
For UUID version 4, clock sequence is a randomly or pseudo-randomly generated 14-bit value as described in Section 4.4.
UUIDバージョン4の場合、4.4で説明されているように、クロックシーケンスはランダムまたは擬似ランダムに生成された14ビット値です。
For UUID version 1, the node field consists of an IEEE 802 MAC address, usually the host address. For systems with multiple IEEE 802 addresses, any available one can be used. The lowest addressed octet (octet number 10) contains the global/local bit and the unicast/multicast bit, and is the first octet of the address transmitted on an 802.3 LAN.
UUIDバージョン1の場合、ノードフィールドはIEEE 802 MACアドレス、通常はホストアドレスで構成されます。複数のIEEE 802アドレスを持つシステムの場合、使用可能なアドレスを使用できます。最も低いアドレス指定オクテット（オクテット番号10）には、グローバル/ローカルビットとユニキャスト/マルチキャストビットが含まれており、802.3 LANで送信されるアドレスの最初のオクテットです。
For systems with no IEEE address, a randomly or pseudo-randomly generated value may be used; see Section 4.5. The multicast bit must be set in such addresses, in order that they will never conflict with addresses obtained from network cards.
IEEEアドレスを持たないシステムの場合、ランダムまたは擬似ランダムに生成された値を使用できます。セクション4.5を参照してください。マルチキャストビットは、ネットワークカードから取得したアドレスと競合しないように、そのようなアドレスに設定する必要があります。
For UUID version 3 or 5, the node field is a 48-bit value constructed from a name as described in Section 4.3.
UUIDバージョン3または5の場合、ノードフィールドは、セクション4.3で説明されている名前から構築された48ビット値です。
For UUID version 4, the node field is a randomly or pseudo-randomly generated 48-bit value as described in Section 4.4.
UUIDバージョン4の場合、ノードフィールドは、セクション4.4で説明されているように、ランダムまたは疑似ランダムに生成された48ビット値です。
The nil UUID is special form of UUID that is specified to have all 128 bits set to zero.
nil UUIDは、128ビットすべてをゼロに設定するように指定されたUUIDの特殊な形式です。
Various aspects of the algorithm for creating a version 1 UUID are discussed in the following sections.
以下のセクションでは、バージョン1 UUIDを作成するためのアルゴリズムのさまざまな側面について説明します。
The following algorithm is simple, correct, and inefficient:
次のアルゴリズムは単純で正確で非効率的です。
o Obtain a system-wide global lock
o システム全体のグローバルロックを取得する
o From a system-wide shared stable store (e.g., a file), read the UUID generator state: the values of the timestamp, clock sequence, and node ID used to generate the last UUID.
o システム全体の共有安定ストア（ファイルなど）から、UUIDジェネレーターの状態（タイムスタンプの値、クロックシーケンス、最後のUUIDの生成に使用されたノードID）を読み取ります。
o Get the current time as a 60-bit count of 100-nanosecond intervals since 00:00:00.00, 15 October 1582.
o 現在の時刻を、1582年10月15日の00：00：00.00以降の100ナノ秒間隔の60ビットカウントとして取得します。
o Get the current node ID.
o 現在のノードIDを取得します。
o If the state was unavailable (e.g., non-existent or corrupted), or the saved node ID is different than the current node ID, generate a random clock sequence value.
o 状態が利用できない（存在しない、破損しているなど）か、保存されたノードIDが現在のノードIDと異なる場合は、ランダムなクロックシーケンス値を生成します。
o If the state was available, but the saved timestamp is later than the current timestamp, increment the clock sequence value.
o 状態は利用可能であるが、保存されたタイムスタンプが現在のタイムスタンプよりも遅い場合は、クロックシーケンス値をインクリメントします。
o Save the state (current timestamp, clock sequence, and node ID) back to the stable store.
o 状態（現在のタイムスタンプ、クロックシーケンス、ノードID）を安定したストアに保存します。
o Release the global lock.
o グローバルロックを解放します。
o Format a UUID from the current timestamp, clock sequence, and node ID values according to the steps in Section 4.2.2.
o セクション4.2.2の手順に従って、現在のタイムスタンプ、クロックシーケンス、ノードID値からUUIDをフォーマットします。
If UUIDs do not need to be frequently generated, the above algorithm may be perfectly adequate. For higher performance requirements, however, issues with the basic algorithm include:
UUIDを頻繁に生成する必要がない場合は、上記のアルゴリズムで十分です。ただし、より高いパフォーマンス要件の場合、基本的なアルゴリズムの問題には次のものがあります。
o Reading the state from stable storage each time is inefficient.
o 安定したストレージから状態を毎回読み取るのは非効率的です。
o The resolution of the system clock may not be 100-nanoseconds.
o システムクロックの解像度は100ナノ秒ではない場合があります。
o Writing the state to stable storage each time is inefficient.
o 状態を安定したストレージに毎回書き込むのは非効率的です。
o Sharing the state across process boundaries may be inefficient.
o プロセスの境界を越えて状態を共有すると、非効率になる場合があります。
Each of these issues can be addressed in a modular fashion by local improvements in the functions that read and write the state and read the clock. We address each of them in turn in the following sections.
これらの各問題は、状態の読み取りと書き込み、およびクロックの読み取りを行う機能をローカルで改善することにより、モジュール方式で対処できます。次のセクションでは、それぞれについて順に説明します。
The state only needs to be read from stable storage once at boot time, if it is read into a system-wide shared volatile store (and updated whenever the stable store is updated).
状態がシステム全体の共有揮発性ストアに読み込まれる場合（および安定ストアが更新されるたびに更新される場合）、状態は起動時に安定ストレージから一度だけ読み取る必要があります。
If an implementation does not have any stable store available, then it can always say that the values were unavailable. This is the least desirable implementation because it will increase the frequency of creation of new clock sequence numbers, which increases the probability of duplicates.
実装に利用可能な安定したストアがない場合、常に値が利用できなかったと言うことができます。新しいクロックシーケンス番号が作成される頻度が高くなり、重複の可能性が高くなるため、これは最も望ましくない実装です。
If the node ID can never change (e.g., the net card is inseparable from the system), or if any change also reinitializes the clock sequence to a random value, then instead of keeping it in stable store, the current node ID may be returned.
ノードIDが変更できない場合（たとえば、ネットカードがシステムから切り離せない場合）、または変更によってクロックシーケンスがランダムな値に再初期化される場合は、安定したストアに保持する代わりに、現在のノードIDが返されることがあります。 。
The timestamp is generated from the system time, whose resolution may be less than the resolution of the UUID timestamp.
タイムスタンプはシステム時刻から生成され、その解像度はUUIDタイムスタンプの解像度よりも低い場合があります。
If UUIDs do not need to be frequently generated, the timestamp can simply be the system time multiplied by the number of 100-nanosecond intervals per system time interval.
UUIDを頻繁に生成する必要がない場合、タイムスタンプは、システム時間にシステム時間間隔あたりの100ナノ秒間隔の数を掛けたものにすることができます。
If a system overruns the generator by requesting too many UUIDs within a single system time interval, the UUID service MUST either return an error, or stall the UUID generator until the system clock catches up.
システムが単一のシステム時間間隔内に要求するUUIDが多すぎるためにジェネレーターがオーバーランする場合、UUIDサービスはエラーを返すか、システムクロックが追いつくまでUUIDジェネレーターを停止させる必要があります。
A high resolution timestamp can be simulated by keeping a count of the number of UUIDs that have been generated with the same value of the system time, and using it to construct the low order bits of the timestamp. The count will range between zero and the number of 100-nanosecond intervals per system time interval.
システム時刻と同じ値で生成されたUUIDの数をカウントし、それを使用してタイムスタンプの下位ビットを構築することにより、高解像度のタイムスタンプをシミュレートできます。カウントの範囲は、ゼロからシステム時間間隔ごとの100ナノ秒間隔の数までです。
Note: If the processors overrun the UUID generation frequently, additional node identifiers can be allocated to the system, which will permit higher speed allocation by making multiple UUIDs potentially available for each time stamp value.
注：プロセッサーがUUID生成を頻繁にオーバーランする場合、追加のノードIDをシステムに割り当てることができます。これにより、各タイムスタンプ値に複数のUUIDを使用できるようになるため、より高速な割り当てが可能になります。
The state does not always need to be written to stable store every time a UUID is generated. The timestamp in the stable store can be periodically set to a value larger than any yet used in a UUID. As long as the generated UUIDs have timestamps less than that value, and the clock sequence and node ID remain unchanged, only the shared volatile copy of the state needs to be updated. Furthermore, if the timestamp value in stable store is in the future by less than the typical time it takes the system to reboot, a crash will not cause a reinitialization of the clock sequence.
UUIDが生成されるたびに、状態を常に安定したストアに書き込む必要はありません。安定したストアのタイムスタンプは、UUIDでまだ使用されていない値よりも大きい値に定期的に設定できます。生成されたUUIDのタイムスタンプがその値よりも小さく、クロックシーケンスとノードIDが変更されていない限り、状態の共有揮発性コピーのみを更新する必要があります。さらに、安定したストアのタイムスタンプ値が将来、システムの再起動にかかる通常の時間より短い場合、クラッシュによってクロックシーケンスが再初期化されることはありません。
If it is too expensive to access shared state each time a UUID is generated, then the system-wide generator can be implemented to allocate a block of time stamps each time it is called; a per-process generator can allocate from that block until it is exhausted.
UUIDが生成されるたびに共有状態にアクセスするにはコストがかかりすぎる場合は、システム全体のジェネレーターを実装して、呼び出されるたびにタイムスタンプのブロックを割り当てることができます。プロセスごとのジェネレータは、そのブロックが使い尽くされるまでそのブロックから割り当てることができます。
Version 1 UUIDs are generated according to the following algorithm:
バージョン1のUUIDは、次のアルゴリズムに従って生成されます。
o Determine the values for the UTC-based timestamp and clock sequence to be used in the UUID, as described in Section 4.2.1.
o セクション4.2.1の説明に従って、UUIDで使用されるUTCベースのタイムスタンプとクロックシーケンスの値を決定します。
o For the purposes of this algorithm, consider the timestamp to be a 60-bit unsigned integer and the clock sequence to be a 14-bit unsigned integer. Sequentially number the bits in a field, starting with zero for the least significant bit.
o このアルゴリズムでは、タイムスタンプを60ビットの符号なし整数、クロックシーケンスを14ビットの符号なし整数と見なします。最下位ビットのゼロから始めて、フィールドのビットに順番に番号を付けます。
o Set the time_low field equal to the least significant 32 bits (bits zero through 31) of the timestamp in the same order of significance.
o time_lowフィールドを、タイムスタンプの最下位32ビット（ビット0から31）と同じ順序で同じ順序で設定します。
o Set the time_mid field equal to bits 32 through 47 from the timestamp in the same order of significance.
o 同じ重要度の順序でタイムスタンプからビット32〜47に等しいtime_midフィールドを設定します。
o Set the 12 least significant bits (bits zero through 11) of the time_hi_and_version field equal to bits 48 through 59 from the timestamp in the same order of significance.
o time_hi_and_versionフィールドの12の最下位ビット（ビット0〜11）を、タイムスタンプのビット48〜59と同じ順序で、重要度の同じ順に設定します。
o Set the four most significant bits (bits 12 through 15) of the time_hi_and_version field to the 4-bit version number corresponding to the UUID version being created, as shown in the table above.
o 上記の表に示すように、time_hi_and_versionフィールドの最上位4ビット（ビット12〜15）を、作成するUUIDバージョンに対応する4ビットバージョン番号に設定します。
o Set the clock_seq_low field to the eight least significant bits (bits zero through 7) of the clock sequence in the same order of significance.
o clock_seq_lowフィールドを、クロックシーケンスの最下位8ビット（ビット0〜7）に、同じ重要度の順序で設定します。
o Set the 6 least significant bits (bits zero through 5) of the clock_seq_hi_and_reserved field to the 6 most significant bits (bits 8 through 13) of the clock sequence in the same order of significance.
o clock_seq_hi_and_reservedフィールドの最下位6ビット（ビット0〜5）を、クロックシーケンスの最上位6ビット（ビット8〜13）と同じ順序で設定します。
o Set the two most significant bits (bits 6 and 7) of the clock_seq_hi_and_reserved to zero and one, respectively.
o clock_seq_hi_and_reservedの最上位2ビット（ビット6と7）をそれぞれ0と1に設定します。
o Set the node field to the 48-bit IEEE address in the same order of significance as the address.
o ノードフィールドを、アドレスと同じ順序で48ビットIEEEアドレスに設定します。
The version 3 or 5 UUID is meant for generating UUIDs from "names" that are drawn from, and unique within, some "name space". The concept of name and name space should be broadly construed, and not limited to textual names. For example, some name spaces are the domain name system, URLs, ISO Object IDs (OIDs), X.500 Distinguished Names (DNs), and reserved words in a programming language. The mechanisms or conventions used for allocating names and ensuring their uniqueness within their name spaces are beyond the scope of this specification.
バージョン3または5のUUIDは、「名前空間」から抽出され、その中で一意である「名前」からUUIDを生成するためのものです。名前と名前空間の概念は広く解釈されるべきであり、テキストの名前に限定されません。たとえば、一部の名前空間は、ドメインネームシステム、URL、ISOオブジェクトID（OID）、X.500識別名（DN）、およびプログラミング言語の予約語です。名前の割り当てと名前空間内での一意性の確保に使用されるメカニズムまたは規則は、この仕様の範囲を超えています。
The requirements for these types of UUIDs are as follows:
これらのタイプのUUIDの要件は次のとおりです。
o The UUIDs generated at different times from the same name in the same namespace MUST be equal.
o 同じ名前空間の同じ名前から異なる時間に生成されたUUIDは同じでなければなりません。
o The UUIDs generated from two different names in the same namespace should be different (with very high probability).
o 同じ名前空間内の2つの異なる名前から生成されたUUIDは、異なる可能性があります（非常に高い確率で）。
o The UUIDs generated from the same name in two different namespaces should be different with (very high probability).
o 2つの異なる名前空間で同じ名前から生成されたUUIDは、異なる可能性があります（非常に高い確率）。
o If two UUIDs that were generated from names are equal, then they were generated from the same name in the same namespace (with very high probability).
o 名前から生成された2つのUUIDが等しい場合、それらは同じ名前空間の同じ名前から生成されました（非常に高い確率で）。
The algorithm for generating a UUID from a name and a name space are as follows:
名前と名前空間からUUIDを生成するアルゴリズムは次のとおりです。
o Allocate a UUID to use as a "name space ID" for all UUIDs generated from names in that name space; see Appendix C for some pre-defined values.
o その名前空間の名前から生成されたすべてのUUIDの「名前空間ID」として使用するUUIDを割り当てます。定義済みの値については、付録Cを参照してください。
o Choose either MD5 [4] or SHA-1 [8] as the hash algorithm; If backward compatibility is not an issue, SHA-1 is preferred.
o ハッシュアルゴリズムとしてMD5 [4]またはSHA-1 [8]を選択します。下位互換性が問題でない場合は、SHA-1が推奨されます。
o Convert the name to a canonical sequence of octets (as defined by the standards or conventions of its name space); put the name space ID in network byte order.
o 名前をオクテットの標準的なシーケンスに変換します（その名前空間の標準または規則で定義されています）。名前空間IDをネットワークのバイト順に並べます。
o Compute the hash of the name space ID concatenated with the name.
o 名前と連結された名前空間IDのハッシュを計算します。
o Set octets zero through 3 of the time_low field to octets zero through 3 of the hash.
o time_lowフィールドのオクテット0〜3をハッシュのオクテット0〜3に設定します。
o Set octets zero and one of the time_mid field to octets 4 and 5 of the hash.
o オクテット0とtime_midフィールドの1つをハッシュのオクテット4および5に設定します。
o Set octets zero and one of the time_hi_and_version field to octets 6 and 7 of the hash.
o オクテット0およびtime_hi_and_versionフィールドの1つをハッシュのオクテット6および7に設定します。
o Set the four most significant bits (bits 12 through 15) of the time_hi_and_version field to the appropriate 4-bit version number from Section 4.1.3.
o time_hi_and_versionフィールドの最上位4ビット（ビット12〜15）を、セクション4.1.3の適切な4ビットバージョン番号に設定します。
o Set the clock_seq_hi_and_reserved field to octet 8 of the hash.
o clock_seq_hi_and_reservedフィールドをハッシュのオクテット8に設定します。
o Set the two most significant bits (bits 6 and 7) of the clock_seq_hi_and_reserved to zero and one, respectively.
o clock_seq_hi_and_reservedの最上位2ビット（ビット6と7）をそれぞれ0と1に設定します。
o Set the clock_seq_low field to octet 9 of the hash.
o clock_seq_lowフィールドをハッシュのオクテット9に設定します。
o Set octets zero through five of the node field to octets 10 through 15 of the hash.
o ノードフィールドのオクテット0〜5をハッシュのオクテット10〜15に設定します。
o Convert the resulting UUID to local byte order.
o 結果のUUIDをローカルバイトオーダーに変換します。
4.4. Algorithms for Creating a UUID from Truly Random or Pseudo-Random Numbers
4.4. 真の乱数または疑似乱数からUUIDを作成するためのアルゴリズム
The version 4 UUID is meant for generating UUIDs from truly-random or pseudo-random numbers.
バージョン4のUUIDは、真に乱数または疑似乱数からUUIDを生成するためのものです。
The algorithm is as follows:
アルゴリズムは次のとおりです。
o Set the two most significant bits (bits 6 and 7) of the clock_seq_hi_and_reserved to zero and one, respectively.
o clock_seq_hi_and_reservedの最上位2ビット（ビット6と7）をそれぞれ0と1に設定します。
o Set the four most significant bits (bits 12 through 15) of the time_hi_and_version field to the 4-bit version number from Section 4.1.3.
o time_hi_and_versionフィールドの最上位4ビット（ビット12〜15）を、セクション4.1.3の4ビットバージョン番号に設定します。
o Set all the other bits to randomly (or pseudo-randomly) chosen values.
o 他のすべてのビットをランダムに（または疑似ランダムに）選択した値に設定します。
See Section 4.5 for a discussion on random numbers.
乱数の説明については、セクション4.5を参照してください。
This section describes how to generate a version 1 UUID if an IEEE 802 address is not available, or its use is not desired.
このセクションでは、IEEE 802アドレスが使用できない場合、またはその使用が望ましくない場合に、バージョン1 UUIDを生成する方法について説明します。
One approach is to contact the IEEE and get a separate block of addresses. At the time of writing, the application could be found at <http://standards.ieee.org/regauth/oui/pilot-ind.html>, and the cost was US$550.
1つのアプローチは、IEEEに連絡して、個別のアドレスブロックを取得することです。執筆時点では、アプリケーションは<http://standards.ieee.org/regauth/oui/pilot-ind.html>にあり、費用は550ドルでした。
A better solution is to obtain a 47-bit cryptographic quality random number and use it as the low 47 bits of the node ID, with the least significant bit of the first octet of the node ID set to one. This bit is the unicast/multicast bit, which will never be set in IEEE 802 addresses obtained from network cards. Hence, there can never be a conflict between UUIDs generated by machines with and without network cards. (Recall that the IEEE 802 spec talks about transmission order, which is the opposite of the in-memory representation that is discussed in this document.)
より良い解決策は、47ビットの暗号品質の乱数を取得し、それをノードIDの下位47ビットとして使用し、ノードIDの最初のオクテットの最下位ビットを1に設定することです。このビットはユニキャスト/マルチキャストビットであり、ネットワークカードから取得したIEEE 802アドレスでは設定されません。したがって、ネットワークカードがあるマシンとないカードで生成されたUUIDが競合することは決してありません。 （IEEE 802仕様は送信順序について話していることを思い出してください。これは、このドキュメントで説明されているメモリ内表現の反対です。）
For compatibility with earlier specifications, note that this document uses the unicast/multicast bit, instead of the arguably more correct local/global bit.
以前の仕様との互換性のために、このドキュメントでは、間違いなくより正確なローカル/グローバルビットの代わりに、ユニキャスト/マルチキャストビットを使用していることに注意してください。
Advice on generating cryptographic-quality random numbers can be found in RFC1750 [5].
暗号品質の乱数の生成に関するアドバイスは、RFC1750 [5]にあります。
In addition, items such as the computer's name and the name of the operating system, while not strictly speaking random, will help differentiate the results from those obtained by other systems.
さらに、厳密にはランダムではありませんが、コンピューターの名前やオペレーティングシステムの名前などの項目は、他のシステムで得られた結果と区別するのに役立ちます。
The exact algorithm to generate a node ID using these data is system specific, because both the data available and the functions to obtain them are often very system specific. A generic approach, however, is to accumulate as many sources as possible into a buffer, use a message digest such as MD5 [4] or SHA-1 [8], take an arbitrary 6 bytes from the hash value, and set the multicast bit as described above.
これらのデータを使用してノードIDを生成する正確なアルゴリズムは、システム固有です。これは、利用可能なデータとそれらを取得する関数の両方が非常にシステム固有であることが多いためです。ただし、一般的なアプローチは、できるだけ多くのソースをバッファに蓄積し、MD5 [4]やSHA-1 [8]などのメッセージダイジェストを使用し、ハッシュ値から任意の6バイトを取得して、マルチキャストを設定することです。上記のビット。
The use of UUIDs is extremely pervasive in computing. They comprise the core identifier infrastructure for many operating systems (Microsoft Windows) and applications (the Mozilla browser) and in many cases, become exposed to the Web in many non-standard ways.
UUIDの使用は、コンピューティングにおいて非常に広まっています。これらは、多くのオペレーティングシステム（Microsoft Windows）およびアプリケーション（Mozillaブラウザ）のコア識別子インフラストラクチャを構成し、多くの場合、非標準的な方法でWebに公開されます。
This specification attempts to standardize that practice as openly as possible and in a way that attempts to benefit the entire Internet.
この仕様は、その慣行をできるだけオープンに、インターネット全体に利益をもたらすように標準化しようとしています。
Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access), for example. A predictable random number source will exacerbate the situation.
UUIDが推測しにくいと思い込まないでください。たとえば、セキュリティ機能（単なる所有物がアクセスを許可する識別子）として使用しないでください。予測可能な乱数ソースは状況を悪化させます。
Do not assume that it is easy to determine if a UUID has been slightly transposed in order to redirect a reference to another object. Humans do not have the ability to easily check the integrity of a UUID by simply glancing at it.
参照を別のオブジェクトにリダイレクトするために、UUIDがわずかに転置されているかどうかを簡単に判断できるとは限りません。人間は、単にそれをちらっと見ただけではUUIDの完全性を簡単にチェックすることができません。
Distributed applications generating UUIDs at a variety of hosts must be willing to rely on the random number source at all hosts. If this is not feasible, the namespace variant should be used.
さまざまなホストでUUIDを生成する分散アプリケーションは、すべてのホストで乱数ソースに依存する必要があります。これが不可能な場合は、名前空間バリアントを使用する必要があります。
This document draws heavily on the OSF DCE specification for UUIDs. Ted Ts'o provided helpful comments, especially on the byte ordering section which we mostly plagiarized from a proposed wording he supplied (all errors in that section are our responsibility, however).
このドキュメントは、UUIDのOSF DCE仕様に重点を置いています。 Ted Ts'oは、彼が提供した提案された表現からほとんど盗用したバイト順序セクションについて、役立つコメントを提供しました（ただし、そのセクションのすべてのエラーは私たちの責任です）。
We are also grateful to the careful reading and bit-twiddling of Ralf S. Engelschall, John Larmouth, and Paul Thorpe. Professor Larmouth was also invaluable in achieving coordination with ISO/IEC.
ラルフ・S・エンゲルシャル、ジョン・ラーマス、ポール・ソープの注意深い読みといじりにも感謝しています。ラーマス教授はまた、ISO / IECとの調整を達成する上で非常に貴重でした。
[1] Zahn, L., Dineen, T., and P. Leach, "Network Computing Architecture", ISBN 0-13-611674-4, January 1990.
[1] Zahn、L.、Dineen、T。、およびP. Leach、「Network Computing Architecture」、ISBN 0-13-611674-4、1990年1月。
[2] "DCE: Remote Procedure Call", Open Group CAE Specification C309, ISBN 1-85912-041-5, August 1994.
[2] 「DCE：リモートプロシージャコール」、Open Group CAE仕様C309、ISBN 1-85912-041-5、1994年8月。
[3] ISO/IEC 9834-8:2004 Information Technology, "Procedures for the operation of OSI Registration Authorities: Generation and registration of Universally Unique Identifiers (UUIDs) and their use as ASN.1 Object Identifier components" ITU-T Rec. X.667, 2004.
[3] ISO / IEC 9834-8：2004情報技術、「OSI Registration Authoritiesの運用手順：Universally Unique Identifier（UUID）の生成と登録、およびASN.1 Object Identifierコンポーネントとしての使用」ITU-T Rec。 X.667、2004。
[4] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC 1321, April 1992.
[4] Rivest、R。、「MD5メッセージダイジェストアルゴリズム」、RFC 1321、1992年4月。
[5] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[5] Eastlake、D.、3rd、Schiller、J.、and S. Crocker、 "Randomness Requirements for Security"、BCP 106、RFC 4086、June 2005。
[6] Moats, R., "URN Syntax", RFC 2141, May 1997.
[6] Moats、R。、「URN構文」、RFC 2141、1997年5月。
[7] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[7] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、RFC 2234、1997年11月。
[8] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-1, April 1995, <http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
[8] 国立標準技術研究所、「Secure Hash Standard」、FIPS PUB 180-1、1995年4月、<http://www.itl.nist.gov/fipspubs/fip180-1.htm>。
This implementation consists of 5 files: uuid.h, uuid.c, sysdep.h, sysdep.c and utest.c. The uuid.* files are the system independent implementation of the UUID generation algorithms described above, with all the optimizations described above except efficient state sharing across processes included. The code has been tested on Linux (Red Hat 4.0) with GCC (2.7.2), and Windows NT 4.0 with VC++ 5.0. The code assumes 64-bit integer support, which makes it much clearer.
この実装は、uuid.h、uuid.c、sysdep.h、sysdep.c、およびutest.cの5つのファイルで構成されています。 uuid。*ファイルは、上記のUUID生成アルゴリズムのシステムに依存しない実装であり、プロセス間の効率的な状態共有を除いて、上記のすべての最適化が含まれています。コードは、GCC（2.7.2）を搭載したLinux（Red Hat 4.0）、およびVC ++ 5.0を搭載したWindows NT 4.0でテストされています。コードは64ビット整数のサポートを想定しているため、より明確になります。
All the following source files should have the following copyright notice included:
以下のすべてのソースファイルには、次の著作権表示を含める必要があります。
copyrt.h
copyrt.h
/*
** Copyright (c) 1990- 1993, 1996 Open Software Foundation, Inc.
** Copyright (c) 1989 by Hewlett-Packard Company, Palo Alto, Ca. &
** Digital Equipment Corporation, Maynard, Mass.
** Copyright (c) 1998 Microsoft.
** To anyone who acknowledges that this file is provided "AS IS"
** without any express or implied warranty: permission to use, copy,
** modify, and distribute this file for any purpose is hereby
** granted without fee, provided that the above copyright notices and
** this notice appears in all source code copies, and that none of
** the names of Open Software Foundation, Inc., Hewlett-Packard
** Company, Microsoft, or Digital Equipment Corporation be used in
** advertising or publicity pertaining to distribution of the software
** without specific, written prior permission. Neither Open Software
** Foundation, Inc., Hewlett-Packard Company, Microsoft, nor Digital
** Equipment Corporation makes any representations about the
** suitability of this software for any purpose.
*/
uuid.h
uuid.h
#include "copyrt.h"
#undef uuid_t
typedef struct {
unsigned32 time_low;
unsigned16 time_mid;
unsigned16 time_hi_and_version;
unsigned8 clock_seq_hi_and_reserved;
unsigned8 clock_seq_low;
byte node[6];
} uuid_t;
/* uuid_create -- generate a UUID */
int uuid_create(uuid_t * uuid);
/* uuid_create_md5_from_name -- create a version 3 (MD5) UUID using a
"name" from a "name space" */
void uuid_create_md5_from_name(
uuid_t *uuid, /* resulting UUID */
uuid_t nsid, /* UUID of the namespace */
void *name, /* the name from which to generate a UUID */
int namelen /* the length of the name */
);
/* uuid_create_sha1_from_name -- create a version 5 (SHA-1) UUID
using a "name" from a "name space" */
void uuid_create_sha1_from_name(
uuid_t *uuid, /* resulting UUID */
uuid_t nsid, /* UUID of the namespace */
void *name, /* the name from which to generate a UUID */
int namelen /* the length of the name */
);
/* uuid_compare -- Compare two UUID's "lexically" and return
-1 u1 is lexically before u2
0 u1 is equal to u2
1 u1 is lexically after u2
Note that lexical ordering is not temporal ordering!
*/
int uuid_compare(uuid_t *u1, uuid_t *u2);
uuid.c
uuid.c
#include "copyrt.h"
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include "sysdep.h"
#include "uuid.h"
/* various forward declarations */
static int read_state(unsigned16 *clockseq, uuid_time_t *timestamp,
uuid_node_t *node);
static void write_state(unsigned16 clockseq, uuid_time_t timestamp,
uuid_node_t node);
static void format_uuid_v1(uuid_t *uuid, unsigned16 clockseq,
uuid_time_t timestamp, uuid_node_t node);
static void format_uuid_v3or5(uuid_t *uuid, unsigned char hash[16],
int v);
static void get_current_time(uuid_time_t *timestamp);
static unsigned16 true_random(void);
/* uuid_create -- generator a UUID */
int uuid_create(uuid_t *uuid)
{
uuid_time_t timestamp, last_time;
unsigned16 clockseq;
uuid_node_t node;
uuid_node_t last_node;
int f;
/* acquire system-wide lock so we're alone */
LOCK;
/* get time, node ID, saved state from non-volatile storage */
get_current_time(×tamp);
get_ieee_node_identifier(&node);
f = read_state(&clockseq, &last_time, &last_node);
/* if no NV state, or if clock went backwards, or node ID
changed (e.g., new network card) change clockseq */
if (!f || memcmp(&node, &last_node, sizeof node))
clockseq = true_random();
else if (timestamp < last_time)
clockseq++;
/* save the state for next time */
write_state(clockseq, timestamp, node);
UNLOCK;
ロック解除;
/* stuff fields into the UUID */
format_uuid_v1(uuid, clockseq, timestamp, node);
return 1;
}
/* format_uuid_v1 -- make a UUID from the timestamp, clockseq,
and node ID */
void format_uuid_v1(uuid_t* uuid, unsigned16 clock_seq,
uuid_time_t timestamp, uuid_node_t node)
{
/* Construct a version 1 uuid with the information we've gathered
plus a few constants. */
uuid->time_low = (unsigned long)(timestamp & 0xFFFFFFFF);
uuid->time_mid = (unsigned short)((timestamp >> 32) & 0xFFFF);
uuid->time_hi_and_version =
(unsigned short)((timestamp >> 48) & 0x0FFF);
uuid->time_hi_and_version |= (1 << 12);
uuid->clock_seq_low = clock_seq & 0xFF;
uuid->clock_seq_hi_and_reserved = (clock_seq & 0x3F00) >> 8;
uuid->clock_seq_hi_and_reserved |= 0x80;
memcpy(&uuid->node, &node, sizeof uuid->node);
}
/* data type for UUID generator persistent state */
typedef struct {
uuid_time_t ts; /* saved timestamp */
uuid_node_t node; /* saved node ID */
unsigned16 cs; /* saved clock sequence */
} uuid_state;
static uuid_state st;
静的uuid_state st;
/* read_state -- read UUID generator state from non-volatile store */
int read_state(unsigned16 *clockseq, uuid_time_t *timestamp,
uuid_node_t *node)
{
static int inited = 0;
FILE *fp;
/* only need to read state once per boot */
if (!inited) {
fp = fopen("state", "rb");
if (fp == NULL)
return 0;
fread(&st, sizeof st, 1, fp);
fclose(fp);
inited = 1;
}
*clockseq = st.cs;
*timestamp = st.ts;
*node = st.node;
return 1;
}
/* write_state -- save UUID generator state back to non-volatile
storage */
void write_state(unsigned16 clockseq, uuid_time_t timestamp,
uuid_node_t node)
{
static int inited = 0;
static uuid_time_t next_save;
FILE* fp;
if (!inited) {
next_save = timestamp;
inited = 1;
}
/* always save state to volatile shared state */
st.cs = clockseq;
st.ts = timestamp;
st.node = node;
if (timestamp >= next_save) {
fp = fopen("state", "wb");
fwrite(&st, sizeof st, 1, fp);
fclose(fp);
/* schedule next save for 10 seconds from now */
next_save = timestamp + (10 * 10 * 1000 * 1000);
}
}
/* get-current_time -- get time as 60-bit 100ns ticks since UUID epoch.
Compensate for the fact that real clock resolution is
less than 100ns. */
void get_current_time(uuid_time_t *timestamp)
{
static int inited = 0;
static uuid_time_t time_last;
static unsigned16 uuids_this_tick;
uuid_time_t time_now;
if (!inited) {
get_system_time(&time_now);
uuids_this_tick = UUIDS_PER_TICK;
inited = 1;
}
for ( ; ; ) {
get_system_time(&time_now);
/* if clock reading changed since last UUID generated, */
if (time_last != time_now) {
/* reset count of uuids gen'd with this clock reading */
uuids_this_tick = 0;
time_last = time_now;
break;
}
if (uuids_this_tick < UUIDS_PER_TICK) {
uuids_this_tick++;
break;
}
/* going too fast for our clock; spin */
}
/* add the count of uuids to low order bits of the clock reading */
*timestamp = time_now + uuids_this_tick;
}
/* true_random -- generate a crypto-quality random number.
**This sample doesn't do that.** */
static unsigned16 true_random(void)
{
static int inited = 0;
uuid_time_t time_now;
if (!inited) {
get_system_time(&time_now);
time_now = time_now / UUIDS_PER_TICK;
srand((unsigned int)
(((time_now >> 32) ^ time_now) & 0xffffffff));
inited = 1;
}
return rand();
}
/* uuid_create_md5_from_name -- create a version 3 (MD5) UUID using a
"name" from a "name space" */
void uuid_create_md5_from_name(uuid_t *uuid, uuid_t nsid, void *name,
int namelen)
{
MD5_CTX c;
unsigned char hash[16];
uuid_t net_nsid;
/* put name space ID in network byte order so it hashes the same
no matter what endian machine we're on */
net_nsid = nsid;
net_nsid.time_low = htonl(net_nsid.time_low);
net_nsid.time_mid = htons(net_nsid.time_mid);
net_nsid.time_hi_and_version = htons(net_nsid.time_hi_and_version);
MD5Init(&c);
MD5Update(&c, &net_nsid, sizeof net_nsid);
MD5Update(&c, name, namelen);
MD5Final(hash, &c);
/* the hash is in network byte order at this point */
format_uuid_v3or5(uuid, hash, 3);
}
void uuid_create_sha1_from_name(uuid_t *uuid, uuid_t nsid, void *name,
int namelen)
{
SHA_CTX c;
unsigned char hash[20];
uuid_t net_nsid;
/* put name space ID in network byte order so it hashes the same
no matter what endian machine we're on */
net_nsid = nsid;
net_nsid.time_low = htonl(net_nsid.time_low);
net_nsid.time_mid = htons(net_nsid.time_mid);
net_nsid.time_hi_and_version = htons(net_nsid.time_hi_and_version);
SHA1_Init(&c);
SHA1_Update(&c, &net_nsid, sizeof net_nsid);
SHA1_Update(&c, name, namelen);
SHA1_Final(hash, &c);
/* the hash is in network byte order at this point */
format_uuid_v3or5(uuid, hash, 5);
}
/* format_uuid_v3or5 -- make a UUID from a (pseudo)random 128-bit
number */
void format_uuid_v3or5(uuid_t *uuid, unsigned char hash[16], int v)
{
/* convert UUID to local byte order */
memcpy(uuid, hash, sizeof *uuid);
uuid->time_low = ntohl(uuid->time_low);
uuid->time_mid = ntohs(uuid->time_mid);
uuid->time_hi_and_version = ntohs(uuid->time_hi_and_version);
/* put in the variant and version bits */
uuid->time_hi_and_version &= 0x0FFF;
uuid->time_hi_and_version |= (v << 12);
uuid->clock_seq_hi_and_reserved &= 0x3F;
uuid->clock_seq_hi_and_reserved |= 0x80;
}
/* uuid_compare -- Compare two UUID's "lexically" and return */
#define CHECK(f1, f2) if (f1 != f2) return f1 < f2 ? -1 : 1;
int uuid_compare(uuid_t *u1, uuid_t *u2)
{
int i;
CHECK(u1->time_low, u2->time_low);
CHECK(u1->time_mid, u2->time_mid);
CHECK(u1->time_hi_and_version, u2->time_hi_and_version);
CHECK(u1->clock_seq_hi_and_reserved, u2->clock_seq_hi_and_reserved);
CHECK(u1->clock_seq_low, u2->clock_seq_low)
for (i = 0; i < 6; i++) {
if (u1->node[i] < u2->node[i])
return -1;
if (u1->node[i] > u2->node[i])
return 1;
}
return 0;
}
#undef CHECK
sysdep.h
sysdep.h
#include "copyrt.h"
/* remove the following define if you aren't running WIN32 */
#define WININC 0
#ifdef WININC
#include <windows.h>
#else
#include <sys/types.h>
#include <sys/time.h>
#include <sys/sysinfo.h>
#endif
#include "global.h"
/* change to point to where MD5 .h's live; RFC 1321 has sample
implementation */
#include "md5.h"
/* set the following to the number of 100ns ticks of the actual
resolution of your system's clock */
#define UUIDS_PER_TICK 1024
/* Set the following to a calls to get and release a global lock */
#define LOCK
#define UNLOCK
typedef unsigned long unsigned32;
typedef unsigned short unsigned16;
typedef unsigned char unsigned8;
typedef unsigned char byte;
/* Set this to what your compiler uses for 64-bit data type */
#ifdef WININC
#define unsigned64_t unsigned __int64
#define I64(C) C
#else
#define unsigned64_t unsigned long long
#define I64(C) C##LL
#endif
typedef unsigned64_t uuid_time_t;
typedef struct {
char nodeID[6];
} uuid_node_t;
void get_ieee_node_identifier(uuid_node_t *node);
void get_system_time(uuid_time_t *uuid_time);
void get_random_info(char seed[16]);
sysdep.c
sysdep.c
#include "copyrt.h"
#include <stdio.h>
#include "sysdep.h"
/* system dependent call to get IEEE node ID.
This sample implementation generates a random node ID. */
void get_ieee_node_identifier(uuid_node_t *node)
{
static inited = 0;
static uuid_node_t saved_node;
char seed[16];
FILE *fp;
if (!inited) {
fp = fopen("nodeid", "rb");
if (fp) {
fread(&saved_node, sizeof saved_node, 1, fp);
fclose(fp);
}
else {
get_random_info(seed);
seed[0] |= 0x01;
memcpy(&saved_node, seed, sizeof saved_node);
fp = fopen("nodeid", "wb");
if (fp) {
fwrite(&saved_node, sizeof saved_node, 1, fp);
fclose(fp);
}
}
inited = 1;
}
*node = saved_node;
}
/* system dependent call to get the current system time. Returned as
100ns ticks since UUID epoch, but resolution may be less than
100ns. */
#ifdef _WINDOWS_
void get_system_time(uuid_time_t *uuid_time)
{
ULARGE_INTEGER time;
/* NT keeps time in FILETIME format which is 100ns ticks since
Jan 1, 1601. UUIDs use time in 100ns ticks since Oct 15, 1582.
The difference is 17 Days in Oct + 30 (Nov) + 31 (Dec)
+ 18 years and 5 leap days. */
GetSystemTimeAsFileTime((FILETIME *)&time);
time.QuadPart +=
(unsigned __int64) (1000*1000*10) // seconds
* (unsigned __int64) (60 * 60 * 24) // days
* (unsigned __int64) (17+30+31+365*18+5); // # of days
*uuid_time = time.QuadPart;
}
/* Sample code, not for use in production; see RFC 1750 */
void get_random_info(char seed[16])
{
MD5_CTX c;
struct {
MEMORYSTATUS m;
SYSTEM_INFO s;
FILETIME t;
LARGE_INTEGER pc;
DWORD tc;
DWORD l;
char hostname[MAX_COMPUTERNAME_LENGTH + 1];
} r;
MD5Init(&c);
GlobalMemoryStatus(&r.m);
GetSystemInfo(&r.s);
GetSystemTimeAsFileTime(&r.t);
QueryPerformanceCounter(&r.pc);
r.tc = GetTickCount();
r.l = MAX_COMPUTERNAME_LENGTH + 1;
GetComputerName(r.hostname, &r.l);
MD5Update(&c, &r, sizeof r);
MD5Final(seed, &c);
}
#else
＃そうしないと
void get_system_time(uuid_time_t *uuid_time)
{
struct timeval tp;
gettimeofday(&tp, (struct timezone *)0);
/* Offset between UUID formatted times and Unix formatted times.
UUID UTC base time is October 15, 1582.
Unix base time is January 1, 1970.*/
*uuid_time = ((unsigned64)tp.tv_sec * 10000000)
+ ((unsigned64)tp.tv_usec * 10)
+ I64(0x01B21DD213814000);
}
/* Sample code, not for use in production; see RFC 1750 */
void get_random_info(char seed[16])
{
MD5_CTX c;
struct {
struct sysinfo s;
struct timeval t;
char hostname[257];
} r;
MD5Init(&c);
sysinfo(&r.s);
gettimeofday(&r.t, (struct timezone *)0);
gethostname(r.hostname, 256);
MD5Update(&c, &r, sizeof r);
MD5Final(seed, &c);
}
#endif
#endif
utest.c
utest.c
#include "copyrt.h"
#include "sysdep.h"
#include <stdio.h>
#include "uuid.h"
uuid_t NameSpace_DNS = { /* 6ba7b810-9dad-11d1-80b4-00c04fd430c8 */
0x6ba7b810,
0x9dad,
0x11d1,
0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8
};
/* puid -- print a UUID */
void puid(uuid_t u)
{
int i;
printf("%8.8x-%4.4x-%4.4x-%2.2x%2.2x-", u.time_low, u.time_mid,
u.time_hi_and_version, u.clock_seq_hi_and_reserved,
u.clock_seq_low);
for (i = 0; i < 6; i++)
printf("%2.2x", u.node[i]);
printf("\n");
}
/* Simple driver for UUID generator */
void main(int argc, char **argv)
{
uuid_t u;
int f;
uuid_create(&u);
printf("uuid_create(): "); puid(u);
f = uuid_compare(&u, &u);
printf("uuid_compare(u,u): %d\n", f); /* should be 0 */
f = uuid_compare(&u, &NameSpace_DNS);
printf("uuid_compare(u, NameSpace_DNS): %d\n", f); /* s.b. 1 */
f = uuid_compare(&NameSpace_DNS, &u);
printf("uuid_compare(NameSpace_DNS, u): %d\n", f); /* s.b. -1 */
uuid_create_md5_from_name(&u, NameSpace_DNS, "www.widgets.com", 15);
printf("uuid_create_md5_from_name(): "); puid(u);
}
uuid_create(): 7d444840-9dc0-11d1-b245-5ffdce74fad2
uuid_compare(u,u): 0
uuid_compare(u, NameSpace_DNS): 1
uuid_compare(NameSpace_DNS, u): -1
uuid_create_md5_from_name(): e902893a-9d22-3c7e-a7b8-d6e313b71d9f
This appendix lists the name space IDs for some potentially interesting name spaces, as initialized C structures and in the string representation defined above.
この付録では、初期化されたC構造として、および上で定義された文字列表現として、興味深い可能性のある名前空間の名前空間IDをリストします。
/* Name string is a fully-qualified domain name */
uuid_t NameSpace_DNS = { /* 6ba7b810-9dad-11d1-80b4-00c04fd430c8 */
0x6ba7b810,
0x9dad,
0x11d1,
0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8
};
/* Name string is a URL */
uuid_t NameSpace_URL = { /* 6ba7b811-9dad-11d1-80b4-00c04fd430c8 */
0x6ba7b811,
0x9dad,
0x11d1,
0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8
};
/* Name string is an ISO OID */
uuid_t NameSpace_OID = { /* 6ba7b812-9dad-11d1-80b4-00c04fd430c8 */
0x6ba7b812,
0x9dad,
0x11d1,
0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8
};
/* Name string is an X.500 DN (in DER or a text output format) */
uuid_t NameSpace_X500 = { /* 6ba7b814-9dad-11d1-80b4-00c04fd430c8 */
0x6ba7b814,
0x9dad,
0x11d1,
0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8
};
Authors' Addresses
著者のアドレス
Paul J. Leach Microsoft 1 Microsoft Way Redmond, WA 98052 US
ポールJ.リーチマイクロソフト1マイクロソフトウェイレドモンド、ワシントン98052米国
Phone: +1 425-882-8080
EMail: paulle@microsoft.com
Michael Mealling Refactored Networks, LLC 1635 Old Hwy 41 Suite 112, Box 138 Kennesaw, GA 30152 US
Michael Mealling Refactored Networks、LLC 1635 Old Hwy 41 Suite 112、Box 138 Kennesaw、GA 30152 US
Phone: +1-678-581-9656
EMail: michael@refactored-networks.com
URI: http://www.refactored-networks.com
Rich Salz DataPower Technology, Inc. 1 Alewife Center Cambridge, MA 02142 US
Rich Salz DataPower Technology、Inc. 1 Alewife Center Cambridge、MA 02142 US
Phone: +1 617-864-0455
EMail: rsalz@datapower.com
URI: http://www.datapower.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
Copyright（C）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントは、BCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または組織（ある場合）、インターネットエンジニアリングおよびインターネットエンジニアリングタスクフォースは、すべての保証を明示的または明示的に後援します。ここに含まれる情報の使用により、商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害されないという保証を含みますが、これに限定されるものではありません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に対して行われたIPR開示のコピー、および使用可能にされるライセンスの保証、または一般ライセンスを取得する試みの結果、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得できるhttp://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。