Re: Encapsulating HTTP parts in MIME "Jay C. Weber" <firstname.lastname@example.org>
To: Marc VanHeyningen <email@example.com>
Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org,
Subject: Re: Encapsulating HTTP parts in MIME
In-reply-to: Your message of "Mon, 28 Jun 1993 09:26:12 CDT."
Date: Mon, 28 Jun 1993 10:19:55 -0700
From: "Jay C. Weber" <email@example.com>
(My news poster choked when I tried to followup via news; feel free to
forward this to comp.infosystems.www, comp.mail.mime)
In article <firstname.lastname@example.org> Marc VanHeyningen <email@example.com> writes:
>HyperText Transfer Protocol (HTTP) is a transaction oriented protocol
>based on request-response. I believe there are some advantages to
>being able to consider these components (the request and the response)
>as MIME content-types, so they may be forwarded, gatewayed,
>- Allowing the full power of HTTP/1.0 to be utilized via a mailbot,
> for users who cannot use HTTP directly due to limitations of dialup
> links like UUCP, firewalls, etc.
To implement this, check out the ServiceMail Toolkit, a package that
helps in constructing mailbots that speak MIME. You'll find it in
the metamail contrib distribution (try to get a recent version with
ServiceMail 2.0). I'm the primary author, I'd be glad to help someone
figure out how to use it for this application. (I'd been planning to
do it myself.)
ServiceMail installations usually use the Subject: field to contain
the "method" and its parameters. Especially if you put it in the
embedded message/http-request, this fits well.
>- Allow an HTTP request or response to have some or all of the
> security services made possible for MIME objects by the PEM-MIME
> inter-operation standard (still in draft right now.)
We're in the middle of adding PEM-MIME support to ServiceMail; we're
directly supporting symmetric-key, in the PEM-MIME style. Public-key
is still too hazy with respect to licensing.
Enterprise Integration Technologies