RFC2913 日本語訳

Network Working Group                                           G. Klyne
Request for Comments: 2913                          Content Technologies
Category: Standards Track                                 September 2000

Klyneがコメントのために要求するワーキンググループG.をネットワークでつないでください: 2913年の満足している技術カテゴリ: 標準化過程2000年9月

            MIME Content Types in Media Feature Expressions

メディアによるMIME content typeは式を特徴とします。

Status of this Memo

このMemoの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

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

Copyright(C)インターネット協会(2000)。 All rights reserved。

Abstract

要約

   In "A Syntax for Describing Media Feature Sets", an expression format
   is presented for describing media feature capabilities using simple
   media feature tags.

「メディア機能について説明するための構文はセットするところ」では、式形式が、特徴がタグ付けをする簡単なメディアを使用することでメディア特徴能力について説明するために提示されます。

   This memo defines a media feature tag whose value is a Multipurpose
   Internet Mail Extensions (MIME) content type.  This allows the
   construction of feature expressions that take account of the MIME
   content type of the corresponding data.

このメモは値がマルチパーパスインターネットメールエクステンション(MIME)content typeであるメディア特徴タグを定義します。 これは対応するデータのMIME content typeを考慮に入れる特徴式の工事を許します。

Table of Contents

目次

   1. Introduction .................................................. 2
      1.1 Terminology and document conventions ...................... 2
   2. Motivation and goals .......................................... 3
   3. MIME content type feature tag ................................. 3
   4. Examples ...................................................... 4
      4.1 Simple text ............................................... 4
      4.2 Fax image ................................................. 4
      4.3 Voice message ............................................. 4
      4.4 Web browser capabilities .................................. 5
   5. IANA Considerations ........................................... 5
   6. Security Considerations ....................................... 5
   7. Acknowledgements .............................................. 5
   8. References .................................................... 6
   9. Author's Address .............................................. 6
   Appendix A: 'Type' feature tag registration ...................... 7
   Full Copyright Statement ......................................... 9

1. 序論… 2 1.1 用語とドキュメントコンベンション… 2 2. 動機と目標… 3 3. MIME content type特徴タグ… 3 4. 例… 4 4.1 簡単なテキスト… 4 4.2 ファックスで、イメージを送ってください… 4 4.3 メッセージを声に出してください… 4 4.4 ウェブブラウザ能力… 5 5. IANA問題… 5 6. セキュリティ問題… 5 7. 承認… 5 8. 参照… 6 9. 作者のアドレス… 6 付録A: 'タイプ'はタグ登録を特徴とします… 7 完全な著作権宣言文… 9

Klyne                       Standards Track                     [Page 1]

RFC 2913       MIME Content in Media Feature Expressions  September 2000

Klyne標準化過程[1ページ]RFC2913は特徴式2000年9月にメディアによる内容をまねます。

1. Introduction

1. 序論

   In "A Syntax for Describing Media Feature Sets" [1], an expression
   format is presented for describing media feature capabilities as a
   combination of simple media feature tags, registered according to
   "Media Feature Tag Registration Procedure" [2].  This provides a
   format for message handling agents to describe the media feature
   content of messages that they can handle.

「特徴が設定するメディアを説明するための構文」[1]では、式形式は、簡単なメディアの組み合わせとしての特徴能力が特集するメディアを説明するためにタグであって、「メディアはタグ登録手順を特徴とする」という[2]によると、登録されていた状態で提示されます。 メッセージハンドリングエージェントがそれらが扱うことができるメッセージのメディア特徴内容について説明するように、これは形式を提供します。

   This memo defines a media feature tag whose value is a MIME content
   type.  This allows the construction of feature expressions that take
   account of the MIME content type of the corresponding data.

このメモは値がMIME content typeであるメディア特徴タグを定義します。 これは対応するデータのMIME content typeを考慮に入れる特徴式の工事を許します。

   Note that a content type feature value may contain parameters, but
   this is discouraged.  See section 3 and appendix A, "Summary of the
   media features indicated" for discussion of this point.

content type特徴価値がパラメタを含むかもしれませんが、これががっかりしていることに注意してください。 このポイントの議論に関してセクション3と付録A、「特徴が示したメディアの概要」を見てください。

1.1 Terminology and document conventions

1.1 用語とドキュメントコンベンション

   This section defines a number of terms and other document
   conventions, which are used with specific meaning in this memo.

このセクションは多くの用語と他のドキュメントコンベンションを定義します。(コンベンションはこのメモによる特定の意味と共に使用されます)。

   media feature
         information that indicates facilities assumed to be available
         for the message content to be properly rendered or otherwise
         presented.  Media features are not intended to include
         information that affects message transmission.

メディアはメッセージ内容が適切に表されるか、またはそうでなければ、提示されるために利用可能であると思われた施設を示す情報を特徴とします。 メディア機能がメッセージ送信に影響する情報を含んでいることを意図しません。

   feature set
         some set of media features described by a media feature
         assertion, as described in "A Syntax for Describing Media
         Feature Sets" [1].  (See that memo for a more formal definition
         of this term.)

特徴はメディア特徴主張で説明された何らかのセットのメディア機能を設定しました、「特徴が設定するメディアを説明するための構文」[1]で説明されるように。 (今期の、より正式な定義に関してそのメモを見てください。)

   feature set expression
         a string that describes some feature set, formulated according
         to the rules in "A Syntax for Describing Media Feature Sets"
         [1] (and possibly extended by other specifications).

設定していて、定式化されて「特徴が設定するメディアを説明するための構文」[1]の規則に従って(ことによると他の仕様で広げられます)の何らかの特徴について説明するセット式aストリングを特徴としてください。

   This specification uses syntax notation and conventions described in
   RFC 2234, "Augmented BNF for Syntax Specifications: ABNF" [3].

この仕様がRFC2234で説明された構文記法とコンベンションを使用する、「構文仕様のための増大しているBNF:」 "ABNF"[3]。

      NOTE:  Comments like this provide additional nonessential
      information about the rationale behind this document.  Such
      information is not needed for building a conformant
      implementation, but may help those who wish to understand the
      design in greater depth.

以下に注意してください。 このようなコメントは原理の追加不要不急な情報をこのドキュメントの後ろに供給します。 そのような情報は、conformant実装を築き上げるのに必要ではありませんが、より大きい深さでデザインを理解したがっている人を助けるかもしれません。

Klyne                       Standards Track                     [Page 2]

RFC 2913       MIME Content in Media Feature Expressions  September 2000

Klyne標準化過程[2ページ]RFC2913は特徴式2000年9月にメディアによる内容をまねます。

2. Motivation and goals

2. 動機と目標

   The media feature expression syntax [1] and feature tags [2] were
   designed with a view to providing content media information that
   augments basic MIME content type information.  There are some
   situations where it is useful to be able include that content type
   information in a media feature expression:

メディアは式構文[1]を特徴とします、そして、特徴タグ[2]は、基本のMIME content type情報を増大させる満足しているメディア情報を提供するように設計されました。 いくつかの状況がaメディアによるcontent type情報が式を特徴とするのによる役に立つのが、できるインクルードであるということであるところにあります:

   o  Media feature details may depend upon the content type being used.
      The media feature combining algebra and syntax [1] cannot apply to
      content type information unless it appears in the feature
      expression.

o 特徴が詳しく述べるメディアは使用されるcontent typeによるかもしれません。 特徴式に現れない場合、代数と構文[1]を結合するメディア機能はcontent type情報に適用できません。

      For example, in HTTP 1.1 [4] with Transparent Content Negotiation
      (TCN) [5] acceptable content types and other media features are
      indicated in different request headers, with no clear way to
      indicate that they may be acceptable only in certain combinations.

例えば、HTTPでは、Transparent Content Negotiation(TCN)の[5]の許容できるcontent typeと他のメディア機能がある1.1[4]は異なった要求ヘッダーで示されます、彼らが、ある組み合わせだけで許容できるかもしれないのを示す明確な方法なしで。

   o  It is sometimes useful for all media capability information to be
      included in a single expression.  For example, DSN and MDN
      extensions [6] that allow a recipient to indicate media
      capabilities provide a single field for conveying this
      information.

o すべてのメディア能力情報がただ一つの式に含まれているのは、時々役に立ちます。 例えば、DSNと受取人がメディア能力を示すことができるMDN拡張子[6]はこの情報を伝えるのにただ一つの野原を供給します。

   o  When media features are used to describe a message content, they
      may refer to inner parts of a MIME composite; e.g. the component
      parts of a 'multipart', files in a compressed archive, or
      encrypted message data.

o メディア機能がメッセージ内容について説明するのに使用されるとき、彼らはMIME合成物の内側の一部について言及するかもしれません。 例えば、'複合'のコンポーネントの部品、圧縮されたアーカイブ、または暗号化メッセージデータのファイル。

3. MIME content type feature tag

3. MIME content type特徴タグ

   Feature tag name    Legal values
   ----------------    ------------
   type                <string>
                       containing a MIME content-type value.

特徴タグ名前Legal値---------------- ------------ MIME content type価値を含む<ストリング>をタイプしてください。

   Reference: this document, appendix A.

参照: このドキュメント、付録A。

   The 'type' feature tag indicates a MIME media content type (i.e.
   that appears in a 'Content-type:' header of the corresponding MIME-
   formatted data).  It must be a string of the form "type/subtype",
   where 'type' and 'subtype' are defined by the MIME specification [7].
   Only lower-case letters should be used.

'タイプ'特徴タグはMIMEメディアcontent typeを示します(すなわち、それは'文書内容に現れます: '対応するMIMEのヘッダーはデータをフォーマットしました)。 それはフォーム「タイプ/「副-タイプ」」のストリングであるに違いありません。そこでは、'タイプ'と'「副-タイプ」'がMIME仕様[7]で定義されます。 小文字アルファベットだけが使用されるべきです。

   The content type must be given without any content-type parameter
   values.

少しもcontent typeパラメタ値なしでcontent typeを与えなければなりません。

Klyne                       Standards Track                     [Page 3]

RFC 2913       MIME Content in Media Feature Expressions  September 2000

Klyne標準化過程[3ページ]RFC2913は特徴式2000年9月にメディアによる内容をまねます。

   To include information in media feature expressions that is otherwise
   conveyed in a MIME content-type parameter, a separate media feature
   tag should be registered [2] and used in the media feature
   expression.  This is illustrated by the use of 'charset' in the
   example at 4.1 below -- the 'charset' tag is defined by a separate
   registration [10].

中に情報を含むように、メディアは式を特徴とします、すなわち、別の方法でMIME content typeパラメタを運ばれて、特徴タグが登録された[2]の、そして、中古のコネがメディアであるならそうするa別々のメディアは式を特徴とします。 これは4.1未満で例における'charset'の使用で例証されます--'charset'タグは別々の登録[10]で定義されます。

      NOTE:  Allowing content-type parameters to be part of a type tag
      value was considered, but rejected because of concerns about
      canonicalization, ordering, case sensitivity, etc.  Only exact,
      case-sensitive, character matching is defined for media feature
      expressions [1].

以下に注意してください。 content typeパラメタがタイプタグ価値の一部であることを許容するのが、canonicalization、注文、ケース感度などに関する心配で考えられましたが、拒絶されました。 正確でだけの、大文字と小文字を区別するキャラクタマッチングはメディア特徴式[1]のために定義されます。

4. Examples

4. 例

4.1 Simple text

4.1 簡単なテキスト

      (& (type="text/plain") (charset=US-ASCII)
         (color=binary) (paper-size=A4) )

((タイプ=「テキスト/平野」)(charsetは米国-ASCIIと等しいです)(=を着色して、2進にします)(紙サイズ=A4))

4.2 Fax image

4.2 ファックスイメージ

      (& (type="image/tiff")
         (color=binary)
         (image-file-structure=TIFF-S)
         (dpi=200)
         (dpi-xyratio=[200/100,200/200])
         (paper-size=A4)
         (image-coding=MH) (MRC-mode=0)
         (ua-media=stationery) )

((タイプ=「イメージ/いさかい」)(=を着色して、2進にします)(イメージファイル構造はいさかいSと等しいです)(dpi=200)(dpi-xyratio=[200/100,200/200])(紙サイズ=A4)(画像符号化はMHと等しいです)(MRC-モード=0)(ua-メディアは文房具と等しいです))

4.3 Voice message

4.3 音声メール

      (& (type="multipart/voice-message")
         (VPIM-version="3.0")
         (audio-codec=[G726-32,GSM-610])
         (audio-file-structure=[None,WAV])
         (ua-terminal=mobile-handset)
         (audio-channels=1) )

((タイプ=「複合/音声メール」)、(「3インチ) (オーディオのコーデック=[G726-32、GSM-610)(オーディオのファイル構造=[なにも、音声データのファイル・フォーマット])(ua端末の=移動体端末)(音声チャンネル=1))」というVPIMバージョン=

         NOTE:  in this case, some media features apply to MIME parts
         contained within the declared 'multipart/voice- message'
         content type.  The goal here is not so much to mirror the MIME
         structure as to convey useful information about the (possible)
         message content.

以下に注意してください。 この場合、特徴がMIMEの部品に当てるいくつかのメディアが宣言している'複合/の中に声のメッセージ'content typeを含みました。 ここの目標はMIME構造を反映するより(可能)のメッセージ内容に関する役に立つ情報を伝えることです。

Klyne                       Standards Track                     [Page 4]

RFC 2913       MIME Content in Media Feature Expressions  September 2000

Klyne標準化過程[4ページ]RFC2913は特徴式2000年9月にメディアによる内容をまねます。

4.4 Web browser capabilities

4.4 ウェブブラウザ能力

      (& (pix-x<=800) (pix-y<=600)
         (| (& (type="text/html") (charset=iso-8859-1)
               (color=limited) )
            (& (type="text/plain") (charset=US-ASCII) )
            (& (type="image/gif") (color=mapped))
            (& (type="image/jpeg") (color=full) ) ) )

写真..写真..タイプ..テキスト..色..制限..タイプ..テキスト..平野..等しい..米国..ASCII..タイプ..イメージ..色..写像..タイプ..イメージ..着色..いっぱい

   This example describes an HTML viewer that can deal with a limited
   number of color text tags, a gif viewer that supports mapped color,
   and a jpeg viewer that supports color.

この例は限られた数のカラーテキストタグに対処できるHTMLビューアー、写像している色をサポートするgifビューアー、および色をサポートするjpegビューアーについて説明します。

5. IANA Considerations

5. IANA問題

   Appendix A of this document calls for registration of a feature tag
   in the "IETF tree", as defined in section 3.1.1 of "Media Feature Tag
   Registration Procedure" [2] (i.e. these feature tags are subject to
   the "IETF Consensus" policies described in RFC 2434 [9]).

このドキュメントの付録Aは「IETF木」での特徴タグの登録を求めます、「メディアはタグ登録手順を特徴とする」という[2]についてセクション3.1.1で定義されるように。(すなわち、これらの特徴タグはRFC2434[9])で説明された「IETFコンセンサス」方針を条件としています。

   ASN.1 identifier 1.3.6.1.8.1.30 has been assigned by the IANA for
   this registered feature tag and has been placed in the body of the
   registration.

ASN.1識別子、1.3 .6 .1 .8 .1 .30 この登録された特徴タグのためにIANAによって割り当てられて、登録のボディーに置かれました。

6. Security Considerations

6. セキュリティ問題

   This memo is not believed to introduce any security considerations
   that are not already inherent in the use of media feature tags and
   expressions [1,2].

このメモが特徴がタグ付けをするメディアと式[1、2]の使用が既に固有でないどんなセキュリティ問題も紹介すると信じられていません。

7. Acknowledgements

7. 承認

   This proposal draws from discussions in the IETF 'conneg' working
   group.  The voice message example is based on some ideas by Glen
   Parsons.

この提案は議論からIETF'conneg'ワーキンググループで描かれます。 Glenパーソンズの音声メールの例はいくつかの考えに基づいています。

   The author would like to thank the following people who offered
   comments that led to significant improvements:  Ted Hardie, Larry
   Masinter, Paul Hoffman, Jacob Palme, Ned Freed.

作者は、だれがそれをコメントに提供したかがかなりの改善に通じたのを以下の人々に感謝したがっています: テッド・ハーディー、ラリーMasinter、ポール・ホフマン、ヤコブ・パルメ、解放されたネッド。

Klyne                       Standards Track                     [Page 5]

RFC 2913       MIME Content in Media Feature Expressions  September 2000

Klyne標準化過程[5ページ]RFC2913は特徴式2000年9月にメディアによる内容をまねます。

8. References

8. 参照

   [1]  Klyne, G., "A Syntax for Describing Media Feature Sets", RFC
        2533, March 1999.

[1]Klyne、G.、「特徴が設定するメディアを説明するための構文」、RFC2533、1999年3月。

   [2]  Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag
        Registration Procedure", RFC 2506, March 1999.

[2]HoltmanとK.とMutzとA.とT.ハーディー、「メディアはタグ登録手順を特徴とする」RFC2506、1999年3月。

   [3]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

[3] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。

   [4]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
        Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
        2068, January 1997.

[4] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2068、1997年ハイパーテキスト転送プロトコル--1月」。

   [5]  Holtman, K. and A. Mutz, "Transparent Content Negotiation in
        HTTP", RFC 2295, March 1998.

[5]HoltmanとK.とA.Mutz、「HTTPにおけるわかりやすい満足している交渉」、RFC2295、1998年3月。

   [6]  Wing, D., "Indicating Supported Media Features Using Extensions
        to DSN and MDN", RFC 2530, March 1999.

[6] 翼、D.、「表示は、メディアが特徴であるとDSNとMDNに拡張子を使用することでサポートした」RFC2530、1999年3月。

   [7]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part One: Format of Internet Message Bodies",
        RFC 2045, November 1996.

解放された[7]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。

   [8]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part Two: Media Types", RFC 2046, November
        1996.

解放された[8]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。

   [9]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", RFC 2434, October 1998.

[9]NartenとT.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」、RFC2434、1998年10月。

  [10]  Hoffman, P., "Registration of Charset and Languages Media
        Features Tags", Work in Progress.

[10] ホフマン、P.、「Charsetと言語メディアの登録はタグを特集すること」が進行中で働いています。

9. Author's Address

9. 作者のアドレス

   Graham Klyne
   Content Technologies Ltd.
   1220 Parkview,
   Arlington Business Park
   Theale
   Reading, RG7 4SA
   United Kingdom

全麦のKlyne満足している技術株式会社1220Parkview、アーリントンビジネスはTheale読書、RG7 4SAイギリスを駐車します。

   Phone: +44 118 930 1300
   Fax:   +44 118 930 1301
   EMail: GK@ACM.ORG

以下に電話をしてください。 +44 118 930、1300Fax: +44 1301年の118 930メール: GK@ACM.ORG

Klyne                       Standards Track                     [Page 6]

RFC 2913       MIME Content in Media Feature Expressions  September 2000

Klyne標準化過程[6ページ]RFC2913は特徴式2000年9月にメディアによる内容をまねます。

Appendix A: 'Type' feature tag registration

付録A: 'タイプ'特徴タグ登録

   -  Media Feature tag name(s):

- メディアFeatureは名前にタグ付けをします:

         Type

タイプ

   -  ASN.1 identifier associated with this feature tag:

- この特徴タグに関連しているASN.1識別子:

         1.3.6.1.8.1.30

1.3.6.1.8.1.30

   -  Summary of the media features indicated:

- 特徴が示したメディアの概要:

         This feature tag indicates a MIME content type that a message
         agent is capable of handling, or that is contained within some
         message data.

この特徴タグがメッセージエージェントが扱うことができるMIME content typeを示すか、またはそれはいくつかのメッセージデータの中に含まれています。

         The content type consists of the MIME media type and subtype,
         presented using all lower case letters and with any whitespace
         characters removed.

content typeはMIMEメディアタイプとすべての小文字を使用することで提示された「副-タイプ」から成りました、そして、どんな空白でも、キャラクタは取り外しました。

   -  Values appropriate for use with this feature tag:

- この特徴タグによる使用に、適切な値:

         String

ストリング

   -  The feature tag is intended primarily for use in the following
      applications, protocols, services, or negotiation mechanisms:

- 特徴タグは主として以下のアプリケーション、プロトコル、サービス、または交渉メカニズムにおける使用のために意図します:

         Any application that wishes to convey MIME content type
         information in a media feature expression.

メディア特徴式におけるMIME content type情報を伝えたがっているどんなアプリケーション。

   -  Examples of typical use:

- 典型的な使用に関する例:

         (type="image/tiff")

(タイプ=「イメージ/いさかい」)

         (& (type="text/plain") (charset=US-ASCII) )

((タイプ=「テキスト/平野」)(charsetは米国-ASCIIと等しいです))

   -  Related standards or documents:

- 関連規格かドキュメント:

         MIME, RFC 2045 [7]

RFC2045、まねてください。[7]

         MIME, RFC 2046 [8]

RFC2046、まねてください。[8]

         Registration of Charset and Languages Media Features Tags [10]

Charsetと言語メディアの登録はタグを特集します。[10]

   -  Considerations particular to use in individual applications,
      protocols, services, or negotiation mechanisms:

- 個々のアプリケーションで使用するために特定の問題、プロトコル、サービス、または交渉メカニズム:

         (N/A)

(なし)

Klyne                       Standards Track                     [Page 7]

RFC 2913       MIME Content in Media Feature Expressions  September 2000

Klyne標準化過程[7ページ]RFC2913は特徴式2000年9月にメディアによる内容をまねます。

   -  Interoperability considerations:

- 相互運用性問題:

         String feature matching is case sensitive, so consistent use of
         case for content type values and parameters is essential if
         content type value matching is to be achieved in a fashion
         consistent with MIME content type matching.

ストリング特徴マッチングは大文字と小文字を区別しています、非常に一貫しているので、ケースのcontent type値とパラメタの使用はcontent type値のマッチングがMIME content typeマッチングと一致したファッションで達成されることであるなら不可欠です。

         Similarly, white space must be used consistently.

同様に、一貫して余白を使用しなければなりません。

         This registration specifies a canonical form to be used for
         content type values (lower case letters and remove all
         whitespace).

この登録は、content type値に使用されるために標準形を指定します(ケース手紙を下ろしてください、そして、すべての空白を取り除いてください)。

   -  Related feature tags:

- 関連特徴タグ:

         (N/A)

(なし)

   -  Intended usage:

- 意図している用法:

         Common

一般的

   -  Author/Change controller:

- コントローラを書くか、または変えてください:

         IETF

IETF

Klyne                       Standards Track                     [Page 8]

RFC 2913       MIME Content in Media Feature Expressions  September 2000

Klyne標準化過程[8ページ]RFC2913は特徴式2000年9月にメディアによる内容をまねます。

Full Copyright Statement

完全な著作権宣言文

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

Copyright(C)インターネット協会(2000)。 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機能のための基金は現在、インターネット協会によって提供されます。

Klyne                       Standards Track                     [Page 9]

Klyne標準化過程[9ページ]