[要約] RFC 6963は、例のための統一資源名(URN)名前空間に関する規格であり、目的は、例を識別するための一意のURNを提供することです。

Internet Engineering Task Force (IETF)                    P. Saint-Andre
Request for Comments: 6963                           Cisco Systems, Inc.
BCP: 183                                                        May 2013
Category: Best Current Practice
ISSN: 2070-1721
        

A Uniform Resource Name (URN) Namespace for Examples

例のUniform Resource Name(URN)名前空間

Abstract

概要

This document defines a Uniform Resource Name (URN) namespace identifier enabling the generation of URNs that are appropriate for use in documentation and in URN-related testing and experimentation.

このドキュメントは、ドキュメントおよびURN関連のテストと実験での使用に適したURNの生成を可能にするUniform Resource Name(URN)名前空間識別子を定義します。

Status of This Memo

本文書の状態

This memo documents an Internet Best Current Practice.

このメモは、インターネットの現在のベストプラクティスを文書化したものです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.

このドキュメントは、IETF(Internet Engineering Task Force)の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ(IESG)による公開が承認されました。 BCPの詳細については、RFC 5741のセクション2をご覧ください。

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

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc6963で入手できます。

Copyright Notice

著作権表示

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

Copyright(c)2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定(http://trustee.ietf.org/license-info)の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

目次

   1. Introduction ....................................................2
   2. Terminology .....................................................2
   3. Completed Namespace Definition Template .........................3
   4. Namespace Considerations ........................................4
   5. Community Considerations ........................................5
   6. Security Considerations .........................................5
   7. IANA Considerations .............................................5
   8. References ......................................................6
   Appendix A. Acknowledgements .......................................7
        
1. Introduction
1. はじめに

The Uniform Resource Name (URN) technology [RFC2141] provides a way to generate persistent, location-independent resource identifiers. The primary "scope" of a URN is provided by its namespace identifier (NID). As specified in [RFC3406], there are three kinds of NIDs: formal, informal, and experimental. Most of the NIDs registered to date are formal. As far as is known, the few informal namespaces have not been widely used, and the experimental namespaces are by definition unregistered.

Uniform Resource Name(URN)テクノロジ[RFC2141]は、場所に依存しない永続的なリソース識別子を生成する方法を提供します。 URNの主要な「スコープ」は、その名前空間識別子(NID)によって提供されます。 [RFC3406]で指定されているように、正式、非公式、実験の3種類のNIDがあります。現在までに登録されているNIDのほとんどは正式です。知られている限りでは、少数の非公式な名前空間は広く使用されておらず、実験的な名前空間は定義により未登録です。

The experimental namespaces take the form "X-NID" (where "NID" is the desired namespace identifier). Because the "X-" convention has been deprecated in general [RFC6648], it seems sensible to achieve the same objective in a different way. Therefore, this document registers a formal namespace identifier of "example", similar to "example.com" and other domain names [RFC2606]. Under the "example" NID, specification authors and code developers can mint URNs for use in documentation and in URN-related testing and experimentation by assigning their own unique Namespace Specific Strings without fear of conflicts with current or future actual URNs. Such URNs are intended for use as examples in documentation, testing of code for URN and URI processing, URN-related experimentation, invalid URNs, and other similar uses. They are not intended for testing non-URI code or for building higher-level applications for use over the Internet or private networks (e.g., as XML namespace names), since it is relatively easy to mint URIs whose authority component is a domain name controlled by the person or organization that wishes to engage in such testing and experimentation.

試験的な名前空間は、「X-NID」という形式を取ります(「NID」は目的の名前空間識別子です)。 「X-」の規約は一般的に非推奨となっているため[RFC6648]、同じ目的を別の方法で達成することは賢明なようです。したがって、このドキュメントでは、「example.com」やその他のドメイン名[RFC2606]と同様に、「example」という正式な名前空間識別子を登録しています。 "example" NIDの下で、仕様の作成者とコード開発者は、ドキュメントやURN関連のテストや実験で使用するために、現在または将来の実際のURNとの競合を恐れることなく、独自の一意の名前空間固有の文字列を割り当てることにより、URNを作成できます。このようなURNは、ドキュメント、URNおよびURI処理のコードのテスト、URN関連の実験、無効なURN、およびその他の同様の使用法の例として使用することを目的としています。権限コンポーネントが制御されたドメイン名であるURIを作成するのは比較的簡単であるため、非URIコードのテストや、インターネットまたはプライベートネットワークを介して使用するための高レベルのアプリケーションの構築(XML名前空間名など)を目的としたものではありません。そのようなテストや実験に従事したい人や組織によって。

2. Terminology
2. 用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの "は、[RFC2119]で説明されているように解釈されます。

3. Completed Namespace Definition Template
3. 完成した名前空間定義テンプレート
3.1. Namespace ID
3.1. 名前空間ID

The Namespace ID "example" has been assigned.

名前空間ID「example」が割り当てられています。

3.2. Registration Information
3.2. 登録情報

Version 1

バージョン1

Date: 2013-04-24

日付:2013-04-24

3.3. Declared Registrant of the Namespace
3.3. 名前空間の宣言された登録者

Registering organization: IETF

登録機関:IETF

Designated contact: IESG, iesg@ietf.org

指定連絡先:IESG、iesg @ ietf.org

3.4. Declaration of Syntactic Structure
3.4. 構文構造の宣言

URNs that use the "example" NID shall have the following structure:

「例」のNIDを使用するURNは、次の構造になります。

   urn:example:{NSS}
        

The Namespace Specific String (NSS) is a mandatory string of ASCII characters [RFC20] that conforms to the URN syntax requirements [RFC2141] and provides a name that is useful within the relevant documentation example, test suite, or other application.

名前空間固有文字列(NSS)は、URN構文要件[RFC2141]に準拠するASCII文字[RFC20]の必須文字列であり、関連するドキュメントの例、テストスイート、またはその他のアプリケーションで役立つ名前を提供します。

3.5. Relevant Ancillary Documentation
3.5. 関連する付属文書

See [RFC6648] for information about deprecation of the "X-" convention in protocol parameters and identifiers.

プロトコルパラメータと識別子の「X-」規則の廃止については、[RFC6648]を参照してください。

3.6. Identifier Uniqueness Considerations
3.6. 識別子の一意性に関する考慮事項

Those who mint example URNs ought to strive for uniqueness in the Namespace Specific String portion of the URN. However, such uniqueness cannot be guaranteed through the assignment process. Therefore, it is NOT RECOMMENDED for implementers to use example URNs for any purposes other than documentation, private testing, and truly experimental contexts.

URNの例を作成する人は、URNの名前空間固有の文字列部分の一意性を追求する必要があります。ただし、そのような一意性は割り当てプロセスを通じて保証できません。したがって、ドキュメント、プライベートテスト、および真に実験的なコンテキスト以外の目的でサンプルURNを使用することは、実装者には推奨されません。

3.7. Identifier Persistence Considerations
3.7. 識別子の永続性に関する考慮事項

Once minted, an example URN is immutable. However, it is simply a string; and there is no guarantee that the documentation, test suite, or other application using the URN is immutable.

作成されたURNの例は不変です。ただし、これは単なる文字列です。また、ドキュメント、テストスイート、またはURNを使用するその他のアプリケーションが不変である保証はありません。

3.8. Process of Identifier Assignment
3.8. 識別子割り当てのプロセス

Assignment is completely open, since anyone can mint example URNs for use in documentation, private testing, and other experimental contexts.

誰でもドキュメント、プライベートテスト、その他の実験的コンテキストで使用するURNの例を作成できるため、割り当ては完全にオープンです。

3.9. Process for Identifier Resolution
3.9. 識別子解決のプロセス

Example URNs are not intended to be resolved, and the namespace will probably never be registered with a Resolution Discovery System (except to simply inform requesters that such URNs are merely examples).

URNの例は解決を意図したものではなく、名前空間が解決検出システムに登録されることはおそらくありません(そのようなURNが単なる例であることを要求者に通知する場合を除きます)。

3.10. Rules for Lexical Equivalence
3.10. 字句等価のルール

No special considerations; the rules for lexical equivalence specified in [RFC2141] apply.

特別な考慮事項はありません。 [RFC2141]で指定されている字句同値の規則が適用されます。

3.11. Conformance with URN Syntax
3.11. URN構文への準拠

No special considerations

特別な考慮事項はありません

3.12. Validation Mechanism
3.12. 検証メカニズム

None

なし

3.13. Scope
3.13. 範囲

The scope of an example URN is limited to the documentation in which it is found, the test in which it is used, the experiment in which it appears, etc. Example URNs have no meaning outside such strictly limited contexts.

サンプルURNの範囲は、それが見つかるドキュメント、それが使用されるテスト、それが現れる実験などに限定されます。サンプルURNは、そのような厳密に限定されたコンテキストの外では意味がありません。

4. Namespace Considerations
4. 名前空間に関する考慮事項

No existing formal namespace enables entities to generate URNs that are appropriate for use as examples in documentation and in URN-related testing and experimentation. It could be argued that no such formal namespace is needed, given that experimental namespaces can be minted at will. However, experimental namespaces run afoul of the trend away from using the "X-" convention in the names of protocol parameters and identifiers [RFC6648]. Additionally, in practice, specification authors often mint examples using fake NIDs that go unregistered because they are never intended to be used. To minimize the possibility of confusion, use of this dedicated example namespace is recommended for generating example URNs.

既存の正式な名前空間では、エンティティは、ドキュメントやURN関連のテストや実験での例としての使用に適したURNを生成できません。実験的な名前空間は自由に作成できるので、そのような正式な名前空間は必要ないと主張することもできます。しかし、実験的な名前空間は、プロトコルパラメータと識別子の名前に「X-」規則を使用することから遠ざかる傾向にあります[RFC6648]。さらに、実際には、仕様の作成者は、使用することを意図していないため、登録解除される偽のNIDを使用して例を作成することがよくあります。混乱の可能性を最小限に抑えるために、この専用のサンプル名前空間を使用してサンプルURNを生成することをお勧めします。

5. Community Considerations
5. コミュニティの考慮事項

The "example" NID is intended to provide a clean, easily recognizable space for minting examples to be used in documentation and in URN-related testing and experimentation. The NSS is best as a unique string, generated by the person, organization, or other entity that creates the documentation, test suite, or other application. There is no issuing authority for example URNs, and it is not intended that they can be resolved in any meaningful way.

「サンプル」NIDは、ドキュメントやURN関連のテストや実験で使用されるサンプルを作成するためのクリーンで簡単に認識できるスペースを提供することを目的としています。 NSSは、ドキュメント、テストスイート、またはその他のアプリケーションを作成する個人、組織、またはその他のエンティティによって生成される一意の文字列として最適です。 URNなどの発行機関はなく、意味のある方法で解決できることを意図していません。

The "example" NID does not obviate the need to coordinate with issuing authorities for existing namespaces (e.g., minting "urn:example:xmpp:foo" instead of requesting issuance of "urn:xmpp:foo"), to register new namespace identifiers if existing namespaces do not match one's desired functionality (e.g., minting "urn:example:sha-1:29ead03e784b2f636a23ffff95ed12b56e2f2637" instead of registering the "sha-1" NID), or to respect the basic spirit of URN NID assignment (e.g., setting up shadow NIDs such as "urn:example:MyCompany:*" instead of using, say, HTTP URIs).

「example」NIDは、既存の名前空間の発行機関と調整する必要をなくしません(たとえば、「urn:xmpp:foo」の発行を要求する代わりに「urn:example:xmpp:foo」を作成する)、新しい名前空間識別子を登録します。既存の名前空間が目的の機能と一致しない場合(たとえば、「sha-1」NIDを登録する代わりに「urn:example:sha-1:29ead03e784b2f636a23ffff95ed12b56e2f2637」を作成する場合)、またはURN NID割り当ての基本的な精神を尊重する場合(設定など)たとえば、HTTP URIを使用する代わりに、「urn:example:MyCompany:*」などのシャドウNIDをアップします。

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

This document introduces no additional security considerations beyond those associated with the use and resolution of URNs in general.

このドキュメントでは、一般的なURNの使用と解決に関連するセキュリティ上の考慮事項以外に、セキュリティに関する考慮事項を紹介していません。

7. IANA Considerations
7. IANAに関する考慮事項

This document defines a URN NID registration of "example", which IANA has added to the "Formal URN Namespaces" registry. The completed registration template can be found in Section 3.

このドキュメントは、IANAが「正式なURN名前空間」レジストリに追加した「example」のURN NID登録を定義しています。完成した登録テンプレートはセクション3にあります。

8. References
8. 参考文献
8.1. Normative References
8.1. 引用文献

[RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, October 1969.

[RFC20] Cerf、V。、「ネットワーク交換用のASCII形式」、RFC 20、1969年10月。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.

[RFC2141] Moats、R。、「URN Syntax」、RFC 2141、1997年5月。

[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002.

[RFC3406] Daigle、L.、van Gulik、D.、Iannella、R。、およびP. Faltstrom、「Uniform Resource Names(URN)Namespace Definition Mechanisms」、BCP 66、RFC 3406、2002年10月。

8.2. Informative References
8.2. 参考引用

[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.

[RFC2606]イーストレイクD.およびA.パニッツ、「予約済みトップレベルDNS名」、BCP 32、RFC 2606、1999年6月。

[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols", BCP 178, RFC 6648, June 2012.

[RFC6648]セントアンドレ、P。、クロッカー、D。、およびM.ノッティンガム、「アプリケーションプロトコルでの「X-」プレフィックスと同様の構成の非推奨」、BCP 178、RFC 6648、2012年6月。

Appendix A. Acknowledgements
付録A謝辞

Thanks to Martin Duerst, Barry Leiba, and Jim Schaad for their feedback; to Christer Holmberg for his Gen-ART review; and to Benoit Claise, Adrian Farrel, and Stephen Farrell for their helpful input during IESG review. Julian Reschke inspired the work on this document, provided valuable suggestions, and shepherded the document.

フィードバックを提供してくれたMartin Duerst、Barry Leiba、Jim Schaadに感謝します。 Gen-ARTレビューのためにChrister Holmbergに。 IESGレビューの際に役立つ情報を提供してくれたBenoit Claise、Adrian Farrel、Stephen Farrellに感謝します。 Julian Reschkeは、このドキュメントの作業に影響を与え、貴重な提案を提供し、ドキュメントを作成しました。

Author's Address

著者のアドレス

Peter Saint-Andre Cisco Systems, Inc. 1899 Wynkoop Street, Suite 600 Denver, CO 80202 USA

Peter Saint-Andre Cisco Systems、Inc. 1899 Wynkoop Street、Suite 600 Denver、CO 80202 USA

   EMail: psaintan@cisco.com