[要約] RFC 3349は、インターネットエンジニアリングタスクフォース(IETF)の作業グループによって開発中のプロファイルを識別するための一時的なプレフィックスについての要約です。このRFCの目的は、開発中のプロファイルを一意に識別し、ネットワーク上でのテストや評価を容易にすることです。

Network Working Group                                            M. Rose
Request for Comments: 3349                  Dover Beach Consulting, Inc.
BCP: 59                                                        July 2002
Category: Best Current Practice
        

A Transient Prefix for Identifying Profiles under Development by the Working Groups of the Internet Engineering Task Force

インターネットエンジニアリングタスクフォースのワーキンググループによる開発中のプロファイルを識別するための一時的なプレフィックス

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 (2002). All Rights Reserved.

Copyright(c)The Internet Society(2002)。無断転載を禁じます。

Abstract

概要

As a part of their deliverables, working groups of the IETF may develop BEEP profiles. During the development process, it is desirable to assign a transient identifier to each profile. If the profile is subsequently published as an RFC, then a permanent identifier is subsequently assigned by the IANA.

成果物の一部として、IETFのワーキンググループはビーププロファイルを開発する場合があります。開発プロセス中に、各プロファイルに過渡識別子を割り当てることが望ましいです。プロファイルがその後RFCとして公開された場合、その後、IANAによって永続的な識別子が割り当てられます。

Table of Contents

目次

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Practice . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Security Considerations  . . . . . . . . . . . . . . . . . . .  4
       References . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   A.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  5
   B.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  5
       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  5
       Full Copyright Statement . . . . . . . . . . . . . . . . . . .  6
        
1. Introduction
1. はじめに

Each BEEP profile [1] is identified by a URI [2]. The BEEP specification uses URIs to identify a BEEP profile both:

各ビーププロファイル[1]は、URI [2]によって識別されます。ビープの仕様では、urisを使用してビーププロファイルを識別します。

o statically, when a profile is formally defined (RFC 3080's Section 5.1); and,

o 静的に、プロファイルが正式に定義されている場合(RFC 3080のセクション5.1)。そして、

o dynamically, during channel management (RFC 3080's Section 2.3.1).

o 動的には、チャネル管理中(RFC 3080のセクション2.3.1)。

If the BEEP profile appears on the standards-track [3], then the IANA is responsible for assigning the URI associated with the BEEP profile. Otherwise, the entity specifying the BEEP profile is free to assign a URI under its administration to the profile.

ビーププロファイルが標準トラック[3]に表示される場合、IANAはビープ音に関連付けられたURIを割り当てる責任があります。それ以外の場合、ビーププロファイルを指定するエンティティは、その管理下にあるURIをプロファイルに自由に割り当てることができます。

If a working group of the IETF is developing a BEEP profile, then, during the development process, it is desirable to use a transient identifier for the profile. Further, it is desirable that the transient identifier be associated with the working group.

IETFのワーキンググループがビーププロファイルを開発している場合、開発プロセス中に、プロファイルに一時的な識別子を使用することが望ましいです。さらに、一時的な識別子をワーキンググループに関連付けることが望ましい。

This memo defines the practice for making such an assignment. Note that this practice does not apply to activities outside of working groups -- anyone able to assign a URL is capable of defining a URI for the purposes of identifying the BEEP profiles that they develop.

このメモは、そのような割り当てを行うためのプラクティスを定義します。このプラクティスは、ワーキンググループ以外のアクティビティには適用されないことに注意してください。URLを割り当てることができる人は誰でも、開発するビーププロファイルを特定する目的でURIを定義できることに注意してください。

2. Practice
2. 練習する

When a working group is formed, the IETF secretariat assigns a brief mnemonic prefix to the working group, e.g., "provreg" or "sacred".

ワーキンググループが形成されると、IETF事務局はワーキンググループ(「Provreg」または「Sacred」など)に簡単なニーモニックプレフィックスを割り当てます。

When a working group begins development of a document which specifies a BEEP profile, the working group chair assigns a transient identifier of the form "http://iana.org/beep/transient/XXX/YYY" where "XXX" is the working group's mnemonic and "YYY" is a unique string. Although the resulting URI must conform to the URI syntax, the "YYY" portion is otherwise arbitrary. For example, it may contain a sub-hierarchy (e.g., "epp/1.0").

ワーキンググループがビーププロファイルを指定するドキュメントの開発を開始すると、ワーキンググループチェアは、「http://iana.org/beep/transient/xxx/yyy」の形式の一時的な識別子を割り当てます。グループのニーモニックと「YYY」はユニークな文字列です。結果のURIはURI構文に準拠する必要がありますが、「YYY」部分は任意です。たとえば、サブ階層(「EPP/1.0」など)が含まれている場合があります。

For example,

例えば、

http://iana.org/beep/transient/provreg/epp/1.0 http://iana.org/beep/transient/sacred/pdm

http://iana.org/beep/transient/provreg/epp/1.0 http://iana.org/beep/transient/sacred/pdm

might be assigned by the chairs of the "provreg" and "sacred" working groups, respectively.

それぞれ「プロブレグ」と「神聖な」ワーキンググループの椅子によって割り当てられる可能性があります。

Following this, the working group chair completes a BEEP profile registration template, and submits this information to the IANA.

これに続いて、ワーキンググループチェアはビーププロファイル登録テンプレートを完成させ、この情報をIANAに提出します。

Note that although the IETF hasn't established a practice with respect to the use of capitalization in URLs employed for namespace purposes, the W3C has a lowercase-only policy. Working group chairs are encouraged to consider this when making assignments.

IETFは、名前空間の目的で採用されているURLでの大文字化の使用に関する慣行を確立していないが、W3Cには小文字のみのポリシーがあることに注意してください。ワーキンググループの椅子は、割り当てを行う際にこれを考慮することをお勧めします。

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

This document describes an administrative convention and raises no additional security considerations. Of course, each BEEP-based protocol has its own set of security considerations, which should be described in the relevant specification.

このドキュメントは、管理条約について説明し、追加のセキュリティ上の考慮事項を提起しません。もちろん、各ビープベースのプロトコルには独自のセキュリティに関する考慮事項があり、関連する仕様で説明する必要があります。

References

参考文献

[1] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.

[1] Rose、M。、「ブロック拡張可能な交換プロトコルコア」、RFC 3080、2001年3月。

[2] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

[2] Berners-Lee、T.、Fielding、R。and L. Masinter、「ユニフォームリソース識別子(URI):Generic Syntax」、RFC 2396、1998年8月。

[3] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996.

[3] Hovey、R。およびS. Bradner、「IETF標準プロセスに関与する組織」、BCP 11、RFC 2028、1996年10月。

Appendix A. Acknowledgements
付録A. 謝辞

The author gratefully acknowledges the contributions of: Dan Kohn and Bob Wyman.

著者は、ダン・コーンとボブ・ワイマンの貢献を感謝して認めています。

Appendix B. IANA Considerations
付録B. IANAの考慮事項

The IANA maintains a registry of transient identifiers used for BEEP profiles under development in the IETF, using the profile registration template defined in Section 5.1 of [1].

IANAは、[1]のセクション5.1で定義されているプロファイル登録テンプレートを使用して、IETFで開発中のビーププロファイルに使用される一時的な識別子のレジストリを維持しています。

Note that unlike the registration procedures defined in Appendix B of [1], the working group chair (instead of the IESG) is responsible for authorizing the registration.

[1]の付録Bで定義されている登録手順とは異なり、ワーキンググループチェア(IESGの代わりに)が登録を承認する責任があることに注意してください。

Author's Address

著者の連絡先

Marshall T. Rose Dover Beach Consulting, Inc. POB 255268 Sacramento, CA 95865-5268 US

マーシャルT.ローズドーバービーチコンサルティング、Inc。POB 255268サクラメント、CA 95865-5268 US

   Phone: +1 916 483 8878
   EMail: mrose@dbc.mtview.ca.us
        

Full Copyright Statement

完全な著作権声明

Copyright (C) The Internet Society (2002). All Rights Reserved.

Copyright(c)The Internet Society(2002)。無断転載を禁じます。

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エディター機能の資金は現在、インターネット協会によって提供されています。