[要約] RFC 3553は、IETF URNサブネームスペースの登録されたプロトコルパラメータに関する規格です。その目的は、プロトコルパラメータの一意の識別子を提供し、パラメータの管理と参照を容易にすることです。
Network Working Group M. Mealling
Request for Comments: 3553 VeriSign
BCP: 73 L. Masinter
Category: Best Current Practice Adobe Systems
T. Hardie
Qualcomm
G. Klyne
Nine by Nine
June 2003
An IETF URN Sub-namespace for Registered Protocol Parameters
登録されたプロトコルパラメーターのIETF URNサブネームスペース
Status of this Memo
本文書の位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
This document describes a new sub-delegation for the 'ietf' URN namespace for registered protocol items. The 'ietf' URN namespace is defined in RFC 2648 as a root for persistent URIs that refer to IETF-defined resources.
このドキュメントでは、登録されたプロトコル項目の「IETF」urnネームスペースの新しいサブディレージングについて説明します。「IETF」URNネームスペースは、IETF定義のリソースを参照する永続的なURIのルートとしてRFC 2648で定義されています。
From time to time IETF standards require the registration of various protocol elements in well known central repository. The Internet Assigned Numbers Authority maintains this central repository and takes direction from the IETF on what, how and when to add items to it. The IANA maintains lists of items such as all assigned port numbers, MIME media types, enterprise numbers, etc.
IETF標準では、よく知られている中央リポジトリにさまざまなプロトコル要素の登録が必要です。インターネットが割り当てられた番号当局は、この中央リポジトリを維持し、IETFから何、、どのように、いつアイテムを追加するかについて方向性を取ります。IANAは、割り当てられたすべてのポート番号、MIMEメディアタイプ、エンタープライズ番号などのアイテムのリストを維持しています。
Over time there has developed a need to be able to reference these elements as URIs in various schema. In the past this was done in a very ad hoc way that easily led to interoperability problems. This document creates a new sub-delegation below the "ietf" [2]URN namespace [1] called 'params' which acts as a standardized mechanism for naming the items registered for IETF standards. Any assignments below that are specified in an RFC according to the IETF consensus process and which include the template found in Section 4.
時間が経つにつれて、これらの要素をさまざまなスキーマのURIとして参照できる必要がありました。過去には、これは非常にアドホックな方法で行われ、相互運用性の問題に簡単につながりました。このドキュメントでは、IETF標準に登録されているアイテムに名前を付けるための標準化されたメカニズムとして機能する「PARAMS」と呼ばれる「IETF」[2] URN Namespace [1]の下に新しいサブディレージングを作成します。IETFコンセンサスプロセスに従ってRFCで指定され、セクション4で見つかったテンプレートを含む以下の割り当て。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119に記載されているとおりに解釈されます。
Sub-namespace name:
サブネームズスペース名：
params
パラメージ
Declared registrant of the namespace:
名前空間の登録者を宣言する：
The Internet Engineering Task Force
インターネットエンジニアリングタスクフォース
Declaration of structure:
構造の宣言：
The namespace is primarily opaque. The IANA, as operator of the registry, may take suggestions for names to assign but they reserve the right to assign whatever name they desire, within guidelines set by the IESG. The colon character (":") is used to denote a very limited concept of hierarchy. If a colon is present then the items on both sides of it are valid names. In general, if a name has a colon then the item on the left hand side represents a class of those items that would contain other items of that class. For example, a name can be assigned to the entire list of DNS resource record type codes as well as for each individual code. The URN for the list might look like this:
名前空間は主に不透明です。IANAは、レジストリのオペレーターとして、名前を割り当てるための提案を受け取る場合がありますが、IESGによって設定されたガイドライン内で、希望する名前を割り当てる権利を留保します。コロン文字（ "："）は、階層の非常に限られた概念を示すために使用されます。コロンが存在する場合、その両側のアイテムは有効な名前です。一般に、名前にコロンがある場合、左側のアイテムは、そのクラスの他のアイテムを含むアイテムのクラスを表します。たとえば、名前は、個々のコードごとに、DNSリソースレコードタイプコードのリスト全体に割り当てることができます。リストのurnは次のようになるかもしれません：
urn:ietf:params:dns:rr-type-codes
while the URN for the SOA records type code might look like this:
SOAレコードタイプコードのurnは次のようになる場合があります。
urn:ietf:params:dns:rr-type-codes:soa
Relevant ancillary documentation:
関連する補助文書：
[3], [2], [1]
[3]、[2]、[1]
Identifier uniqueness considerations:
識別子の一意性の考慮事項：
The IESG uses the IETF consensus process to ensure that sub-namespaces generate unique names within that sub-namespace. The IESG delegates to the IANA the task of ensuring that the sub-namespace names themselves are unique. Until and unless the IESG specifies differently, the IANA is directed to ensure uniqueness by comparing the name to be assigned with the list of previously assigned names. In the case of a conflict the IANA is to request a new string from the registrant until the conflict is resolved.
IESGは、IETFコンセンサスプロセスを使用して、サブネームスペースがそのサブネームスペース内で一意の名前を生成するようにします。IESGはIANAに代表者に、サブネームズスペースの名前自体がユニークであることを保証するタスクです。IESGが異なる方法で指定しない限り、IANAは、以前に割り当てられた名前のリストと割り当てられる名前を比較することにより、一意性を確保するように指示されます。紛争の場合、IANAは紛争が解決するまで登録者から新しい文字列を要求することです。
Identifier persistence considerations:
識別子の持続性の考慮事項：
Once a name has been allocated it MUST NOT be re-allocated for a different purpose. The rules provided for assignments of values within a sub-namespace MUST be constructed so that the meaning of values cannot change. This registration mechanism is not appropriate for naming values whose meaning may change over time. If a value that changes over time the assignment MUST name the container or concept that contains the value, not the value itself. For example, if a parameter called 'foo' has a value that changes over time, it is valid to create the name 'urn:ietf:params:foo-params:foo' that identifies that 'slot'. It is not valid to actually create a name that contains that value unless it is a persistent and unique value such as a version number.
名前が割り当てられたら、別の目的のために再割り当ててはなりません。サブネームスペース内の値の割り当てに提供されるルールは、値の意味が変更できないように構築する必要があります。この登録メカニズムは、意味が時間とともに変化する可能性のある値を命名するのに適していません。時間の経過とともに変化する値が、割り当ては値自体ではなく、値を含むコンテナまたは概念に名前を付ける必要があります。たとえば、「foo」と呼ばれるパラメーターに時間の経過とともに変化する値がある場合、「urn：ietf：params：foo-params：foo」という名前を作成するのが有効です。バージョン番号などの永続的で一意の値でない限り、その値を含む名前を実際に作成することは無効です。
Process of identifier assignment:
識別子割り当てのプロセス：
Identifiers are assigned only after a particular protocol element or number has been registered with the IANA using standard policies and procedures, or documented in an RFC describing a standards track protocol. This means that the 'gating' function for assignment is the "IETF Consensus" process documented in RFC 2434 [4].
識別子は、特定のプロトコル要素または数が標準のポリシーと手順を使用してIANAに登録された後にのみ割り当てられます。または、標準トラックプロトコルを説明するRFCに文書化されます。これは、割り当ての「ゲーティング」関数がRFC 2434 [4]で文書化された「IETFコンセンサス」プロセスであることを意味します。
Process of identifier resolution:
識別子解像度のプロセス：
At this time no resolution mechanism is defined.
現時点では、解像度メカニズムは定義されていません。
Rules for Lexical Equivalence:
語彙の等価性のルール：
Lexical equivalence is achieved by exact string match according to the rules for URN syntax found in RFC 2141 [1]. Specifically, due to the URN syntax definitions, the 'stringprep' standard found in RFC 3454 [7] does not apply.
語彙の等価性は、RFC 2141 [1]で見つかったurn構文のルールに従って、正確な文字列一致によって達成されます。具体的には、URN構文の定義により、RFC 3454 [7]にある「StringPrep」標準は適用されません。
Conformance with URN Syntax:
urn構文への適合：
There are no additional characters reserved.
予約された追加の文字はありません。
Validation mechanism:
検証メカニズム：
None.
なし。
Scope:
範囲：
Global
グローバル
The creation of a new registry name will be simple for most flat registries. The only required elements will be the registry name, a reference to relevant documents, a statement about which current/proposed document repositories contains the authoritative data for the registry, and a statement specifying which element in the registry is the value to be used in the URN. In most cases this last element will be the index value assigned by the IANA.
新しいレジストリ名の作成は、ほとんどのフラットレジストリにとって簡単です。必要な要素は、レジストリ名、関連するドキュメントへの参照、現在/提案されているドキュメントリポジトリにレジストリの権威あるデータが含まれていることに関するステートメント、およびレジストリ内のどの要素が使用される値であるかを指定するステートメントです。urn。ほとんどの場合、この最後の要素は、IANAによって割り当てられたインデックス値になります。
More complex registries (DNS Parameters for example) will need to repeat that information for any sub-namespaces. It should also be clear as to whether or not a name is assigned to the sub-namespace itself (i.e., is 'urn:ietf:params:dns:rr-types' valid by itself and if so, what does it name?).
より複雑なレジストリ（たとえば、DNSパラメーター）は、サブネームスペースに対してその情報を繰り返す必要があります。また、名前がsub-namespace自体に割り当てられているかどうかについても明確にする必要があります（つまり、 'urn：ietf：params：dns：rr-types' fal by byall、もしそうなら、名前は何ですか？）。
The template:
テンプレート：
Registry name: -- The name of the sub-namespace. In many cases this should be the same name that the IANA calls the registry itself.
レジストリ名： - サブネームスペースの名前。多くの場合、これはIANAがレジストリ自体と呼ぶのと同じ名前である必要があります。
Specification: -- Relevant IETF published documents that define the registry and the items in it.
仕様： - 関連するIETF公開されたドキュメントは、レジストリとその項目を定義します。
Repository: -- A pointer to the 'current' location of the registry in the protocol parameters repository or the relevant RFCs that document the items being named. This value will change over time as the entity that maintains the repository moves files and or fileservers. It is not meant as a permanent binding to the filename but as a hint to the IANA for what the initial mapping would be.
リポジトリ：-Protocolパラメーターリポジトリのレジストリの「現在」の位置または名前が付けられているアイテムを文書化する関連RFCへのポインター。リポジトリを維持するエンティティがファイルやファイルアーバーを移動すると、この値は時間とともに変化します。それは、ファイル名への永続的なバインディングとしてではなく、最初のマッピングがどうなるかについてのIANAへのヒントとして意図されています。
Index value: -- Description of how a registered value is to be embedded in the URI form. This MUST include details of any transformations that may be needed for the resulting string to conform to URN syntax rules and any canonicalization needed so that the case-sensitive string comparison yields the expected equivalences.
インデックス値： - 登録値がURI形式に埋め込まれる方法の説明。これには、結果の文字列がurn構文ルールに準拠するために必要な変換の詳細と、ケースに敏感な文字列比較が予想される同等性を生成するように必要な標準化化が含まれている必要があります。
The process for requesting that a URN be assigned is currently to put the above template or a reference to it in the IANA considerations section of the specifying document. Other more automated processes may be proposed at a latter time if demand requires it.
現在、urnに割り当てられるように要求するプロセスは、現在、指定されたドキュメントのIANA考慮事項セクションに上記のテンプレートまたはそれを参照することです。需要が必要な場合、他のより自動化されたプロセスが後期に提案される場合があります。
None not already inherent to using URNs. Security considerations for URNs in general can be found in RFC 2141 [1]. Further security considerations for one specific URN resolution method can be found in Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application (RFC 3404) [5] which is part of a series starting with Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS (RFC 3401) [6].
URNを使用することにまだ固有のものはありません。一般的なURNのセキュリティ上の考慮事項は、RFC 2141 [1]に記載されています。1つの特定のURN解像度法のさらなるセキュリティに関する考慮事項は、動的委任発見システム（DDDS）パート4にあります。システム（DDDS）パート1：包括的なDDD（RFC 3401）[6]。
This document puts a new and significant burden on the IANA since it may require an additional assignment process to happen for each new IANA registry. To minimize the administrative burden on IANA, any parameter namespace registration is very clear about the criteria for inclusion in that namespace.
このドキュメントでは、IANAの新しい負担が必要になるため、新しいIANAレジストリごとに追加の割り当てプロセスが必要になる場合があります。IANAの管理負担を最小限に抑えるために、パラメーター名空間登録は、その名前空間に含めるための基準について非常に明確です。
Defining a registry that fits the constraints of a URN namespace will impose extra discipline that should take some of the guess-work about creating and maintaining that registry.
urnネームスペースの制約に適合するレジストリを定義すると、そのレジストリの作成と維持に関する推測作業の一部を必要とする余分な規律が課されます。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実践するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待します。情報をIETFエグゼクティブディレクターに宛ててください。
[1] Moats, R., "URN Syntax", RFC 2141, May 1997.
[1] Moats、R。、「urn構文」、RFC 2141、1997年5月。
[2] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[2] Moats、R。、「IETFドキュメント用のurnネームスペース」、RFC 2648、1999年8月。
[3] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002.
[3] Daigle、L.、Van Gulik、D.、Iannella、R。、およびP. Faltstrom、「ユニフォームリソース名（URN）名前空間定義メカニズム」、BCP 66、RFC 3406、2002年10月。
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[4] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, February 2002.
[5] Mealling、M。、「動的委任発見システム（DDDS）パート4：ユニフォームリソース識別子（URI）」、RFC 3404、2002年2月。
[6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, May 2002.
[6] Mealling、M。、「Dynamic Delogation Discovery System（DDDS）パート1：包括的なDDDS」、RFC 3401、2002年5月。
[7] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[7] Hoffman、P。and M. Blanchet、「国際化された文字列の準備（「StringPrep "）」、RFC 3454、2002年12月。
Michael Mealling VeriSign 21345 Ridgetop Circle Sterling, VA 20166 US
Michael Mealling Verisign 21345 Ridgetop Circle Sterling、VA 20166 US
EMail: michael@verisignlabs.com, michael@neonym.net
URI: http://www.verisign.com
Larry Masinter Adobe Systems Incorporated 345 Park Ave San Jose, CA 95110 US
Larry Masinter Adobe Systems Incorporated 345 Park Ave San Jose、CA 95110 US
Phone: +1 408 536-3024
EMail: LMM@acm.org
URI: http://larry.masinter.net
Ted Hardie Qualcomm, Inc. 675 Campbell Technology Parkway Suite 200 Campbell, CA U.S.A.
Ted Hardie Qualcomm、Inc。675 Campbell Technology Parkway Suite 200 Campbell、CA U.S.A.
EMail: hardie@qualcomm.com
Graham Klyne Nine by Nine
Graham Klyne Nine by Nine
EMail: GK-IETF@ninebynine.org
URI: http://www.ninebynine.net/
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。