NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 11-Mar-98
Chair(s):
Einar Stefferud <stef@nma.com>
Applications Area Director(s):
Keith Moore <moore@cs.utk.edu>
Harald Alvestrand <Harald.Alvestrand@maxware.no>
Applications Area Advisor:
Keith Moore <moore@cs.utk.edu>
Mailing Lists:
General Discussion: mhtml@segate.sunet.se
To Subscribe: listserv@segate.sunet.se
In Body: subscribe mhtml <full name>
Archive: ftp://segate.sunet.se/lists/mhtml/
Description of Working Group:
World Wide Web documents are most often written using Hyper Text Markup Language (HTML). HTML is notable in that it contains "embedded content"; that is, HTML documents often contain pointers or links to other objects (images, external references) which are to be presented to the recipient. Currently, these compound structured Web documents are transported almost exclusively via the interactive HTTP protocol. The MHTML working group has developed three Proposed Standards (RFCs 2110, 2111 and 2112) which permit the transport of such compound structured Web documents via Internet mail in MIME multipart/related body parts.
The Proposed Standards are intended to support interoperability between separate HTTP-based systems and Internet mail systems, as well as being suitable for combined mail/HTTP browser systems.
It is beyond the scope of this working group to come up with standards for document formats other than HTML Web documents. However, the Proposed Standards so far produced by the working group have been designed to allow other such formats to use similar strategies.
The MHTML WG is currently INACTIVE while first implementations are under way. To support implementation efforts, the WG Editor maintains an Informational Internet-Draft ftp://ftp.dsv.su.se/users/jpalme/draft-ietf-mhtml-info-06.txt which provides additional useful information for implementors. This Informational Draft also discusses Web page formatting choices that affect their efficient use through disconnected channels such as mail. It will become an Informational RFC after implementation experience has been collected. Until then, this informational draft will be kept current and available in the IETF Internet-Drafts library.
The MHTML Mailing List remains open for discussion of any issues that may arise during implementation, and to collect information about successful interoperable and interworkable implementations in anticipation of progression to Draft-Standard Status.
From May to October, 1997, the working group will Monitor Implementation progress and discuss issues, periodically Update Draft of Informational Document.
The editors of this group are:
Main editor: Jacob Palme <jpalme@dsv.su.se Associate editor: Alex Hopmann <alex.hop@resnova.co
Goals and Milestones:
Mar 96 |
|
Clarify issues and submit first Internet-Draft. |
Jun 96 |
|
Submit first Internet-Draft for MIME encapsulation of HTML. |
Sep 96 |
|
Submit MHTML specification to IESG for consideration as a Proposed Standard. |
Oct 96 |
|
Submit Internet-Draft for guidelines in created documents for disconnected access. |
Dec 96 |
|
Submit guidelines Internet-Draft to IESG for consideration as an Informational RFC. |
Aug 97 |
|
Meet at Munich to review Implementation progress. |
Oct 97 |
|
Submit Implementation Progress Internet-Draft to IESG for publication as an Informational RFC. |
Internet-Drafts:
· Sending HTML in MIME, an informational supplement to the RFC: MIME Encapsulation of Aggregate HTML Documents (MHTML)
· MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)
· Content-ID and Message-ID Uniform Resource Locators
· The MIME Multipart/Related Content-type
Request For Comments:
RFC |
Status |
Title |
RFC2112 |
PS |
The MIME Multipart/Related Content-type |
RFC2111 |
PS |
Content-ID and Message-ID Uniform Resource Locators |
RFC2110 |
PS |
MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML) |
Minutes of the MIME Encapsulation of Aggregate HTML Documents (mhtml) Working Group
These minutes were prepared by MHTML WG Chair Einar Stefferud <stef@nma.com>, based on the agenda prepared by Jacob Palme <jpalme@dsv.su.se> and using meeting notes recorded by Eric Berman <ericbe@microsoft.com>.
These minutes are submitted to the Application Area Director and to the IETF Secretariat for inclusion in the LA IETF Proceedings.
A list of attendees is included at end of the minutes. There were 32 attendees at IETF-41, compared with 16 at IETF-40, and 27 at IETF-39.
Mhtml agenda and minutes for the IETF meeting March-April 1998
The original agenda can be found at URL: http://www.dsv.su.se/~jpalme/ietf/mhtml-agenda-9803.html.
I. The implementors questionnaire on implemented features.
http://www.dsv.su.se/~jpalme/ietf/mhtml-impl-status-v3.html:
a. Is it too detailed?
b. Is something missing which should be there?
c. Is it OK that implementors can, but are not required, to report also on features soon coming in their implementation?
d. When is the right time to ask implementors to fill in the questionnaire?
The proper time to collect data on interoperating implementations is just before moving the Proposed MHTML Standard to Draft, since there is no point in doing the work of collecting data early, and then having to do it all over again, or having to reverify it later.
Jacob Palme has received some feedback about the questionnaire, and will be revising it to make it more useful. The goal in this meeting is to get the form right, not get the answers to the questions.
Jacob discussed the split between internal or external display of HTML. Someone indicated that this is immaterial [e.g., if Qualcomm uses Microsoft's code to display HTML but does the URL fix-ups (cid:, content-location base handling, etc.) or if they don't do this] then that is all that matters.
It was observed that the quality of the HTML rendering itself does not matter. But link-related rendering (e.g., IMG, BODY backgrounds, etc.) does matter. So we need to be very careful with the questions.
Question: these might not be yes/no questions. For example, someone may have some secret code in house. Is this good enough for the interoperability request? Answer from Harald Alvestrand: Reporting is on the honor system!
It was noted that a connect-a-thon is a fine idea. Suggestion: Post from a variety of clients to the MHTML mailing list, and collect indications of successful receipt from a variety of clients. Perhaps a special testing mailing list should be set up?
It was humorously suggested that we should spam the MHTML mailing list with some interesting pictures using content-location and content-Id in order to test interoperability.
A major conclusion about the questionnaire was to factor out the standards-specific stuff from the academically interesting stuff. E.g., Part A is critical and part B is optional. Jacob agreed to make this separation.
It was agreed that implementing engineers should fill out the questionnaires and not marketing staff! Our data has to be real.
Question: Should our collected data reference HTML at all? E.g., does a given implementation fix up URLs, provide base, etc.? Answer: Our spec is in fact HTML specific, so we are focused on HTML. XML will need to develop a separate Proposed Standard in due course.
It was noted that if some implementation exploded the MIME parts to files and then rendered the files, it would be fine.
II. Any issues left on the new proposed standard.
All our recycled proposed standards drafts are in last call. No comments really since the WG or IESG last call, which implies no outstanding issues or delays.
The attendees were asked: "Do we have any issues?" "Does everyone know that we have removed content-base in favor of keeping content-location?"
Silence in the room was deafening. Issue closed!
III. When are we planning to start moving to draft standard?
We must wait at least six months which will be after IETF-42 in August, so MHTML does not plan to meet in Chicago at IETF-42. We anticipate meeting at IETF-43 in Orlando in December to work on moving our standards to DRAFT status.
We asked Ned Freed: What does it take to move to Draft standard? Answer: Multiple Interoperable Implementations!
We do not anticipate any shortage of implementations for our purpose, since more than 4 implementation teams are now active, but it was observed that very few implementations now generate content-location.
Question: Are tools publicly available to generate content-location? Answer: 6-12 months from now, we should have them available. Jacob said he will, and others in the room indicated that they would also.
Question: Why is nobody using content-location? This seems telling. Answer: Content-location mostly applies to mailing web pages; new composition generally implies use of content-id. Many existing implementations receive but do not send content-location because there is one widely deployed implementation that does not receive it. People are waiting for this deployed product to receive it. We were assured that this product will soon handle received content-location.
We need two independent implementations generating to take any feature to draft. Question: Is it OK if one of the implementations is a test implementation? Ned Freed's Answer: YES!
It will be interesting to see whether content-location proves to be really useful by many, if any implementations. In any case, this is not something to worry about until at least 6 months from now, which is when MHTML will become eligible for moving to DRAFT. If content-location does not find broad implementation and use, perhaps it is actually not needed. We should not falsely force implementation of any features that do not actually deliver services of value. It is better to shed non-useful features in the move to DRAFT status.
IV. The Informational Draft
ftp://ftp.dsv.su.se/users/jpalme/draft-ietf-mhtml-info-09.txt. If someone has the time to read it, we could check it chapter by chapter:
a. Implementation methods
b. Problems with rewriting URIs when copying HTML documents
c. Caching of body parts
d. Recipients which cannot handle the Multipart/related Content-Type
e. Use of the Content-Type: Multipart/alternative
f. Recipient may not have full Internet connectivity
g. Encoding of non-ascii characters
h. Conversion from HTTP to MIME
It was observed that the Informational RFC Draft might have two purposes, and thus be broken into two separate documents. One would be a story (marketing document) about what MHTML is about. The other would be an implementors guide published as an Informational RFC.
Question: How can we make sure that people not already familiar with this group's work can and will find out about the new work that flows out of implementation experiences, which will be incrementally added to the Internet-Draft "implementors guide? We cannot refer to an Internet-Draft in a Proposed Standard RFC. Can we somehow refer to an Internet-Draft as a "work in progress" which provides useful information for implementors?
Jacob pointed out that the Informational document contains a collection of ideas on how to implement. But he has not received much feedback. Perhaps publishing as an Informational RFC would generate more feedback.
It was suggested to bring the Information Internet-Draft to WG last call to get people to read and comment on it. This will greatly increase its value to implementors, and provide new information to be included. Then it will hopefully be regularly recycled with new information over the next 6 months of implementation effort.
The main issue is whether or not this informational draft will have to be revised as we get more experience, or whether we should attempt to freeze it now, and then find that this might be premature. Not that we should not publish -- just that we should not go to RFC too soon.`
One proposal is to put a work-in-progress reference in the standards-track document to encourage more reading/comments, and to go with a WG last call to will generate feedback and give us a good reading on whether or not to immediately pursue it further. Silence indicated consensus on this conclusion.
V. Any Other Issues
None were put forth. The one-hour meeting then closed 10 minutes early. End of mhtml minutes from meeting at IETF-41 in Los Angeles.
None Received