RFC1796 日本語訳

Network Working Group                                         C. Huitema
Request for Comments: 1796                                         INRIA
Category: Informational                                        J. Postel
                                                                     ISI
                                                              S. Crocker
                                                               CyberCash
                                                              April 1995

Huitemaがコメントのために要求するワーキンググループC.をネットワークでつないでください: 1796年のINRIAカテゴリ: 情報のJ.のポステルISI S.医者サイバーキャッシュ1995年4月

                       Not All RFCs are Standards

どんなAll RFCsもStandardsではありません。

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Abstract

要約

   This document discusses the relationship of the Request for Comments
   (RFCs) notes to Internet Standards.

このドキュメントはComments(RFCs)注意のためにインターネットStandardsとRequestの関係について議論します。

Not All RFCs Are Standards

すべてのRFCsが規格であるというわけではありません。

   The "Request for Comments" (RFC) document series is the official
   publication channel for Internet standards documents and other
   publications of the IESG, IAB, and Internet community.  From time to
   time, and about every six months in the last few years, someone
   questions the rationality of publishing both Internet standards and
   informational documents as RFCs.  The argument is generally that this
   introduces some confusion between "real standards" and "mere
   publications".

「コメントを求める要求」(RFC)ドキュメントシリーズは、インターネット規格文書のための公式の公開チャネルとIESG、IAB、およびインターネットコミュニティの他の刊行物です。 時々とここ数年間で6カ月毎の周りに関して、だれかがRFCsとしてインターネット標準と情報のドキュメントの両方を発表する合理性に質問します。 議論は一般に、これが「本当の規格」と「単なる刊行物」の間に何らかの混乱を導入するということです。

   It is a regrettably well spread misconception that publication as an
   RFC provides some level of recognition.  It does not, or at least not
   any more than the publication in a regular journal.  In fact, each
   RFC has a status, relative to its relation with the Internet
   standardization process: Informational, Experimental, or Standards
   Track (Proposed Standard, Draft Standard, Internet Standard), or
   Historic.  This status is reproduced on the first page of the RFC
   itself, and is also documented in the periodic "Internet Official
   Protocols Standards" RFC (STD 1).  But this status is sometimes
   omitted from quotes and references, which may feed the confusion.

それはRFCとしての公表が何らかのレベルの認識を提供するという残念なことによく広げられた誤解です。 それがそうしない、または、通常のジャーナルでの公表より少なくとももっと多くのものでない。 事実上、各RFCには、インターネット標準化過程との関係に比例して状態がいます: 情報的か、実験的であるか、標準化過程的(提案された標準、標準の草稿インターネット規格)、または歴史的です。 この状態は、RFC自身の最初のページで再生して、また、周期的な「インターネットの公式のプロトコル規格」RFC(STD1)に記録されます。 しかし、この状態は引用文と参照から時々省略されます。(参照は混乱を食べさせるかもしれません)。

   There are two important sources of information on the status of the
   Internet standards:  they are summarized periodically in an RFC
   entitled "Internet Official Protocol Standards" and they are
   documented in the "STD" subseries.  When a specification has been

2つの重要な情報筋がインターネット標準の状態にあります: それらは「インターネット公式プロトコル標準」の権利を与えられたRFCに定期的にまとめられます、そして、"STD"「副-シリーズ」に記録されます。 仕様はいつですか。

Huitema, Postel & Crocker                                       [Page 1]

RFC 1796               Not All RFCs are Standards             April 1995

1995年4月にHuitema、ポステル、およびクロッカー[1ページ]RFC1796Not All RFCsはStandardsです。

   adopted as an Internet Standard, it is given the additional label
   "STD xxxx", but it keeps its RFC number and its place in the RFC
   series.

インターネットStandardとして採用されています、追加ラベル"STD xxxx"をそれに与えますが、それはRFC番号とRFCシリーズにおけるその場所を保ちます。

   It is important to note that the relationship of STD numbers to RFC
   numbers is not one to one.  STD numbers identify protocols, RFC
   numbers identify documents.  Sometimes more than one document is used
   to specify a Standard protocol.

RFC番号へのSTD番号の関係が1〜1でないことに注意するのは重要です。 STD番号はプロトコルを特定して、RFC番号はドキュメントを特定します。 時々、1通以上のドキュメントが、Standardプロトコルを指定するのに使用されます。

   In order to further increase the publicity of the standardization
   status, the IAB proposes the following actions:

標準化状態の宣伝をさらに増加させるように、IABは以下の動作を提案します:

      Use the STD number, rather than just the RFC numbers, in the cross
      references between standard tracks documents,

まさしく標準の道の間の相互参照におけるRFC番号よりむしろSTD番号が記録する使用

      Utilize the "web" hypertext technology to publicize the state of
      the standardization process.

標準化過程の状態についてピーアールする「ウェブ」ハイパーテキスト技術を利用してください。

   More precisely, we propose to add to the current RFC repository an
   "html" version of the "STD-1" document, i.e., the list of Internet
   standards.  We are considering the extension of this document to also
   describes actions in progress, i.e., standards track work at the
   "proposed" or "draft" stage.

より正確に、私たちは、「すなわち、STD-1インチのドキュメント、インターネット標準のリスト」の"html"バージョンを現在のRFC倉庫に加えるよう提案します。 私たちがこのドキュメントの拡大を考えている、また、進行中(すなわち、「提案」か「草稿」段階での規格保線工事)で動作について説明します。

A Single Archive

ただ一つのアーカイブ

   The IAB believes that the community benefitted significantly from
   having a single archival document series.  Documents are easy to find
   and to retrieve, and file servers are easy to organize.  This has
   been very important over the long term.  Experience of the past shows
   that subseries, or series of limited scope, tend to vanish from the
   network.  And, there is no evidence that alternate document schemes
   would result in less confusion.

IABは、共同体がただ一つの記録保管所のドキュメントシリーズを持つのからかなり利益を得たと信じています。 見つけやすくて、ドキュメントは検索しやすいです、そして、ファイルサーバーは組織化しやすいです。 これは長期的に見ると非常に重要です。 過去の経験は、「副-シリーズ」、または限られた範囲のシリーズが、ネットワークから消え失せる傾向があるのを示します。 そして、交互のドキュメント計画が、より少ない混乱をもたらすだろうという証拠が全くありません。

   Moreover, we believe that the presence of additional documents does
   not actually hurt the standardization process.  The solution which we
   propose is to better publicize the "standard" status of certain
   documents, which is made relatively easy by the advent of networked
   hypertext technologies.

そのうえ、私たちは、追加ドキュメントの存在が実際に標準化過程に害を与えないと信じています。 私たちが提案する解決策はあるドキュメントの「標準」の状態について、よりよく、ピーアールすることです。(それは、ネットワークでつながれたハイパーテキスト技術の到来によって比較的簡単にされます)。

Rather Document Than Ignore

むしろ記録する、無視

   The RFC series includes some documents which are informational by
   nature and other documents which describe experiences.  A problem of
   perception occurs when such a document "looks like" an official
   protocol specification.  Misguided vendors may claim conformance to
   it, and misguided clients may actually believe that they are buying
   an Internet standard.

RFCシリーズはいくつかの生来、情報であることのドキュメントと経験について説明する他のドキュメントを含んでいます。 そのようなドキュメントが公式のプロトコル仕様に「似ている」と、知覚の問題は起こります。 見当違いの業者は順応をそれに主張するかもしれません、そして、見当違いのクライアントは彼らがインターネット標準を買っていると実際に信じるかもしれません。

Huitema, Postel & Crocker                                       [Page 2]

RFC 1796               Not All RFCs are Standards             April 1995

1995年4月にHuitema、ポステル、およびクロッカー[2ページ]RFC1796Not All RFCsはStandardsです。

   The IAB believes that the proper help to misguided vendors and
   clients is to provide them guidance.  There is actually very little
   evidence of vendors purposely attempting to present informational or
   experimental RFCs as "Internet standards".  If such attempts
   occurred, proper response would indeed be required.

IABは、見当違いの業者とクライアントへの適切な助けが指導を彼らに提供することであると信じています。 業者が、「インターネット標準」として情報的、または、実験的なRFCsを寄贈するのをわざわざ試みるという実際に非常に少ない証拠があります。 そのような試みが起こるなら、本当に、適切な応答が必要でしょうに。

   The IAB believes that the community is best served by openly
   developed specifications.  The Internet standardization process
   provides guarantees of openness and thorough review, and the normal
   way to develop the specification of an Internet protocol is indeed
   through the IETF.

IABは、オープンに開発された仕様で共同体に役立つのが最も良いと信じています。 インターネット標準化過程は風通しの良さの保証と徹底的なレビューを提供します、そして、本当にIETFを通してインターネットプロトコルの仕様を開発する正常な方法があります。

   The community is also well served by having access to specifications
   of which have been developed outside the IETF standards process,
   either because the protocols are experimental in nature, were
   developed privately, or failed to achieve the acquire the degree of
   consensus required for elevation to the standards track.

また、どれがプロトコルが現実に実験しているので、IETF標準化過程の外で開発されたか、個人的に開発されたか、または失敗されたかについて仕様に達成する近づく手段を持っているのが共同体によく役立たれている、高度に標準化過程に必要であるコンセンサスの度合いを取得してください。

   The IAB believes that publication is better than ignorance.  If a
   particular specification ends up being used in products that are
   deployed over the Internet, we are better off if the specification is
   easy to retrieve as an RFC than if it is hidden in some private
   repository.

IABは、公表が無知より良いと信じています。 結局インターネットの上で配備される製品の中に特記仕様書が使用されるなら、仕様はRFCとして検索しやすいなら私たちが、より暮らし向きが良い、それが、ある個人的な倉庫に隠されるなら。

Huitema, Postel & Crocker                                       [Page 3]

RFC 1796               Not All RFCs are Standards             April 1995

1995年4月にHuitema、ポステル、およびクロッカー[3ページ]RFC1796Not All RFCsはStandardsです。

Security Considerations

セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

Authors' Addresses

作者のアドレス

   Christian Huitema
   INRIA, Sophia-Antipolis
   2004 Route des Lucioles
   BP 109
   F-06561 Valbonne Cedex
   France

クリスチャンのHuitema INRIA、2004台のソフィア-Antipolis Route desルシオールBP109F-06561Valbonne Cedexフランス

   Phone: +33 93 65 77 15
   EMail: Christian.Huitema@MIRSA.INRIA.FR

以下に電話をしてください。 +33 93 65 77 15はメールされます: Christian.Huitema@MIRSA.INRIA.FR

   Jon Postel
   USC/Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292

ジョンポステルUSC/Information Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア 90292

   Phone: 1-310-822-1511
   EMail: Postel@ISI.EDU

以下に電話をしてください。 1-310-822-1511 メールしてください: Postel@ISI.EDU

   Steve Crocker
   CyberCash, Inc.
   2086 Hunters Crest Way
   Vienna, VA 22181

スティーブ医者サイバーキャッシュInc.2086ハンターは道ウィーン(ヴァージニア)22181の前立てを付けます。

   Phone: 1- 703-620-1222
   EMail: crocker@cybercash.com

以下に電話をしてください。 1- 703-620-1222 メールしてください: crocker@cybercash.com

Huitema, Postel & Crocker                                       [Page 4]

Huitema、ポステル、およびクロッカー[4ページ]