LISTSERV mailing list manager LISTSERV 15.5

Help for MHTML Archives

MHTML Archives

MHTML Archives


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


Join or Leave MHTML
Reply | Post New Message
Search Archives


WG MHTML Minutes from Montreal


Einar Stefferud <[log in to unmask]>


[log in to unmask]


Fri, 12 Jul 1996 14:11:46 -0700





text/plain (1 lines)

Minutes of the MHTML WG meeting held at the Montreal IETF
on Monday, 24 June, 1996.

Einar Stefferud, chair
Jacob Palme, document editor
Ned Freed, minute-taker

The primary draft documents discussed at the meeting was
draft-ietf-mhtml-spec-00.txt. The meeting also discussed the
informational document a little, draft-ietf-mhtml-info-00.txt.

Jacob Palme agreed to have a new version of the document based on the
results of this meeting out by Wednesday, June 26. A document editing
committee consisting of Alex Hopmann, Lewis Geer, Mark Joseph, and Hal
Howard was designated to meet then to do an editing pass over the

The WG meeting then moved on to consider the various agenda items:
    (A copy of the original agenda is appended to these minutes).

(a) Use of the Content-Location header. It was decided to delete the
    text requiring an exact match of document URLs to Content-Location
    and instead require that receivers resolve relative URLs to
    absolute URLs (per RFC 1808) prior to comparison.

(b) Format of Links to Other Body Parts. It was decided to simply say
    that if you want to make sure that a recipient has a given
    resource you should put it inside of the same multipart/related
    construct. Others means of referencing may work, or they may not.

(c) Multipart/related vs. content-disposition. It was decided to
    remove the text in section 10 to resolve this issue.

(d) LWSP in URLs in e-mail headers. It was decided to reference the
    URL access-type RFC (not yet assigned an RFC number).

(e) Encoding of 8-bit characters in URLs. It was decided to reference
    to URL access-type RFC (again).

(f) Relation to HTTP 1.1 specification of Content-Base and
    Content-Location. The present text is fine; it coincides with
    HTTP 1.1; the Base: header in RFC 1808 is no longer relevant.

(g) Use of relative URLs in text/html contents. The present text is fine.

    (*) Recent RFCs have received some pushback because they do not
        define "should" and "must". Text needs to be added to do this.

(h) Support for fast rendering. Take out section 8.4; catalogs are
    for further study.

    (*) The includes parameter to multipart/related. Take out section
        7.2; this is also for further study and resolution of (h) may
        eliminate this anyway.

    (*) It is noted that the IMAP community needs to be aware of any
        future work done on (h) and (i), as it may impact IMAP4.

(i) Allow file URLs. Allow them but there may be problems. Don't
    encourage them. Larry Masinter agreed to provide additional text.

(j) Allow non-IETF URLs. Not specifically disallowed; not discussed.

(k) Encoding of non-ASCII characters in HTML bodies. Jacob Palme has
    new text which seems acceptable modulo some terminology changes
    from Larry Masinter. Further work will be done during the editing
    session later this week.

(l) Recommend any encoding as better than another. This can be
    discussed in the informational document if necessary; no absolute
    recommendation will be made.

(m) Line breaks must be CRLF. This is discussed in MIME; no need to
    talk about it here. It can go into the informational document.

(n) base64 should be allowed. Of course it should be. There is
    apparently one missing reference to it that needs to be added.

(o) Conformance requirements. Statements involving the include
    parameter and catalogs will be removed. Discussion of conformance
    on the part of senders should also be removed. The remaining
    discussion of receiver conformance will be moved from section 13 to
    section 8. Section 13 can now be used to define "should" and"must"

(p) Multipart/related become a proposed standard. This work depends
    on this happening; this WG has a new draft to replace the
    experimental multipart/related RFC.

(q) Multipart/related issues. None are known.

(r) Informational companion RFC? Plan for it to appear, but let it sit
    out there as a draft until it is complete and then worry about it.

(s-w) All part of the informational RFC. Deferred.

(x) Default action in forms. Some words of warning about not assuming
    a default form action are needed. The rest is for further study.

(y) Keep Alex Hopmann as editor. The answer is yes.

(z) Reports on implementation status. Deferred.

(za) Future work plan. See above. There will be an immediate working
     group last call after the editing is complete. This will be four
     week last call -- target is the end of July.

(zb) Any other issues. Larry brought up document versioning; he now
     says that this is best turned into an offline discussion with Ed
     Levinson. The meeting adjourned with 8 minutes remaining on the

Respectfully submitted by Ned Freed...
  Lightly edited by Einar Stefferud...


Agenda used in the meeting:

Draft Agenda MHTML in Montreal, June 1996

Version two, 21 June 1996 from Jacob Palme E-mail: [log in to unmask] at
the Department of Computer and Systems Sciences, Stockholm

This draft agenda can be found at URL:
Revised versions might become available as draft-agenda-2, 3, etc.

The issues in this draft agenda are more fully described in the issues
list. The issues in this draft agenda are the same as in the issues list
and listed in the same order, except that I have moved the three most
controversial to the top of the agenda, to be discussed first.


ISSUES: draft-ietf-mhtml-spec
SPEC: draft-ietf-mhtml-spec
INFO: draft-ietf-mhtml-info
REL: draft-ietf-mhtml-related

The issue numbers in the table below refer to the issues in the issues

Agenda Issue Time Description
Item No. No. in

A 8 15 Require exact match of links and Content-
                        Location headers

B 7 10 Linked body parts SHOULD or MUST be inside

C 9 10 Multipart/related versus Content-Disposition

D 2a 3 LWSP in URL-s in e-mail headers

E 2b 10 Encoding of 8-bit characters in URL-s in e-
                        mail headers

F 2c 10 Relation to HTTP 1.1 specification of Content-
                        Base and Content-Location

G 3 3 Resolving relative URLs

H 4 10 Support for fast rendering

I 5 3 Allow File URLs

J 6 3 Allow non-IETF URIs

K 10a 10 Encoding of non-ascii characters in HTML
                        bodies; allow all combinations

L 10b 10 Recommend any encoding as better than another?

M 10c 5 Line breaks must be CRLF, but only before
                        QP/Base64 decoding.

N 10d 2 Base64 should of course also be allowed.

O 11 10 Conformance requirements

P 12 5 Multipart/related become a proposed or draft

Q 13 10 Multipart/related issues

R 14 5 An informational RFC?

S 15 5 Implementation methods

T 16 5 Recipients who cannot handle multipart/related

U 17 5 Multipart/alternative

V 18 5 Recipients without full Internet connectivity

X 19 10 Default ACTION in forms

Y 1 3 Keep Alex Hopmann as editor?

Z 20 10 Reports on implementation status for various

ZA 20 10 Future work plan

ZB 21 5 Any other issues

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



CataList Email List Search Powered by the LISTSERV Email List Manager