|
Two revisions:
1. Meeting date corrected from January 1996 to December 1996.
2. Added Pete Resnick to the Attendee list in Appendix C.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
WG MHTML met as scheduled in the evening of 9 December 1996 in San Jose.
The meeting agenda was followed, and is here used for the structure of
these minutes. Attendees are listed in Appendix X.
These minutes are prepared by Einar Stefferud, WG MHTML Chair, from
notes provided by Jacob Palme, Dirk van Gulik, Ed Levinson, and Mark
Joseph. All notes used here-in were also sent to the MHTML WG
mailinglist <[log in to unmask]>.
Respectfully submitted by Einar Stefferud, WG Chair <[log in to unmask]>.
ISSUES ADDRESSED AT THE MHTML MEETING DURING
THE IETF MEETING IN SAN JOSE, DECEMBER 1996
0. Unresolved references to IETF drafts:
Internationalization of the Hypertext Markup Language".
draft-ietf-html-i18n-05.txt. Not yet published as an RFC?
N. Freed & N. Borenstein:
"Multipurpose Internet Mail Extensions (MIME) Part One:
draft-ietf-822ext-mime-imb-07.txt
Part Two: Media Types",
draft-ietf-draft-ietf-822ext-mime-imt-02.txt.
Published as RFC 2045 and RFC 2046.
N. Freed and Keith Moore: "Definition of the URL MIME
External-Body Access-Type", draft-ietf-mailext-acc-url-01.txt,
November 1995. Published as RFC 2017.
Resolution: These will be resolved in due course for MHTML RFC
publication.
1. URL-s which cannot be rewritten: The problem that in some cases it
is not possible to know what is an URL and not an URL in HTML code
containing applets, and that thus mhtml maybe will not work in such
cases.
Resolution: A clear warning needs to be in the INFO document,
as this problem essentially cannot be solved.
2. Interoperability tests: Have any interoperability tests between
working implementations of the mhtml-spec been done yet?
Resolution: One action is to put example messages up at the WG
MHTML web site. Another is to collect information on
implementations and their problems and successes with
interworking.
3. Planning of interoperability tests: What should be tested?
(see appendix A).
Resolution: Each implementor should their own stuff up on the net,
and try to read others' stuff. Then discuss the
problems on the list or privately, with final
interworking results posted to the list. WE ned to be
collecting evidence of interworking implementations for
use in advancing the standard from Proposed to Draft
status.
4. Will all or only a subset of the functions (see appendix A)
be implemented by current implementations?
Resolution: Working group chair will collect reports; and collate
into which features are really in use. Area Director
stated that more than one implementation will be
needed. The required information must include how much
of each part of the standard is implemented
5a. Will rewriting of URLs be done before sending out HTML messages?
Resolution: Deferred to the info/implementation guide draft.
5b. Will rewriting of URLs be done after receipt of HTML messages?
Resolution: Deferred to the info/implementation guide draft.
5c. Which of the implementation methods described in chapter 4 of
draft-ietf-mhtml-info-05.txt will be used?
(a) Combing browser and e-mail in one integrated software package.
(b) Rewriting the HTML at receipt and turning the result over to a
web browser.
(c) Using a translation table or other similar tool to turn
information over from the mail program to the web browser.
(d) Deliver the HTML pages from a proxy server which has the parts
of message available.
(e) The whole mail client built into a proxy server.
Resolution: Implementors stated that they are working on doing the
following items listed above:
(b+d+e) Jacob Palme <[log in to unmask]>
(a+b) Pete Resnick <[log in to unmask]>
(a+b) Chris Cotton <[log in to unmask]>
(a+c) Mark Joseph <[log in to unmask]>
(a) Alex Hopmann <[log in to unmask]>
(a) Eric Berman <[log in to unmask]>
(a) Linda Welsh, Lotus
We expect others to join the party, but this
provides a critical mass for the next stage.
We noted that someone is working on each type of
implementation listed in our agenda. Progress and
problems will be reported and discussed on the WG
mailing list: <[log in to unmask]>.
6. Use of multipart/alternative, inside or outside of
multipart/related (chapter 8 of draft-ietf-mhtml-info-05.txt)
and problems with the start parameter of multipart/related when
referring to a multipart/alternative (see appendix B below).
Cases a, and b, were considered.
Resolution: Problem seems to be that multipart-related parameter
does not really allow recursive use, ie. plain + html,
where html is again multipart-related. Both examples
(a & b) are valid MIME; but they mean quite different
things.
Is case a an issue? No. Nor is case b;
In case a, type/location does not seem to be the
problem. One can have more than one alternative.
But the problem seems to be how far the pointing out
can be.
Conclusion? Cases a & b seem to be nice testing
examples; makes the code complex, but that is the
functionality that we wanted.
7. Go through draft-ietf-mhtml-info-05.txt chapter by chapter and
check which comments there are: Can also the info document be
forwarded for publication as an informational document (not as a
standard)?
Resolution: Comments are solicited on the list;
Jacob got very few comments back,
and would like to see some more checks made.
8. Other items and issues.
* WG MHTML should communicate with other WG Chairs to alert them to
what MHTML is doing and delivering.
* The WG asked for efforts to apply MHTML to PDF, in addition to
applying it to HTML.
This was directed to Steve Zilles <[log in to unmask]>
* References to the INFO-draft that is in progress will be removed
from the MHTML spec-drafts, as the INFO draft will not be
published any time soon.
9. The meeting adjourned on schedule.
Appendix A: Table of important functionalities for HTML in e-mail:
Function
Implementation for generation
Implementation for receipt
Use of multipart/related
- for HTML with embedded graphics, etc.
- for sets of related HTML objects
Reference to embedded body parts
- using Content-ID-s
- using absolute Content-Location
- using relative URLs and no Content-Location
Use of combinations of multipart/related and multipart/alternative
Use of content-disposition header for recipients who do not handle mhtml
Use of HTML messages whose URLs for enbedded graphics must be resolved
through HTTP retrieval from the source
Use of the message/external-body method for sending HTML in e-mail
Use of character sets in HTML messages
- US-ascii
- ISO 8859-1
- Other ISO 8859 variants
- ISO 10646/Unicode
- Other character sets
Appendix B: more about the multipart/alternative issue
(a) Inside the "Content-Type Multipart/related", body parts
can be specified with "Content-Type: Text/plain" as the first
choice, and "Content-Type: Text/HTML" as the second choice:
Content-Type: Multipart/related;
type=3DMULTIPART/ALTERNATIVE =
Content-Type: MULTIPART/ALTERNATIVE
Content-Type: Text/plain
... plain text version of the document for recipients
whose mailers cannot handle Text/HTML ...
Content-Type: Text/HTML; charset=3DUS&endash;ASCII
... text of the HTML document ...
Content-Type: Image/GIF
... a body part, to which the HTML document has a link ...
(b) Outside the multipart/related:
Content-Type: Multipart/alternative
Content-type: Text/plain
... plain text version of the document for recipients
whose mailers cannot handle Text/HTML ...
Content-Type: Multipart/related; type=3DText/HTML =
Content-Type: Text/HTML; charset=3DUS&endash;ASCII
... text of the HTML document ...
Content-Type: Image/GIF
... a body part, to which the HTML text has a link
When choosing between these two methods of employing
multipart/alternative, note the following:
(1) Clients which do not support Multipart/related, and which thus
will interpret it as Multipart/mixed, will with choice (a) display
the inline objects. Thus, a recipient whose mailer can handle
Image/gif but not multipart/related will still be shown the
images, they will not be suppressed by being inside a suppressed
branch of the Multipart/alternative.
(2) Choice (b) will not show inline images in the Multipart/Related,
unless this information is repeated in both branches of the
Multipart/Alternative.
APENDIX C: List of attendees at the session.
1. Einar Stefferud (WG Chair) <[log in to unmask]>
2. Jacob Palme <[log in to unmask]>
3. Edward Levinson <[log in to unmask]>
4. Mark Joseph <[log in to unmask]>
5. Hiroyuki Kajiura <[log in to unmask]>
6. Mark Fu <[log in to unmask]>
7. Juerg von Kaenel <[log in to unmask]>
8. Donal Hanna <[log in to unmask]>
9. Ron Daniel <[log in to unmask]>
10. Terry Allan <[log in to unmask]>
11. Harald Tveit Alvestrand <[log in to unmask]>
12. Mike Gahrns <[log in to unmask]>
13. David Johnson <[log in to unmask]>
14. Keith Lamond <[log in to unmask]>
15. Stephen Martin <[log in to unmask]>
16. Don Dumimu <[log in to unmask]>
17. L. A. Heberlon <[log in to unmask]>
18. Dan Sharon <[log in to unmask]>
19. William Flanigan <[log in to unmask]>
20. Larry Masinter <[log in to unmask]>
21. Carl Uno Manros <[log in to unmask]>
22. Sandro Mazzucato <[log in to unmask]>
23. Shin Okadu <[log in to unmask]>
24. Svante Nygnen <[log in to unmask]>
25. Alex Hopmann <[log in to unmask]>
26. Eric Berman <[log in to unmask]>
27. Chris Cotton <[log in to unmask]>
28. Steve Zilles <[log in to unmask]>
29: Pete Resnick <[log in to unmask]>
NOTE: Any errors in names or addresses are due to
transcription problems from the signup sheet.
End of WG MHTML Minutes for 9 December, 1996...
|
