原典 RFC1867
ftp://ds.internic.net/rfc/rfc1867.txt
98.2.14
翻訳開始
98.4.15
翻訳終了
http://www.bekkoame.or.jp/%7Epoetlabo/WWW/rfc1867J.html
Network Working Group
Request For Comments: 1867
Category: Experimental
E. Nebel
L. Masinter
Xerox Corporation
November 1995
この書き付けは、インターネット社会のための実験的な作法を定義するものです。この書き付けは、その種類を問わず、インターネット標準を決めるものではありません。改良のための議論や提案が求められます。この書き付けの配布は無制限です。
This memo defines an Experimental Protocol for the Internet
community. This memo does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
現在、 HTML 書式によって、書式を読んでいる利用者からの情報をその制作者において求めることが可能になっています。
この書式は、幅広い種類の利用者からの入力が必要なアプリケーションに役立つことがわかってきました。
しかしながら HTML 書式は、利用者に対してデータのファイルを送るように求める方法を備えていないので、この能力は限られたものになっています。
利用者からのファイルを取得する必要があるサービスプロバイダは、特注の利用者アプリケーションを実行しなければなりませんでした。
（これらの特注ブラウザの見本が、 www-talk メーリング・リストに現われたことがあります）
ファイルの上納は多くのアプリケーションに利益を与える機能なので、ここでは情報提供者が一定の形式でファイル上納要請を表せるようにするための HTML の拡張と、 MIME 互換性のあるファイル上納応答表現を提案します。
これには、新しいサーバが現行の HTML 利用者エージェントと互いに影響し合うようにする逆行適合性戦略の記述も含まれます。
Currently, HTML forms allow the producer of the form to request
information from the user reading the form. These forms have proven
useful in a wide variety of applications in which input from the user
is necessary. However, this capability is limited because HTML forms
don't provide a way to ask the user to submit files of data. Service
providers who need to get files from the user have had to implement
custom user applications. (Examples of these custom browsers have
appeared on the www-talk mailing list.) Since file-upload is a
feature that will benefit many applications, this proposes an
extension to HTML to allow information providers to express file
upload requests uniformly, and a MIME compatible representation for
file upload responses. This also includes a description of a
backward compatibility strategy that allows new servers to interact
with the current HTML user agents.
この提案は、これを組み入れる HTML のバージョンとは無関係です。
The proposal is independent of which version of HTML it becomes a
part.
現行のHTML仕様書は、INPUT要素のTYPE属性が取り得る値として、CHECKBOX, HIDDEN, IMAGE,PASSWORD, RADIO, RESET, SUBMIT, TEXTの8つを定義しています。
The current HTML specification defines eight possible values for the
attribute TYPE of an INPUT element: CHECKBOX, HIDDEN, IMAGE,
PASSWORD, RADIO, RESET, SUBMIT, TEXT.
さらに、POSTメソッドを使うFORM要素の既定のENCTYPE属性を、既定値"application/x-www-form-urlencoded"を持つものとして定義しています。
In addition, it defines the default ENCTYPE attribute of the FORM
element using the POST METHOD to have the default value
"application/x-www-form-urlencoded".
この提案では、HTMLを2箇所変更します。
This proposal makes two changes to HTML:
さらに、ここでは新しいMIMEメディアであるmultipart/form-dataを定義し、
ENCTYPE="multipart/form-data"あるいは<INPUT type="file">、またはその両方のタグを持つ書式を解釈するときのHTML利用者手先の動作を指定します。
In addition, it defines a new MIME media type, multipart/form-data,
and specifies the behavior of HTML user agents when interpreting a
form with ENCTYPE="multipart/form-data" and/or <INPUT type="file">
tags.
以上の変更は別々に検討してかまいませんが、合理的なファイル上納には全て必要です。
These changes might be considered independently, but are all
necessary for reasonable file upload.
利用者から1個以上のファイルを入手したいHTML書式の作者は、例を示すと、以下のように書けるようになります。
The author of an HTML form who wants to request one or more files
from a user would write (for example):
<FORM ENCTYPE="multipart/form-data" ACTION="_URL_" METHOD=POST>
File to process: <INPUT NAME="userfile1" TYPE="file">
<INPUT TYPE="submit" VALUE="Send File">
</FORM>
HTML DTD への変更点としては、"InputType"実体に品目を１つ加えることになります。
さらに、 INPUT タグに ACCEPT 属性を持たせることを提案します。 これは、コンマで区切られたメディアタイプの一覧となります。
The change to the HTML DTD is to add one item to the entity
"InputType". In addition, it is proposed that the INPUT tag have an
ACCEPT attribute, which is a list of comma-separated media types.
... (other elements) ...
<!ENTITY % InputType "(TEXT | PASSWORD | CHECKBOX |
RADIO | SUBMIT | RESET |
IMAGE | HIDDEN | FILE )">
<!ELEMENT INPUT - 0 EMPTY>
<!ATTLIST INPUT
TYPE %InputType TEXT
NAME CDATA #IMPLIED -- required for all but submit and reset
VALUE CDATA #IMPLIED
SRC %URI #IMPLIED -- for image inputs --
CHECKED (CHECKED) #IMPLIED
SIZE CDATA #IMPLIED --like NUMBERS,
but delimited with comma, not space
MAXLENGTH NUMBER #IMPLIED
ALIGN (top|middle|bottom) #IMPLIED
ACCEPT CDATA #IMPLIED --list of content types
>
... (other elements) ...HTML を解釈する利用者エージェントは、それぞれの動作条件に最もふさわしいメカニズムを選ぶのに広範な余地を残すため、このセクションでは利用者エージェントの一種である WWW 書見器が実行できるファイル上納の仕方について提案します。
While user agents that interpret HTML have wide leeway to choose the
most appropriate mechanism for their context, this section suggests
how one class of user agent, WWW browsers, might implement file
upload.
種別が FILE になっている INPUT タグに出くわしたとき、書見器は（以前に選択された）ファイル名の表示と『 Browse 』ボタンか選択方法を示すことができます。
『 Browse 』ボタンを選択すると、書見器は、そのプラットホームにふさわしいファイル選択モードに入るようになります。
たとえばウィンドウ形式の書見器では、ファイル選択窓が飛び出すようにしてかまいません。
利用者はそのようなファイル選択ダイアログで、現行のファイル選択を入れ替えたり、新しいファイル選択を加えたりできるようになるでしょう。
書見器設計者は、ファイル名の一覧が手書きされるようにしてかまいません。
When a INPUT tag of type FILE is encountered, the browser might show
a display of (previously selected) file names, and a "Browse" button
or selection method. Selecting the "Browse" button would cause the
browser to enter into a file selection mode appropriate for the
platform. Window-based browsers might pop up a file selection window,
for example. In such a file selection dialog, the user would have the
option of replacing a current selection, adding a new file selection,
etc. Browser implementors might choose let the list of file names be
manually edited.
ACCEPT 属性がある場合は、書見器は、プラットホームに対応している適切なファイル拡張子を組み合わせるようにしたファイルパターンを強いて構いません。
If an ACCEPT attribute is present, the browser might constrain the
file patterns prompted for to match those with the corresponding
appropriate file extensions for the platform.
利用者が書式に記入して SUBMIT 要素を選択すると、書見器は、書式データと選択されたファイルの内容を送ることになります。
符号化方式種別 application/x-www-form-urlencoded は、非ASCII文字を含んでいる大量のバイナリデータあるいは文章を送るのには非効率的です。
かくして、受け手側から送り手側へ、記入された書式に関する値を効率的に送る方法として、新しいメディアタイプであるmultipart/form-data が提案される次第です。
When the user completes the form, and selects the SUBMIT element, the
browser should send the form data and the content of the selected
files. The encoding type application/x-www-form-urlencoded is
inefficient for sending large quantities of binary data or text
containing non-ASCII characters. Thus, a new media type,
multipart/form-data, is proposed as a way of efficiently sending the
values associated with a filled-out form from client to server.
multipart/form-data の定義は、第7項に入っています。
境界線は、データのいずれにも見出されないようなものが選ばれます。（この選択は、ときどきprobabilisticlyとなる）
書式の各々のフィールドは、多元ストリームの元素となり、それが書式に出てくる順序のとおりに送られます。
各元素には、元の HTML 書式にある INPUT の名前が結合しています。
各元素は、（情報をファイル拡張子かOSの種類の情報から推察するなどして）そのメディアタイプがわかっている場合には適切なcontent-typeとして、或いはapplication/octet-stream として分類されるべきです。
The definition of multipart/form-data is included in section 7. A
boundary is selected that does not occur in any of the data. (This
selection is sometimes done probabilisticly.) Each field of the form
is sent, in the order in which it occurs in the form, as a part of
the multipart stream. Each part identifies the INPUT name within the
original HTML 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.
複合ファイルが選択された場合は、multipart/mixed 形式を用いて一斉に転送されるべきです。
If multiple files are selected, they should be transferred together
using the multipart/mixed format.
HTTP 作法が任意のバイナリデータを配送することができるのに、メール配送（ACTIONが"mailto:" URLである場合など）では7ビット符号化方式が所定のものとされています。
元素に与えられた値は、符号化される必要があるかもしれません。そしてその値が所定の符号化方式に従っていないならば、"content-transfer-encoding"ヘッダが与えられる必要があるかもしれません。
詳細については、RFC 1521の第5項を見てください。
While the HTTP protocol can transport arbitrary BINARY data, the
default for mail transport (e.g., if the ACTION is a "mailto:" URL)
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 1521 for more details.]
'content-disposition: form-data'ヘッダか、複合ファイルの場合は副元素のヘッダ'content-disposition: file'に'filename'変数が入っているもののどちらにおいても、さらに元のローカルなファイル名が提供されるようにしてかまいません。
受け手側応用ソフトウェアは、ファイル名を提供するために全力を尽くすべきです。受け手側のオペレーティング・システム上のファイル名がUS-ASCIIで表わせない場合には、ファイル名は近似するか、 RFC 1522 の方法を用いて符号化するようにしてかまいません。
これは、たとえばTeXファイルとその.sty補助スタイル記述などのように、上納されたファイルにお互いへの参照を入れられるなど、さまざまなケースにおいて便利です。
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 client application should make best
effort to supply the file name; if the file name of the client's
operating system is not in US-ASCII, the file name might be
approximated or encoded using the method of RFC 1522. This is a
convenience for those cases where, for example, the uploaded files
might contain references to each other, e.g., a TeX file and its .sty
auxiliary style description.
送り手側で、 ACTION が、CGI により動作する書式を実行する HTTP URL を指示するようにしてかまいません。
そのようなケースでは、CGI プログラムは、content-typeが multipart/form-data であることに注目して、種々のフィールドを解析する（妥当性のチェック、次の処理過程のためにローカルファイルへファイルデータを書き出すなど）ことになります。
On the server end, the ACTION might point to a HTTP URL that
implements the forms action via CGI. In such a case, the CGI program
would note that the content-type is multipart/form-data, parse the
various fields (checking for validity, writing the file data to local
files for subsequent processing, etc.).
VALUE 属性を、既定のファイル名のために<INPUT TYPE=file>タグと共に使用できることが望まれます。
この使用は、おそらくプラットホームに左右されるでしょう。
これはしかしながら、同じファイル名が何度もくりかえして利用者に与えられるようにすることを避けるなど、複数の処理の流れにおいて有用になるかもしれません。
The VALUE attribute might be used with <INPUT TYPE=file> tags for a
default file name. This use is probably platform dependent. It might
be useful, however, in sequences of more than one transaction, e.g.,
to avoid having the user prompted for the same file name over and
over again.
SIZE 属性はSIZE=width,height を用いて指定されます。ここでwidthは所定のファイル名の幅であり、これに対してheightは選択されたファイルのリストを示すために予想されるサイズです。
例えば、これは、複数のファイルを入手しようとしている、また、ブラウザで 多行ファイル入力欄を（できれば、その横に"browse"ボタンを添えて）示したいと思っている書式の設計者に役立ちます。
高さが指定されていないとき（書式設計者がファイルを１つだけ求めるとき）は１行の書き込み欄を示し、高さが１以上のとき（書式設計者が複合ファイルを求めるとき）スクロールバーのある多行書き込み枠を示すように使えます。
The SIZE attribute might be specified using SIZE=width,height, where
width is some default for file name width, while height is the
expected size showing the list of selected files. For example, this
would be useful for forms designers who expect to get several files
and who would like to show a multiline file input field in the
browser (with a "browse" button beside it, hopefully). It would be
useful to show a one line text field when no height is specified
(when the forms designer expects one file, only) and to show a
multiline text area with scrollbars when the height is greater than 1
(when the forms designer expects multiple files).
現行の WWW 書式機構の補完を全面的に採用する必要はありませんが、これはまた、移植戦略を計画するのにも役立ちます。まだ古い書見器を利用している人も、ヘルパーアプリケーションを用いて、ファイル上納ダイアログに参加することが可能なのです。
ほとんどの現行のweb書見器は、<INPUT TYPE=FILE>が与えられると、 それを<INPUT TYPE=TEXT>と同様に扱って、利用者にテキスト・ボックスを与えます。
利用者は、このテキスト・ボックスにファイル名を打ち込むことができます。
なお、現行の書見器は<FORM>要素の ENCTYPE 変数を無視し、常に application/x-www-form-urlencoded としてのデータを送るもののようです。
While not necessary for successful adoption of an enhancement to the
current WWW form mechanism, it is useful to also plan for a migration
strategy: users with older browsers can still participate in file
upload dialogs, using a helper application. Most current web browers,
when given <INPUT TYPE=FILE>, will treat it as <INPUT TYPE=TEXT> and
give the user a text box. The user can type in a file name into this
text box. In addition, current browsers seem to ignore the ENCTYPE
parameter in the <FORM> element, and always transmit the data as
application/x-www-form-urlencoded.
従ってサーバ CGI は、返された書式データには内容-タイプ multipart/form-data の代わりにapplication/x-www-form- urlencodedがあることに注目し、利用者がファイル上納を実装していない書見器を用いていることを判別する方法で書くことができます。
Thus, the server CGI might be written in a way that would note that
the form data returned had content-type application/x-www-form-
urlencoded instead of multipart/form-data, and know that the user was
using a browser that didn't implement file upload.
この場合、サーバ上の CGI は、"text/html"応答をもって応じる代わりに、ヘルパーアプリケーションが代わって処理するかもしれないデータストリームを送り返すことができます。これは以下に挙げるものを含むtype "application/x-please-send-files"のデータストリームとなります。
In this case, rather than replying with a "text/html" response, the
CGI on the server could instead send back a data stream that a helper
application might process instead; this would be a data stream of
type "application/x-please-send-files", which contains:
この場合書見器は、application/x-please-send-files を処理するヘルパーアプリケーションを立ち上げるように設定されている必要があります。
In this case, the browser needs to be configured to process
application/x-please-send-files to launch a helper application.
ヘルパーは書式データを読み取り、データ内容を入れ替える必要がある「ローカルなファイル名」がどのフィールドに含まれているかに注目し、利用できるファイルの一覧を利用者が変更あるいは追加できるようにし、その上でデータとファイル内容をサーバに送り直すために multipart/form-data へ組み替えるようにできます。
The helper would read the form data, note which fields contained
'local file names' that needed to be replaced with their data
content, might itself prompt the user for changing or adding to the
list of files available, and then repackage the data & file contents
in multipart/form-data for retransmission back to the server.
ヘルパーは、送られた URL が元の ACTION URL に相当するという見方のもとに、「新しい」書見器が実際に当初送るべきであった種類のデータを生成します。
これの長所は、書見器を取り扱う機構をサーバに実装する際に、旧式のものにも新しいものにも同一のCGI が使えることです。
The helper would generate the kind of data that a 'new' browser
should actually have sent in the first place, with the intention that
the URL to which it is sent corresponds to the original ACTION URL.
The point of this is that the server can use the *same* CGI to
implement the mechanism for dealing with both old and new browsers.
ヘルパーが書式データを表示する必要はありませんが、実際に利用者が要請されたファイルを送ることが適切であるかどうかについて助言されることを保証するべきです（これは利用者にそのつもりがなかったファイルを求める悪意のサーバにまつわる安全問題を避けるためです）。
必要とされたファイルの転送状態が表示できると便利でしょう。
The helper need not display the form data, but *should* ensure that
the user actually be prompted about the suitability of sending the
files requested (this is to avoid a security problem with malicious
servers that ask for files that weren't actually promised by the
user.) It would be useful if the status of the transfer of the files
involved could be displayed.
このスキームは、ファイル圧縮の可能性については言及しません。
考えてみるだけでも、ファイルが圧縮されているかどうかを書見器に自動判定させるには、ファイル圧縮の最適化問題は複雑すぎると思われます。
高速モデムなど、多くのリンク-階層輸送メカニズムはリンク上でデータ圧縮を行ないます。そしてこの階層で圧縮のために最適化することは、適切でないかもしれません。
強い要望があれば、ファイルデータ圧縮の内容-転送-符号化方式を書見器が選択的に取り出し、処理する前のデータをサーバが解凍することは可能かもしれません。しかしながらこれは提案からは省かれています。
This scheme doesn't address the possible compression of files. After
some consideration, it seemed that the optimization issues of file
compression were too complex to try to automatically have browsers
decide that files should be compressed. Many link-layer transport
mechanisms (e.g., high-speed modems) perform data compression over
the link, and optimizing for compression at this layer might not be
appropriate. It might be possible for browsers to optionally produce
a content-transfer-encoding of x-compress for file data, and for
servers to decompress the data before processing, if desired; this
was left out of the proposal, however.
同様に提案には、データ暗号化機構が入っていません。これはデータの安全な伝達に代わるべき保安 HTTP かメールによるあらゆる他の機構によって扱われるべきです。
Similarly, the proposal does not contain a mechanism for encryption
of the data; this should be handled by whatever other mechanisms are
in place for secure transmission of data, whether via secure HTTP or
mail.
状況によっては、実際にデータを受信する準備に先だって、書式データの種々の要素（利用者の名前やアカウントなど）をサーバに認証してもらうのが賢明かもしれません。
しかしながら考えてみますと、これを行なおうとするサーバへの要求として最も良いように思われるのは、これが一連の書式として実行されるようになることです。これは、認証済みのデータ要素のいくつかが隠しフィールドとしてクライアントに送り返されるようにしてもいいし、或いは最初に認証を必要とする要素が見出されるように、書式を編集することによってもいいでしょう。
簡素な作りですむ簡素な入力があるような場合はさほどでもありませんが、これは複雑なアプリケーションを構築しようとするサーバのみに処理の状態を維持する責任を課すことになります。
In some situations, it might be advisable to have the server validate
various elements of the form data (user name, account, etc.) before
actually preparing to receive the data. However, after some
consideration, it seemed best to require that servers that wish to do
this should implement this as a series of forms, where some of the
data elements that were previously validated might be sent back to
the client as 'hidden' fields, or by arranging the form so that the
elements that need validation occur first. This puts the onus of
maintaining the state of a transaction only on those servers that
wish to build a complex application, while allowing those cases that
have simple input needs to be built simply.
HTTP 作法は、転送物全体のcontent-lengthを要求することができます。
そこまでいかないにしても HTTP クライアントには、もし提出されたファイルデータが合理的に処理されるには大きすぎるならば、稼働中のサーバがそれとわかるように入力ファイル全体のcontent-lengthを提供し、エラーコードを返すだけで、すべての入ってくるデータの処理を待たずに接続を切るようにすることが奨励されます。
CGI の現行の実装の中には、全てのPOST処理でcontent-lengthを要求するものもあります。
The HTTP protocol may require a content-length for the overall
transmission. Even if it were not to do so, HTTP clients are
encouraged to supply content-length for overall file input so that a
busy server could detect if the proposed file data is too large to be
processed reasonably and just return an error code and close the
connection without waiting to process all of the incoming data. Some
current implementations of CGI require a content-length in all POST
transactions.
INPUT タグに属性 MAXLENGTH が入っているならば、利用者エージェントはその値を、サーバが受けとるはずの転送ファイルの最大限のContent-Lengthを（バイトで）表現したものとみなすべきです。このようにしてサーバは、上納を開始する前に、どのくらいの空間をファイル上納のために利用できるかをクライアントに示唆することができます。しかしながら特に注意すべきこととして、これは示唆するにとどまります。サーバの実際の必要条件は、書式制作からファイル送信への間に変化しているかもしれません。
If the INPUT tag includes the attribute MAXLENGTH, the user agent
should consider its value to represent the maximum Content-Length (in
bytes) which the server will accept for transferred files. In this
way, servers can hint to the client how much space they have
available for a file upload, before that upload takes place. It is
important to note, however, that this is only a hint, and the actual
requirements of the server may change between form creation and file
submission.
いずれにせよ、HTTPサーバは、受け取るファイルが大きすぎるときには、処理の途中でファイル上納を中断して構いません。
In any case, a HTTP server may abort a file upload in the middle of
the transaction if the file being received is too large.
多くの人々が multipart-style 境界に頼るよりも、 aggregate/mixed などの新しい mime トップ-レベルタイプ"aggregate"か、バイナリデータのindeterminate-length を表す『パケット』の内容-転送-符号化方式を用いることを提案しました。
我々はこれに反対していないので、"aggregate"を受け入れるための追加設計と標準化のための努力が求められます。
他方では'multipart'メカニズムはうまく設定されており、送っているクライアントと受けるサーバのどちらとも実装が簡単である上に、バイナリデータの多元結合を取り扱う他の方法と同じくらい効果的です。
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 we are not opposed
to doing so, this would require additional design and standardization
work to get acceptance of "aggregate". On the other hand, 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.
書式要素の異なるタイプを与えることよりも、この機能によって起きる'INPUT'の過負荷対策について思い悩む人は少なくありません。
他の考察にあって、<INPUT>を用いる際に許される移植戦略は重要です。
それに加えて<INPUT>フィールドは、データ入力のほとんどの種類を含むために、すでに負担がかかりすぎています。どちらかというと、<INPUT>タグの種類を数多く造り出すよりも、<INPUT>を強化するのが最も合理的なように思われます。
INPUTの'type'は、返されたcontent-typeではなく、相互作用スタイルを利用者に結び付けるような'widget-type'です。
ここにある説明は、<INPUT TYPE=FILE>が文章書見器や音声マークアップで動作できるように注意して書いてあります。
Various people have wondered about the advisability of overloading
'INPUT' for this function, rather than merely providing a different
type of FORM element. Among other considerations, the migration
strategy which is allowed when using <INPUT> is important. In
addition, the <INPUT> field *is* already overloaded to contain most
kinds of data input; rather than creating multiple kinds of <INPUT>
tags, it seems most reasonable to enhance <INPUT>. The 'type' of
INPUT is not the content-type of what is returned, but rather the
'widget-type'; i.e., it identifies the interaction style with the
user. The description here is carefully written to allow <INPUT
TYPE=FILE> to work for text browsers or audio-markup.
HTML の多くの入力欄は、打ち込み可能です。
書式データのサーバへの返送のしかたについては従来、曖昧なところがありました。
<INPUT>フィールドの内容種別がはっきりと text/plain とわかるようにするには、サーバに返送する前に、クライアントが適切に CRLF をもってデータを符号化するべきです。
Many input fields in HTML are to be typed in. There has been some
ambiguity as to how form data should be transmitted back to servers.
Making the content-type of <INPUT> fields be text/plain clearly
disambiguates that the client should properly encode the data before
sending it back to the server with CRLFs.
この提案とは別に、書式のACTIONを"mailto:" URLとしていいようにすると、 HTML に対応している利用者エージェントに非常に便利です。
この提案によってもよらなくても、これは良い考えのように思われます。
メールによって受信される、おそらく既定値がメッセージの"reply-to:"であろう HTML 書式の ACTION についても同様です。
この2つの提案は、 HTML 書式が HTTP サーバによって送付され、メールによって返送されるようにするか、その代わりに HTML 書式が HTML対応メーラーによって記入され、メールで送られ、そして結果が返送されるようにするものです。
Independent of this proposal, it would be very useful for HTML
interpreting user agents to allow a ACTION in a form to be a
"mailto:" URL. This seems like a good idea, with or without this
proposal. Similarly, the ACTION for a HTML form which is received via
mail should probably default to the "reply-to:" of the message.
These two proposals would allow HTML forms to be served via HTTP
servers but sent back via mail, or, alternatively, allow HTML forms
to be sent by mail, filled out by HTML-aware mail recipients, and the
results mailed back.
筋書きによっては、受け手側ソフトウェアを操作する利用者は、手元にあるファイルでなく離れた場所にあるデータのURL指定を望むかもしれません。このような場合に、その外部データそのものでなくポインタを、書見機が受け手側へ送るようにできる方法があるでしょうか？この能力は、例えば受け手側に、"message/external-body" タイプのデータに "access-type" をセットして、それに"uri"とメッセージ本体にある外部データのURLを、送り手側へ送らせるような実装ができるでしょう。
In some scenarios, the user operating the client 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.
書式が<INPUT TYPE=file>要素を含むが<FORM>の範囲内にENCTYPEを含まない場合には、
その動作は指定されません。
サーバが予期しないような大量のデータのURN符号化を試すのは、あまりよろしくないでしょう。
If a form contains <INPUT TYPE=file> elements but does not contain an
ENCTYPE in the enclosing <FORM>, the behavior is not specified. It
is probably inappropriate to attempt to URN-encode large quantities
of data to servers that don't expect it.
MIME転送全てに共通することですが、multipart/form-dataでのデータ送出では、行の区切りとしてCRLFが使われます。
As with all MIME transmissions, CRLF is used as the separator for
lines in a POST of the data in multipart/form-data.
MIMESGML グループでは、 multipart/related と呼ばれる新種が提案されています。これは multipart/form-data と同じような機能を持つものですが、その書式-データの使用と応用は、その書式-データが別に描き分けられているくらい違います。
The MIMESGML group is proposing a new type called multipart/related.
While it contains similar features to multipart/form-data, the use
and application of form-data is different enough that form-data is
being described separately.
いつの日か、 multipart/related な本文（ファイルを含む）での HTML 書式の結果の符号化が可能になるかも知れません。ただし、これはこの提案とは整合しません。
It might be possible at some point to encode the result of HTML forms
(including files) in a multipart/related body part; this is not
incompatible with this proposal.
mime ヘッダは普通、US-ASCII文字セットによる７ビットデータのみで構成する必要があることに注意してください。
従って、そのセットにない文字がフィールド名に含まれるときには、そのフィールド名は RFC 1522 の規定によって符号化されるべきです。
HTML 2.0 での所定の文字セットは ISO-8859-1 ですが、フィールド名の非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 prescriptions of RFC 1522 if they contain
characters outside of that set. In HTML 2.0, the default character
set is ISO-8859-1, but non-ASCII characters in field names should be
encoded.
サーバが次のHTMLを出したとしましょう。
Suppose the server supplies the following HTML:
<FORM ACTION="http://server.dom/cgi/handle"
ENCTYPE="multipart/form-data"
METHOD=POST>
What is your name? <INPUT TYPE=TEXT NAME=submitter>
What files are you sending? <INPUT TYPE=FILE NAME=pics>
</FORM>
そして利用者が氏名欄に"Joe Blow"と打ち込み、「どのファイルを送りますか？」への答えとしてテキストファイル"file1.txt"を選ぶと、
and the user types "Joe Blow" in the name field, and selects a text
file "file1.txt" for the answer to 'What files are you sending?'
クライアントは以下のデータを送り返すことになるでしょう。
The client might send back the following data:
Content-type: multipart/form-data, boundary=AaB03x
--AaB03x
content-disposition: form-data; name="field1"
Joe Blow
--AaB03x
content-disposition: form-data; name="pics"; filename="file1.txt"
Content-Type: text/plain
... contents of file1.txt ...
--AaB03x--
同様に利用者が「どのファイルを送りますか？」への答えとして画像ファイル"file2.gif"を選ぶと、クライアントは以下のデータを送り返すことになるでしょう。
If the user also indicated an image file "file2.gif" for the answer
to 'What files are you sending?', the client might client might send
back the following data:
Content-type: multipart/form-data, boundary=AaB03x
--AaB03x
content-disposition: form-data; name="field1"
Joe Blow
--AaB03x
content-disposition: form-data; name="pics"
Content-type: multipart/mixed, boundary=BbC04y
--BbC04y
Content-disposition: attachment; filename="file1.txt"
Content-Type: text/plain
... contents of file1.txt ...
--BbC04y
Content-disposition: attachment; filename="file2.gif"
Content-type: image/gif
Content-Transfer-Encoding: binary
...contents of file2.gif...
--BbC04y--
--AaB03x--
メディア-タイプ multipart/form-data は、 RFC 1521 で概説された全ての multipart mime データストリームとしての規則に基づいています。
これは記入された書式からデータを返すのに使うために用意されているものです。
書式には（ HTML では他のアプリケーションが書式を用いてもいいのですが）、書式に記入する利用者に提供されるフィールド一式があります。
各々のフィールドには名前があります。
与えられた書式の範囲内では、名前は重複しません。
The media-type multipart/form-data follows the rules of all multipart
MIME data streams as outlined in RFC 1521. It is intended for use in
returning the data that comes about from filling out a form. In a
form (in HTML, although other applications may also use 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.
multipart/form-data は部品一式を備えます。
各々の部品は、値が"form-data"である内容-性質ヘッダと、書式の範囲内でフィールド名を指定する名前属性を持つことになっています。たとえば'content-disposition: form-data; name="xxxxx"'では、xxxxxがそのフィールドに対応しているフィールド名です。
非ASCII 文字セットによる元のフィールド名は、RFC 1522 で概説された方法を用いて符号化してかまいません。
multipart/form-data contains a series of parts. Each part is expected
to contain a content-disposition header where the value is "form-
data" and a name attribute specifies the field name within the form,
e.g., 'content-disposition: form-data; name="xxxxx"', where xxxxx is
the field name corresponding to that field. Field names originally in
non-ASCII character sets may be encoded using the method outlined in
RFC 1522.
multipart mimeタイプ全てに共通することですが、各々の部品は選択可能な内容-タイプを持ち、その既定値は text/plain になっています。
ファイルの内容が書式に記入することによって返される場合には、ファイル入力は、application/octet-stream として、もしわかっているならば適切なメディアタイプとして認識されます。
単一の書式実行の結果として複合的なファイルが返されるのならば、それは multipart/form-data に埋め込まれた multipart/mixed として返すことが可能です。
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
application/octet-stream or the appropriate media type, if known. If
multiple files are to be returned as the result of a single form
entry, they can be returned as multipart/mixed embedded within the
multipart/form-data.
各々の部品は符号化してかまいませんし、部品の値が所定の符号化方式に基いていないときは"content-transfer-encoding"ヘッダを与えてかまいません。
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.
ファイル入力では、ファイル名も判別されるでしょう。ファイル名は"content-disposition"ヘッダの'filename'変数を用いて述べることができます。これは不可欠ではありませんが、どのような場合にも元のファイル名がわかるようにするため、強く奨励されます。これは多くのアプリケーションにおいて便利であり、必要ともなります。
File inputs may also identify the file name. The file name may be
described using the 'filename' parameter of the "content-disposition"
header. This is not required, but is strongly recommended in any case
where the original filename is known. This is useful or necessary in
many applications.
重要なこととして、ファイル送出について利用者の明白な意思表示がないものを、利用者エージェントが送ってはなりません。
従って HTML を解釈しているエージェントは、 <INPUT TYPE=file VALUE="yyyy">をもって示されるどんな所定のファイル名も確かめることになっています。
いかなるものであれ、隠しフィールドにファイルを指定できるようなことがあってはなりません。
It is important that a user agent not send any file that the user has
not explicitly asked to be sent. Thus, HTML interpreting agents are
expected to confirm any default file names that might be suggested
with <INPUT TYPE=file VALUE="yyyy">. Never have any hidden fields be
able to specify any file.
この提案には、データの暗号化のための機構は入っていません。これはデータの安全な転送のためのあらゆる他の機構、保安 HTTP や（ RFC 1848 で描写された）MOSSによって与えられる防犯システムにおいて扱われるべきです。
This proposal does not contain a mechanism for encryption of the
data; this should be handled by whatever other mechanisms are in
place for secure transmission of data, whether via secure HTTP, or by
security provided by MOSS (described in RFC 1848).
ファイルが一旦アップロードされたら、適切にファイルを処理し保管することは受け入れ先の仕事になります。
Once the file is uploaded, it is up to the receiver to process and
store the file appropriately.
示唆された実装はクライアントに、サーバへ送ることができるファイルの数と種類においてきわめて大幅な柔軟性を与えます。また、サーバに、ファイル受け入れ決定に関する制御を与えます。そしてまた、これはサーバに、入力タイプ『ファイル』を扱わない書見器と互いに影響し合う機会を与えます。
The suggested implementation gives the client a lot of flexibility in
the number and types of files it can send to the server, it gives the
server control of the decision to accept the files, and it gives
servers a chance to interact with browsers which do not support INPUT
TYPE "file".
HTML DTD への変更は非常に単純ですが、非常に強力です。
これをもってすれば、World-Wide Webにおいて実現されるサービスを、ファイル送信設備の不足に足を取られている現状より、はるかに多様なものにすることができるでしょう。
The change to the HTML DTD is very simple, but very powerful. It
enables a much greater variety of services to be implemented via the
World-Wide Web than is currently possible due to the lack of a file
submission facility. This would be an extremely valuable addition to
the capabilities of the World-Wide Web.
The multipart/form-data type introduces no new security considerations beyond what might occur with any of the enclosed parts.