Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/mhtml/mhtml-minutes-96dec.txt

Text File | 1997-01-30 | 10KB | 276 lines

Editor's note:  These minutes have not been edited.

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 <[e-mail]>.

Respectfully submitted by Einar Stefferud, WG Chair <[e-mail]>.


        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  <[e-mail]>
        (a+b)    Pete Resnick <[e-mail]>
        (a+b)    Chris Cotton <[e-mail]>
        (a+c)     Mark Joseph  <[e-mail]>
        (a)     Alex Hopmann <[e-mail]>
        (a)    Eric Berman  <[e-mail]>
        (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: <[e-mail]>.

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 <[e-mail]>

   * 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)    <[e-mail]>
2.  Jacob Palme         <[e-mail]>
3.  Edward Levinson         <[e-mail]>
4.  Mark Joseph         <[e-mail]>
5.  Hiroyuki Kajiura        <[e-mail]>
6.  Mark Fu             <[e-mail]>
7.  Juerg von Kaenel        <[e-mail]>
8.  Donal Hanna            <[e-mail]>
9.  Ron Daniel            <[e-mail]>
10. Terry Allan            <[e-mail]>
11. Harald Tveit Alvestrand    <[e-mail]>
12. Mike Gahrns            <[e-mail]>
13. David Johnson        <[e-mail]>
14. Keith Lamond        <[e-mail]>
15. Stephen Martin        <[e-mail]>
16. Don Dumimu            <[e-mail]>
17. L. A. Heberlon        <[e-mail]>
18. Dan Sharon            <[e-mail]>
19. William Flanigan        <[e-mail]>
20. Larry Masinter        <[e-mail]>
21. Carl Uno Manros        <[e-mail]>
22. Sandro Mazzucato        <[e-mail]>
23. Shin Okadu            <[e-mail]>
24. Svante Nygnen        <[e-mail]>
25. Alex Hopmann         <[e-mail]>
26. Eric Berman            <[e-mail]>
27. Chris Cotton        <[e-mail]>
28. Steve Zilles        <[e-mail]>
29: Pete Resnick        <[e-mail]>

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...