W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997

Re: Is MHTML only for e-mail?

From: Einar Stefferud <Stef@nma.com>
Date: Sat, 04 Oct 1997 10:42:44 -0700
To: mhtml@segate.sunet.se, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <982.875986964@nma.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4515
Speaking as Chair of MHTML:

rom Jacob's message Sat, 4 Oct 1997 10:55:10 +0200:
}The title of RFC 2110 is "MIME E-mail Encapsulation of Aggregate Documents,
}such as HTML (MHTML)". The title thus says that this standard is for e-mail
}only. In several places inside RFC 2110 the proposed standard says that it
}is for sending HTML in e-mail.
}However, the recent discussion about inheritance of Content-Base has made
}us aware that multipart/related may be sent via HTTP too. That is, it is
}feasible that an HTTP server sends a multipart/related containing both HTML
}text and embedded objects as separate body parts within a
}Question 1: Is it the intention that HTTP can be used in this way?

I say yes, though in the beginning we could not see far enough ahead
to address the more general issues.  But, what is the difference,
after receipt, when the MIME Multipart/Related is shipped in an SMTP,

	Who should care how it will be shipped.
	Who should care how it was shipped?  

The main difference is whether the "pipe" offers responsive
interaction with the server, such that "missing" URI objects
can/cannot easily be resolved by just asking for the "missing" URI
item across the available "pipe".

Mail and HTTP just appear to be the extreme ends of the spectrum.  The
others seems to fall in between.  But, certainly we do not intend that
the IETF Applications Directorate should be a party to making it hard
for Internet Application users to work together by exchanging
Application Information Objects in MIME wrappings.

}Question 2: Should MHTML be amended to say that it covers all sending of
}HTML in MIME, not only through SMTP but also through HTTP and possibly
}other protocols, for example FTP?

YES!  Full Stop!

}Question 3: A main principle of MHTML is that if a HTML document is sent
}as part of a multipart/related, lookup of links in the HTML document
}should first go to other body parts within the multipart/related,
}and ordinary HTTP lookup should only be done if there is no match
}in another body part. Is this principle true also when multipart/related
}is sent via HTTP?

I think, but of course leave it to be decided, that it should be true
in all Multipart/Related compound objects that do contain additional
related parts.

}Question 4: If the answer to question 2 is "yes", does this mean that
}the IETF MHTML group should liaise with some other IETF group on this
}issue? I am sending a copy of this message to the mailing list for the
}IETF working group on HTTP. Since I am not a member of that group,
}please post responses also to the mhtml mailing list.


And we have been doing just that with some cross WG participation.
Larry Masinter is Chair of HTTP WG and he has been a long time
participant in our MHTML WG.  Some MHTML WG people have also been
participants in the HTTP WG, although I have personally withdrawn from
participation in the HTTP sessions or list discussions.

What has made all this such a clear issue just now is that we finally
got to the crux issues between MHTML and HTTP Specifications where we
need to jointly be truly inventive to find a way out of the current

In short, we have a very real conflict between two critically
important installed application bases, both of which promise not to be
replaced by the other, so they must be given a way to interwork.  

So, this is our joint task, between MHTML and HTTP WGs, with some help
from our APP ADs, who have both be participating in our work.


PS: I notice that the CALSH (Calendar) folk are facing similar
    difficulties, so we should alert them to our problems, in case
    they have not yet noticed.  I think some CALSCH WG folk are
    reading our MHTML and HTTP lists.
Received on Saturday, 4 October 1997 10:49:54 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:21 UTC