RFC3553 日本語訳
3553 An IETF URN Sub-namespace for Registered Protocol Parameters. M.Mealling, L. Masinter, T. Hardie, G. Klyne. June 2003. (Format: TXT=14815 bytes) (Also BCP0073) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
RFC一覧
英語原文
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
コメントを求める要求を荒びきにして、作業部会M.をネットワークでつないでください: 3553ベリサインBCP: 73L.Masinterカテゴリ: 2003年6月9日までに最も良い現在の習慣のアドビ・システムズT.ハーディークアルコムG.Klyne Nine
An IETF URN Sub-namespace for Registered Protocol Parameters
登録されたプロトコルパラメタのためのサブ名前空間のIETFつぼ
Status of this Memo
この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.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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名前空間はRFC2648でIETFによって定義されたリソースを示すしつこいURIのための根と定義されます。
1. Introduction
1. 序論
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規格はよく知られている中央倉庫での様々なプロトコル要素の登録を必要とします。 インターネットAssigned民数記Authorityはこの中央倉庫を維持して、ことに関してIETFから指示して取ります、どのように、いつ。それに項目を加えるために。 ポートナンバー、MIMEメディアタイプ、企業番号などがすべて割り当てられるようにIANAは項目のリストを維持します。
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名前空間[1]の下で新しい復委任を作成します。 以下のIETFコンセンサスを得るためのプロセスによってRFCで指定されて、セクション4で見つけられたテンプレートを含んでいるどんな課題。
Mealling, et. al. Best Current Practice [Page 1] RFC 3553 IANA URN Namespace June 2003
et食事、アル。 最も良い現在の練習[1ページ]RFC3553IANAつぼの名前空間2003年6月
2. Terminology
2. 用語
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.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
3. IETF Sub-namespace Specifics
3. IETFサブ名前空間詳細
Sub-namespace name:
サブ名前空間名:
params
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
つぼ:ietf:params: dns: rrタイプコード
while the URN for the SOA records type code might look like this:
SOA記録のためのURNがタイプしている間、コードはこれに似るかもしれません:
urn:ietf:params:dns:rr-type-codes:soa
つぼ:ietf:params: dns: rrタイプコード: 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
IESGは、サブ名前空間がそのサブ名前空間の中でユニークな名前を発生させるのを保証するのにIETFコンセンサスを得るためのプロセスを使用します。 IESG代表、サブ名前空間名自体が確実にユニークになるようにするIANAへのタスク。 IESGが異なって指定しない場合、IANAが割り当てられる名前を比較することによってユニークさを確実にするよう指示されます。
Mealling, et. al. Best Current Practice [Page 2] RFC 3553 IANA URN Namespace June 2003
et食事、アル。 最も良い現在の練習[2ページ]RFC3553IANAつぼの名前空間2003年6月
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.
名前が割り当てられる以前にのリストで。 闘争の場合では、闘争が解決されるまで、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'と呼ばれるパラメタが時間がたつにつれて変化する値を持っているなら、'つぼ: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に記録された後にだけ識別子は割り当てられます。 これは、機能が課題のために'ゲート'であることが、RFC2434[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.
規則に従って、語彙等価性はRFC2141[1]で見つけられたURN構文のために正確なストリングマッチによって達成されます。 明確に、URN構文定義のため、RFC3454[7]で見つけられた'stringprep'規格は適用されません。
Conformance with URN Syntax:
つぼの構文との順応:
There are no additional characters reserved.
予約された添字が全くありません。
Validation mechanism:
合法化メカニズム:
None.
なし。
Mealling, et. al. Best Current Practice [Page 3] RFC 3553 IANA URN Namespace June 2003
et食事、アル。 最も良い現在の練習[3ページ]RFC3553IANAつぼの名前空間2003年6月
Scope:
範囲:
Global
グローバル
4. Assigning Names
4. 名前を割り当てます。
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 Parameters)は、どんなサブ名前空間のためのその情報も繰り返す必要があるでしょう。 また、名前がサブ名前空間(すなわち、'つぼ:ietf:params: dns: rrタイプ'はそれ自体で有効であり、そうだとすれば、それは何を命名しますか?)自体に割り当てられるかどうかに関してそれも明確であるはずです。
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.
倉庫: -- プロトコルパラメタ倉庫での登録の'現在'の位置か命名される項目を記録する関連RFCsへのポインタ。 そして、倉庫を維持する実体がファイルを動かすのに従ってこの値が時間がたつにつれて変える、または、fileservers。 それは永久的な結合としてファイル名に意味されるのではなく、初期のマッピングが何であるかための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フォームに埋め込まれているかに関する登録された値がことである記述。 これが結果として起こるストリングが規則とどんなcanonicalizationも必要とした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問題部で現在、上のテンプレートか参照をそれにつけることです。 要求がそれを必要とするなら、他の、より自動化された過程は後半の時に提案されるかもしれません。
Mealling, et. al. Best Current Practice [Page 4] RFC 3553 IANA URN Namespace June 2003
et食事、アル。 最も良い現在の練習[4ページ]RFC3553IANAつぼの名前空間2003年6月
5. Security Considerations
5. セキュリティ問題
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].
既にURNsを使用するのに固有でないなし。 RFC2141[1]で一般に、URNsのためのセキュリティ問題を見つけることができます。 Dynamic DelegationディスカバリーSystem(DDDS)パートFourで1つの特定のURN解決方法のためのさらなるセキュリティ問題を見つけることができます: Dynamic DelegationディスカバリーSystem(DDDS)から始まるシリーズの一部であるUniform Resource Identifier(URI)解決Application(RFC3404)[5]はOneを分けます: 包括的なDDDS(RFC3401)[6]。
6. IANA Considerations
6. IANA問題
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名前空間の規制に合う登録を定義すると、その登録を作成して、維持することに関して憶測のいくつか取るべきである余分な規律はでしゃばるでしょう。
7. Intellectual Property Statement
7. 知的所有権声明
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はどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、または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専務に情報を記述してください。
Mealling, et. al. Best Current Practice [Page 5] RFC 3553 IANA URN Namespace June 2003
et食事、アル。 最も良い現在の練習[5ページ]RFC3553IANAつぼの名前空間2003年6月
8. Normative References
8. 引用規格
[1] Moats, R., "URN Syntax", RFC 2141, May 1997.
[1]堀(R.、「つぼの構文」、RFC2141)は1997がそうするかもしれません。
[2] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999.
[2] モウツ、R.、「IETFドキュメントのためのつぼの名前空間」、RFC2648、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.、バンGulik、D.、Iannella、R.、およびP.Faltstrom、「一定のリソースは(つぼ)名前空間定義をメカニズムと命名します」、BCP66、RFC3406、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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Four: The Uniform Resource Identifiers (URI)", RFC 3404,
February 2002.
[5] 食事、M.、「ダイナミックな代表団発見システム(DDDS)は4を分けます」。 「Uniform Resource Identifier(URI)」、RFC3404、2002年2月。
[6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
One: The Comprehensive DDDS", RFC 3401, May 2002.
[6] 食事、M.、「ダイナミックな代表団発見システム(DDDS)は1つを分けます」。 「包括的なDDDS」(RFC3401)は2002がそうするかもしれません。
[7] Hoffman, P. and M. Blanchet, "Preparation of Internationalized
Strings ("stringprep")", RFC 3454, December 2002.
[7] ホフマンとP.とM.Blanchet、「国際化しているストリング("stringprep")の準備」、RFC3454、2002年12月。
Mealling, et. al. Best Current Practice [Page 6] RFC 3553 IANA URN Namespace June 2003
et食事、アル。 最も良い現在の練習[6ページ]RFC3553IANAつぼの名前空間2003年6月
9. Authors' Addresses
9. 作者のアドレス
Michael Mealling VeriSign 21345 Ridgetop Circle Sterling, VA 20166 US
ベリサイン21345屋根の頂円の英貨、ヴァージニア20166米国を荒びきにするマイケル
EMail: michael@verisignlabs.com, michael@neonym.net URI: http://www.verisign.com
メール: michael@verisignlabs.com 、michael@neonym.net URI: http://www.verisign.com
Larry Masinter Adobe Systems Incorporated 345 Park Ave San Jose, CA 95110 US
ラリーMasinterアドビ・システムズ株式会社345公園Aveカリフォルニア95110サンノゼ(米国)
Phone: +1 408 536-3024 EMail: LMM@acm.org URI: http://larry.masinter.net
以下に電話をしてください。 +1 408 536-3024 メールしてください: LMM@acm.org ユリ: http://larry.masinter.net
Ted Hardie Qualcomm, Inc. 675 Campbell Technology Parkway Suite 200 Campbell, CA U.S.A.
テッドハーディークアルコムInc.675キャンベル技術公園道路Suite200カリフォルニアキャンベル(米国)
EMail: hardie@qualcomm.com
メール: hardie@qualcomm.com
Graham Klyne Nine by Nine
グラハムKlyne9時9分前
EMail: GK-IETF@ninebynine.org URI: http://www.ninebynine.net/
メール: GK-IETF@ninebynine.org ユリ: http://www.ninebynine.net/
Mealling, et. al. Best Current Practice [Page 7] RFC 3553 IANA URN Namespace June 2003
et食事、アル。 最も良い現在の練習[7ページ]RFC3553IANAつぼの名前空間2003年6月
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Mealling, et. al. Best Current Practice [Page 8]
et食事、アル。 最も良い現在の習慣[8ページ]
一覧
スポンサーリンク
