Ned has done a nice job of recording the minutes and providing them
for mailing list reveiw prior to handing over to the IETF for
publication. Now is your chance to correct anything that needs
correction. I will ship this to the IETF Secretariat on Wednesday,
July 10 with whatever corrections are in hand at that time.
Best...\Stef (Thanks Ned!...;-)
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
Jacob Palme agreed to have a new version of the document based on the
results of this meeting out by Wednesday. A document editing
committee consisting of Alex Hopman, Lewis Geer, Mark Joseph, and Hal
Howard will meet then to do a final editing pass over the document.
The meeting then moved on to consider the various agenda items:
(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 theinformational 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 -- targe 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
Respectfully submitted by Ned Freed...