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
document.
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
clock.
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: jpalme@dsv.su.se. at
the Department of Computer and Systems Sciences, Stockholm
University/KTH
This draft agenda can be found at URL:
HTTP://www.dsv.su.se/~jpalme/ietf/draft-agenda-1-June-1996.html.
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.
References:
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
list.
Agenda Issue Time Description
Item No. No. in
Issue
List
A 8 15 Require exact match of links and Content-
Location headers
B 7 10 Linked body parts SHOULD or MUST be inside
multipart/related
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
standard?
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
implementations
ZA 20 10 Future work plan
ZB 21 5 Any other issues