To: minutes@ietf.org cc: Keith Moore , mhtml@SEGATE.SUNET.SE Subject: MHTML Minutes from the 41st IETF in Los Angeles. Reply-to: Stef@nma.com From: Einar Stefferud MIME-Version: 1.0 Date: Fri, 17 Apr 1998 15:47:40 -0700 Sender: owner-mhtml@SEGATE.SUNET.SE These minutes were prepared by MHTML WG Chair Einar Stefferud , based on the agenda prepared by Jacob Palme and using meeting notes recorded by Eric Berman . These minutes are submitted to the APPlication Area Director and to the IETF Secretariat for inclusion in the LA IETF Proceedings. A list of attendees is included at end of the minutes. There were 32 attendees at IETF-41, compared with 16 at IETF-40, and 27 at IETF-39. MHTML AGENDA and MINUTES for IETF meeting March-April 1998 The original agenda can be found at URL: http://www.dsv.su.se/~jpalme/ietf/mhtml-agenda-9803.html. ITEM 1. The implementors questionnaire on implemented features. http://www.dsv.su.se/~jpalme/ietf/mhtml-impl-status-v3.html: a. Is it too detailed? b. Is something missing which should be there? c. Is it OK that implementors can, but are not required, to report also on features soon coming in their implementation? d. When is the right time to ask implementors to fill in the questionnaire? The proper time to collect data on interoperating implentations is just before moving the Proposed MHTML Standard to Draft, since ther eis no point in doing the work of collecting data early, and then having to do it all over again, or having to reverify it later. Jacob Palme has received some feedback about the questionnaire, and will be revising it to make it more useful. The goal in this meeting is to get the form right, not get zthe answers to the questions. Jacob discussed the split between internal or external display of HTML. Someone indicated that this is immaterial [e.g., if Qualcomm uses Microsoft's code to display HTML but does the URL fixups (cid:, content-location base handling, etc.) or if they don't do this] then that is all that matters. It was observed that the quality of the HTML rendering itself does not matter. But link-related rendering (e.g., IMG, BODY backgrounds, etc.) does matter. So we need to be very careful with the questions. Question: these might not be yes/no questions. For example, someone may have some secret code in house. Is this good enough for the interoperability request? Answer from Harald Alvestrand: Reporting is on the honor system! It was noted that a connect-a-thon is a fine idea. Suggestion: Post from a variety of clients to the MHTML mailing list, and and collect indications of successful receipt from a variety of clients. Perhaps a special testing mailing list should be set up? It was humorously suggested that we should spam the MHTML mailing list with some interesting pictures using content-location and content-Id in order to test interoperability. A major conclusion about the questionnaire was to factor out the standards-specific stuff from the academically interesting stuff. E.g., Part A is critical and part B is optional. Jacob agreed to make this separation. It was agreed that implementing engineers should fill out the questionnaires and not marketing staff! Our data has to be real. Question: Should our collected data reference HTML at all? E.g., does a given implementation fix up URLs, provide base, etc.? Answer: Our spec is in fact HTML specific, so we are focused on HTML. XML will need to develop a separate Proposed Standard in due course. It was noted that if some implementation exploded the MIME parts to files and then rendered the files, it would be fine. 2. Any issues left on the new proposed standard. All our recycled proposed standards drafts are in last call. No comments really since the WG or IESG last call, which implies no outstanding issues or delays. The attendees were asked:: "Do we have any issues?" "Does everyone know that we have removed content-base in favor of keeping content-location?" Silence in the room was deafening. Issue closed! 3. When are we planning to start moving to draft standard? We must wait at least 6 months which will be after IETF-42 in August, so MHTML does not plan to meet in Chicago at IETF-42. We anticipate meeting at IETF-43 in Orlando in December to work on moving our standards to DRAFT status. We asked Ned Freed: What does it take to move to Draft standard? Answer: Multiple Interoperable Implementations! We do not anticipate any shortage of implementations for our purpose, since more than 4 implementation teams are now active, but it was observed that very few implementations now generate content-location. Question: Are tools publicly available to generate content-location? Answer: 6-12 months from now, we should have them available. Jacob said he will, and others in the room indicated that they would also. Question: Why is nobody using content-location? This seems telling. Answer: Content-location mostly applies to mailing web pages; new composition generally implies use of content-id. Many existing implementations receive but do not send content-location because there is one widely deployed implementation that does not receive it. People are waiting for this deployed product to receive it. We were assured that this product will soon handle received content-location. We need two independent iplementations generating to take any feature to draft. Question: Is it OK if one of the implementations is a test implementation? Ned Freed's Answer: YES! It will be interesting to see whether content-location proves to be really useful by many, if any implementations. In any case, this is not something to worry about until at least 6 months from now, which is when MHTML will become eligible for moving to DRAFT. If content-location does not find broad implementation and use, perhaps it is actually not needed. We should not falsely force implementation of any features that do not actually deliver services of value. It is better to shed non-useful features in the move to DRAFT status. 4. The informational draft ftp://ftp.dsv.su.se/users/jpalme/draft-ietf-mhtml-info-09.txt. If someone has the time to read it, we could check it chapter by chapter: a. Implementation methods b. Problems with rewriting URIs when copying HTML documents c. Caching of body parts d. Recipients which cannot handle the Multipart/related Content-Type e. Use of the Content-Type: Multipart/alternative f. Recipient may not have full Internet connectivity g. Encoding of non-ascii characters h. Conversion from HTTP to MIME It was observed that the Informational RFC Draft might have two purposes, and thus be broken into two separate documents. One would be a story (marketing document) about what MHTML is about. The other would be an implementors guide published as an Informational RFC. Question: How can we make sure that people not already familiar with this group's work can and will find out about the new work that flows out of implementation experiences, which will be incrementally added to the Internet-Draft "implementors guide? We cannot refer to an Internet-Draft in a Proposed Standard RFC. Can we somehow refer to an Internet-Draft as a "work in progress" which provides useful information for implementors? Jacob pointed out that the Informational document contains a collection of ideas on how to implement. But he has not received much feedback. Perhaps publishing as an Informational RFC would generate more feedback. It was suggested to bring the Information Internet-Draft to WG last call to get people to read and comment on it. This will greatly increase its value to implementors, and provide new information to be included. Then it will hopefully be regularly recycled with new information over the next 6 months of implementation effort. The main issue is whether or not this informational draft will have to be revised as we get more experience, or whether we should attempt to freeze it now, and then find that this might be premature. Not that we should not publish -- just that we should not go to RFC too soon.` One proposal is to put a work-in-progress reference in the standards-track document to encourage more reading/comments, and to go with a WG last call to will generate feedback and give us a good reading on whether or not to immediately pursue it further. Silence indicated consensus on this conclusion. 5. Any other issues. None were put forth. The 1 hour meeting then closed 10 minutes early. ATTENDEES Name EMail 1. Lauren Antonoff laurena@microsoft.com 2. Eric Berman ericbe@microsoft.com 3. Ari Bixhorn bixhorn@reston.btna.com 4. Vergel Blake vblake@sitara.net 5. Chris Chiotasso cchiotasso@infolibria.com 6. WAyne Clark wclark@technauts.com 7. Cyrus Daboo daboo@cyrusoft.com 8. Alec Sun alecdu@microsoft.com 9. Roger Fajman raf@cu.nih.gov 10. Tomas Fasth tomas@uronetics.se 11. Arnaud Florequin arnaud.florequin@cnet.francetelecom.fr 12. Ted Hardie hardie@nasa.gov 13. Maicael Harer mharer@lotus.com 14. Steve Hole steve.hole@esys.ca 15. Anders Klemets andersk@microsoft.com 16. Anders Kristensen ak@hplb.hp.com 17. Hans Lachman lackman@netscape.com 18. Don Lavange dlavange@novell.com 19. Laurence Lundblade lgl@qualcomm.com 20. Ingrid Melve ingrid.melve@uuninett.no 21. Chis Newman chris.newman@innosoft.com 22. Jacob Palme jpalme@dsv.su.se 23. Glenn Parsons glenn.parsons@nortel.com 24. Pete Resnick presnick@qualcomm.com 25. Nick Shelness shelness@lotus.com 26. John-Paul Sicotte john-paul.scicotte@esys.ca 27. Einar Stefferud stef@nma.com 28. Kunihiro Taniguchi taniguchi@ccrl.sj.nec.com 29. Edwin Van Tricht e.vantricht@research.kpn.com 30. Jon-Olov Vatn vatn@it.kth.se 31. Hirosi Wakai wakai@slab.tnr.sharp.co.jp 32. Lawrence Wilcock lw@hplb.hp.com END of MHTML Minutes from Meeting at IETF-41 in Los Angeles.