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