RFC4897 日本語訳
4897 Handling Normative References to Standards-Track Documents. J.Klensin, S. Hartman. June 2007. (Format: TXT=13023 bytes) (Updates RFC3967) (Also BCP0097) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Klensin Request for Comments: 4897 BCP: 97 S. Hartman Updates: 3967 MIT Category: Best Current Practice June 2007
Klensinがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 4897BCP: 97秒間ハートマンUpdates: 3967年のMITカテゴリ: 最も良い現在の練習2007年6月
Handling Normative References to Standards-Track Documents
標準化過程文書の引用規格を扱います。
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.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
The Internet Engineering Task Force (IETF) and Request for Comments (RFC) Editor have a long-standing rule that a document at a given maturity level cannot be published until all of the documents that it references as normative are at that maturity level or higher. This rule has sometimes resulted in very long publication delays for documents and some claims that it was a major obstruction to advancing documents in maturity level. The IETF agreed on a way to bypass this rule with RFC 3967. This document describes a simpler procedure for downward references to Standards-Track and Best Current Practice (BCP) documents, namely "note and move on". The procedure in RFC 3967 still applies for downward references to other classes of documents. In both cases, annotations should be added to such References.
Comments(RFC)エディタへのインターネット・エンジニアリング・タスク・フォース(IETF)とRequestには、それが標準として参照をつけるドキュメントのすべてがその成熟レベルにあるか、または、より高くなるまで当然のことの成熟レベルにおけるドキュメントを発表できないという長年の規則があります。 この規則は成熟レベルでドキュメントのための非常に長い公表遅れとそれがドキュメントを進めることへの主要な障害であったといういくつかのクレームを時々もたらしました。 IETFはRFC3967と共にこの規則を迂回させる方法に同意しました。 このドキュメントが下方向参照のためにStandards-道とBest Current Practice(BCP)ドキュメントにより簡単な手順について説明する、すなわち、「注意して、動きます」。 RFC3967の手順はまだ他のクラスのドキュメントに下方向参照に申し込んでいます。 どちらの場合も、注釈はそのようなReferencesに加えられるべきです。
Klensin & Hartman Best Current Practice [Page 1] RFC 4897 Normative References June 2007
参照2007年6月の標準のKlensinとハートマン最も良い現在の習慣[1ページ]RFC4897
Table of Contents
目次
1. Introduction ....................................................2 2. Terminology .....................................................3 3. Normative Reference Rule ........................................3 3.1. Source Documents Not Yet Processed by the IESG .............3 3.2. Documents Already in the RFC Editor Queue ..................4 4. Target Documents Not on the Standards Track .....................4 5. Target Documents that Can Be Referenced This Way ................4 6. Security Considerations .........................................5 7. Acknowledgements ................................................5 8. Normative References ............................................5
1. 序論…2 2. 用語…3 3. 引用規格規則…3 3.1. ソースドキュメントはIESGによってまだ処理されていませんでした…3 3.2. 既にRFCエディタのドキュメントは列を作ります…4 4. 目標ドキュメントは規格で追跡されません…4 5. Documentsを狙ってください、そのCan Be Referenced This Way…4 6. セキュリティ問題…5 7. 承認…5 8. 標準の参照…5
1. Introduction
1. 序論
The IETF and RFC Editor have a long-standing rule (see, e.g., RFC 2026, Section 4.2.4 [RFC2026] and the extended discussion in RFC 3967 [RFC3967]) that a document at a given maturity level cannot be published until all of the documents to which it makes a normative reference are at that maturity level or higher. This rule has sometimes resulted in very long publication delays for documents and some claims that it was a major obstruction to advancing documents in maturity level. Recognizing the problems that this rule sometimes caused, RFC 3967 established an exception procedure for normative downward references under some specific circumstances. Perhaps because of its fairly stringent requirements, RFC 3967 has not proven adequate either to clear the backlog of documents awaiting upgraded documents or to prevent additional documents from joining that queue.
IETFとRFC Editorには、長年の規則があります。(与えられた成熟レベルにおけるドキュメントがそうであるはずがないそれが引用規格をするドキュメントのすべてまで発行されたRFC3967[RFC3967)の例えば、RFC2026、セクション4.2.4[RFC2026]、および長い討論がその成熟レベルにあるか、または、より高いのを見てください。 この規則は成熟レベルでドキュメントのための非常に長い公表遅れとそれがドキュメントを進めることへの主要な障害であったといういくつかのクレームを時々もたらしました。 この規則が時々引き起こした問題を認識して、RFC3967はいくつかの特定の状況による標準の下方向参照のために例外手順を確立しました。 恐らくかなり厳しい要件のために、RFC3967は、アップグレードしたドキュメントを待つドキュメントを予備から取り除くか、または追加ドキュメントがその待ち行列に参加するのを防ぐために適切であると判明しませんでした。
This document replaces the long-standing rule for downward references to Standards-Track documents (including BCPs) that are already published. For normative references to Standards-Track and BCP documents, that rule was to hold the newer, referencing, document until the referenced ones could be brought to the appropriate maturity level. It is now possible, following procedures described below, to simply note the downward normative reference and move on.
このドキュメントは下方向参照のために既に発表されるStandards-道のドキュメント(BCPsを含んでいる)に長年の規則を置き換えます。 Standards-道の引用規格とBCPドキュメントに関しては、その規則は参照をつけられたものを適切な成熟レベルにもたらすことができるまで、より新しくて、参照をつけたドキュメントを保持することでした。 単に下向きの引用規格に注意して、移動するために以下で説明された手順に従って、それは現在、可能です。
This document also updates RFC 3967. When downward references from a source document are approved under the procedure specified in that specification, we recommend that the references in the approved (source) document be annotated in the same way as references approved under this rule.
また、このドキュメントはRFC3967をアップデートします。 ソースドキュメントからの下方向参照がその仕様で指定された手順の下で承認されるとき、私たちは、この規則により承認された参照と同様に、承認された(ソース)ドキュメントにおける参照が注釈されることを勧めます。
Klensin & Hartman Best Current Practice [Page 2] RFC 4897 Normative References June 2007
参照2007年6月の標準のKlensinとハートマン最も良い現在の習慣[2ページ]RFC4897
2. Terminology
2. 用語
A reference involves two documents, the one in which the reference is embedded and the document referenced. Where needed for clarity, these documents are referred to as the "source document" and "target document", respectively.
参照は参照をつけられる2通のドキュメント、参照が埋め込まれているもの、およびドキュメントを伴います。 明快に必要であるところでは、これらのドキュメントはそれぞれ「ソースドキュメント」と「目標ドキュメント」と呼ばれます。
The term "Standards-Track document", as used in this specification, is assumed to include BCPs but not Informational or Experimental documents of any variety or origin.
「規格道のドキュメント」というこの仕様で使用される用語がInformationalかExperimentalドキュメントではなく、どんなバラエティーや起源のBCPsも含んでいると思われます。
3. Normative Reference Rule
3. 引用規格規則
This document specifies an alternative to holding source documents until all target documents referenced normatively are upgraded or by applying the procedure of RFC 3967.
このドキュメントは、標準に参照をつけられるすべての目標ドキュメントがアップグレードするまでソースドキュメントを保持するか、またはRFC3967の手順を適用することによって、代替手段を指定します。
3.1. Source Documents Not Yet Processed by the IESG
3.1. IESGによってまだ処理されていなかったソースドキュメント
An author or editor who requires a normative downward reference to a Standards-Track RFC uses the following very simple procedure:
Standards-道のRFCに標準の下方向参照を必要とする作者かエディタが以下の非常に簡単な手順を用います:
o The reference text (i.e., in the "Normative References" section of
the source document) is written as usual.
o A note is included in the reference text that indicates that the
reference is to a target document of a lower maturity level, that
some caution should be used since it may be less stable than the
document from which it is being referenced, and, optionally,
explaining why the downward reference is appropriate.
o 参照テキスト(すなわち、ソースドキュメントの「引用規格」セクションの)はいつものように書かれています。o A注意は何らかの警告で下側の成熟レベルの目標ドキュメントには参照があって、それが参照をつけられているドキュメントほど安定していないかもしれないので使用されて、任意に下方向参照がなぜ適切であるかがわかるべきであるのを示す参照テキストに含まれています。
The Internet Engineering Steering Group (IESG) may, at its discretion, specify the exact text to be used, establish procedures regarding the text to use, or give guidance on this text. When establishing procedures, the IESG should seek appropriate community review.
インターネットEngineering Steering Group(IESG)は使用されるために自己判断で正確なテキストを指定するか、使用するテキストに関して手順を確立するか、または本稿で指導を与えるかもしれません。 手順を確立するとき、IESGは適切な共同体レビューを求めるはずです。
These annotations are part of the source document. If members of the community consider either the downward reference or the annotation text to be inappropriate, those issues can be raised at any time during the document life cycle, just as with any other text in the document. There is no separate review of these references.
これらの注釈はソースドキュメントの一部です。 共同体のメンバーが、下方向参照か注釈テキストのどちらかが不適当であると考えるなら、いつでもドキュメントライフサイクルの間、それらの問題を提起できます、ちょうどドキュメントのいかなる他のテキストのようにも。 これらの参照のどんな別々のレビューもありません。
With appropriate community review, the IESG may establish procedures for when normative downward references should delay a document and when downward references should be noted. Absent specific guidance, authors and reviewers should use their best judgment. It is assumed that, in a significant majority of cases, noting a downward reference is preferable to delaying publication.
適切な共同体レビューで、標準の下方向参照がいつドキュメントを遅らせるべきであるか、そして、下方向参照がいつ注意されるべきであるか間、IESGは手順を確立するかもしれません。 欠けている特定の指導、作者、および評論家は彼らの最も良い判断を使用するべきです。 下方向参照に注意するのが出版を遅らせるより場合のかなりの大部分で望ましいと思われます。
Klensin & Hartman Best Current Practice [Page 3] RFC 4897 Normative References June 2007
参照2007年6月の標準のKlensinとハートマン最も良い現在の習慣[3ページ]RFC4897
At the option of the author, similar notes may be attached to non- normative references.
作者の選択のときに、同様の注意は非引用規格に添付されるかもしれません。
3.2. Documents Already in the RFC Editor Queue
3.2. 既にRFCエディタ待ち行列におけるドキュメント
The IESG may, at its discretion, specify a procedure to be applied to source documents that are already in the RFC Editor queue, awaiting target referenced documents. The IESG should encourage authors with documents in the RFC Editor queue awaiting downward references to Standards-Track RFCs to evaluate whether this new rule is appropriate for their documents. If authors believe that adding an annotation and releasing the document is the best way forward, then the IESG should ensure that appropriate review is conducted and, if that review agrees with that of the authors' evaluation, allow the annotations to be added. The IESG will announce its decision via the normal Protocol-Action or Document-Action mechanisms.
IESGはRFC Editor待ち行列既に中であることのソースドキュメントに適用されるために自己判断で手順を指定するかもしれなくて、目標を待つのはドキュメントに参照をつけました。 IESGは、RFC Editor待ち行列におけるドキュメントがStandards-道のRFCsに下方向参照を待っている作者が、彼らのドキュメントに、この新しい規則が適切であるかどうか評価するよう奨励するはずです。 作者が、注釈を加えて、ドキュメントを発表するのが、次に、前方に、IESGが、適切なレビューが行われるのを確実にするはずである最も良い方法であると信じているなら、そのレビューが作者の評価のものに同意するなら、注釈は加えさせられてください。 IESGは通常のプロトコル動作かDocument-動作メカニズムで決定を発表するでしょう。
4. Target Documents Not on the Standards Track
4. 目標ドキュメントは規格で追跡されません。
In the case of a normative reference to a document not on the standards track that is approved under the procedures defined in RFC 3967, the annotation described in Section 3.1 or the retrospective annotation described in Section 3.2, SHOULD be added to the reference unless the IESG, after consideration of Last Call input, concludes it is inappropriate.
RFC3967で定義された手順の下で承認される標準化過程、セクション3.1で説明された注釈または回顧展注釈のときにセクション3.2、SHOULDで説明されなかったドキュメントの引用規格の場合では、IESGが、Last Call入力の考慮の後にそれが不適当であると結論づけない場合、参照に追加されてください。
5. Target Documents that Can Be Referenced This Way
5. 目標DocumentsはそのCan Be Referenced This Wayです。
The "downward reference by annotation" model specified here is applicable only to published Standards-Track RFCs at lower maturity levels.
ここで指定された「注釈による下方向参照」モデルは下側の成熟レベルで発行されたStandards-道のRFCsだけに適切です。
Obviously, such downward references are part of the relevant source document at IETF Last Call and subject to comments from the community.
明らかに、そのような下方向参照は共同体からのIETF Last Callにおけるコメントを条件とした関連ソースドキュメントの一部です。
Advancing documents, when appropriate, is still considered preferable to the use of either this procedure or the one specified in RFC 3967. This specification does not impose a specific test or requirement to determine appropriateness. This is partially because it would be impossible to do so for the general case, but more so because the intention is to permit the IESG and the community to balance the importance of getting a source document published against the time and difficulty associated with upgrading a target document. That requirement is intended to be less stringent than the one of RFC 3967.
適切であるときにドキュメントを進めるのはRFC3967で指定されたこの手順かもののどちらかの使用より望ましいとまだ考えられています。 この仕様は特異的な試験か適切さを決定するという要件を課しません。 そうするのは不可能でしょう、したがって、一般的なケースのための部分的にであるソースドキュメントが意志がIESGと共同体が得ることの重要性のバランスをとることを許可することであるので目標ドキュメントをアップグレードさせると関連している時間と困難に対して発表して、これはさらにそうすること。 その要件がRFC3967の1つほど厳しくないことを意図します。
Klensin & Hartman Best Current Practice [Page 4] RFC 4897 Normative References June 2007
参照2007年6月の標準のKlensinとハートマン最も良い現在の習慣[4ページ]RFC4897
6. Security Considerations
6. セキュリティ問題
This document specifies an IETF procedure. It is not believed to raise any security issues although, in principle, relaxing the normative downward reference rules for references associated with security mechanisms could make a specification less stable and hence less secure.
このドキュメントはIETF手順を指定します。 仕様は原則としてセキュリティー対策に関連している参照のための標準の下方向参照規則を弛緩するのにそれほど安定していなくてまたしたがって、より安全でなくなるかもしれませんが、それがどんな安全保障問題も提起すると信じられていません。
7. Acknowledgements
7. 承認
This proposal was suggested by a comment by Spencer Dawkins and many complaints about the negative impact of the current rules. The author is unsure about the validity of some of those complaints; the proposal is, in part, a way to test the validity question. Spencer also provided helpful comments on a preliminary version. It was revised in response to extensive discussion in the IESG and benefited significantly by comments from Brian Carpenter.
この提案は現在の規則の負の衝撃に関するスペンサー・ダウキンズと多くの苦情によってコメントで示されました。 作者はそれらの苦情のいくつかの正当性に関して不確かです。 提案は一部、正当性質問をテストする方法です。 また、スペンサーは準備段階で役に立つコメントを提供しました。 それは、IESGでの大規模な議論に対応して改訂されて、かなりブライアンCarpenterからコメントの利益を得ました。
8. Normative References
8. 引用規格
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track
Documents may Refer Normatively to Documents at a Lower
Level", BCP 97, RFC 3967, December 2004.
[RFC3967] ブッシュ、R.、およびT.Narten、「Standards Track Documentsがそうするときのはっきりさせる、Lower LevelのDocumentsへのRefer Normatively、」、BCP97、RFC3967(2004年12月)
Authors' Addresses
作者のアドレス
John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
Ave、ジョンC Klensin1770マサチューセッツ#322MA02140ケンブリッジ(米国)
Phone: +1 617 491 5735 EMail: john-ietf@jck.com
以下に電話をしてください。 +1 5735年の617 491メール: john-ietf@jck.com
Sam Hartman Massachusetts Institute of Technology 77 Massachusetts Ave Cambridge, MA 02139 USA
サムハートマンマサチューセッツ工科大学77マサチューセッツAve MA02139ケンブリッジ(米国)
EMail: hartmans-ietf@mit.edu
メール: hartmans-ietf@mit.edu
Klensin & Hartman Best Current Practice [Page 5] RFC 4897 Normative References June 2007
参照2007年6月の標準のKlensinとハートマン最も良い現在の習慣[5ページ]RFC4897
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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はこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Klensin & Hartman Best Current Practice [Page 6]
KlensinとハートマンBest現在の習慣[6ページ]
一覧
スポンサーリンク
