LISTSERV mailing list manager LISTSERV 15.5

Help for MHTML Archives

MHTML Archives

MHTML Archives


Next Message | Previous Message
Next in Topic | Previous in Topic
Next by Same Author | Previous by Same Author
Chronologically | Most Recent First
Proportional Font | Monospaced Font


Join or Leave MHTML
Reply | Post New Message
Search Archives


Re: draft-masinter-form-data-04.txt


Larry Masinter <[log in to unmask]>


IETF working group on HTML in e-mail <[log in to unmask]>


Sat, 27 Jun 1998 18:49:09 PDT





text/plain (1 lines)

> Your draft mentions explicitly that an object with
> Content-Disposition: form-data can have the following
> Content-Types:
> application/octet-stream
> multipart/mixed
> text/plain and other subtypes to text/
> message/external-body
> It is not quite clear whether any other content-types can be included.

Wow, you really like to have things spelled out. It says
"as with all multipart types". Does it need to say that there
are no restrictions?

> Question 1: Can multipart/form-data be recursively embedded
> inside multipart/form-data?

This is not disallowed, but I imagine it might be rare. If I had
received a form result earlier, saved it to disk, and then later
sent it in as a file as part of another form query, this could happen.

> Question 2: Can application/x-url-encoded be embedded
> inside application/form-data?

Same answer. Rare.

> Question 3: Can objects of Content-Type: Message/rfc822 or
> Content-Type: Message/http be embedded inside application/form-data?

Same answer, but rare. If I dragged a message attachment from
a mail message into a 'file upload' box in a form, this might

> If yes, perhaps one should add
> If a complete e-mail message is to be returned, the
> "Content-Type: Message/rfc822" can be embedded within
> multipart/form-data.

This makes no sense to me. What do you mean "a complete e-mail message"?
Forms rarely ask for 'a complete email message', anyway.

> or
> If a complete message is to be returned, the
> "Content-Type: Message" can be embedded within
> multipart/form-data.

"message" isn't a valid media type, so I wouldn't recommend that.

> Your draft says:
> 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".
> Maybe one should here add:
> If a HTML document including inline objects like images or
> applets is to be returned as the result of a single form
> entry, they should be represented as a "multipart/related"
> part embedded within the "multipart/form-data". Also other
> submodes to multipart may be embedded within the "multipart/
> form-data".

Well, I'm wary of suggesting this; I'd rather avoid too much advice about
how to use "multipart/form-data" except to say what it means if you DO
use it under various circumstances.

> If this is added, references should maybe be added to RFC 2110 or
> to RFC 2110, 2111 and 2112.

I think I would rather avoid making references to all of the things
that _could_ be sent. It just defines a method of sending things.


Back to: Top of Message | Previous Page | Main MHTML Page



CataList Email List Search Powered by the LISTSERV Email List Manager