LISTSERV mailing list manager LISTSERV 15.5

Help for MHTML Archives


MHTML Archives

MHTML Archives


View:

Next Message | Previous Message
Next in Topic | Previous in Topic
Next by Same Author | Previous by Same Author
Chronologically | Most Recent First
Proportional Font | Monospaced Font

Options:

Join or Leave MHTML
Reply | Post New Message
Search Archives


Subject: Minutes of WG MHTML, San Jose, December 1996b
From: Einar Stefferud <[log in to unmask]>
Reply-To:[log in to unmask]
Date:Tue, 7 Jan 1997 00:34:52 -0800
Content-Type:text/plain
Parts/Attachments:
Parts/Attachments

text/plain (272 lines)


WG MHTML met as scheduled in the evening of 9 January 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]>

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

Back to: Top of Message | Previous Page | Main MHTML Page

Permalink



LISTSRV.NORDU.NET

CataList Email List Search Powered by the LISTSERV Email List Manager