RFC2388 日本語訳

Network Working Group                                         L. Masinter
Request for Comments: 2388                              Xerox Corporation
Category: Standards Track                                     August 1998

Masinterがコメントのために要求するワーキンググループL.をネットワークでつないでください: 2388年のゼロックス社のカテゴリ: 標準化過程1998年8月

           Returning Values from Forms:  multipart/form-data

フォームからの戻っている値: 複合かデータを形成します。

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

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

1. Abstract

1. 要約

   This specification defines an Internet Media Type, multipart/form-
   data, which can be used by a wide variety of applications and
   transported by a wide variety of protocols as a way of returning a
   set of values as the result of a user filling out a form.

この仕様はインターネットメディアTypeを定義して、複合/はデータを形成します。(ユーザが書類に書き込むという結果として1セットの値を返す方法としてデータをさまざまなアプリケーションで使用して、さまざまなプロトコルは輸送できます)。

2. Introduction

2. 序論

   In many applications, it is possible for a user to be presented with
   a form. The user will fill out the form, including information that
   is typed, generated by user input, or included from files that the
   user has selected. When the form is filled out, the data from the
   form is sent from the user to the receiving application.

多くのアプリケーションでは、フォームをユーザに与えるのは可能です。 ユーザは用紙に記入するでしょう、タイプされるか、ユーザ入力で生成されるか、またはユーザが選択したファイルから含まれている情報を含んでいて。 書類に書き込むとき、ユーザから受信アプリケーションにフォームからのデータを送ります。

   The definition of MultiPart/Form-Data is derived from one of those
   applications, originally set out in [RFC1867] and subsequently
   incorporated into [HTML40], where forms are expressed in HTML, and in
   which the form values are sent via HTTP or electronic mail. This
   representation is widely implemented in numerous web browsers and web
   servers.

書式がHTMLで言い表されて、フォーム値がHTTPで送られる元々、[RFC1867]を始められて、次に[HTML40]に組み入れられたそれらのアプリケーションか電子メールの1つからフォームMultiPart/データの定義を得ます。 この表現は多数のウェブブラウザとウェブサーバーで広く実装されます。

   However, multipart/form-data can be used for forms that are presented
   using representations other than HTML (spreadsheets, Portable
   Document Format, etc), and for transport using other means than
   electronic mail or HTTP. This document defines the representation of
   form values independently of the application for which it is used.

しかしながら、電子メールかHTTP以外の手段を使用しながらHTML(スプレッドシート、Portable Document Formatなど)、および輸送の表現を使用することで提示されるフォームに複合/フォームデータを使用できます。 このドキュメントはそれが使用されているアプリケーションの如何にかかわらずフォーム値の表現を定義します。

Masinter                    Standards Track                     [Page 1]

RFC 2388                  multipart/form-data                August 1998

複合の、または、データを形成しているMasinter Standards Track[1ページ]RFC2388 1998年8月

3. Definition of multipart/form-data

3. 複合かデータを形成する定義

   The media-type multipart/form-data follows the rules of all multipart
   MIME data streams as outlined in [RFC 2046].  In forms, there are a
   series of fields to be supplied by the user who fills out the form.
   Each field has a name. Within a given form, the names are unique.

メディアタイプ複合/フォームデータは[RFC2046]に概説されているようにすべての複合MIMEデータ・ストリームの規則に従います。 フォームには、用紙に記入するユーザによって供給される一連の野原がいます。 各分野には、名前があります。 与えられたフォームの中では、名前はユニークです。

   "multipart/form-data" contains a series of parts. Each part is
   expected to contain a content-disposition header [RFC 2183] where the
   disposition type is "form-data", and where the disposition contains
   an (additional) parameter of "name", where the value of that
   parameter is the original field name in the form. For example, a part
   might contain a header:

「複合/フォームデータ」は一連の部品を含んでいます。 各部分がフォームに気質タイプが「フォームデータ」であり、気質がそのパラメタの値がオリジナルのフィールド名である「名前」の(追加する)のパラメタを含む満足している気質ヘッダー[RFC2183]を含むことが期待されます。 例えば、部分はヘッダーを含むかもしれません:

        Content-Disposition: form-data; name="user"

満足している気質: フォームデータ。 名前=「ユーザ」

   with the value corresponding to the entry of the "user" field.

「ユーザ」分野のエントリーに対応する値で。

   Field names originally in non-ASCII character sets may be encoded
   within the value of the "name" parameter using the standard method
   described in RFC 2047.

元々非ASCII文字の組のフィールド名は、パラメタという「名前」の値の中でRFC2047で説明された標準方法を使用することでコード化されるかもしれません。

   As with all multipart MIME types, each part has an optional
   "Content-Type", which defaults to text/plain.  If the contents of a
   file are returned via filling out a form, then the file input is
   identified as the appropriate media type, if known, or
   "application/octet-stream".  If multiple files are to be returned as
   the result of a single form entry, they should be represented as a
   "multipart/mixed" part embedded within the "multipart/form-data".

すべての複合MIMEの種類のように、各部分には任意の「コンテントタイプ」があります。(それは、テキスト/平野をデフォルトとします)。 ファイルの中身は知られているなら適切なメディアがタイプされるように書類に書き込むことを通して返します、次に、ファイル入力が特定されるということであるか、そして、「八重奏アプリケーション/ストリーム。」 複数のファイルが単一の形式記入の結果として返すことであるなら、「複合かデータを形成する」中で埋め込まれた「複合か混ぜられた」部分としてそれらを表すべきです。

   Each part may be encoded and the "content-transfer-encoding" header
   supplied if the value of that part does not conform to the default
   encoding.

各部分はコード化されるかもしれません、そして、その部分の値であるなら供給された「満足している転送コード化」ヘッダーはデフォルトコード化に従いません。

4. Use of multipart/form-data

4. 複合かデータを形成することの使用

4.1 Boundary

4.1 境界

   As with other multipart types, a boundary is selected that does not
   occur in any of the data. Each field of the form is sent, in the
   order defined by the sending appliction and form, as a part of the
   multipart stream.  Each part identifies the INPUT name within the
   original form. Each part should be labelled with an appropriate
   content-type if the media type is known (e.g., inferred from the file
   extension or operating system typing information) or as
   "application/octet-stream".

他の複合タイプのように、データのいずれにも起こらない境界は選択されます。 フォームの各野原を送ります、送付applictionと用紙によって定義されたオーダーで、複合ストリームの一部として。 各部分は原型の中でINPUT名を特定します。 知られているか(例えば、情報をタイプするファイル拡張子かオペレーティングシステムから、推論されます)、「八重奏アプリケーション/ストリーム」としてメディアタイプがあるなら、各部分は適切なcontent typeでラベルされるべきです。

Masinter                    Standards Track                     [Page 2]

RFC 2388                  multipart/form-data                August 1998

複合の、または、データを形成しているMasinter Standards Track[2ページ]RFC2388 1998年8月

4.2 Sets of files

4.2 ファイルのセット

   If the value of a form field is a set of files rather than a single
   file, that value can be transferred together using the
   "multipart/mixed" format.

フォーム分野の値が一列よりむしろ1セットのファイルであるなら、「複合か混ぜられた」形式を使用することでその値を一緒に移すことができます。

4.3 Encoding

4.3 コード化

   While the HTTP protocol can transport arbitrary binary data, the
   default for mail transport is the 7BIT encoding.  The value supplied
   for a part may need to be encoded and the "content-transfer-encoding"
   header supplied if the value does not conform to the default
   encoding.  [See section 5 of RFC 2046 for more details.]

HTTPプロトコルは任意のバイナリ・データを輸送できますが、メール輸送のためのデフォルトは7BITコード化です。 部分に供給された値は値がデフォルトコード化に従わないなら供給されたコード化されるべき必要性と「満足している転送コード化」ヘッダーがそうするかもしれません。 [その他の詳細に関してRFC2046のセクション5を見てください。]

4.4 Other attributes

4.4 他の属性

   Forms may request file inputs from the user; the form software may
   include the file name and other file attributes, as specified in [RFC
   2184].

フォームはユーザからファイル入力を要求するかもしれません。 フォームソフトウェアは[RFC2184]で指定されるようにファイル名と他のファイル属性を含むかもしれません。

   The original local file name may be supplied as well, either as a
   "filename" parameter either of the "content-disposition: form-data"
   header or, in the case of multiple files, in a "content-disposition:
   file" header of the subpart. The sending application MAY supply a
   file name; if the file name of the sender's operating system is not
   in US-ASCII, the file name might be approximated, or encoded using
   the method of RFC 2231.

また、どちらか「ファイル名」パラメタとしてオリジナルのローカルファイル名前を提供するかもしれない、「満足している気質:」 「フォームデータ」ヘッダーか複数のファイルの場合におけるコネ、「満足している気質:」 下位区分の「ファイル」ヘッダー。 送付アプリケーションはファイル名を提供するかもしれません。 米国-ASCIIに送付者のオペレーティングシステムのファイル名がないなら、近似されるかもしれないか、またはRFC2231のメソッドを使用することでコード化されたファイル名です。

   This is a convenience for those cases where the files supplied by the
   form might contain references to each other, e.g., a TeX file and its
   .sty auxiliary style description.

これはフォームによって提供されたファイルが互いについての言及、例えばTeXファイルを入れてあるかもしれないそれらのケースとその.styの補助のスタイル記述のための便利です。

4.5 Charset of text in form data

4.5 フォームデータのテキストのCharset

   Each part of a multipart/form-data is supposed to have a content-
   type.  In the case where a field element is text, the charset
   parameter for the text indicates the character encoding used.

複合/フォームデータの各部分には、内容タイプがあるべきです。 フィールド要素がテキストである場合では、テキストのためのcharsetパラメタは、文字符号化が使用したのを示します。

   For example, a form with a text field in which a user typed 'Joe owes
   <eu>100' where <eu> is the Euro symbol might have form data returned
   as:

例えば、ユーザのタイプされた'ジョーが'<eu>がユーロシンボルであるところで<eu>100に負っているテキストフィールドでのフォームには、データが戻ったフォームがあるかもしれません:

    --AaB03x
    content-disposition: form-data; name="field1"
    content-type: text/plain;charset=windows-1250
    content-transfer-encoding: quoted-printable

--AaB03xの満足している気質: フォームデータ。 =を命名してください、「field1"content type:」 テキスト/平野; charsetは窓-1250の満足している転送コード化と等しいです: 引用されて印刷可能です。

Masinter                    Standards Track                     [Page 3]

RFC 2388                  multipart/form-data                August 1998

複合の、または、データを形成しているMasinter Standards Track[3ページ]RFC2388 1998年8月

    Joe owes =80100.
    --AaB03x

ジョーは=80100を負っています。 --AaB03x

5. Operability considerations

5. 運転可能性問題

5.1 Compression, encryption

5.1 圧縮、暗号化

   Some of the data in forms may be compressed or encrypted, using other
   MIME mechanisms. This is a function of the application that is
   generating the form-data.

圧縮されるか、またはフォームのいくつかのデータが暗号化されるかもしれません、他のMIMEメカニズムを使用して。これはフォームデータを生成しているアプリケーションの機能です。

5.2 Other data encodings rather than multipart

5.2 複合であるよりむしろ他のデータencodings

   Various people have suggested using new mime top-level type
   "aggregate", e.g., aggregate/mixed or a content-transfer-encoding of
   "packet" to express indeterminate-length binary data, rather than
   relying on the multipart-style boundaries. While this would be
   useful, the "multipart" mechanisms are well established, simple to
   implement on both the sending client and receiving server, and as
   efficient as other methods of dealing with multiple combinations of
   binary data.

様々な人々は複合スタイル境界を当てにするよりむしろトップレベルタイプが「集める」新しいパントマイム、例えば混ぜられた骨材/を使用するか、言い表す「パケット」の満足している転送コード化不確定の長さのバイナリ・データを勧めました。 これが役に立つでしょうが、「複合」のメカニズムは、同じくらい確固として、送付クライアントと受信の両方でサーバを実装する同じくらい簡単で、バイナリ・データの複数の組み合わせに対処する他のメソッドと同じくらい効率的です。

   The multipart/form-data encoding has a high overhead and performance
   impact if there are many fields with short values. However, in
   practice, for the forms in use, for example, in HTML, the average
   overhead is not significant.

複合の、または、データを形成しているコード化には、短い値がある多くの分野があれば、高いオーバーヘッドと性能影響力があります。 しかしながら、例えばHTMLで使用中のフォームにおいて、実際には、平均したオーバーヘッドは重要ではありません。

5.3 Remote files with third-party transfer

5.3 第三者転送に伴うリモートファイル

   In some scenarios, the user operating the form software might want to
   specify a URL for remote data rather than a local file. In this case,
   is there a way to allow the browser to send to the client a pointer
   to the external data rather than the entire contents? This capability
   could be implemented, for example, by having the client send to the
   server data of type "message/external-body" with "access-type" set
   to, say, "uri", and the URL of the remote data in the body of the
   message.

いくつかのシナリオでは、フォームソフトウェアを操作しているユーザはローカルファイルよりむしろリモートデータにURLを指定したがっているかもしれません。 この場合、ブラウザが全体のコンテンツよりむしろ外部のデータへの指針をクライアントに送るのを許容する方法がありますか? 例えば、クライアントにメッセージ欄で「アクセス型」による「外部のメッセージ/ボディー」のタイプに関するデータがたとえば、"uriする"であるように設定するサーバ、およびリモートデータのURLに発信させることによって、この能力を実装することができるでしょう。

5.4 Non-ASCII field names

5.4 非ASCIIフィールド名

   Note that MIME headers are generally required to consist only of 7-
   bit data in the US-ASCII character set. Hence field names should be
   encoded according to the method in RFC 2047 if they contain
   characters outside of that set.

一般に、MIMEヘッダーが米国-ASCII文字の組の7ビット・データだけから成らなければならないことに注意してください。 したがって、そのセットの外にキャラクタを含んでいるなら、RFC2047のメソッドによると、フィールド名はコード化されるべきです。

Masinter                    Standards Track                     [Page 4]

RFC 2388                  multipart/form-data                August 1998

複合の、または、データを形成しているMasinter Standards Track[4ページ]RFC2388 1998年8月

5.5 Ordered fields and duplicated field names

5.5は、分野を命令して、フィールド名をコピーしました。

   The relationship of the ordering of fields within a form and the
   ordering of returned values within "multipart/form-data" is not
   defined by this specification, nor is the handling of the case where
   a form has multiple fields with the same name. While HTML-based forms
   may send back results in the order received, and intermediaries
   should not reorder the results, there are some systems which might
   not define a natural order for form fields.

フォームの中の分野の注文と「複合かデータを形成する」中の戻り値の注文の関係はこの仕様で定義されません、そして、ケースがフォームが同じ名前がある複数の分野を持っているところに取り扱いがありません。 HTMLベースのフォームは追加注文ではなく、受注、および仲介者の結果がそうするべきである後部に結果を送るかもしれませんが、フォーム分野のための自然界の秩序を定義しないかもしれないいくつかのシステムがあります。

5.6 Interoperability with web applications

5.6 ウェブアプリケーションがある相互運用性

   Many web applications use the "application/x-url-encoded" method for
   returning data from forms. This format is quite compact, e.g.:

多くのウェブアプリケーションが、フォームからデータを返すのに「x-urlによってアプリケーション/コード化された」メソッドを使用します。この形式は例えばかなりコンパクトです:

   name=Xavier+Xantico&verdict=Yes&colour=Blue&happy=sad&Utf%F6r=Send

名前=ザビエル+Xanticoと議決=はいと= 悲しい、そして、Utf%F6r=が発信するのが青くてうれしい色の=

   however, there is no opportunity to label the enclosed data with
   content type, apply a charset, or use other encoding mechanisms.

しかしながら、content typeで同封のデータをラベルするか、charsetを適用するか、または他のコード化メカニズムを使用する機会が全くありません。

   Many form-interpreting programs (primarly web browsers) now implement
   and generate multipart/form-data, but an existing application might
   need to optionally support both the application/x-url-encoded format
   as well.

多くのフォームを解釈するプログラム(予備選挙ウェブブラウザ)が、現在、複合/がフォームデータであると実装して、生成しますが、既存のアプリケーションは、両方がまた、x-urlによってアプリケーション/コード化された形式であると任意にサポートする必要があるかもしれません。

5.7 Correlating form data with the original form

5.7 原型でフォームデータを関連させること。

   This specification provides no specific mechanism by which
   multipart/form-data can be associated with the form that caused it to
   be transmitted. This separation is intentional; many different forms
   might be used for transmitting the same data. In practice,
   applications may supply a specific form processing resource (in HTML,
   the ACTION attribute in a FORM tag) for each different form.
   Alternatively, data about the form might be encoded in a "hidden
   field" (a field which is part of the form but which has a fixed value
   to be transmitted back to the form-data processor.)

この仕様は複合/フォームデータをそれを伝えたフォームに関連づけることができるどんな特定のメカニズムも提供しません。 この分離は意図的です。 多くの異なったフォームが、同じデータを送るのに使用されるかもしれません。 実際には、アプリケーションはそれぞれの異なったフォームのための特定のフォーム処理リソース(FORMタグのHTMLにおけるACTION属性)を提供するかもしれません。 あるいはまた、フォームに関するデータは「隠された分野」でコード化されるかもしれません。(形式の一部ですが、伝えられるべき一定の価値をフォームデータプロセッサに返してもらう分野。)

6. Security Considerations

6. セキュリティ問題

   The data format described in this document introduces no new security
   considerations outside of those introduced by the protocols that use
   it and of the component elements. It is important when interpreting
   content-disposition to not overwrite files in the recipients address
   space inadvertently.

本書では説明されたデータの形式はそれを使用するプロトコルによって紹介されたものとコンポーネント要素の外でどんな新しいセキュリティ問題も紹介しません。 受取人アドレス空間でうっかり上書きしないためには満足している気質ファイルを解釈するとき、それは重要です。

   User applications that request form information from users must be
   careful not to cause a user to send information to the requestor or a
   third party unwillingly or unwittingly. For example, a form might

ユーザからフォーム情報を要求するユーザアプリケーションは、ユーザが要請者か第三者に情報を不本意か知らず知らず送ることを引き起こさないように慎重でなければなりません。 例えば、フォームはそうするかもしれません。

Masinter                    Standards Track                     [Page 5]

RFC 2388                  multipart/form-data                August 1998

複合の、または、データを形成しているMasinter Standards Track[5ページ]RFC2388 1998年8月

   request 'spam' information to be sent to an unintended third party,
   or private information to be sent to someone that the user might not
   actually intend. While this is primarily an issue for the
   representation and interpretation of forms themselves, rather than
   the data representation of the result of form transmission, the
   transportation of private information must be done in a way that does
   not expose it to unwanted prying.

ユーザが実際に意図しないかもしれないだれかに送られる故意でない第三者、または個人情報に送られるよう'スパム'情報に要求してください。 これが主として形式自体の表現と解釈のための問題である間、フォームトランスミッションの結果のデータ表現よりむしろ、求められていない覗き見にそれを暴露しない方法で個人情報の輸送をしなければなりません。

   With the introduction of form-data that can reasonably send back the
   content of files from user's file space, the possibility that a user
   might be sent an automated script that fills out a form and then
   sends the user's local file to another address arises. Thus,
   additional caution is required when executing automated scripting
   where form-data might include user's files.

ユーザのファイルのスペースからファイルの中身を合理的に返送できるフォームデータの導入で、ユーザが書類に書き込む自動化スクリプトを送るかもしれなくて、次に、ユーザのローカルファイルを別のアドレスに送る可能性は起こります。 フォームデータがユーザのファイルを含むかもしれないところで自動化されたスクリプティングを実行するとき、したがって、追加警告が必要です。

7. Author's Address

7. 作者のアドレス

   Larry Masinter
   Xerox Palo Alto Research Center
   3333 Coyote Hill Road
   Palo Alto, CA 94304

ラリーMasinterゼロックスパロアルト研究センター3333コヨーテヒル・Roadパロアルト、カリフォルニア 94304

   Fax:    +1 650 812 4333
   EMail:   masinter@parc.xerox.com

Fax: +1 4333年の650 812メール: masinter@parc.xerox.com

Masinter                    Standards Track                     [Page 6]

RFC 2388                  multipart/form-data                August 1998

複合の、または、データを形成しているMasinter Standards Track[6ページ]RFC2388 1998年8月

Appendix A. Media type registration for multipart/form-data

付録A.メディアは複合/フォームデータのための登録をタイプします。

   Media Type name:
     multipart

メディアTypeは以下を命名します。 複合

   Media subtype name:
     form-data

メディア「副-タイプ」は以下を命名します。 フォームデータ

   Required parameters:
     none

必要なパラメタ: なし

   Optional parameters:
     none

任意のパラメタ: なし

   Encoding considerations:
     No additional considerations other than as for other multipart
     types.

問題をコード化します: 他の複合タイプ以外の追加問題がありません。

   Security Considerations
     Applications which receive forms and process them must be careful
     not to supply data back to the requesting form processing site that
     was not intended to be sent by the recipient. This is a
     consideration for any application that generates a multipart/form-
     data.

書式を受けて、それらを処理するセキュリティConsiderations Applicationsは、受取人によって送られることを意図しなかったサイトを処理する要求フォームにデータを供給して戻さないように慎重でなければなりません。 これは複合/フォームがデータであると生成するどんなアプリケーションのための考慮です。

     The multipart/form-data type introduces no new security
     considerations for recipients beyond what might occur with any of
     the enclosed parts.

複合の、または、データを形成しているタイプは受取人のために同封の部品のいずれでも起こるかもしれないことを超えてどんな新しいセキュリティ問題も紹介しません。

Masinter                    Standards Track                     [Page 7]

RFC 2388                  multipart/form-data                August 1998

複合の、または、データを形成しているMasinter Standards Track[7ページ]RFC2388 1998年8月

References

参照

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

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

   [RFC 2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
              Part Three: Message Header Extensions for Non-ASCII Text",
              RFC 2047, November 1996.

ムーア、[RFC2047]K.、「パートThreeをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、1996年11月。

   [RFC 2231] Freed, N., and K. Moore, "MIME Parameter Value and Encoded
              Word Extensions: Character Sets, Languages, and
              Continuations", RFC 2231, November 1997.

解放された[RFC2231]、N.、およびK.ムーア、「パラメタ値とコード化されたWord拡大をまねてください」 「文字コード、言語、および続刊」、RFC2231、11月1997日

   [RFC 1806] Troost, R., and S. Dorner, "Communicating Presentation
              Information in Internet Messages: The Content-Disposition
              Header", RFC 1806, June 1995.

[RFC1806] Troost、R.、およびS.デルナー、「中でプレゼンテーション情報を伝えて、インターネットは通信します」。 「満足している気質ヘッダー」、RFC1806、1995年6月。

   [RFC 1867] Nebel, E., and L. Masinter, "Form-based File Upload in
              HTML", RFC 1867, November 1995.

[RFC1867] Nebel、E.、およびL.Masinter、「HTMLにおけるフォームベースのファイルアップロード」、RFC1867、1995年11月。

   [RFC 2183] Troost, R., Dorner, S., and K. Moore, "Communicating
              Presentation Information in Internet Messages: The
              Content-Disposition Header Field", RFC 2183, August 1997.

[RFC2183] Troost、R.、デルナー、S.、およびK.ムーア、「中でプレゼンテーション情報を伝えて、インターネットは通信します」。 「満足している気質ヘッダーフィールド」、RFC2183、1997年8月。

   [RFC 2184] Freed, N., and K. Moore, "MIME Parameter Value and Encoded
              Word Extensions: Character Sets, Languages, and
              Continuations", RFC 2184, August 1997.

解放された[RFC2184]、N.、およびK.ムーア、「パラメタ値とコード化されたWord拡大をまねてください」 「文字コード、言語、および続刊」、RFC2184、8月1997日

   [HTML40]   D. Raggett, A. Le Hors, I. Jacobs. "HTML 4.0
              Specification", World Wide Web Consortium Technical Report
              "REC-html40", December, 1997. <http://www.w3.org/TR/REC-
              html40/>

[HTML40] D.Raggett、A.Le Hors、I.ジェイコブズ。 「HTML4.0仕様」、「REC-html40"、1997年12月」というワールドワイドウェブコンソーシアム技術報告書。 <http://www.w3.org/TR/REC- html40/>。

Masinter                    Standards Track                     [Page 8]

RFC 2388                  multipart/form-data                August 1998

複合の、または、データを形成しているMasinter Standards Track[8ページ]RFC2388 1998年8月

Full Copyright Statement

完全な著作権宣言文

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

Copyright(C)インターネット協会(1998)。 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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Masinter                    Standards Track                     [Page 9]

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