MIME Transfer Format (was Re: Protocol Benchmarking...)
mcrae@ora.com (Christopher McRae)
Message-id: <199402030142.AA04574@rock.west.ora.com>
From: mcrae@ora.com (Christopher McRae)
Organization: O'Reilly & Associates
Email: mcrae@ora.com
Phone: 415/242-9623
To: vinay@eit.COM (Vinay Kumar)
Cc: www-talk@www0.cern.ch
In-reply-to: Your message of Wed, 02 Feb 94 14:46:07 -0800
<9402022246.AA23878@eit.COM>
Subject: MIME Transfer Format (was Re: Protocol Benchmarking...)
Date: Wed, 02 Feb 94 17:42:25 -0800
Sender: mcrae@ora.com
Content-Length: 11174
Vinay Kumar writes:
> If i understand this correctly, then another possible solution could
> lie in upgrading the current Browsers/Servers to handle "MIME multipart"
> messages within the same GET request. You could now easily transport
> multiple files with one request. Each part of the "mutipart" msg could
> easily be a "Content-type: text/html", "Content-type: image/gif",
> "Content-type: audio/basic", etc....
This is the right way to do it, I believe. We've kicked this idea around
before (see background messages included below), and it's clear that using
multipart messages is a big win in other ways, too. For instance, one could
use multipart messages to deliver pages containing sections which would be
displayed only if certain conditions were met. The rules specifying how and
when the various sections should be expanded/collapsed would be delivered
along with the other parts, perhaps as the first part of the multipart. Note
that this technique is also useful for delivering encrypted information, and
for including the DTD along with a document instance (when we abandon HTML for
arbitrary DTD's :-)
In fact, I have been thinking about how one would go about defining standard
ways of putting together such multipart packages. To use the techniques
mentioned above, we would need to define a control scripting language for
describing the relationships between the different message parts and for
orchestrating their interaction. In my thinking, this control language shares
some characteristics of the 'Universal network graphics language' which Tim
brought up on this list last week. Although I think 'Universal network graphics
language' is a misnomer for the kind of thing we wrote about - graphical objects
are just one of the object types we're all interested in squirting around the net.
Example:
MIME-Version: 1.0
Content-Type: multipart/related;
boundary=unique-boundary-1
--unique-boundary-1
Content-Type: application/html-control
[
here is where one would put a simple control script instructing the browser
which part to show first, second, etc.
]
--unique-boundary-1
Content-Type: text/html
Part-Name: doc1
[ html formatted document here ]
--unique-boundary-1
Content-Type: image/gif
Part-Name: image1
[ image here ]
--unique-boundary-1
Chris
-----------------------------------------------------------------------
Christopher McRae mcrae@ora.com
President, SIGWEB 415/242-9623
Project Manager
O'Reilly & Associates, Publishers 510/540-6036
Background messages - more context can be found at
http://gummo.stanford.edu/html/hypermail/www-talk-1993q4.index.html
-----------------------------------------------------------------------
Replied: Mon, 18 Oct 1993 11:03:14 PDT
Replied: Christopher.McRae
From www-talk-request@dxcern.cern.ch Sun Oct 17 12:36:16 1993
Received: from dxmint.cern.ch by library.ucsf.edu with SMTP id AA17872
(5.67a8/IDA-1.5 for <www-talk-local@ckm.ucsf.edu>); Sun, 17 Oct 1993 12:36:14 -0700
Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
id AA05510; Sun, 17 Oct 1993 20:33:56 +0100
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3)
id AA03196; Sun, 17 Oct 1993 20:28:50 +0100
Received: from dxmint.cern.ch by dxcern.cern.ch (5.65/DEC-Ultrix/4.3)
id AA03192; Sun, 17 Oct 1993 20:28:48 +0100
Received: from nxoc01.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
id AA03233; Sun, 17 Oct 1993 20:28:46 +0100
Received: from dxmint.cern.ch by nxoc01.cern.ch (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
id AA04035; Sun, 17 Oct 93 19:59:56 MET
Received: from athena.library.ucsf.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
id AA03229; Sun, 17 Oct 1993 20:28:42 +0100
Received: from sphinx.library.ucsf.edu by library.ucsf.edu with SMTP id AA17807
(5.67a8/IDA-1.5 for <www-talk>); Sun, 17 Oct 1993 12:27:30 -0700
Message-Id: <199310171927.AA17807@library.ucsf.edu>
From: Christopher.McRae (Christopher McRae)
Organization: UCSF Center for Knowledge Management
Email: mcrae@ckm.ucsf.edu or uunet!mcrae
Phone: 415/476-3577
Fax: 415/476-4653
To: www-talk@library.ucsf.edu
Cc: Dave_Raggett <dsr@hplb.hpl.hp.com>
In-Reply-To: Your message of Tue, 12 Oct 1993 13:18:16 -0000
<9310121218.AA27649@manuel.hpl.hp.com>
Subject: Re: request for new forms submission consensus
Date: Sun, 17 Oct 1993 12:34:04 PDT
Sender: Christopher.McRae
Dave Raggett writes:
> Frans van Hoesel has pointed out the value in being able to
> use a checkbox or an icon or whatever to submit forms. In
> a tax return there might be a load of questions that become
> irrelevant when you click the checkbox to indicate that you
> are "single". In this case the form would be submitted and
> the server would then return it with the irrelevant questions
> greyed-out:
>
> Single? <INPUT NAME="single" TYPE=checkbox SUBMIT>
>
> The idea here is to make SUBMIT an independent attribute
> that can be used with arbitrary field types. You could
> have multiple "submit buttons" in the same form. This way
> authors can choose whether the form contents gets checked
> after each field on a per field basis.
Why not allow/define the use of MIME multipart messages for such applications?
That is, rather than using the SUBMIT attribute as above to retreive a
customized version of the form, why not include named sections of a document
section and define EXPAND/COLLAPSE attributes to control display? For instance,
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary=unique-boundary-1
--unique-boundary-1
Content-Type: application/html-form
[some stuff here]
<INPUT NAME="single" TYPE=checkbox EXPAND=single_form COLLAPSE=couple_form>
[more stuff here]
--unique-boundary-1
Content-Type: application/html-form
Part-Name: single_form
[ single-specific stuff goes here ]
--unique-boundary-1--
Content-Type: application/html-form
Part-Name: couple_form
[ couple-specific stuff goes here ]
--unique-boundary-1--
Note that one could also use only one of EXPAND or COLLAPSE to toggle display
of a document section as opposed to selecting between alternate sections.
Another example:
<SELECT SEVERAL NAME="what-to-do">
<LI EXPAND=book_selection_form> Read A Book
<LI EXPAND=walking_trail_map> Take a Walk
<LI EXPAND=bagelry_menu> Buy a Bagel
<LI EXPAND=tv_guide> Watch TV
</SELECT>
This model would work well for those applications where the overhead of
transferring possibly irrelevant sections of a document was low relative to
the overhead of performng multiple GETs.
Chris
--------------------------------------------------------------------------------
Christopher McRae mail: mcrae@ckm.ucsf.edu
UCSF Center for Knowledge Management at&t: 415/476-3577
530 Parnassus Avenue, Box 0840 fax: 415/476-4653
San Francisco, California 94143
Replied: Mon, 18 Oct 1993 10:39:34 PDT
Replied: Dave_Raggett <dsr@hplb.hpl.hp.com>
From dsr@hplb.hpl.hp.com Mon Oct 18 04:02:08 1993
Received: from hplb.hpl.hp.com by library.ucsf.edu with SMTP id AA22789
(5.67a8/IDA-1.5 for <Christopher.McRae@library.ucsf.edu>); Mon, 18 Oct 1993 04:02:06 -0700
Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Mon, 18 Oct 93 11:51:41 +0100
Received: by manuel.hpl.hp.com
(16.6/15.6+ISC) id AA26007; Mon, 18 Oct 93 12:00:49 +0100
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-Id: <9310181100.AA26007@manuel.hpl.hp.com>
Subject: Re: request for new forms submission consensus
To: Christopher.McRae@library.ucsf.edu
Date: Mon, 18 Oct 93 12:00:47 BST
Mailer: Elm [revision: 66.36.1.1]
Why not allow/define the use of MIME multipart messages for such applications?
> That is, rather than using the SUBMIT attribute as above to retreive a
> customized version of the form, why not include named sections of a document
> section and define EXPAND/COLLAPSE attributes to control display? For
> instance,
An interesting idea! Unfortunately, I don't see much chance of it getting
supported by the browser writers for some time yet. Sorry to be downbeat but
right now I am struggling to get the discussion document finished and to
find a balance between what is possible and what browser writers will
agree to implementing quickly. There is considerable pressure to get the
basic spec pinned down ASAP now that Mosaic and other browsers are starting
to implement forms in the absence of a solid spec.
I see ideas like this finding their worth once we have had basic forms
support for a while, and people are prepared to take on new ideas.
Many thanks,
Dave Raggett
From Christopher.McRae Mon Oct 18 10:56:37 1993
Received: from sphinx.library.ucsf.edu by library.ucsf.edu with SMTP id AA26274
(5.67a8/IDA-1.5 for <Christopher.McRae>); Mon, 18 Oct 1993 10:56:36 -0700
Message-Id: <199310181756.AA26274@library.ucsf.edu>
From: Christopher.McRae (Christopher McRae)
Organization: UCSF Center for Knowledge Management
Email: mcrae@ckm.ucsf.edu or uunet!mcrae
Phone: 415/476-3577
Fax: 415/476-4653
To: Christopher.McRae
In-Reply-To: Your message of Sun, 17 Oct 1993 12:34:04 -0700
<199310171927.AA17807@library.ucsf.edu>
Subject: Re: request for new forms submission consensus
Date: Mon, 18 Oct 1993 11:03:12 PDT
Sender: Christopher.McRae
I hope I'm not about to provoke Marc's kitchen sink speech again. ;)
On Sun, 17 Oct I wrote:
> Why not allow/define the use of MIME multipart messages for such applications?
> That is, rather than using the SUBMIT attribute as above to retreive a
> customized version of the form, why not include named sections of a document
> section and define EXPAND/COLLAPSE attributes to control display? For instance
[ rest of message not included ]
I realized that we could use the same technique to store and retrieve
encrypted documents as well. For instance,
MIME-Version: 1.0
Content-Type: multipart/related;
boundary=unique-boundary-1
--unique-boundary-1
Content-Type: application/html-form
[some stuff here]
<INPUT NAME="key" TYPE=text ENCRYPT=@secret SUBMIT>
[ possibly more stuff here ]
--unique-boundary-1
[ whatever MIME headers are appropriate for an encrypted message ]
Content-Id: secret
[ encrypted text of message goes here ]
--unique-boundary-1--
One could hit a button on the client to pull in the above template, then type
in a key and the secret text. The client would encrypt the secret portion
using the given key, and then submit it to the server.
Later, when the document is downloaded, the secret portion will be unreadable
until the appropriate key is typed in.
This method is nice since the key never even needs to leave the client
machine. The server doesn't even know how to decrypt the secret part(s).
Of course, you could share the key with others in separate transmissions and
thus allow them to view the secret message.
Chris
--------------------------------------------------------------------------------
Christopher McRae mail: mcrae@ckm.ucsf.edu
UCSF Center for Knowledge Management at&t: 415/476-3577
530 Parnassus Avenue, Box 0840 fax: 415/476-4653
San Francisco, California 94143