Received: from ietf.org by ietf.org id aa24733; 16 Aug 96 14:08 EDT Received: from cnri by ietf.org id aa24729; 16 Aug 96 14:08 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa11449; 16 Aug 96 14:08 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id NAA13584; Fri, 16 Aug 1996 13:57:20 -0400 Received: from moon.nbn.com (MOON.NBN.COM [199.4.65.1]) by list.cren.net (8.6.12/8.6.12) with ESMTP id NAA13558 for ; Fri, 16 Aug 1996 13:56:57 -0400 Received: from candle.brasslantern.com (annex1-2.diego.netmanage.com [156.27.60.164]) by moon.nbn.com (8.7.3/8.7.3) with ESMTP id KAA02134 for ; Fri, 16 Aug 1996 10:56:54 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.6.12/8.6.12) id KAA24721 for ietf-822@list.cren.net; Fri, 16 Aug 1996 10:58:47 -0700 Message-Id: <960816105847.ZM24720@candle.brasslantern.com> Date: Fri, 16 Aug 1996 10:58:46 -0700 Reply-To: schaefer@nbn.com X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Bart Schaefer To: ietf-822@list.cren.net Subject: Re: MIME implementation documentation In-Reply-To: Dave Crocker "Re: MIME implementation documentation" (Aug 16, 8:12am) References: "Your message dated Fri 16 Aug 1996 05:47:51 -0400 (EDT)" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Z-Mail (4.0b.729 29jul96) X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN On Aug 16, 8:12am, Dave Crocker wrote: } Subject: Re: MIME implementation documentation } } demonstration is fine. on the other hand, MIME ain't new and a lack of } implementation in production systems by now is not a good sign. no? In addition to the receiving implementations Ned has mentioned, I believe Ishmail has a UI for constructing multipart/alternative, and is therefore hopefully able to display it rationally on receipt. I haven't looked at Ishmail for several months, though. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.nbn.com/people/lantern New male in /home/schaefer: >N 2 Justin William Schaefer Sat May 11 03:43 53/4040 "Happy Birthday"   Received: from ietf.org by ietf.org id aa27147; 16 Aug 96 15:09 EDT Received: from cnri by ietf.org id aa27143; 16 Aug 96 15:09 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa12459; 16 Aug 96 15:09 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id PAA14624; Fri, 16 Aug 1996 15:01:45 -0400 Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by list.cren.net (8.6.12/8.6.12) with ESMTP id PAA14609 for ; Fri, 16 Aug 1996 15:01:30 -0400 Received: from elbonia.innosoft.com ("port 33691"@ELBONIA.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.0-7 #8694) id <01I8CCQN36L68Y51R2@INNOSOFT.COM> for ietf-822@list.cren.net; Fri, 16 Aug 1996 12:00:37 -0700 (PDT) Message-Id: Date: Fri, 16 Aug 1996 12:00:52 -0700 (PDT) X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Chris Newman To: ietf-822@list.cren.net Subject: Re: MIME implementation documentation MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN Since 4-6 interoperable implementations of multipart/alternative have been identified on this list, I think it is certainly ready for draft status. As for multipart/parallel, the only implementation I know of is metamail. Were it to be "excised", the obvious place for the text would be in the IANA media type registry.   Received: from ietf.org by ietf.org id aa05198; 16 Aug 96 19:52 EDT Received: from cnri by ietf.org id aa05194; 16 Aug 96 19:52 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa16220; 16 Aug 96 19:52 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id TAA23307; Fri, 16 Aug 1996 19:44:52 -0400 Received: from ng.netgate.net (root@ng.netgate.net [204.145.147.10]) by list.cren.net (8.6.12/8.6.12) with ESMTP id TAA23284 for ; Fri, 16 Aug 1996 19:44:27 -0400 Received: from [205.214.160.106] (d78.netgate.net [205.214.160.114]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id QAA19758 for ; Fri, 16 Aug 1996 16:50:29 -0700 (PDT) Message-Id: Date: Fri, 16 Aug 1996 16:43:48 -0700 X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Dave Crocker To: ietf-822@list.cren.net Subject: Re: MIME implementation documentation In-Reply-To: <01I8CJGV6XIU8Y507E@INNOSOFT.COM> References: "Your message dated Fri, 16 Aug 1996 13:38:23 -0400 (EDT)" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Sender: dcrocker@ng.netgate.net X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN At 3:10 PM -0700 8/16/96, Ned Freed wrote: >So that's three MUAs producing multipart/alternative. I respectively submit to one an all that the question of /alternative is now answered and the topic closed. I think it was dandy to raise the question, but it is well and truly laid to rest. /parallel seems to be a different matter? d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org   Received: from ietf.org by ietf.org id aa05331; 17 Aug 96 22:00 EDT Received: from cnri by ietf.org id aa05327; 17 Aug 96 22:00 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa13023; 17 Aug 96 22:00 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id VAA06393; Sat, 17 Aug 1996 21:52:58 -0400 Received: from domen.uninett.no (domen.uninett.no [129.241.131.10]) by list.cren.net (8.6.12/8.6.12) with SMTP id VAA06356 for ; Sat, 17 Aug 1996 21:52:33 -0400 Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) id <23916-0@domen.uninett.no>; Sat, 17 Aug 1996 09:36:12 +0200 Message-Id: <23913.840267370@domen.uninett.no> Date: Sat, 17 Aug 1996 09:36:10 +0200 X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Harald.T.Alvestrand@uninett.no To: ietf-822@list.cren.net Cc: moore@cs.utk.edu Subject: Re: MIME implementation documentation In-Reply-To: Your message of "Fri, 16 Aug 1996 15:10:43 PDT." <01I8CJGV6XIU8Y507E@INNOSOFT.COM> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <23909.840267369.0@domen.uninett.no> X-Sender: Harald.T.Alvestrand@uninett.no X-Mailer: exmh version 1.6.7 5/3/96 X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23909.840267369.1@domen.uninett.no> When in doubt, write a Web page.... I have written up a Web page for the Last Call on http://domen.uninett.no/apps/last-call/mime-draft2.html and attached a text version to this document. Given the debate that has occured, I regard the question of multipart/alternative as settled, while there is still missing evidence for multipart/parallel, generation of nested body parts and handling of external body parts. When new evidence arrives (on this list, please!), I will update the Web page. Harald T. Alvestrand Apps AD ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23909.840267369.2@domen.uninett.no> LAST CALL FOR MIME DOCUMENTS TO RECYCLE AT DRAFT The following Last Call has been issued: The IESG has received a request to consider the following Protocol Actions: 1. Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies" for the status of Draft Standard. 2. Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types for the status of Draft Standard. 3. MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text for the status of Best Current Practice. 5. Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples for the status of Draft Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by August 8, 1996. No objections to the Last Call were received before August 8. After the timeout date for the Last Call comments, the following issues with regard to implementation experience have been raised: * Is multipart/alternative widely implemented for generation? * Is multipart/alternative widely implemented for reception? * Is multipart/parallel widely implemented? * Are Nested Body Parts widely implemented? * Are External Body Parts widely implemented? The issue here is if the "two implementations" rule (which traditionally have allowed two experimental implementations without terribly useful user interfaces) should be strengthened for a specification of this maturity to mean "two interworking, commercial implementations that can be used by someone not terribly skilled in the arcana of MIME". The sections below will give the arguments and evidence in each case. Is multipart/alternative widely implemented for generation? The question is if there exist MUAs that can generate a MIME multipart/alternative without excessive thinking on the part of the user. The following MIME UAs have been claimed to do so: * Cyberdog for the Macintosh * Ishmail * An yet-unnamed product from Microsoft This AD regards the question as settled. Is multipart/alternative widely implemented for reception? The question is if there exist UAs that display the "best" body part (that being defined as the last part of the multipart/alternative that the UA is able to display). The following UAs have been claimed to do so: * Pine * Metamail * Mac Eudora 3.0 This AD regards the question as settled. Is multipart/parallel widely implemented? The question is if there are UAs that display all parts of the multipart/parallel "at the same time", as described in the drafts, and do not jsut treat it like multipart/mixed, and if there are generating UAs. To date, no generating UA has been identified. To date, only Metamail has been mentioned as an example of a displayer. Are Nested Body Parts widely implemented? Many MUAs work according to the "one message with attachments" metaphor, which is not the same as the MIME "bodyparts may nest to any level" structure. Forwarded messages are not part of this question. One may argue that the "inline/attachment" distinction that is carried in content-disposition is missing functionality in MIME. However, content-disposition is the subject of another ongoing action, and will have to catch up later. The question is if there exist MUAs that: 1. Generate nested multiparts through a reasonable user interface 2. Usefully display nested multiparts The following MUAs have reasonable support for generating nested multiparts: * The following MUAs have reasonable support for displaying nested multiparts: * EXMH 1.6.7 Are External Body Parts widely implemented? The question is if there exist MUAs that: 1. Generate External Body Parts through a reasonable user interface 2. Usefully handle External Body Parts The IETF internet-drafts announcement uses multipart/alternative with external body parts to list the ways in which one can get the I-Ds. This is special purpose code, and only proves that such messages can be generated. The following MUAs have reasonable support for generating External Body Parts: * The following MUAs have reasonable support for handling External Body Parts: * MH 6.8.3 _________________________________________________________________ Harald.T.Alvestrand@uninett.no Last modified: Sat Aug 17 09:32:26 1996 ------- =_aaaaaaaaaa0--   Received: from ietf.org by ietf.org id aa13946; 18 Aug 96 1:03 EDT Received: from cnri by ietf.org id aa13942; 18 Aug 96 1:03 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa01466; 18 Aug 96 1:03 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id AAA14152; Sun, 18 Aug 1996 00:55:59 -0400 Received: from moon.nbn.com (moon.nbn.com [199.4.65.1]) by list.cren.net (8.6.12/8.6.12) with ESMTP id AAA14132 for ; Sun, 18 Aug 1996 00:55:33 -0400 Received: from candle.brasslantern.com (srf-70.nbn.com [199.4.64.70]) by moon.nbn.com (8.7.3/8.7.3) with ESMTP id VAA19177; Sat, 17 Aug 1996 21:55:19 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.6.12/8.6.12) id VAA20698; Sat, 17 Aug 1996 21:57:21 -0700 Message-Id: <960817215720.ZM20697@candle.brasslantern.com> Date: Sat, 17 Aug 1996 21:57:20 -0700 Reply-To: schaefer@nbn.com X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Bart Schaefer To: Harald.T.Alvestrand@uninett.no, ietf-822@list.cren.net Cc: moore@cs.utk.edu Subject: Re: MIME implementation documentation In-Reply-To: Harald.T.Alvestrand@uninett.no "Re: MIME implementation documentation" (Aug 17, 9:36am) References: <23913.840267370@domen.uninett.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Z-Mail (4.0b.729 29jul96) X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN On Aug 17, 9:36am, Harald.T.Alvestrand@uninett.no wrote: } Subject: Re: MIME implementation documentation } } Are Nested Body Parts widely implemented? Do the various multipart/security extensions count as nested body parts for this purpose? } The question is if there exist MUAs that: } 1. Generate nested multiparts through a reasonable user interface } 2. Usefully display nested multiparts } } The following MUAs have reasonable support for generating nested } multiparts: } * Ishmail. The "Add Container" menu item. } The following MUAs have reasonable support for displaying nested } multiparts: } * EXMH 1.6.7 Metamail. Or does it not count? Ishmail, I'm fairly sure. Is anybody from HaL on this list? Z-Mail does provide for display of nested body parts, but it does so by invoking metamail for the second nesting level and beyond. I'd be willing to bet that there are IMAP4 clients very near release that support this; certainly any IMAP4 server has the ability to parse a nested MIME structure and present it to clients. } Are External Body Parts widely implemented? } } The question is if there exist MUAs that: } 1. Generate External Body Parts through a reasonable user interface } 2. Usefully handle External Body Parts Are special cases included? MediaMail (Z-Mail as bundled with IRIX 5/6) and the forthcoming Z-Mail 4.0 for Unix both generate a special "removed by recipient" external body part to preserve the MIME body structure when a user requests that an individual body part be deleted from a message. However, such messages would never be sent to another UA unless forwarded. Also, the "reassembler" agent included with MediaMail, whose primary purpose is to automatically collect message/partial sections and rebuild the single original message, will strip out attachments larger than a specified threshold and replace them with a message/external-body with access-type=local-file. This all happens without any user interface at all (except one button click to install the reassembler, and a file to edit if you want to change the stripping threshold). MediaMail and Z-Mail both "usefully handle" these cases for display, and can be programmed to handle other external types (the default setup is to invoke metamail for most access-types). } The following MUAs have reasonable support for generating External } Body Parts: } * Is the "reassembler" agent an MUA? } The following MUAs have reasonable support for handling External Body } Parts: } * MH 6.8.3 Metamail. Z-Mail with the caveats noted above. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.nbn.com/people/lantern New male in /home/schaefer: >N 2 Justin William Schaefer Sat May 11 03:43 53/4040 "Happy Birthday"   Received: from ietf.org by ietf.org id aa17165; 19 Aug 96 14:54 EDT Received: from cnri by ietf.org id aa17161; 19 Aug 96 14:54 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa12315; 19 Aug 96 14:54 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id OAA10197; Mon, 19 Aug 1996 14:45:30 -0400 Received: from nugget.scr.atm.com ([206.100.186.2]) by list.cren.net (8.6.12/8.6.12) with ESMTP id OAA10173 for ; Mon, 19 Aug 1996 14:45:15 -0400 Received: from mailman.scr.atm.com (mailman.scr.atm.com [206.100.186.54]) by nugget.scr.atm.com (8.6.12/8.6.9) with ESMTP id LAA11124 for ; Mon, 19 Aug 1996 11:48:59 -0700 Message-Id: <19960819182833.izzy@scr.atm.com> Date: Mon, 19 Aug 1996 11:38:06 -0700 X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: "Dr. Mark K. Joseph" To: ietf-822@list.cren.net Subject: RE: mime implementation (nested bodyparts) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_19tW07g.bO1996u.N18d000A.r08Y.38:004dc7" Content-Transfer-Encoding: 7bit X-Mailer: Emissary V2.01, by Attachmate Corp. X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN --=_19tW07g.bO1996u.N18d000A.r08Y.38:004dc7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 1. Emissary 2.0 handles the viewing of arbitrary nested bodyparts. It is different in that it does not flatten the nesting out. It shows the next level down as an icon. When the user clicks on that icon the user's entire view of that message changes to the next level down. That is we do not open up another window. The user can move up and down the message by pressing an "Up" button to move up in the message and clicking nested icons to move down. 2. Emissary usually will show all parts of a multipart/alternative except in the case where their is only a text/plan and a text/html bodyparts. Here it will just show the text/html. In showing the user all the bodyparts we put up a small notice telling the user what is going on. We chose this approach because on a PC there is no way for the mail/web client to know of all the installed viewer software the user may have. So if we don't have a built in viewer the user can select some other program he knows of. 3. We automatically generate nested multipart/mixed messages for forwarded messages. We preserve all content-types of a forwarded message, so if it contains a multipart/alternative then we perserve that, but we do not generate mutlipart/alternative, parellel, or disgest by ourselves. 4. We also translate ALL message/external bodyparts into clickable URLs, including mail-server. With a mail-server we generate a mailto WITH parameters. This way the body of the message, as well as its subject can be automatically set by the mailto. We however, show the generated message to the user before we send it out so that he can decide what to do with it. 5. And contrary to what the Netscape Web pages says today Emissary also has full HTML support in its mail and news clients. In fact we had this support way before Netscape had it. In addition, we fully support MULTIPART/RELATED with "cid:" links from a text/html bodypart to bodyparts inside the same message for images and all embedded objects (e.g., gifs, word documents). Such a message can be composed by grabbing a page off the web or from scratch in the compose window. The Emissary mail compose window is a full HTML editor. --=_19tW07g.bO1996u.N18d000A.r08Y.38:004dc7 Content-Type: application/octet-stream; name="MJOSEPH.VCF" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="MJOSEPH.VCF" Content-Description: The Sender's Signature QkVHSU46VkNBUkQNCk5PVEU6IHZDYXJkIEZvcm1hdDogVmVyc2lvbiAyLjAoU3BlYy00LzI5Lzk2 KQ0KUkVWOjE5OTYtMDgtMDdUMTg6MzQ6MDZaDQpOOkpvc2VwaDtNYXJrDQpFbWlzc2FyeUEuRk46 TWFyayBLLiBKb3NlcGgsIFBoLkQuDQpNQUlMRVI6RW1pc3NhcnkgMi4wMQ0KRU1BSUw7d29yaztw cmVmO2ludGVybmV0Oml6enlAc2NyLmF0bS5jb20NCkVNQUlMO2hvbWU7aW50ZXJuZXQ6bWFya2pv c2VwaEBkZWxwaGkuY29tDQpURUw7V09SSztQUkVGO01TRzooNDA4KSA0NzEgLSAzMDE2DQpURUw7 V09SSztGQVg6KDQwOCkgNDcxIC0gMzAxMA0KVEVMO0hPTUU7RkFYO01TRzooNDA4KSA0NzUgLSA4 ODA1DQpUWjotMDgwMA0KT1JHOkF0dGFjaG1hdGUgQ29ycG9yYXRpb247SW50ZXJuZXQgUHJvZHVj dHMgR3JvdXANClRJVExFOlNvZnR3YXJlIEFyY2hpdGVjdA0KTE9HTztCQVNFNjQ7Z2lmOg0KUjBs R09EbGh1UUF3QVBjQUFQLy8vKy92NytmbjU5N2UzdGJXMXM3T3pzYkd4cjI5dmEydHJhV2xwWnlj bkpTVWxJeU1qSVNFaEh0Nw0KZTNOemMydHJhMk5qWTFwYVdsSlNVa3BLU2tKQ1FqazVPVEV4TVNr cEtTRWhJUmdZR0JBUUVBZ0lDT2ZlMW9SN2MyTmFVakVwSWUvbg0KM3M3R3ZhMmxuSXlFZTBwQ09h V2NqSnlVaEwydGpGcFNRb3g3V250clNoZ1FBTmJHbk02OWxNYTFqTy9XbEpTRVd0YTllOGF0YTN0 cg0KUXEyVVVxV01TcFI3T1lScktUa3BBS1djaElSN1krL2VyZWZXcGEyY2E2V1VZNHg3U3B5RVFz YWxTcjJjUW1OU0liV1VPWXh6S2FXRQ0KS1lScklaeDdJZSs5S1VvNUNHdFNDTWFVQUtWN0FGcENB UC8zM3Uvbnp0N1d2ZGJPdGIyMW5LMmxqSlNNYzR5RWEvL3Z2WHR6V25Ocg0KVW10alN1ZlduTDJ0 ZS8vbm5GSktNZS9XaEVwQ0thV1VXdWZPZTg2MVk4YXRXb1J6T1hOak1lL09ZOWExU3FXTU9mZk9V akVwRU1hbA0KT2UvR1FwUjdLVnBLR0wyY01kNjFPZWU5TWZmR01kYXRLYTJNSWM2bEllKzlJYjJV R01hY0dPKzlHTWFjRU5hbEVKUnpDTFdNQ0syRQ0KQ042dENOYWxBSXhyQUd0U0FFbzVBTWE5bkxX bGE5YTlZNzJsVXZmV1kzdHJNYldjUW5OaktlZkdVdS9PVXQ2OVN1ZkdTcHlFTWRhMQ0KUXQ2OVFx V01NYzZ0T2ZmT1F0YTFPWnlFS2NhbE1lL0dPYzZ0TWIyY0tkNjFLVnBLRUwyY0llL0dLWXh6R05h dEliV1VHTjYxR0ZKQw0KQ0syTUVOYXRFTys5RUwyVUNNNmxDTys5Q09lMUNPKzlBT2UxQU42dEFM MlVBTFdNQUp4N0FKUnpBSE5hQU43V3RiMjFsSzJsaFAvdg0KcllSN1V1ZldqTTY5YzhhMWEvZmVl Mk5hTWUvV2M1eU1TdmZlYzZXVVN1Zk9ZOWE5VW94N01jYXRRdS9PU29SekthMlVLZS9HSVl4eg0K RU9lOUdONjFFSVJyQ042MUNOYXRBTTZsQUlSckFIdGpBQ2toQVAvM3p1L252ZGJPcGJXdGhON09o TmJHZTdXbFdzNjlZMUpLSVhOag0KR0wyMWhLV2NhL2Zuak43T2MwSTVDTWJHdmYvLzc5N2V6c2JH dGJXMXBlZm56cFNVaEVwS1F0Yld2Y2JHcmIyOXBZU0VjMnRyV3BTVQ0KZTFwYVNudDdZMUpTUW1O alNrSkNNVnBhUWlFaEdFSkNLVGs1SVJnWUNCQVFBQWdJQUFBQUFDd0FBQUFBdVFBd0FBQUkvd0FC Q0J4SQ0Kc0tEQmd3Z1RLbHpJc0tIRGh4QWpTcHhJc2FMRml4Z3phdHpJc2FQSGp5QkRpaHhKc3FU Smt5aFRxbHpKc3FYTGx6Qmp5cHhKczZiTg0KaHhIKzZkeVo0V2JCblR0OTNnUUsxQ0RSZnorSmxq eDYwNEpTbUFHTzZrU1F0Q2hCcGlTeDFxenc5T1VFcWY4MlZBMTZ0YXRJclRTNQ0KV24wSlZ1ZFl0 MlhYbmpVNzA2bmNrd2NJUm0xTEZjQ0JBMGNOL0JWODlDOEJ2UTNVNnF5Z0lDRUN1LzhxcEh1TEZF RE9meGthRHh6OA0KTjREQUJ6b3ZGQ0E0UU8yRnZnVUxSTWdBZElLQnpRY3VFQjFjY01EWHhZYzM1 aDBvdTIxbDM4QXJDQVRzZTBKQkIyMGpERHhhUUtwbg0KQUVRTklEZ3FGc0FHcVFSQisyNE1mT0FB dmgrQi8vOFdEMWI0ZFBFUEJsNzNYWjA4WEtMSXBWWllUMTJnWXQvZmZRdFVBUHhDeC93Nw0KT2NB QVVkeTVkNVJ3QmdwMFczRFF1VmVnZ1dBSkJLRit6YUhIVVc5a2FZVldnM0pwK05SUkZ6UkFYMUFH aWpVaFdBcndCNVIvQUFpQQ0KMVgyVlNValVBQUtOR0dOR1dIbDRGMW9POU5qamJod0dkZGxPeHNr SVZEb2cxc2hVZlVIdTVOOWVRRWx3UUFOVVVoa1hXWkRCQlVDRg0KT3dIWlpKRVljYW1UQnZZUnhZ Q1JaQzFIVjBFSFFJQWRXZ3BVSUtlY0tuYW9sRmJFclJYZlRzSVpsTTZDVnNFNEVJeWM1Wm5tUmF3 Qg0KMVJjQk9kSzFZUUUydnJrbVpWZTZoUmFlUlBWWnAzNEFaQm5qaEJwZCtxR2paa1VhNFlaR21i V2txbDBaUUpRRlRYTC9LaWlhNUdWMA0Kbm52cGJhZ1ZqRHhoYU9ta2xkNjRxcDFyR1JwWlc3N0M1 YW1hQ1dKa3FuNjZkcFVrclVqQm1hbW9SV0dicHJHZS91TUFzMlRCT0JvQQ0KeVdZRjZsRVovRVh0 QXdhSXFXV3NsaEhWRTdXYnZqdnNvVnE1MmgyNHloSzF3ViszaGtiUW5ITmlGREN1YlZHN1dHQUNK VHZldGZmYQ0KZXllcnhZcjNISFlBOFBvclVCa0k0TzQvQ1dTc2t3TVZmQWVSamY4ZUlKaktrV3I4 TU1UdWZVWmVyaFNUV0xPV3hyb2NJUUI3S21Wcw0Kd3ZieG5JRUdOekowbEdZRTFmdVBpeGhyWE1H QVlObElvOGkrc2FqdHh2aTJtcW5EUU1jS2w5Sm9DZWVBYlVVcnBEUkNSMFhRYzVxSg0KQWlXY2R2 QTFXZDJXYlFGNWRiVTN4NWd6dVZJVi8xQ3ZjZ0FjckdVQXp3SStVSHFhOVNrVUFoQlU0TUM0RFNG QXNnT294Y1FBQlJNMA0KOE54RkIweCtwbENnaHk3NjZLU1hidnJwcUtldXVrUUJTT0JqajQwVjRN RGNFZm5vNWVna3o3dTZRaGZRK0U5Nml2K0RBVVZSVGIyUQ0KdDB0QmZ0QUdmU3B1MFFGZ3prUlZj d0o5RHQxb3R3TXdRUFlFNWFUWGM3Y1hUU1AzcjVFMm5FRUZlRWs5UXMwaERRR2JCdVZHQVBnLw0K WmE0OFFSNFR0SnNCbS9zbGtQRVlrVTFCcG1NZEFRb2tLZ0dZWFVMQ01wQ2NSQ0FDMHdGU1RzcFhn QXhVUURhN0tkNzZBS0FBMWlnQQ0KT1Ezd0RsSXUrTDhOWktCOFJ0RmRRVGF3Z0l5aDVqb0d1TUJY QmdBYXhRRkdRb1lEUUFhKzlRL3JDVEFEM2dOQUFQOUE0eG5rNGNoNQ0KMXNtQWZ4cndxY1lRYllG SWk4b0NBbUN5NVJnT09STUl3RzdXeDVXQk5JZHkwTm5jUDN5bnUzOVVManRscTFGMVhDV1FrUDNE T0JpNA0KZ0hMK0Fia0JDY1NDeTJsTVZBWXlnUVQ4Z3dQUTZWTlBRSmF4amZ3ak4ycFNVdlgrY1FB TklERnBONHJLdHk1QXUzLzBEek5YMGVNLw0Ka0FZZC80Q0dqLzlJeHdZTXQwR0RkUEVnUzFOUWpB WWtnQVp4VUZqcGdjNzdSQ2Fqc2tqb2tpR2tuVVdDNkVWTFNpaHhhVXdLUWI0aQ0KSWIvdEJ5bFRL eVVCNHlYRVkwcm9BWnA1VjhOOGVSRGtER3c1eXdsZVQ3N2p1d2xBcmpKVmhFNWpaTE1BcEcwU0FI YThTZ05paVNOZA0KWm1BREF5Q0FBMWowU2lvT0QyM3NoTTZadmlPcWdlZklabTZVSkFoeUNuQUIw QUJTUW4zYTVMaThkd0REL1k2ZVJ1a1RRYkZwbVVyZQ0KOFRmcENOa3JmN2tjQjVCcGs4L2hEMElo MnNQN1ZZUUNQWXBlQXdhZ2dBdmNUa1JuSElnQUlyQk8xSVN3UlJuWW5BTnl1TktmZktzQg0KS2xV UEFGZmpKUTE4U3lHWHllTEFYRXFhb3phZ2xkYUJhaUNaMXo4NTNYRnpDK2pMRG45eTA5MTU5WGo5 czhnQUlQclZzaFlrSjJHVg0KeUhjQ1FGYXp1cFVqQndEZ1crZEsxN3FXTlNBQU93PT0NCg0KVVJM Omh0dHA6Ly93d3cuYXRtLmNvbQ0KTEFCRUw7V09SSztQQVJDRUw7UE9TVEFMO0RPTTtRVU9URUQt UFJJTlRBQkxFOjE0MCBEdSBCb2lzIFN0cmVldCwgU3VpdGUgQz0wQT0NClNhbnRhIENydXosIENB IDk1MDYwDQpFTkQ6VkNBUkQNCg== --=_19tW07g.bO1996u.N18d000A.r08Y.38:004dc7--   Received: from ietf.org by ietf.org id aa23918; 19 Aug 96 19:43 EDT Received: from cnri by ietf.org id aa23913; 19 Aug 96 19:43 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa21612; 19 Aug 96 19:43 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id TAA21375; Mon, 19 Aug 1996 19:37:23 -0400 Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by list.cren.net (8.6.12/8.6.12) with ESMTP id TAA21357 for ; Mon, 19 Aug 1996 19:37:00 -0400 Received: from elbonia.innosoft.com ("port 34319"@ELBONIA.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.0-7 #8694) id <01I8GT837H1O8Y53VT@INNOSOFT.COM>; Mon, 19 Aug 1996 16:35:59 -0700 (PDT) Message-Id: Date: Mon, 19 Aug 1996 16:36:15 -0700 (PDT) X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Chris Newman To: Harald.T.Alvestrand@uninett.no, ietf-822@list.cren.net, moore@cs.utk.edu Subject: Re: MIME implementation documentation MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN I believe Pine and IMAP4 servers (I know of at least 4 independant implementations) are examples of handling nested multiparts on the client side. Pine numbers the parts in such a way that the nested structure is clearly visible to the user. IMAP4 parses the MIME message into a hierarchical structure which preserves the nested represntation. I am curious what will happen if the IESG rules that there isn't enough support for generation of arbitrary nested multiparts through a reasonable user interface. The nesting structure of MIME is widely used, although it is usually used for special purpose sub-structure (multipart/appledouble, message/rfc822, multipart/security, etc) rather than general purpose hierarchy (although there seems to be plenty of support for displaying general purpose hierarchy in messages). As for multipart/parallel, it does not seem to be widely implemented, nor does it seem to be an important part of the spec. One reasonable option would be to remove the text from the spec and place it in the IANA media type registry.   Received: from ietf.org by ietf.org id aa17543; 20 Aug 96 12:13 EDT Received: from cnri by ietf.org id aa17539; 20 Aug 96 12:13 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa09364; 20 Aug 96 12:13 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id MAA10326; Tue, 20 Aug 1996 12:02:44 -0400 Received: from domen.uninett.no (domen.uninett.no [129.241.131.10]) by list.cren.net (8.6.12/8.6.12) with SMTP id EAA05203 for ; Tue, 20 Aug 1996 04:38:38 -0400 Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) id <26215-0@domen.uninett.no>; Tue, 20 Aug 1996 10:38:37 +0200 Message-Id: <26212.840530314@domen.uninett.no> Date: Tue, 20 Aug 1996 10:38:34 +0200 X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Harald.T.Alvestrand@uninett.no To: ietf-822@list.cren.net Cc: ned@innosoft.com, moore@cs.utk.edu Subject: The MIME debate - my conclusions Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: Harald.T.Alvestrand@uninett.no X-Mailer: exmh version 1.6.7 5/3/96 X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN I have reached the following preliminary conclusion, based on the evidence collected in the Web page http://www.apps.ietf.org/apps/last-call/mime-draft2.html: - Multipart/alternative is implemented. - Nested Body Parts are implemented. - External Body Parts are implemented. - Multipart/parallel is NOT implemented. The evidence is a little weak on programs to generate nested body parts, and on programs that generate EBPs that are not FTP; I will not pursue this matter further at this time. Based on this, I will recommend the following to the IESG: - The current MIME drafts are accepted for Draft Standard - The RFC-Editor is instructed to delete all reference to multipart/parallel from draft-ietf-822ext-mime-imt-05.txt RFC 1521 will remain the definition of that body part. Comments must be in before Thursday morning if they are to be heard before the IESG meets! Harald A   Received: from ietf.org by ietf.org id aa08237; 21 Aug 96 1:50 EDT Received: from cnri by ietf.org id aa08233; 21 Aug 96 1:50 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa01971; 21 Aug 96 1:50 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id BAA16446; Wed, 21 Aug 1996 01:42:40 -0400 Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by list.cren.net (8.6.12/8.6.12) with ESMTP id BAA16427 for ; Wed, 21 Aug 1996 01:42:15 -0400 Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.0-7 #8694) id <01I8IJ8OIWXS8Y5617@INNOSOFT.COM>; Tue, 20 Aug 1996 22:42:15 -0700 (PDT) Message-Id: <01I8IKBIZN0E8Y5617@INNOSOFT.COM> Date: Tue, 20 Aug 1996 22:33:57 -0700 (PDT) X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Ned Freed To: Harald.T.Alvestrand@uninett.no, ietf-822@list.cren.net, moore@cs.utk.edu Subject: Re: MIME implementation documentation In-Reply-To: "Your message dated Mon, 19 Aug 1996 16:36:15 -0700 (PDT)" MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN > I believe Pine and IMAP4 servers (I know of at least 4 independant > implementations) are examples of handling nested multiparts on the client > side. Pine numbers the parts in such a way that the nested structure is > clearly visible to the user. IMAP4 parses the MIME message into a > hierarchical structure which preserves the nested represntation. PMDF MAIL does this as well. So do the various DEC MailWorks clients, and while they don't support MIME directly they support it just fine indirectly through our MIME-->Message Router gateway. Message Router is one of the few non-MIME environments around that actually handles nested structures reasonably and completely, even when you nest them very deeply. (Please don't try to tell me that X.400 agents generally support this too, as I have way to many experiences with X.400 MTAs that fall over dead when presented with nested messages to believe it.) There's also ALL-IN-1, which again doesn't support MIME directly but does support it indirectly through both our gateway as well as those of several other vendors. And ALL-IN-1 has to be the heaviest user of part nesting anywhere -- it routinely generates three levels just for what it regards as a simple attachment, and this quickly multiplies when you reply or worse, forward and add a cover note. I've seen casual ALL-IN-1 users produce MIME structures 20 or more levels deep with no effort at all, and heaven help the non-ALL-IN-1 user who has to deal with such messes. (Support is one thing, presenting suc complex objects so that casual users can deal with them is quite another. I've also seen these structure blow some agents out of the water, but plenty of others handle such things very nicely.) Ned   Received: from ietf.org by ietf.org id aa09917; 15 Aug 96 11:28 EDT Received: from cnri by ietf.org id aa09912; 15 Aug 96 11:28 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa08738; 15 Aug 96 11:28 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id LAA27106; Thu, 15 Aug 1996 11:21:25 -0400 Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by list.cren.net (8.6.12/8.6.12) with ESMTP id LAA27021 for ; Thu, 15 Aug 1996 11:20:53 -0400 Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.0-7 #8694) id <01I8AQ9J8S288Y513Y@INNOSOFT.COM>; Thu, 15 Aug 1996 08:20:47 -0700 (PDT) Message-Id: <01I8AQRQPUT48Y513Y@INNOSOFT.COM> Date: Thu, 15 Aug 1996 08:17:25 -0700 (PDT) X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Ned Freed To: Harald.T.Alvestrand@uninett.no Cc: ietf-822@list.cren.net Subject: Re: MIME implementation documentation In-Reply-To: "Your message dated Thu, 15 Aug 1996 13:28:57 +0200" <25999.840108537@domen.uninett.no> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN > just as a formality, I'll need someone to stand up and say that they have > products implementing MIME according to the new documents. Our PMDF MAIL user agent implements MIME per the specification. (So does the version of Pine we ship, but it is not really any different than UW Pine in this regard.) We also implement MIME handling as part of our various LAN email, X.400, MR, and SNADS gateways, but I'm not entirely sure that these really count as MIME user agent implementations. > If they're prepared to say that they implement all functionality in the > documents completely, I'd be even happier. > (Are there two interoperable implementations of c-t-e: Binary?) There are probably more implementatons of CTE binary than any other CTE besides 7bit. Ever heard of Web browsers? Ned   Received: from ietf.org by ietf.org id ab02086; 16 Aug 96 0:24 EDT Received: from cnri by ietf.org id aa02068; 16 Aug 96 0:24 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa01207; 16 Aug 96 0:24 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id AAA21516; Fri, 16 Aug 1996 00:12:29 -0400 Received: from a4.jck.com (ns.jck.com [206.99.215.40]) by list.cren.net (8.6.12/8.6.12) with ESMTP id AAA21458 for ; Fri, 16 Aug 1996 00:11:19 -0400 Received: from white-box.jck.com ("port 2283"@white-box.jck.com) by a4.jck.com (PMDF V5.0-5 #16053) id <0DW7QAKW9006UB@a4.jck.com>; Fri, 16 Aug 1996 00:11 -0400 (EDT) Message-Id: Date: Fri, 16 Aug 1996 00:11:05 -0400 (EDT) Reply-To: John C Klensin X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: John C Klensin To: Ned Freed Cc: ietf-822@list.cren.net, Harald.T.Alvestrand@uninett.no Subject: Re: MIME implementation documentation MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-Sender: john@mail1.reston.mci.net X-Mailer: Simeon for Windows Version 4.1a5 X-Authentication: none X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN On Thu, 15 Aug 1996 08:17:25 -0700 (PDT) Ned Freed wrote: > > just as a formality, I'll need someone to stand up and say that they have > > products implementing MIME according to the new documents. > > Our PMDF MAIL user agent implements MIME per the specification. (So does the > version of Pine we ship, but it is not really any different than UW Pine in > this regard.) Consider these philosophical questions, rather than a complaint or objection, but: * Does "having an implementation" as IETF is prone to define it, imply that there are mechanisms to create specified relevant forms as well as reading them? * Should one consider a particular MUA to be an "implementation" if it provides sufficient facility that a user can carefully hand-edit an outgoing message into conformity to a particular form or option? * Do we consider that some form is "implemented" if, e.g., the "default if you don't recognize" option is taken? For example, if few MUAs actually support receipt of multipart/alternative with tables of preferences rather than treating it as a variant on multipart/mixed, has "multipart/alternative" been "implemented"? Following up the question above, if the only way to create a multipart/alternative object in some MUA is to construct a multipart/mixed message, read the message (including all header and boundary information) into an editor and then change "/mixed" to "/alternative", has multipart/alternative been implemented? And so on for any number of MIME features. Harald, I don't want to derail the train here, but I think I object to the idea of removing features that have not been independently implemented (whatever that means) and used only when a document comes up for full standard. As I read the Poised docs, that step has to be taken at Draft. More important than the procedural issue, unless something comes toward full standard with very wide (and clear) community consensus about what is worthwhile and what isn't, an attempt to remove a feature at that stage could easily, and legitimately, lead to a claim that the standard without it has not been proven in the marketplace to be consistent and of adequate interest/ importance to the community. IMO, the bugs, and the questions about what functionality should be there and what should not, really ought to get worked out in going to Draft. john   Received: from ietf.org by ietf.org id aa03668; 16 Aug 96 2:50 EDT Received: from cnri by ietf.org id aa03664; 16 Aug 96 2:50 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa02784; 16 Aug 96 2:50 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id CAA24034; Fri, 16 Aug 1996 02:36:47 -0400 Received: from ng.netgate.net (root@ng.netgate.net [204.145.147.10]) by list.cren.net (8.6.12/8.6.12) with ESMTP id CAA24018 for ; Fri, 16 Aug 1996 02:36:05 -0400 Received: from [205.214.160.106] (d76.netgate.net [205.214.160.112]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id XAA04137; Thu, 15 Aug 1996 23:42:00 -0700 (PDT) Message-Id: Date: Thu, 15 Aug 1996 23:01:25 -0700 X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Dave Crocker To: John C Klensin Cc: Ned Freed , ietf-822@list.cren.net, Harald.T.Alvestrand@uninett.no Subject: Re: MIME implementation documentation In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Sender: dcrocker@ng.netgate.net X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN At 9:11 PM -0700 8/15/96, John C Klensin wrote: > * Does "having an implementation" as IETF is prone to define >it, imply that there are mechanisms to create specified relevant >forms as well as reading them? create or otherwise map different data into different mime types. yes. > * Should one consider a particular MUA to be an >"implementation" if it provides sufficient facility that a user >can carefully hand-edit an outgoing message into conformity to a >particular form or option? permit is different than require. permit them to hand-edit, sure. require it, e.g., in lieue of having the software, itself, do the work. no way. > * Do we consider that some form is "implemented" if, e.g., the >"default if you don't recognize" option is taken? For example, >if few MUAs actually support receipt of multipart/alternative >with tables of preferences rather than treating it as a variant >on multipart/mixed, has "multipart/alternative" been >"implemented"? Following up the question above, if the only way no. >And so on for any number of MIME features. > >Harald, I don't want to derail the train here, but I think I >object to the idea of removing features that have not been >independently implemented (whatever that means) and used only >when a document comes up for full standard. As I read the Yes, we need to audit functions not implemented and remove them from the spec. do you have any candidates for removal? d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org   Received: from ietf.org by ietf.org id aa05626; 16 Aug 96 3:25 EDT Received: from cnri by ietf.org id aa05622; 16 Aug 96 3:25 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa03167; 16 Aug 96 3:25 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id DAA24573; Fri, 16 Aug 1996 03:14:02 -0400 Received: from domen.uninett.no (domen.uninett.no [129.241.131.10]) by list.cren.net (8.6.12/8.6.12) with SMTP id DAA24557 for ; Fri, 16 Aug 1996 03:13:40 -0400 Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) id <09551-0@domen.uninett.no>; Fri, 16 Aug 1996 09:13:33 +0200 Message-Id: <9548.840179611@domen.uninett.no> Date: Fri, 16 Aug 1996 09:13:31 +0200 X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Harald.T.Alvestrand@uninett.no To: John C Klensin Cc: Ned Freed , ietf-822@list.cren.net Subject: Re: MIME implementation documentation In-Reply-To: Your message of "Fri, 16 Aug 1996 00:11:05 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Sender: Harald.T.Alvestrand@uninett.no X-Mailer: exmh version 1.6.7 5/3/96 X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN John, valid question. The relevant section of draft-ietf-poised95-std-proc-3-06.txt is 4.1.2 Draft Standard, which says: The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. Interestingly enough, RFC 1602 is silent on the subject of features; it was probably a needed clarification. I think I will have one question here for POISSON: Where should we document features that are NOT part of the Draft Standard, but nonetheles= s remain valid applications of the standard in question, such as body parts= in MIME that were in the current standards, but do not themselves deserve= elevation to Draft? That is, does "remove" mean "remove from specification", "move to a document with another status", or "mark as not part of the standard"? Anyway, you're right, and we need that documentation. The WG chair is responsible for gathering it, but we don't have a WG chair. Shucks, we don't even have a feature list! The IESG vote is scheduled for next week. Do we have a volunteer to do some work on this? If not, I'm strongly tempted to declare that this document was already at Draft, so we're just continuing a historical mistake..... Harald A   Received: from ietf.org by ietf.org id aa07869; 16 Aug 96 5:57 EDT Received: from cnri by ietf.org id aa07865; 16 Aug 96 5:57 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa04638; 16 Aug 96 5:56 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id FAA26127; Fri, 16 Aug 1996 05:48:24 -0400 Received: from a4.jck.com (ns.jck.com [206.99.215.40]) by list.cren.net (8.6.12/8.6.12) with ESMTP id FAA26112 for ; Fri, 16 Aug 1996 05:47:54 -0400 Received: from white-box.jck.com ("port 2026"@white-box.jck.com) by a4.jck.com (PMDF V5.0-5 #16053) id <0DW85VS9I006UB@a4.jck.com>; Fri, 16 Aug 1996 05:47 -0400 (EDT) Message-Id: Date: Fri, 16 Aug 1996 05:47:51 -0400 (EDT) Reply-To: John C Klensin X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: John C Klensin To: Dave Crocker Cc: Ned Freed , ietf-822@list.cren.net, Harald.T.Alvestrand@uninett.no Subject: Re: MIME implementation documentation MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-Mailer: Simeon for Windows Version 4.1a5 X-Authentication: none X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN On Thu, 15 Aug 1996 23:01:25 -0700 Dave Crocker wrote: > Yes, we need to audit functions not implemented and remove them > from the spec. do you have any candidates for removal? Just a hunch, based on MUAs I've looked at recently, but multipart/alternative and multipart/parallel are good starters. The only creation-implementations I know of either require either hand-fussing (e.g., editing proto-outgoing-messages from /mixed) or specialized assembly macros that are not what we normally consider MUAs (e.g., the process used to prepare the I-D announcements). The difficulty I'm having here is that I consider at least one of these to be a very valuable and important feature (which makes the question Harald asks about what we do about the stuff that we "remove" very important), but I wonder if we really have the implementations. Parallel is even worse, because I've been involved in several conversations (and imagine others have too) that question whether it really is the right design and contains the right information to permit a sender to convey adequate information to a receiver to make the thing useful. And we find that out only by implementing the thing and getting it out there widely enough to accumulate some serious operational experience. The problem here, obviously, is that coming up with an implementation of these things in the sense of some prototype- or demonstration-quality critter that can demonstrate the ability to put the right format out on the wire and then read it from the wire is trivial and uninteresting. Implementing to a level of quality needed to show actual utility -- that the feature has the right syntax and semantics to actually serve useful purpose as defined -- is, IMO, another matter and I'm not convinced that we are there yet. john   Received: from ietf.org by ietf.org id aa09526; 16 Aug 96 8:20 EDT Received: from cnri by ietf.org id aa09522; 16 Aug 96 8:20 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa06052; 16 Aug 96 8:20 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id GAA26423; Fri, 16 Aug 1996 06:26:11 -0400 Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by list.cren.net (8.6.12/8.6.12) with ESMTP id GAA26400 for ; Fri, 16 Aug 1996 06:25:51 -0400 Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.0-7 #8694) id <01I8B3US9CS08Y50ZG@INNOSOFT.COM>; Fri, 16 Aug 1996 03:24:45 -0700 (PDT) Message-Id: <01I8BUQ1R3XU8Y50ZG@INNOSOFT.COM> Date: Fri, 16 Aug 1996 03:00:06 -0700 (PDT) X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Ned Freed To: John C Klensin Cc: Dave Crocker , Ned Freed , ietf-822@list.cren.net, Harald.T.Alvestrand@uninett.no Subject: Re: MIME implementation documentation In-Reply-To: "Your message dated Fri, 16 Aug 1996 05:47:51 -0400 (EDT)" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN > On Thu, 15 Aug 1996 23:01:25 -0700 Dave Crocker > wrote: > > Yes, we need to audit functions not implemented and remove them > > from the spec. do you have any candidates for removal? > Just a hunch, based on MUAs I've looked at recently, but > multipart/alternative > and > multipart/parallel > are good starters. The only creation-implementations I know of > either require either hand-fussing (e.g., editing > proto-outgoing-messages from /mixed) or specialized assembly > macros that are not what we normally consider MUAs (e.g., the > process used to prepare the I-D announcements). I'm sorry, but I do not buy the argument that inavailability to casual users of mail user agents capable of directly building these things is in any way meaningful. (I'm also pretty sure it isn't the case -- for example, we're now providing facilities for people to complex objects of this sort in PMDF without hand editing anything.) The fact remains that there are many agents out there that build messages of this sort -- there are at least two, for example, that post multipart/alternative objects to the IETF list on a regular basis. I see nothing in the Poised requirements that says anything about ease of use, merely that multiple implementations must exist and must be able to interoperate. There are countless features and options in IETF standards intended for use primarily, if not exclusively, in an automated fashion and not directly by users. I view both multipart/alternative and multipart/parallel as features of this sort -- they are absolutely not the sort of thing people create casually -- but instead they are the sorts of things complex applications create indirectly on behalf of users. Frankly, I also see this emphasis on MUA implementation of MIME capabilities as entirely misplaced. MIME exceeded its design goals and became a general data structuring format before the first set of MIME RFCs were even out. There are now a vast array of automated applications out there that construct and send MIME objects (often not via email), receive MIME objects (often not via email), and manipulate MIME objects in increasinly complex ways. Excluding these applications from consideration as valid MIME implementations on the sending side is, in my opinion, highly inappropriate. However, I have no problem with requiring multiple MUAs that can receive and process alternative and especially parallel objects, if for no other reason than it is unclear to me what it means for an automated process to handle parallel objects "correctly". But we have multiple interoperating implementations of both of these before the MIME RFCs first came out, so this at least is a complete non-issue for us at this time. > The problem here, obviously, is that coming up with an > implementation of these things in the sense of some prototype- > or demonstration-quality critter that can demonstrate the > ability to put the right format out on the wire and then read it > from the wire is trivial and uninteresting. Implementing to a > level of quality needed to show actual utility -- that the > feature has the right syntax and semantics to actually serve > useful purpose as defined -- is, IMO, another matter and I'm not > convinced that we are there yet. Perhaps we aren't, but it seems to me that you are reading an awful lot into the proposed-->draft step of the process. Ned   Received: from ietf.org by ietf.org id aa17123; 16 Aug 96 10:56 EDT Received: from cnri by ietf.org id aa17119; 16 Aug 96 10:56 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa08211; 16 Aug 96 10:56 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id KAA04361; Fri, 16 Aug 1996 10:46:23 -0400 Received: from glaucus.cso.uiuc.edu (glaucus.cso.uiuc.edu [128.174.81.2]) by list.cren.net (8.6.12/8.6.12) with SMTP id KAA04075 for ; Fri, 16 Aug 1996 10:45:07 -0400 Received: from resnick1.isdn.uiuc.edu by glaucus.cso.uiuc.edu (AIX 3.2/UCB 5.64/4.03) id AA10211; Fri, 16 Aug 1996 09:40:39 -0500 Message-Id: Date: Fri, 16 Aug 1996 09:43:55 -0500 X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Pete Resnick To: John C Klensin Cc: Dave Crocker , Ned Freed , ietf-822@list.cren.net, Harald.T.Alvestrand@uninett.no Subject: Re: MIME implementation documentation In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: resnick@glaucus.cso.uiuc.edu X-Mailer: Eudora [Macintosh version 3.0] X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN On 8/16/96 at 4:47 AM -0500, John C Klensin wrote: >On Thu, 15 Aug 1996 23:01:25 -0700 Dave Crocker > wrote: >> Yes, we need to audit functions not implemented and remove them >> from the spec. do you have any candidates for removal? > >Just a hunch, based on MUAs I've looked at recently, but > multipart/alternative >and > multipart/parallel >are good starters. The only creation-implementations I know of >either require either hand-fussing (e.g., editing >proto-outgoing-messages from /mixed) or specialized assembly >macros that are not what we normally consider MUAs (e.g., the >process used to prepare the I-D announcements). Just to name names: I know that Cyberdog on the Macintosh and Microsoft's new mail and news offering (the latter for which I don't know the release status) both produce multipart/alternative by default (without "by-hand" user manipulation) for certain types of messages. I have, to date, never seen a multipart/parallel message. pr -- Pete Resnick QUALCOMM Incorporated Work: (217)337-6377 / Fax: (217)337-1980   Received: from ietf.org by ietf.org id aa17351; 16 Aug 96 11:00 EDT Received: from cnri by ietf.org id aa17347; 16 Aug 96 11:00 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa08299; 16 Aug 96 11:00 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id KAA05386; Fri, 16 Aug 1996 10:52:28 -0400 Received: from a4.jck.com (ns.jck.com [206.99.215.40]) by list.cren.net (8.6.12/8.6.12) with ESMTP id KAA05322 for ; Fri, 16 Aug 1996 10:52:05 -0400 Received: from white-box.jck.com ("port 2096"@white-box.jck.com) by a4.jck.com (PMDF V5.0-5 #16053) id <0DW8JYGDK006UB@a4.jck.com>; Fri, 16 Aug 1996 10:51 -0400 (EDT) Message-Id: Date: Fri, 16 Aug 1996 10:51:50 -0400 (EDT) Reply-To: John C Klensin X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: John C Klensin To: Ned Freed Cc: Dave Crocker , Ned Freed , ietf-822@list.cren.net, Harald.T.Alvestrand@uninett.no Subject: Re: MIME implementation documentation MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-Mailer: Simeon for Windows Version 4.1a5 X-Authentication: none X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN Ned, I'm really not trying to have an argument here, just to raise a question, following Harald's, about what various maturity steps in the process mean in an applications context. It seems to me that there are two positions at opposite ends of some spectrum and that both are totally unreasonable. They are: (i) An applications standard that specifies a format for the transmission of information (which is basically all that MIME, HTML, RFC 822, and, for that matter, MOSS in all of its variations, do) has adequately demonstrated interoperability if it is possible to demonstrate that it can be created somehow (an intra-host matter that is of no interest to IETF), sent over a TCP connection, and received without information loss (or with no more information loss than is explicitly permitted by the specification). There is no requirement that the receiving system be able to interpret what is sent in the fashion the sender intended (since that is another intra-host matter), only that the bits arrive and, hence, the quality of the semantic specification is almost irrelevant. (ii) We don't have an interoperable specification unless * each and every feature, and every option of every feature, can be effectively created and exercised by a totally clueless user sitting behind a mindless point-and-shoot DWIM UI and that * each and every intention of the sender with regard to content, formatting, display options, etc., can be accurately understood by a receiver (and processed within a sensible, but narrow, interpretation of the conformance rules) who is equally clueless and sitting behind equally pretty but mindless tools. If we can agree that both of those positions are silly --and I think we can-- then the question, at least for applications, is about where the optimality point is in between them. Personally, I'd like to see that optimality point include a requirement for general-purpose MUA UIs that really support the functionality specified, not just carefully-crafted single-purpose templates into which things can be stuffed and handed off for transport. I wouldn't try insist that those things get down into every logical permutation of possible functionality -- that gets a little too close to the second extreme. And, while I really don't have opinions about the answers --I'm too confused by the many tradeoffs-- I think there are some important questions about MIME features lurking here and that we would serve ourselves and the community better by addressing them now, rather than later (or, as we did with some questions about 821 and 822, just ignoring the issues for 8 or 12 years). The following are just examples: (1) multipart/alternative: Logically speaking, it shouldn't be hard to build a fairly simple MUA feature that could send out, say, two or three forms of a document -- text, some revisable markup or word processor format, and some print-ready page image format -- with some defaults for the specific formats that could be reconfigured by some process that might be less-than-completely-easy. We haven't seen that happen (at least where I've been looking). What we have seen instead is the deployment of one or more (non-MIME) MUAs that rely on the idea of maintaining a directory of known receipients and then having the MUA decide which format to send each user based on the directory information about what capabilities that user has available. Now I personally think that the latter concept is somewhere below brain-dead for more reasons than I care to enumerate. But there are more copies of MUAs that do it that way out there than there are copies of MIME MUAs who can permit an equivalently-skilled user to construct the multipart/alternative strategy instead. So, at best, we lack good proof of the viability of our approach. You will note that I haven't asked for anything of the complexity of the I-D template output, nor to get nested objects within alternatives, etc. I'm pretty happy to leave those to specialized tools, since I don't think there is a requirement that casual users be able to understand the features well enough to utilize them sensibly. I do think that, at this point, we need to ask ourselves why MUAs with that sort of near-minimal capability of creating multipart/alternative structures haven't been widely implemented and deployed. Arguably, we ought to be able to _prove_ that the reason isn't some latent defect in the definition of multipart/alternative that makes it a lot less useful than we think it ought to be. (2) Multipart/alternative, part 2. If we believe that demonstrating competence in receivers is more important than demonstrating competence in senders -- that receivers ought to be able to deal competently with things for which senders may require specialized tools or user sophistication, then we ought to be asking how many receiving MUAs out there are really able to handle fairly complex and nested multipart/alternative forms, where "handle" should mean "do the right thing automatically after appropriate configuration". Let's consider as examples the I-D form (we have proof there that the form, if it can be processed, is a way to organize useful information). Let's even go so far as to consider the nested form in which a second layer of /alternative structure is used to provide alternate sites from which to pick up an external body part. Again, I suggest that we need to examine that issue to determine whether the current definition of /alternative provides a sufficient information path between the sender and the recipient that the latter is able to the right thing without excessive guesswork. I don't know, but the number of widely-deployed implementations causes me to wonder if we are sure. (3) multipart/parallel. I think there is pretty strong evidence at this point that we don't have enough parameter information to make this feature useful -- if "useful" implies that the recipient can figure out what the sender intended and, if it wants to, to do that. If I'm wrong, and the feature is useful as defined, why aren't we seeing more implementations of /parallel rather than, e.g., (and if you are willing to admit this as an example, which I'm not -- see below) HTML with embedded image links? (4) External body parts. One of the greatest hopes for external body parts was not for delayed file transfers (of the I-D announcement persuasion) but for referencing other messages that would provide context so that, e.g., instead of forwarding a message to you with comments, I could forward a pointer to that message. Now supporting that --in principle rather simple-- functionality for casual users would require a type of database and server infrastructure which goes well beyond the MIME definition and which no one has implemented (and hooked up to external body parts). So we have no demonstration that external body parts, as defined, are adequate for that use and, in particular, we have no worked examples to tell us that our definition will prove adequate if/when those facilities become available. Are we obligated to demonstrate that the structure is right for that type of application to prove utility and interoperability of the feature? I think not if the highest use of external body parts is the way we are using them in I-D announcements. But I keep seeing MIME-ish mail messages with embedded references, references that aren't external body parts at all but simply embedded URLs. And I'm seeing several MUAs out there that offer a "double click to retrieve on embedded URL" capability -- MUAs that have not bothered to implement external body part support. One hypothesis about his is that the marketplace has demonstrated that external body parts are either useless (at least OBE) or that they aren't specified in a way to add value. The first of these possibilities is grounds for elimination at full standard; the second is (or ought to be) grounds from some fairly serious review of functionality and intent at Draft. (5) And, since I'm kicking the hornet's nest, I'll push a good strawman out there: There is the whole question of the nested body part structure. I'll argue strongly that it is a good idea and important and that there are all sorts of interesting things that one can't do without it. However, practically all of the MUAs out there, especially the graphical interface ones, are dealing with body parts through a single-level "message and attachments" model. We could save the community a lot of pain and suffering (especially in gateways to products that operate in terms of "message and attachments" by eliminating the nesting if it turned out that it had no value that anyone wanted to expose to users. IMO, it is better to ask that question now than later and, again, to examine why we aren't seeing a lot of MUAs with metaphor switches to multiple, potentially nested, body parts if that feature is as useful as we think and MIME is as widely deployed as we think. Just examples (and the last a not very good one)... Finally, and almost independent of all of the above, it seems to me that there is an element of "be careful what you wish for" in some of these discussions. If we consider that what HTTP transports is ultimately MIME-like but not necessarily MIME, then things that get transported over HTTP can't get used as proof of MIME implementation and deployment. Conversely, if we claim that HTTP transport of things that look like MIME are actually MIME implementations, then the recent flap on the MHTML list about CRLF canonicalizations and their interactions with MD5, and the web's use of Content-Encoding with rather different implications from Content-transfer-encoding, rapidly turn into worked examples of interoperability problems with MIME. Whichever approach one prefers, it is pretty clear to me that we can't have it both ways at the same time. john   Received: from ietf.org by ietf.org id aa18664; 16 Aug 96 11:30 EDT Received: from cnri by ietf.org id aa18660; 16 Aug 96 11:30 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa08906; 16 Aug 96 11:30 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id LAA09656; Fri, 16 Aug 1996 11:22:14 -0400 Received: from ng.netgate.net (root@ng.netgate.net [204.145.147.10]) by list.cren.net (8.6.12/8.6.12) with ESMTP id LAA09635 for ; Fri, 16 Aug 1996 11:22:00 -0400 Received: from [205.214.160.106] (d26.netgate.net [205.214.160.58]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id IAA25961; Fri, 16 Aug 1996 08:27:53 -0700 (PDT) Message-Id: Date: Fri, 16 Aug 1996 08:07:37 -0700 X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Dave Crocker To: John C Klensin Cc: Ned Freed , ietf-822@list.cren.net, Harald.T.Alvestrand@uninett.no Subject: Re: MIME implementation documentation In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Sender: dcrocker@ng.netgate.net X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN At 2:47 AM -0700 8/16/96, John C Klensin wrote: >Just a hunch, based on MUAs I've looked at recently, but > multipart/alternative >and > multipart/parallel grrrrr. good point. parallel is a lost, good idea. alternative is important, but I DO note that my own MUA doesn't support it. grrrrr. >from the wire is trivial and uninteresting. Implementing to a >level of quality needed to show actual utility -- that the >feature has the right syntax and semantics to actually serve >useful purpose as defined -- is, IMO, another matter and I'm not >convinced that we are there yet. agree, about the importance. suspect you are right about status. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org   Received: from ietf.org by ietf.org id aa18674; 16 Aug 96 11:30 EDT Received: from cnri by ietf.org id aa18670; 16 Aug 96 11:30 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa08917; 16 Aug 96 11:30 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id LAA09671; Fri, 16 Aug 1996 11:22:26 -0400 Received: from ng.netgate.net (root@ng.netgate.net [204.145.147.10]) by list.cren.net (8.6.12/8.6.12) with ESMTP id LAA09641 for ; Fri, 16 Aug 1996 11:22:08 -0400 Received: from [205.214.160.106] (d26.netgate.net [205.214.160.58]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id IAA25964; Fri, 16 Aug 1996 08:27:59 -0700 (PDT) Message-Id: Date: Fri, 16 Aug 1996 08:12:10 -0700 X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Dave Crocker To: Ned Freed Cc: John C Klensin , Ned Freed , ietf-822@list.cren.net, Harald.T.Alvestrand@uninett.no Subject: Re: MIME implementation documentation In-Reply-To: <01I8BUQ1R3XU8Y50ZG@INNOSOFT.COM> References: "Your message dated Fri, 16 Aug 1996 05:47:51 -0400 (EDT)" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Sender: dcrocker@ng.netgate.net X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN At 3:00 AM -0700 8/16/96, Ned Freed wrote: >entirely misplaced. MIME exceeded its design goals and became a general data >structuring format before the first set of MIME RFCs were even out. There are indeed it did and I agree that MUAs aren't the only place to look for satisfaction of the implementation/use. But the use needs to be real. The fact that RFC and I-D announcements use /alternative is a good start, for believing the contruct is a good one. But what receiving software is there that uses this contruct meaningfully? Is it used elsewhere? (For reference, I really DO want the answer to be yes. I think is is a marvelous construct.) >Perhaps we aren't, but it seems to me that you are reading an awful >lot into the proposed-->draft step of the process. this step doesn't require implementation into production systems; demonstration is fine. on the other hand, MIME ain't new and a lack of implementation in production systems by now is not a good sign. no? d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org   Received: from ietf.org by ietf.org id aa18763; 16 Aug 96 11:32 EDT Received: from cnri by ietf.org id aa18756; 16 Aug 96 11:32 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa08950; 16 Aug 96 11:31 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id LAA09739; Fri, 16 Aug 1996 11:24:28 -0400 Received: from ng.netgate.net (root@ng.netgate.net [204.145.147.10]) by list.cren.net (8.6.12/8.6.12) with ESMTP id LAA09722 for ; Fri, 16 Aug 1996 11:24:08 -0400 Received: from [205.214.160.106] (d26.netgate.net [205.214.160.58]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id IAA25948; Fri, 16 Aug 1996 08:27:47 -0700 (PDT) Message-Id: Date: Fri, 16 Aug 1996 08:05:41 -0700 X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Dave Crocker To: Harald.T.Alvestrand@uninett.no Cc: John C Klensin , Ned Freed , ietf-822@list.cren.net Subject: Re: MIME implementation documentation In-Reply-To: <9548.840179611@domen.uninett.no> References: Your message of "Fri, 16 Aug 1996 00:11:05 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Sender: dcrocker@ng.netgate.net X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN Harald, At 12:13 AM -0700 8/16/96, Harald.T.Alvestrand@uninett.no wrote: >That is, does "remove" mean "remove from specification", "move to a >document with another status", or "mark as not part of the standard"? I believe this one is easy. We make ALL of a document a standard, so we must remove from that document anything which does not qualify. I don't know that we've ever attended to the question of where to put excised parts, other than drop them on the floor. But as you observe, they might still have benefit, just not enough for standardization. In such cases, a new and separate document seems the right venue. >Shucks, we don't even have a feature list! > >The IESG vote is scheduled for next week. Do we have a volunteer to >do some work on this? >If not, I'm strongly tempted to declare that this document was already >at Draft, so we're just continuing a historical mistake..... Not so much a mistake as an intentional looseness. We take folks' word that they tested what they are supposed to test. This looseness has served us pretty well, I think. One always needs to look for checks and balances and in this case the primary forcing function is claims from others that one or another feature isn't really implemented or used. What's wrong with that mechanism? E.g., note that John K. raised a question about binary and Ned F. responded. Further discussion should/will take place about it as needed. Seems pretty diligent, to me. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org   Received: from ietf.org by ietf.org id aa22880; 16 Aug 96 13:17 EDT Received: from cnri by ietf.org id aa22876; 16 Aug 96 13:17 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa10547; 16 Aug 96 13:17 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id MAA12522; Fri, 16 Aug 1996 12:59:02 -0400 Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by list.cren.net (8.6.12/8.6.12) with ESMTP id MAA12506 for ; Fri, 16 Aug 1996 12:58:41 -0400 Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.0-7 #8694) id <01I8C85FO08W8Y52GF@INNOSOFT.COM>; Fri, 16 Aug 1996 09:57:40 -0700 (PDT) Message-Id: <01I8C8G7F7TK8Y52GF@INNOSOFT.COM> Date: Fri, 16 Aug 1996 09:49:32 -0700 (PDT) X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Ned Freed To: Dave Crocker Cc: Ned Freed , John C Klensin , ietf-822@list.cren.net, Harald.T.Alvestrand@uninett.no Subject: Re: MIME implementation documentation In-Reply-To: "Your message dated Fri, 16 Aug 1996 08:12:10 -0700" References: <01I8BUQ1R3XU8Y50ZG@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN > At 3:00 AM -0700 8/16/96, Ned Freed wrote: > >entirely misplaced. MIME exceeded its design goals and became a general data > >structuring format before the first set of MIME RFCs were even out. There are > indeed it did and I agree that MUAs aren't the only place to look > for satisfaction of the implementation/use. But the use needs to be real. > The fact that RFC and I-D announcements use /alternative is a good start, > for believing the contruct is a good one. But what receiving software is > there that uses this contruct meaningfully? Is it used elsewhere? (For > reference, I really DO want the answer to be yes. I think is is a > marvelous construct.) I already pointed out that there are plenty of implementations of multipart/alternative on the receiving side. If you want to look at two of the more popular ones, consider Metamail and Pine, both of which implement it and both of which don't simply display the final part, even though this would meet the requirements of the MIME specification for alternative support. > this step doesn't require implementation into production systems; > demonstration is fine. on the other hand, MIME ain't new and a lack of > implementation in production systems by now is not a good sign. no? There is no such lack now and there never has been. As I said before, there were interoperating implementations of alternative before RFC1341 came out. Ned   Received: from ietf.org by ietf.org id aa23886; 16 Aug 96 13:46 EDT Received: from cnri by ietf.org id aa23876; 16 Aug 96 13:46 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa10972; 16 Aug 96 13:46 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id NAA13140; Fri, 16 Aug 1996 13:38:37 -0400 Received: from a4.jck.com (ns.jck.com [206.99.215.40]) by list.cren.net (8.6.12/8.6.12) with ESMTP id NAA13122 for ; Fri, 16 Aug 1996 13:38:24 -0400 Received: from white-box.jck.com ("port 2122"@white-box.jck.com) by a4.jck.com (PMDF V5.0-5 #16053) id <0DW8RO08T006UB@a4.jck.com>; Fri, 16 Aug 1996 13:38 -0400 (EDT) Message-Id: Date: Fri, 16 Aug 1996 13:38:23 -0400 (EDT) Reply-To: John C Klensin X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: John C Klensin To: Pete Resnick Cc: Dave Crocker , Ned Freed , ietf-822@list.cren.net, Harald.T.Alvestrand@uninett.no Subject: Re: MIME implementation documentation MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-Mailer: Simeon for Windows Version 4.1a5 X-Authentication: none X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN On Fri, 16 Aug 1996 09:43:55 -0500 Pete Resnick wrote: > Just to name names: I know that Cyberdog on the Macintosh and Microsoft's > new mail and news offering (the latter for which I don't know the release > status) both produce multipart/alternative by default (without "by-hand" > user manipulation) for certain types of messages. Well, that is considerable progress, although it would be nice to know -- what types of messages and -- what really acts on these on receipt, other than treating them as "mixed". Note that we can't appeal to HTTP for validation of any of the multipart formats -- they quite aggressively don't use them. john   Received: from ietf.org by ietf.org id aa24045; 16 Aug 96 13:50 EDT Received: from cnri by ietf.org id aa24041; 16 Aug 96 13:50 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa11062; 16 Aug 96 13:50 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id NAA13257; Fri, 16 Aug 1996 13:42:18 -0400 Received: from ng.netgate.net (root@ng.netgate.net [204.145.147.10]) by list.cren.net (8.6.12/8.6.12) with ESMTP id NAA13239 for ; Fri, 16 Aug 1996 13:42:12 -0400 Received: from [205.214.160.106] (d13.netgate.net [205.214.160.45]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id KAA02586; Fri, 16 Aug 1996 10:48:08 -0700 (PDT) Message-Id: Date: Fri, 16 Aug 1996 10:08:12 -0700 X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Dave Crocker To: Ned Freed Cc: ietf-822@list.cren.net Subject: Re: MIME implementation documentation In-Reply-To: <01I8C8G7F7TK8Y52GF@INNOSOFT.COM> References: "Your message dated Fri, 16 Aug 1996 08:12:10 -0700" <01I8BUQ1R3XU8Y50ZG@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Sender: dcrocker@ng.netgate.net X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN At 9:49 AM -0700 8/16/96, Ned Freed wrote: >I already pointed out that there are plenty of implementations of >multipart/alternative on the receiving side. If you want to look at two of the >more popular ones, consider Metamail and Pine, both of which implement it and missed that part of you previous note. these examples are plenty, as far as I'm concerned. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org   Received: from ietf.org by ietf.org id aa24667; 16 Aug 96 14:06 EDT Received: from cnri by ietf.org id aa24663; 16 Aug 96 14:06 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa11420; 16 Aug 96 14:06 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id NAA13546; Fri, 16 Aug 1996 13:56:34 -0400 Received: from name.net (NS.NAME.NET [204.50.44.10]) by list.cren.net (8.6.12/8.6.12) with ESMTP id NAA13527 for ; Fri, 16 Aug 1996 13:56:14 -0400 Received: from engine.name.net (engine.name.net [204.50.44.14]) by name.net (8.6.12/8.6.12) with ESMTP id NAA12278; Fri, 16 Aug 1996 13:56:08 -0400 Received: from localhost.name.net (localhost.name.net [127.0.0.1]) by engine.name.net (8.6.12/8.6.12) with SMTP id NAA14361; Fri, 16 Aug 1996 13:56:08 -0400 Message-Id: <199608161756.NAA14361@engine.name.net> Date: Fri, 16 Aug 1996 13:56:07 -0400 X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Rens Troost To: John C Klensin Cc: Pete Resnick , Dave Crocker , Ned Freed , ietf-822@list.cren.net, Harald.T.Alvestrand@uninett.no Subject: Re: MIME implementation documentation In-Reply-To: Your message of "Fri, 16 Aug 1996 13:38:23 EDT." X-Authentication-Warning: engine.name.net: Host localhost.name.net didn't use HELO protocol X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN > > Note that we can't appeal to HTTP for validation of any of the > multipart formats -- they quite aggressively don't use them. I run multipart over HTTP regularly for some HTTP/based remote file processing systems. I also deployed multipart/mixed over HTTP as part of a kiosk application that actually ran in stores all over canada. In addition, a hack called multipart/x-mixed-replace was used for early animation work by netscape. But alas, I've never seen a multipart/alternative in this context. -Rens   Received: from ietf.org by ietf.org id aa26590; 16 Aug 96 14:52 EDT Received: from cnri by ietf.org id aa26581; 16 Aug 96 14:52 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa12176; 16 Aug 96 14:52 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id OAA14273; Fri, 16 Aug 1996 14:43:50 -0400 Received: from glaucus.cso.uiuc.edu (glaucus.cso.uiuc.edu [128.174.81.2]) by list.cren.net (8.6.12/8.6.12) with SMTP id OAA14254 for ; Fri, 16 Aug 1996 14:43:22 -0400 Received: from resnick1.isdn.uiuc.edu by glaucus.cso.uiuc.edu (AIX 3.2/UCB 5.64/4.03) id AA11509; Fri, 16 Aug 1996 13:39:06 -0500 Message-Id: Date: Fri, 16 Aug 1996 13:43:01 -0500 X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Pete Resnick To: John C Klensin Cc: Dave Crocker , Ned Freed , ietf-822@list.cren.net, Harald.T.Alvestrand@uninett.no Subject: Re: MIME implementation documentation In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: resnick@glaucus.cso.uiuc.edu X-Mailer: Eudora [Macintosh version 3.0] X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN On 8/16/96 at 12:38 PM -0500, John C Klensin wrote: >On Fri, 16 Aug 1996 09:43:55 -0500 Pete Resnick > wrote: >> Just to name names: I know that Cyberdog on the Macintosh and Microsoft's >> new mail and news offering (the latter for which I don't know the release >> status) both produce multipart/alternative by default (without "by-hand" >> user manipulation) for certain types of messages. > >Well, that is considerable progress, although it would be nice >to know > -- what types of messages Cyberdog sends multipart/alternative containing text/plain and text/enriched whenever the user puts any styled text into their message. MS's thing I'm told (I haven't actually gotten one yet) sends mult/alt with text/plain and text/html, though I'm not sure of the circumstances. > -- what really acts on these on receipt, other than treating >them as "mixed". Ned mentions metamail and Pine, though I don't know what they do. I know Mac Eudora 3.0 displays the "best" one (i.e. furthest down the list) that it can handle. pr -- Pete Resnick QUALCOMM Incorporated Work: (217)337-6377 / Fax: (217)337-1980   Received: from ietf.org by ietf.org id aa03835; 16 Aug 96 18:21 EDT Received: from cnri by ietf.org id aa03831; 16 Aug 96 18:21 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa15277; 16 Aug 96 18:21 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id SAA21423; Fri, 16 Aug 1996 18:15:03 -0400 Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by list.cren.net (8.6.12/8.6.12) with ESMTP id SAA21385 for ; Fri, 16 Aug 1996 18:14:35 -0400 Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.0-7 #8694) id <01I8CJ99XDDC8Y507E@INNOSOFT.COM>; Fri, 16 Aug 1996 15:13:33 -0700 (PDT) Message-Id: <01I8CJGV6XIU8Y507E@INNOSOFT.COM> Date: Fri, 16 Aug 1996 15:10:43 -0700 (PDT) X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Ned Freed To: John C Klensin Cc: Pete Resnick , Dave Crocker , Ned Freed , ietf-822@list.cren.net, Harald.T.Alvestrand@uninett.no Subject: Re: MIME implementation documentation In-Reply-To: "Your message dated Fri, 16 Aug 1996 13:38:23 -0400 (EDT)" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN > > Just to name names: I know that Cyberdog on the Macintosh and Microsoft's > > new mail and news offering (the latter for which I don't know the release > > status) both produce multipart/alternative by default (without "by-hand" > > user manipulation) for certain types of messages. Sheesh, now that you mention it, there's another MUA that does this too -- Ishmail. I completely forgot about it. So that's three MUAs producing multipart/alternative. > Well, that is considerable progress, although it would be nice > to know > -- what types of messages > and > -- what really acts on these on receipt, other than treating > them as "mixed". Ishmail also handles this on receipt. That makes three MUAs I know of, Pine, Ishmail, and Metamail, that handle multipart/alternative. Ned   Received: from ietf.org by ietf.org id aa13667; 18 Aug 96 0:20 EDT Received: from cnri by ietf.org id aa13663; 18 Aug 96 0:20 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa00957; 18 Aug 96 0:20 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id AAA12985; Sun, 18 Aug 1996 00:14:26 -0400 Received: from glaucus.cso.uiuc.edu (glaucus.cso.uiuc.edu [128.174.81.2]) by list.cren.net (8.6.12/8.6.12) with SMTP id AAA12949 for ; Sun, 18 Aug 1996 00:14:05 -0400 Received: from resnick1.isdn.uiuc.edu by glaucus.cso.uiuc.edu (AIX 3.2/UCB 5.64/4.03) id AA07207; Sat, 17 Aug 1996 23:09:47 -0500 Message-Id: Date: Sat, 17 Aug 1996 23:13:38 -0500 X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Pete Resnick To: Harald.T.Alvestrand@uninett.no Cc: ietf-822@list.cren.net, moore@cs.utk.edu Subject: Re: MIME implementation documentation In-Reply-To: <23913.840267370@domen.uninett.no> References: Your message of "Fri, 16 Aug 1996 15:10:43 PDT." <01I8CJGV6XIU8Y507E@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: resnick@glaucus.cso.uiuc.edu X-Mailer: Eudora [Macintosh version 3.0] X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN On 8/17/96 at 2:36 AM -0500, Harald.T.Alvestrand@uninett.no wrote: >Are Nested Body Parts widely implemented? I have one example from Macintosh Eudora 3.0, but it is sort of a special cased example: Mac Eudora 3.0 handles (and in fact expects) reception of nested multiparts when it comes to multipart/digest. If someone sends a multipart/mixed where the first part is a text/plain (or text/*) and the second part is a multipart/digest, Eudora will create a mail message in the In-box with the text/* part and an icon for an attached mailbox. When the attachment is opened, inside are the contents of the multipart/digest, each as a seperate mailbox entry, and those can themselves be any sort of message, including multipart messages which are handled recursively. We don't do any other particular sort of special handling for nested multiparts. Though never released, we do have some code which will generate multipart/digests within multipart/mixed, but I don't know if that would count toward operational experience. >Are External Body Parts widely implemented? Again, Mac Eudora (perhaps even prior to 3.0; I don't remember) provides a datapoint, both for reception and generation. For the 'ftp' access-type, Eudora receives it as a Macintosh bookmark type attachment which is used by the FTP clients on the Macintosh. When the icon for the bookmark attachment is double-clicked in the message, Eudora causes the users FTP client to be launched and download the file (or display the directory). A user can also send a bookmark and Eudora encodes it as a message/external-body with the 'ftp' access-type. For the 'mail-server' access-type, Eudora receives them as Eudora mail stationery attachments. When double-clicked, these cause Eudora to create a new mail message with the information provided in the phantom body of the external-body. If a user attaches these stationery files to a message, Eudora encodes them as message/external-body with the 'mail-server' access-type. pr -- Pete Resnick QUALCOMM Incorporated Work: (217)337-6377 / Fax: (217)337-1980   Received: from ietf.org by ietf.org id aa14128; 18 Aug 96 1:29 EDT Received: from cnri by ietf.org id aa14124; 18 Aug 96 1:29 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa01709; 18 Aug 96 1:29 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id BAA14630; Sun, 18 Aug 1996 01:23:12 -0400 Received: from urchin.mcom.com (h-198-95-250-59.netscape.com [198.95.250.59]) by list.cren.net (8.6.12/8.6.12) with ESMTP id BAA14612 for ; Sun, 18 Aug 1996 01:22:52 -0400 Received: from gruntle ([205.217.227.10]) by urchin.mcom.com (8.7.5/8.7.3) with SMTP id WAA21188; Sat, 17 Aug 1996 22:22:12 -0700 (PDT) Message-Id: <3216A883.2781@netscape.com> Date: Sat, 17 Aug 1996 22:22:11 -0700 X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Jamie Zawinski To: Pete Resnick Cc: Harald.T.Alvestrand@uninett.no, ietf-822@list.cren.net, moore@cs.utk.edu Subject: Re: MIME implementation documentation References: Your message of "Fri, 16 Aug 1996 15:10:43 PDT." <01I8CJGV6XIU8Y507E@INNOSOFT.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Sender: jwz@netscape.com X-Mailer: Mozilla 3.0 (X11; U; IRIX 5.3 IP22) X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN Pete Resnick wrote: > > On 8/17/96 at 2:36 AM -0500, Harald.T.Alvestrand@uninett.no wrote: > > >Are Nested Body Parts widely implemented? > > I have one example from Macintosh Eudora 3.0, but it is sort of a special > cased example: Mac Eudora 3.0 handles (and in fact expects) reception of > nested multiparts when it comes to multipart/digest. If someone sends a > multipart/mixed where the first part is a text/plain (or text/*) and the > second part is a multipart/digest, Eudora will create a mail message in the > In-box with the text/* part and an icon for an attached mailbox. When the > attachment is opened, inside are the contents of the multipart/digest, each > as a seperate mailbox entry, and those can themselves be any sort of > message, including multipart messages which are handled recursively. Netscape 2.0 and newer handle arbitrary nesting of parts, but will only generate "deep" messages if a document is attached which is itself a MIME object (forwarding a message which has a multipart inside of it, for example.) (Oh, if a dual-forked Mac file is attached, it will be sent as multipart/appledouble, and that will probably itself end up within a multipart/mixed.) We normally generate multipart/mixed when there are attachments, but will generate multipart/digest if all of the attachments (that is, all parts but the first) are messages. (So we might generate digests with only messages in them, or we might generate digests where the very first part is text/plain and all the rest are messages.) We don't handle receipt of multipart/digest any differently than multipart/mixed (except for the rule about what the default part-type is.) Netscape 3.0 handles multipart/alternative (receipt, not generation) but has slightly lenient rules for what the "best" part is. RFC1521 says that, when a multipart/mixed is within a multipart/alternative, it would be reasonable to descend into it to see if all sub-parts are displayable, but we don't do that. Instead, we display the first part of the multipart/alternative which is of a type which we can display inline. (The types we can display inline are text/plain, text/richtext, text/enriched, text/html, image/gif, image/jpeg, image/xbm, certain subtypes of message/external-body, and multipart/*.) (Actually, we don't display the first part that is displayable inline, we move forward in it until we reach a part that is *not* displayable inline, and then we display the part before that. So if we got text/plain, text/enriched, text/xxx, and text/html, we would display the text/enriched rather than the text/html. I'm not 100% convinced that this is the right thing...) > >Are External Body Parts widely implemented? 3.0 converts these to clickable URLs when it can (types ftp, anon-ftp, local-file, mail-server, and url.) (afs is treated like local-file if running on Unix and "/afs/." is stat()able; mail-server is turned into a mailto: URL, which will cause a filled-in mail composition window to come up. But if there is a body, it's not filled in automatically.) Others are presented by basically just pretty-printing the header parameters. -- Jamie Zawinski jwz@netscape.com http://www.netscape.com/people/jwz/ ``A signature isn't a return address, it is the ASCII equivalent of a black velvet clown painting; it's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who.'' -- Chris Maeda   Received: from ietf.org by ietf.org id aa16080; 18 Aug 96 11:08 EDT Received: from cnri by ietf.org id aa16076; 18 Aug 96 11:08 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa06845; 18 Aug 96 11:08 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id LAA21072; Sun, 18 Aug 1996 11:01:58 -0400 Received: from glaucus.cso.uiuc.edu (glaucus.cso.uiuc.edu [128.174.81.2]) by list.cren.net (8.6.12/8.6.12) with SMTP id LAA21055 for ; Sun, 18 Aug 1996 11:01:39 -0400 Received: from resnick1.isdn.uiuc.edu by glaucus.cso.uiuc.edu (AIX 3.2/UCB 5.64/4.03) id AA03383; Sun, 18 Aug 1996 09:57:25 -0500 Message-Id: Date: Sun, 18 Aug 1996 10:01:22 -0500 X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Pete Resnick To: Jamie Zawinski Cc: Harald.T.Alvestrand@uninett.no, ietf-822@list.cren.net, moore@cs.utk.edu Subject: Re: MIME implementation documentation In-Reply-To: <3216A883.2781@netscape.com> References: Your message of "Fri, 16 Aug 1996 15:10:43 PDT." <01I8CJGV6XIU8Y507E@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: resnick@glaucus.cso.uiuc.edu X-Mailer: Eudora [Macintosh version 3.0] X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN Jamie, we can take this off list (or perhaps over to mailext) if it turns out to generate a lot of back and forth discussion between the two of us. On 8/18/96 at 12:22 AM -0500, Jamie Zawinski wrote: >(Oh, if a dual-forked Mac file is attached, it will be sent as >multipart/appledouble, and that will probably itself end up within a >multipart/mixed.) Yes, I'd forgotten about this one. Of course anyone who generates stuff with appledouble is generating nested multipart, but again this is a "special case" kind of processing. Does this count, Harald? >We normally generate multipart/mixed when there are attachments, but >will generate multipart/digest if all of the attachments (that is, all >parts but the first) are messages. (So we might generate digests with >only messages in them, or we might generate digests where the very first >part is text/plain and all the rest are messages.) This is not a good thing. From section 7.1.5 of : Note: Though it is possible to specify a Content-Type value for a body part in a digest which is other than "message/rfc822", such as a "text/plain" part containing a description of the material in the digest, actually doing so is undesireble. The "multipart/digest" Content-Type is intended to be used to send collections of messages. If a "text/plain" part is needed, it should be included as a seperate part of a "multipart/mixed" message. If Eudora gets a digest with a text/plain part, we make a "dummy" message in the mailbox which represents the digest and put the text/plain part in there. It's much better to put the text/plain part as the first part of a multipart/mixed where the second part is the digest: multipart/mixed text/plain multipart/digest message/rfc822 message/rfc822 message/rfc822 It makes much more sense in this form. >(Actually, we don't display the first part that is displayable inline, >we move forward in it until we reach a part that is *not* displayable >inline, and then we display the part before that. So if we got >text/plain, text/enriched, text/xxx, and text/html, we would display the >text/enriched rather than the text/html. I'm not 100% convinced that >this is the right thing...) I think this is a reasonable thing to do. Even though walking the parts backwards is probably the optimal thing to do, it can be a pain in the butt, and what you're doing should get a reasonable result to the user. pr -- Pete Resnick QUALCOMM Incorporated Work: (217)337-6377 / Fax: (217)337-1980   Received: from ietf.org by ietf.org id aa25081; 18 Aug 96 23:44 EDT Received: from cnri by ietf.org id aa25077; 18 Aug 96 23:44 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa00567; 18 Aug 96 23:44 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id XAA06147; Sun, 18 Aug 1996 23:22:39 -0400 Received: from ns.airco.co.jp (ns.airco.co.jp [203.178.5.68]) by list.cren.net (8.6.12/8.6.12) with ESMTP id XAA06102 for ; Sun, 18 Aug 1996 23:20:56 -0400 Received: from airco.co.jp ([192.168.10.33]) by ns.airco.co.jp (8.6.9/3.3W96052512) with ESMTP id MAA26340; Mon, 19 Aug 1996 12:21:35 +0900 Received: from winter ([192.168.10.66]) by airco.co.jp (8.6.9+2.4Wb3/3.3W96052513) with SMTP id MAA10441; Mon, 19 Aug 1996 12:14:35 +0900 Message-Id: <199608190314.MAA10441@airco.co.jp> Date: Mon, 19 Aug 1996 12:21:09 +0900 (JST) Reply-To: Mark Keasling X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Mark Keasling To: Harald.T.Alvestrand@uninett.no Cc: ietf-822@list.cren.net Subject: Re: MIME implementation documentation (nested bodies) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-2139633923-5758-840424870:#18941" X-Mailer: AIR MAIL for Motif (v1.5) X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN ---2139633923-5758-840424870:#18941 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hi Harald, AIR Mail (AIR Company Limited Japan) can generate nested mulipart messages indirectly via forwarding or reply. In composition, it currently will only generate a single level multipart/mixed. This will change when/if we ever start working on version 2 (It's in planning stages now). The message is display part by part with multipart items in a list. There is screen shot after your included message... Mark Keasling ---2139633923-5758-840424870:#18941 Content-Type: MESSAGE/RFC822 Return-Path: Received: from airco.co.jp by winter.airco.co.jp (SMI-8.6/SMI-SVR4) id KAA18779; Sun, 18 Aug 1996 10:59:38 +0900 Received: from ns.airco.co.jp (ns.airco.co.jp [192.168.10.99]) by airco.co.jp (8.6.9+2.4Wb3/3.3W96052513) with ESMTP id KAA07110 for ; Sun, 18 Aug 1996 10:53:12 +0900 Received: from list.cren.net (list.cren.net [204.153.50.13]) by ns.airco.co.jp (8.6.9/3.3W96052512) with ESMTP id KAA23535 for ; Sun, 18 Aug 1996 10:59:54 +0900 Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id VAA06393; Sat, 17 Aug 1996 21:52:58 -0400 Received: from domen.uninett.no (domen.uninett.no [129.241.131.10]) by list.cren.net (8.6.12/8.6.12) with SMTP id VAA06356 for ; Sat, 17 Aug 1996 21:52:33 -0400 Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) id <23916-0@domen.uninett.no>; Sat, 17 Aug 1996 09:36:12 +0200 Message-Id: <23913.840267370@domen.uninett.no> Date: Sat, 17 Aug 1996 09:36:10 +0200 Sender: owner-ietf-822@list.cren.net Precedence: bulk From: Harald.T.Alvestrand@uninett.no To: ietf-822@list.cren.net Cc: moore@cs.utk.edu Subject: Re: MIME implementation documentation In-Reply-To: Your message of "Fri, 16 Aug 1996 15:10:43 PDT." <01I8CJGV6XIU8Y507E@INNOSOFT.COM> MIME-Version: 1.0 X-Sender: Harald.T.Alvestrand@uninett.no X-Mailer: exmh version 1.6.7 5/3/96 X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN Content-Length: 5633 Content-Type: MULTIPART/MIXED; BOUNDARY="-2139633923-16838-840424869:#18941" ---2139633923-16838-840424869:#18941 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII When in doubt, write a Web page.... I have written up a Web page for the Last Call on http://domen.uninett.no/apps/last-call/mime-draft2.html and attached a text version to this document. Given the debate that has occured, I regard the question of multipart/alternative as settled, while there is still missing evidence for multipart/parallel, generation of nested body parts and handling of external body parts. When new evidence arrives (on this list, please!), I will update the Web page. Harald T. Alvestrand Apps AD ---2139633923-16838-840424869:#18941 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII LAST CALL FOR MIME DOCUMENTS TO RECYCLE AT DRAFT The following Last Call has been issued: The IESG has received a request to consider the following Protocol Actions: 1. Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies" for the status of Draft Standard. 2. Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types for the status of Draft Standard. 3. MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text for the status of Best Current Practice. 5. Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples for the status of Draft Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by August 8, 1996. No objections to the Last Call were received before August 8. After the timeout date for the Last Call comments, the following issues with regard to implementation experience have been raised: * Is multipart/alternative widely implemented for generation? * Is multipart/alternative widely implemented for reception? * Is multipart/parallel widely implemented? * Are Nested Body Parts widely implemented? * Are External Body Parts widely implemented? The issue here is if the "two implementations" rule (which traditionally have allowed two experimental implementations without terribly useful user interfaces) should be strengthened for a specification of this maturity to mean "two interworking, commercial implementations that can be used by someone not terribly skilled in the arcana of MIME". The sections below will give the arguments and evidence in each case. Is multipart/alternative widely implemented for generation? The question is if there exist MUAs that can generate a MIME multipart/alternative without excessive thinking on the part of the user. The following MIME UAs have been claimed to do so: * Cyberdog for the Macintosh * Ishmail * An yet-unnamed product from Microsoft This AD regards the question as settled. Is multipart/alternative widely implemented for reception? The question is if there exist UAs that display the "best" body part (that being defined as the last part of the multipart/alternative that the UA is able to display). The following UAs have been claimed to do so: * Pine * Metamail * Mac Eudora 3.0 This AD regards the question as settled. Is multipart/parallel widely implemented? The question is if there are UAs that display all parts of the multipart/parallel "at the same time", as described in the drafts, and do not jsut treat it like multipart/mixed, and if there are generating UAs. To date, no generating UA has been identified. To date, only Metamail has been mentioned as an example of a displayer. Are Nested Body Parts widely implemented? Many MUAs work according to the "one message with attachments" metaphor, which is not the same as the MIME "bodyparts may nest to any level" structure. Forwarded messages are not part of this question. One may argue that the "inline/attachment" distinction that is carried in content-disposition is missing functionality in MIME. However, content-disposition is the subject of another ongoing action, and will have to catch up later. The question is if there exist MUAs that: 1. Generate nested multiparts through a reasonable user interface 2. Usefully display nested multiparts The following MUAs have reasonable support for generating nested multiparts: * The following MUAs have reasonable support for displaying nested multiparts: * EXMH 1.6.7 Are External Body Parts widely implemented? The question is if there exist MUAs that: 1. Generate External Body Parts through a reasonable user interface 2. Usefully handle External Body Parts The IETF internet-drafts announcement uses multipart/alternative with external body parts to list the ways in which one can get the I-Ds. This is special purpose code, and only proves that such messages can be generated. The following MUAs have reasonable support for generating External Body Parts: * The following MUAs have reasonable support for handling External Body Parts: * MH 6.8.3 _________________________________________________________________ Harald.T.Alvestrand@uninett.no Last modified: Sat Aug 17 09:32:26 1996 ---2139633923-16838-840424869:#18941-- ---2139633923-5758-840424870:#18941 Content-Type: IMAGE/JPEG; NAME="amcompose.jpg" Content-Transfer-Encoding: BASE64 Content-Description: amcompose.jpg /9j/4AAQSkZJRgABAQAAAQABAAD/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQID BAUGBwgJCgv/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1 EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHB FVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFla Y2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0 tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/ xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGh scEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVW V1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeo qaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4 +fr/2wBDABALDA4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxO QERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVGC8aGi9jQjhC Y2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2Nj Y2NjY2P/wAARCAHYAcIDABEAAREBAhEB/9oADAMAAAERAhEAPwDpp5pEmZVb AHtXM27mySsR/aZf7/6ClzMfKg+0y/3/ANBRzMOVB9pl/v8A6CjmYcqD7TL/ AH/0FHMw5UH2mX+/+go5mHKg+0y/3/0FHMw5UH2mX+/+go5mHKg+0y/3/wBB RzMOVB9pl/v/AKCjmYcqD7TL/f8A0FHMw5UH2mX+/wDoKOZhyoPtMv8Af/QU czDlQfaZf7/6CjmYcqD7TL/f/QUczDlQfaZf7/6CjmYcqD7TL/f/AEFHMw5U H2mX+/8AoKOZhyoPtMv9/wDQUczDlQfaZf7/AOgo5mHKg+0y/wB/9BRzMOVB 9pl/v/oKOZhyoPtMv9/9BRzMOVB9pl/v/oKOZhyoPtMv9/8AQUczDlQfaZf7 /wCgo5mHKg+0y/3/ANBRzMOVB9pl/v8A6CjmYcqD7TL/AH/0FHMw5UH2mX+/ +go5mHKg+0y/3/0FHMw5UH2mX+/+go5mHKg+0y/3/wBBRzMOVB9pl/v/AKCj mYcqD7TL/f8A0FHMw5UH2mX+/wDoKOZhyoPtMv8Af/QUczDlQfaZf7/6CjmY cqD7TL/f/QUczDlQfaZf7/6CjmYcqD7TL/f/AEFHMw5UH2mX+/8AoKOZhyoP tMv9/wDQUczDlQfaZf7/AOgo5mHKg+0y/wB/9BRzMOVB9pl/v/oKOZhyoPtM v9/9BRzMOVB9pl/v/oKOZhyoPtMv9/8AQUczDlQfaZf7/wCgo5mHKg+0y/3/ ANBRzMOVB9pl/v8A6CjmYcqD7TL/AH/0FHMw5UH2mX+/+go5mHKg+0y/3/0F HMw5UH2mX+/+go5mHKjrfBsMN54YtLi5hilmcyFndASf3jV+vcN/8iul/wBv f+lMg4vWJ2tre7nQAtFEzgHpkLmvyJq8ilsc7Frd61jJcyXWkjESuFVnZkJZ R8yjJ7kcd8VXKr2FzOxbh1+CJLp9QljhEd3JBHtUksFxzjk9+vTpS5H0Hzdz YR1kRXRgysMhgcgj1qChaAOfvNYvU1W6tYZtNgjg2YN0zKWyueMHn/8AVVqK tchyd7E2q64unWToZbdtSjjRmi5K5JAOPzJxnOOaIxu/IblZEK+ISusxWLyW 7BriSJtiPlRwEHPcnIOMijk0uLm1sdBUFhQBz/8Abd7s/tDybf8Asnztm/Le Zszt3/TPbGf51fKtupHM9+hfk17S4pHjku0V0ZlYEHgr17fl69s0uRj5kUdM 19ryKyeWW2j8wyidSrDG0ZG09BwQTk03C1xKVy5H4g0qWGWVLsFYgC/yMCAT jOMZPJHT1pcjHzIedc0wQSz/AGyMxxPsYjJ57YHU9+R6H0o5WPmRct7iK6gS eBxJE4yrDvUtWGtSSgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAMyfVVttbFncSQxQG280P I207t2MZJx0qlG6uTfWxBYeIbZ7C0l1CeKGe43YVQccMVz3wOOp96bg76ApK 2otvr8CG5F/LHDsuZYo8KfmVADz155/HtQ4PoHN3NW3uIrqBJ4HEkTjKsO9Q 1Ypanc+A/wDkULH/ALaf+jGr9f4b/wCRXS/7e/8ASmZnDa3E89pewxLukkhZ VGcZJXAr8ifxFL4TDu9FJ8M+RbWcS3rQxq+0KrEgqWy3fp601L3tROPulC90 O/keSRYHYG8nfZHMqMyOFAIJyMcHIPPPSqUkJxZ1NnD9ns4IMY8uNU656DHX Az+QrJ6stbE1AznLqzuk1q9uP7Giv4pvL2NJIg24XBxnP+RWiaslchp32INT sNVnN/5VgGF+kLHEy/uioGVOevPpTTStrsJpk0GmX0GqR3YgDKt/O5G8A+XI AA34YPHWk5K1h2d7nSVmWFAHM/2ZqP2T+xPsyfYPO/4+fNG7yt27GP73bOMe 3etOZX5upFnsQWkF3eXssUVuPIi1Zp3nMgGNvVdvX8fem2kvkJJt/MWLRdRN rZ2rwov2dbqIyeYCpDr8reuCTjpnijmWrDlexHNpOq3VpIHsxE0dlHbIvmqT IVdTn0HAPX9aOZJhZsuajpd7LeahPFbCQPLA8X73Yx2qQSpB4YE8Z49jSUlZ Dad2auh201npFtb3IQSop3BMYHJOOO/r7+tRJ3d0VFWRfpDCgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgA oAKACgAoAyZ9N+0+IRcXFtHLai02AyAMN+/PQ+3eqTtGxNtTBHh2/aGzSS3c r5JilVLhU2/vCwLHByOQcDPStOdakcrJZIbyw1q3dbXzZZLy6lij8wLvUqvO e3fr6UtGh6pm/oNpLYaNb204AlQEsAc4yxOP1qJO7uXFWR6L4D/5FCx/7af+ jGr9d4b/AORXS/7e/wDSmQcNe6hax3UiNKNynBwCecV+RNO5SehB/aVp/wA9 v/HT/hS5WO6D+0rT/nt/46f8KOVhdB/aVp/z2/8AHT/hRysLoP7StP8Ant/4 6f8ACjlYXQf2laf89v8Ax0/4UcrC6D+0rT/nt/46f8KOVhdB/aVp/wA9v/HT /hRysLoP7StP+e3/AI6f8KOVhdB/aVp/z2/8dP8AhRysLoP7StP+e3/jp/wo 5WF0MjvdPi3eUyJvYs22Mjcx6k8daLMLof8A2laf89v/AB0/4UcrC6D+0rT/ AJ7f+On/AAo5WF0H9pWn/Pb/AMdP+FHKwug/tK0/57f+On/CjlYXQf2laf8A Pb/x0/4UcrC6D+0rT/nt/wCOn/CjlYXQf2laf89v/HT/AIUcrC6D+0rT/nt/ 46f8KOVhdB/aVp/z2/8AHT/hRysLoP7StP8Ant/46f8ACjlYXQf2laf89v8A x0/4UcrC6D+0rT/nt/46f8KOVhdB/aVp/wA9v/HT/hRysLoP7StP+e3/AI6f 8KOVhdB/aVp/z2/8dP8AhRysLoP7StP+e3/jp/wo5WF0H9pWn/Pb/wAdP+FH Kwug/tK0/wCe3/jp/wAKOVhdB/aVp/z2/wDHT/hRysLoP7StP+e3/jp/wo5W F0H9pWn/AD2/8dP+FHKwug/tK0/57f8Ajp/wo5WF0H9pWn/Pb/x0/wCFHKwu g/tK0/57f+On/CjlYXQf2laf89v/AB0/4UcrC6D+0rT/AJ7f+On/AAo5WF0H 9pWn/Pb/AMdP+FHKwug/tK0/57f+On/CjlYXQf2laf8APb/x0/4UcrC6D+0r T/nt/wCOn/CjlYXQf2laf89v/HT/AIUcrC6D+0rT/nt/46f8KOVhdB/aVp/z 2/8AHT/hRysLoP7StP8Ant/46f8ACjlYXQf2laf89v8Ax0/4UcrC6D+0rT/n t/46f8KOVhdB/aVp/wA9v/HT/hRysLoP7StP+e3/AI6f8KOVhdB/aVp/z2/8 dP8AhRysLoP7StP+e3/jp/wo5WF0H9pWn/Pb/wAdP+FHKwug/tK0/wCe3/jp /wAKOVhdDGvdPeRJGZGkjzsYxklc9cHHFFmF0P8A7StP+e3/AI6f8KOVhdHo HgP/AJFCx/7af+jGr9e4b/5FdL/t7/0pkHnjyD7RJFFp8Enl4ydqDqPpX5OQ G6X/AKBUH/jn+FFwDdL/ANAqD/xz/Ci4Bul/6BUH/jn+FFwDdL/0CoP/ABz/ AAouAbpf+gVB/wCOf4UXAN0v/QKg/wDHP8KLgG6X/oFQf+Of4UXAN0v/AECo P/HP8KLgG6X/AKBUH/jn+FFwDdL/ANAqD/xz/Ci4Bul/6BUH/jn+FFwDdL/0 CoP/ABz/AAouAbpf+gVB/wCOf4UXAN0v/QKg/wDHP8KLgG6X/oFQf+Of4UXA N0v/AECoP/HP8KLgG6X/AKBUH/jn+FFwDdL/ANAqD/xz/Ci4Bul/6BUH/jn+ FFwDdL/0CoP/ABz/AAouAbpf+gVB/wCOf4UXAN0v/QKg/wDHP8KLgG6X/oFQ f+Of4UXAN0v/AECoP/HP8KLgG6X/AKBUH/jn+FFwDdL/ANAqD/xz/Ci4Bul/ 6BUH/jn+FFwDdL/0CoP/ABz/AAouAbpf+gVB/wCOf4UXAN0v/QKg/wDHP8KL gG6X/oFQf+Of4UXAN0v/AECoP/HP8KLgG6X/AKBUH/jn+FFwDdL/ANAqD/xz /Ci4Bul/6BUH/jn+FFwDdL/0CoP/ABz/AAouAbpf+gVB/wCOf4UXAN0v/QKg /wDHP8KLgG6X/oFQf+Of4UXAN0v/AECoP/HP8KLgG6X/AKBUH/jn+FFwDdL/ ANAqD/xz/Ci4Bul/6BUH/jn+FFwDdL/0CoP/ABz/AAouAbpf+gVB/wCOf4UX AN0v/QKg/wDHP8KLgG6X/oFQf+Of4UXAN0v/AECoP/HP8KLgG6X/AKBUH/jn +FFwDdL/ANAqD/xz/Ci4Bul/6BUH/jn+FFwDdL/0CoP/ABz/AAouAbpf+gVB /wCOf4UXAN0v/QKg/wDHP8KLgOjWaSRUGl24yep2YH6UAakGoXltCsNvcSQx L91IztUd+AK/WeG3/wAJdL/t7/0pjMu3/wCQhd/8A/lX5KBbpAFABQAUAFAG Tfarc2l0IxYho2nSCOR5du9mGc42ngdM/wD16pIRZh1FFtY5NQ8uxkcsPLlk A6HHBOM9j+NKwy15sfneT5iebt3bNw3bemcelACuA2xWAIMiAg9/mFCAndLZ b6K2+yRHzInk3bRxtKDGMf7f6UxECXWmLD5l0LS2zLJGolKjdscqSM49M/jR qBPI2mRSrFIbRJGbYqNtBLccAevzDj3HrRqAbtM+1fZc2n2j/nl8u/pnp16c 0agNiWF9QuLVrOBREiSK4AO4NuHIxxgqfWgBkM+nXF3FDbR2s6OjsZIyrAFS gxx/v/5zQAamBZWklzDYWsyRI0kgdthwBnjCnPf0oAnt7YNGTc2VrG+eBGd4 x9So/lQBFceUk5gt7CKeRFEkgwq4UkgYyOWODgcDg5I4yANaS1LWDQ2sEkF4 cCTbgj5C4OMc5Cn0xQBYEViduI7c7mKLwvLDOQPcYPHsaAGRNpk07wRG0kmT O6NdpZcHByOo5o1AYlxo7xSSpNYNHHje4ZCFz0ye2aNQI7K60y70+G7ItEV1 BYZUhG27ipPqBkn6UagStLpKWy3LPZLA5wspKbWPPAPTsfyo1AJJdJijWSV7 JEYKQzFACGzg598HH0NGoDNQn06xhmLR2pnSFpVgJUM4UE8Dr2POKAK0t/aJ dpGtlE8JlERcLlgxfZnAXAXdkZYjO1sA4GQDQZdOSFZmFqsTjKudu1hgtkH6 An6CgAhXTp5JI4RayPEcSKm0lD6EDp0P5UARQSafJai4kS0SNmcK25GVgpbk Hp91Sfbn0oAVpdJS2W5Z7JYHOFlJTax54B6dj+VGoEF3e6TayWqubIC4OdxZ BhNrEP7glQM+9GoDpbrTItTisWFoJHUkglQVbK7Vx6ndkfSjUC99ktv+feL/ AL4FAEETaZPL5UJtJJNofYm0nacYOB25HPuKNQK0Lafd6gi2lxayoELPHF5b dOBnuPvf+OjkchgDQ+yW3/PvF/3wKAD7Jbf8+8X/AHwKAD7Jbf8APvF/3wKA D7Jbf8+8X/fAoAPslt/z7xf98CgA+yW3/PvF/wB8CgA+yW3/AD7xf98CgA+y W3/PvF/3wKAD7Jbf8+8X/fAoAPslt/z7xf8AfAoAPslt/wA+8X/fAoAPslt/ z7xf98CgA+yW3/PvF/3wKAD7Jbf8+8X/AHwKAD7Jbf8APvF/3wKAD7Jbf8+8 X/fAoAPslt/z7xf98CgA+yW3/PvF/wB8CgAEMUUsXlxomS2dqgZ4oAp1+s8N /wDIrpf9vf8ApTGVLf8A5CF3/wAA/lX5KBbpAFABQAUAFAGXrkFxP9h+z27z eTdJM+1lGFX6kc800Ig1ayunv554IDMs1i9sArKCrE5BOSOOe2aaYFuxt5LZ 7eF7WM+VaLGboMM5GBsxjOO9JgXm6x/9dE/9CFCGS3thHealbPcW0U8EcMoP mKGAYlMcH2DUxGfFYXNuvlJausLNIFW3kWLjzXZd7A7goDKRs5GWyD0oAl0X SjDp9xBe26qZ0jjfkZZRCikZHoQw/wD10NgMubO8lnC+RKQl0koKyqkITzQx IUHLMRydw67iD0BAH3cN1d3OoxLZyxpc2v2dJXZNoI8zk4YnB3Dtn2FAE8KT z6zFdvYtbotu8RaRkLklkIB2k8cHHPrwOMgBO9xqWh3yfY5beZ0liSOQrluC Ac5xz/nIwSAXL2eS2s5p4rd7h0UssSdWPp/n8AelAFM2H2vUpLmdbiJGt4lU JO0ZDAuSDsbnGR6j0oArJFeW9po0QsZpWtFRpdjx4B8pkI5YZOSPb3oAtw2M iaiSx/0WNmniHpI+Q3vx8554Pm/7IoAz7PTrtYrW3uEuJltUI2zvCIGPllMD apcg7v4h05PIwWBoactx57GaCZY0XEbXJRpFyR8oKk5Xgfe5yBy2eEBWt7O4 MGlW89quyxdAzMyncViddwHpu247+wxQBPf2rpOJbeGVhIWMxgZRKxIUYBYj CkLztIOQpHc0AQaHp01pczS3MCoxQqrb/MIzNKxG48nhkOT178ihgU1069j0 G5082HnSXECYJdNiMIUTByc7gyZGAR05HJD6gTyabcx3u2NHaKSdZHkVVI2i YygcupUgswPDZGCMHIpXAiurLUJtItrBLNs20LRs5kXDnyHQFRnoSR1weRx1 wwNaSBor63lggzDBbSoETA5Jj2qASOyn24pAUba1uJvsq3Fi8aw30lwfNKEY bzSpGGPILL+PTpmgBLixvU1Sa7iFwFLsB9nMW9gyQjPz8YzG3v07UATraTwW lk6xSyvBcPO8ZdDI28Sd+Fzl8kdBzgnjIBPcJdC7tbpLdZHWF4mRZAArMUOc nHyjackDPI4NAEz3Mq6hFbC1laJ0ZmnBG1CMYB5zzn/9fOADJl0id/D+n2MU SRyJEyyDIAVmgdSTjr8zc4z1zRfUCyl352sxPLC1sIoZIz5sseSzNFgYVifT /voeooA1qQBQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAMf/Ww/Vv5C mBQr9Z4b/wCRXS/7e/8ASmMqW/8AyELv/gH8q/JQLdIAoAKACgAoAKACgAoA RiFAY54YEYGec8frTAl+2T/3ZP8Avwf8KNRB9sn/ALsn/fg/4UagH2yf+7J/ 34P+FGoB9sn/ALsn/fg/4UagH2yf+7J/34P+FGoB9sn/ALsn/fg/4UagH2yf +7J/34P+FGoB9sn/ALsn/fg/4UagH2yf+7J/34P+FGoB9sn/ALsn/fg/4Uag H2yf+7J/34P+FGoB9sn/ALsn/fg/4UagH2yf+7J/34P+FGoB9sn/ALsn/fg/ 4UagH2yf+7J/34P+FGoB9sn/ALsn/fg/4UagH2yf+7J/34P+FGoB9sn/ALsn /fg/4UagH2yf+7J/34P+FGoB9sn/ALsn/fg/4UagH2yf+7J/34P+FGoB9sn/ ALsn/fg/4UagH2yf+7J/34P+FGoB9sn/ALsn/fg/4UagH2yf+7J/34P+FGoB 9sn/ALsn/fg/4UagH2yf+7J/34P+FGoB9sn/ALsn/fg/4UagH2yf+7J/34P+ FGoB9sn/ALsn/fg/4UagH2yf+7J/34P+FGoB9sn/ALsn/fg/4UagH2yf+7J/ 34P+FGoB9sn/ALsn/fg/4UagH2yf+7J/34P+FGoB9sn/ALsn/fg/4UagH2yf +7J/34P+FGoB9sn/ALsn/fg/4UagH2yf+7J/34P+FGoB9sn/ALsn/fg/4Uag H2yf+7J/34P+FGoB9sn/ALsn/fg/4UagH2yf+7J/34P+FGoB9sn/ALsn/fg/ 4UagH2yf+7J/34P+FGoEkE0ks6bwwAzjchXt9KaAr1+s8N/8iul/29/6UxlS 3/5CF3/wD+VfkoFukBna7c3NpYCa2D4WRTMyKCyx/wARAPGf8+9NCZBa6kbe KNp5ZLuG6uRHbzqqDggYDAY77h07HpxTsBDe6y7JbzWxmhCXwtp42RWLdz0y fy9/aiwE1/q6nR7i5gaaBopfKkIjV2iYEA5BOD2HBPWhLUCf+2rb7T5WyXZ9 o+zebgbfMx93rn2zjFKwFO78RhLCW5tbO4kQKSkzqBGfm25znPXtjP0607Bc 1kuS1ysBt5kJi8wuVG0c425Bxu9qQyVusf8A10T/ANCFCAqXMi2+rNHFLNbr J5jObWASOSBGQCMPgZkc9F5bOOcsxGhJfw6fHNHcTSyvbw+cWfaGkB3nAxgE 4Ruw4H1oAh1bVGt7S++zxTFoImzMqgrG+zcARnJ6qcgEc89DgSAuPcyrqEVs LWVonRmacEbUIxgHnPOf/wBfOABNVmkt9JvJ4m2yRwO6nGcEKSKEBnw6kkNx +71BtRhKHcVMbFHLKqKCgAG4sfvenUAGgDQhvTL5yG2mjniUOYWKbmBzjBDF eSpHXtzigB9lPJc2cM8tu9u7qGaJ+qn0/wA/iB0oAzr6/voNWkgt4vOjaCMI AhbZKzOAzY6J8vzHtxjvQBGkt5cWmjSi+mia7VFl2JHgnymcnlTg5A9vagCH +1dS3eVs4+3Y8/y/l8nz/L2Z6b8/+O89adgLWhSzXltBcSX15IxiVpI5IFRC WXsdgyM+h9KTA2KQGUurJb2CXFyJiHnlQ5VQYwpcnIBxhVQ8jJOOmTTsBMdW jJhWO3uJZZRJiNFGQUYKwJJwME9c4OODyMlgG3V40ljDcW0jxH7THG6kDP8A rQjqevqeR6cHFAD7jU0geb9xNJFb/wCulXbtj4DHIJBOFIPAPX14osAlvq9v Pd/ZgkqPvaMFgMEgsOx7+XJj/dOcZGSwEb63DHb/AGiS3uFt2RpIpTtIlAUv wA2RlQT8wHTnBosBKNSLMUFnc7ypeNCEBlUEAkZbjG4cNg89OtFgItO1CeXR rW4mtbiSaRE+VQmZCVBLDBwB16kemMkAgEE+t+dYJPYRSyH7RHE+xo225dMr ndg5DYBBOM8kY4LAXr25eK1gkCyxGSaJWwFYpucDB5xznbkZxnIzQA241NIH m/cTSRW/+ulXbtj4DHIJBOFIPAPX14osAiatG7/8e9wIhMYGmKgKH37AOuTk 45AI55xg4LAXJ5o7eCSeVtscal2OM4AGTSAzJNWeO/iSW3uIFMLkxOqku2+N UwQSOrEdRjOTgYNOwE51VVPlva3CXJIC252bmyGIIIbb0R+pH3fcZLASw3yy zpA8E0MrK7bZAOApXPIJB++Ome/cYoAqSa/axyOrxzAJu3PgYG1nB756RO3T oPUgEsBPcamkDzfuJpIrf/XSrt2x8BjkEgnCkHgHr68UWARNWjd/+Pe4EQmM DTFQFD79gHXJyccgEc84wcFgI7DUJ5p78XFrcRxwv8uQjbR5aHbhSSTyTxnr 17UAOj1dZJ5bYWswuo13+RviLkZGejkD7wPJGc8ZosA7Sbue50aC5mhlMphV iDsBlO0HIwcDJ9cfhQwG2+on7DYkJNdzzwCQBVRGYYXLEEhRyw4z34oAF1dJ ZDFBaXM0qruZFCjb8zKQSWAyGQjrz2yMkFgL0E0dxBHPE26ORQ6nGMgjIpAP oAKACgAoAKACgAoAY/8ArYfq38hTAoV+s8N/8iul/wBvf+lMZUt/+Qhd/wDA P5V+SgW6QFW+tZbkQNBOIZIZRIGKbweCCMZHUGmgM8aBstY44rhEdbv7XkRf Ju7KFzwOnencVgTQXVWBvN/+l/a1Ji534PBwcEZweAOh6Z4LhYrapYSQaPc2 USy3FxezGYskZCBi68d9ox6nseaE9QLsOiJDeyTgwssk/n5eANIp4OA5PAyP TPPXPNFwsRf2BINJm037cTAx/dZiGUG4Nzzz09up9sF9bhY0ooblLgPJd+ZH 5eDH5YHz5zuB64xxj9SaQyw33o/+uif+hChASw2076mt08UyAI4Ctg43CI4+ 8e6noAOv1ZiI9S0QX85kMjoGTy2AXORh149Plkf152nsQQAvdJuLhLyKG58m K8B8zMO5gdgXg5xjCjjGevIyMAFt7SdtQiuRcTLEiMrQADa5OME8Z4x/+rnI At9aNeWNxbZKedE0e7bnGQRnH40AV7/SReGQZ2pIAZIzHuWR1ZSpYd/u4I7g 4zwMABYaU1nHMFEMTygDNrbLEFxnBwc5PPckdOOuQCxZW01tZwwSzSXDooVp XHLH1/z+JPWgAS0Zb6W5yT5kSR7dvTaXOc/8D/SgCl/ZN4kOnxQXMSrZKoG+ 3LFmCFM8OOMN0/WgCf8Asxvsf2fef+Pn7Ru2f9NvMx/TP4+1ADdOsb+zht7d 7iGSCFBHgW7KxAGBzvI9O1AF50lMbCP5XwdpZSQD7jjP50AZH9hTzW32e7uV ePzZZP3UJQ/vFkDDJY/89OPp3pgOOl3kV5A9tLtCC4Yu0e5cySKwUrkE8Z5B HKj6FAPm0q6NlHbw3CIRN58jPAW3P5nmcAMMDdnjnjv3oAin0Dz7h5pFtHab aZXksw7ghQp2En5RgZAIbBz16UwJYdEEV3HciRy6zNIRt4IJlIHt/rjz7dBS Aqr4YVLd4EFqi+S0SSJZgS8qVyz554OTgLk+gyKdwNZ7RmvornJHlxPHt29d xQ5z/wAA/WkBSOjTGxjtGnWSOHasUckG6MqoIAdc/Oec9QMqpAGDkAeulTeR crLOXlmnS4D+XgKyhMDGeVyg4znHGc80AOu7C9uLWKJbpAyusju8BbcVcMAA GGBkY7nHfPNAEc2lXUqXEf2hBFdj/SB5B3ElAjbDu+XhRjIbB9elAE39mN9j +z7z/wAfP2jds/6beZj+mfx9qALF1ai7tJraQOEmRo2K9QCMcUAUJtIu7qZJ rm7VnjXCCODagO9HBILEnlBnnkdMdSAK2lXTzi6kuEN2pXYywERgAOOV3ZPE jfxDt6HIBI1hemSO4F0hukDLloD5e1tuQFDA/wAA5LHqfbABTbw1vimWS5kd pFcBzGAQW87kgdeJj0x0/CmBLd6CtxeSz7LUiYguZrQSOMKF+VicDgDqDznr 0pAWf7Mb7H9n3n/j5+0btn/TbzMf0z+PtQAPpszTXJS4kiiucs4RcOG2BMhu wwAemcjrjigCOy0qa3uYpmeILFE8aQwW/lIAzK2QMk5yvPPp05yASWtjd2ln 9niuFPlqscO+HIVV4GQCCzEdTkDpgDnIBBb6TeW0FqEuYjNaxGBHNudpjIXq u/O7KDnOOvFAE9hpjWc0spcu0qgN8mBu3u5I9syHA7Y6mgCaxtGs7G3tsl/J iWPdtxnAAzj8KAJ9rf3T+VABtb+6fyoANrf3T+VABtb+6fyoANrf3T+VABtb +6fyoANrf3T+VADJARLDkY5b+QoAz6/WeG/+RXS/7e/9KYypb/8AIQu/+Afy r8lAt0gCgAoAKACgAoAKACgBrkgDaASWCjJx1OKYEv2a5/uxf99n/wCJoAPs 1z/di/77P/xNAB9muf7sX/fZ/wDiaAD7Nc/3Yv8Avs//ABNAB9muf7sX/fZ/ +JoAPs1z/di/77P/AMTQAfZrn+7F/wB9n/4mgA+zXP8Adi/77P8A8TQAfZrn +7F/32f/AImgA+zXP92L/vs//E0AH2a5/uxf99n/AOJoAPs1z/di/wC+z/8A E0AH2a5/uxf99n/4mgA+zXP92L/vs/8AxNAB9muf7sX/AH2f/iaAD7Nc/wB2 L/vs/wDxNAB9muf7sX/fZ/8AiaAD7Nc/3Yv++z/8TQAfZrn+7F/32f8A4mgC JvMW5W3Ij81xlRluRzk5244xz6ZHqMlgJfs1z/di/wC+z/8AE0AH2a5/uxf9 9n/4mgA+zXP92L/vs/8AxNAB9muf7sX/AH2f/iaAD7Nc/wB2L/vs/wDxNAB9 muf7sX/fZ/8AiaAD7Nc/3Yv++z/8TQAfZrn+7F/32f8A4mgA+zXP92L/AL7P /wATQAfZrn+7F/32f/iaAD7Nc/3Yv++z/wDE0AH2a5/uxf8AfZ/+JoAPs1z/ AHYv++z/APE0AH2a5/uxf99n/wCJoAPs1z/di/77P/xNAB9muf7sX/fZ/wDi aAD7Nc/3Yv8Avs//ABNAB9muf7sX/fZ/+JoAPs1z/di/77P/AMTQAfZrn+7F /wB9n/4mgA+zXP8Adi/77P8A8TQAfZrn+7F/32f/AImgA+zXP92L/vs//E0A H2a5/uxf99n/AOJoAPs1z/di/wC+z/8AE0ASQRSxzoZAgznG1ie30FNCIK/W eG/+RXS/7e/9KYypb/8AIQu/+Afyr8lAt0gCgAoAKAK2oyvBpt1NEdrxwuyn GcEAkU0BnWWnWr6VZTkJFM3kyvMfvOxZWIY5ycnse+PQU76iE0u3i1CfUZ7t BLKl28KO3VFXG0Kf4cZPIwc80PQC9YxzQpbxJJDLZpbKocZ3Mwxz6bSKTGW2 6x/9dE/9CFCAm1ssuiXzKEbEDkq4JDDByOCDyMjrTQiC/wBRmivjbQt5e2JZ C32SSfduLDGEI2429+ufagCJHvbjV9PnJigElq7mF4mLICYtyk7hznvgYx0N ADgk9x4ikFxbwlIYo2jcTNujBaTlRtGC2AGGegHJ6UdAJ57x3tpxcWl5Zw+U 5efdHmMbTkjaxOfTANAFO1sIzcCCe2isjJCG8q2UKswDKW3gceg28gB2AZsn AA+CxspRPN5cUOmgqyxAKsMoVWzIw6YJb/yGrZIxQBRuozGqxGJYrOYvKLdk GyJA8SbipGBhWeTBGAWyRlc0wJ4Vjk8P2xDrOsV+oikODwLnaCMcD5eOMDHA 4o6gad+WF9pvCFTOw5ByD5TkEEH0BHIPXtikAz7TeDUfJdoUQt8kbRN86+ok zjdjJ27c8Ht81AEekpdLfal580Lr54BCRFSW8qPnljxjt+Oe1DAuX9w9ta74 wpdnSNd3IBZwuSO+M5xxnHUUAVZ5tSt2t4i1pI883liTYygDY7H5cnptB685 xx1oAiudQvbaWO2lCLI29hMls8odV2f8s1OV5fGSf4f9oYAC1vtRvZmijWG3 2RK5eaF8kl5F+4SCAQgbk8ZxznIANGxuPtljb3O3Z50Sybc5xkA4z+NAFBL+ 92faX+ziAXRt/LCtuYed5YbdnA7HGDnHUZ4AIbHVbu8NuyL8tyuQDZyqIcqW BLk7XGQBxjOcjFFgHaJ9oWTbPNE4L3OFRCnIm5OC5zz0+XjOM88jA2qQBQAU AFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFADH/1sP1b +QpgUK/WeG/+RXS/7e/9KYypb/8AIQu/+Afyr8lAt0gCgAoAKACgCpFpdnCw KQ8K25ULEojZzlVJwpz6CncBZdOtZZ2meM73AD7XZQ4HQMAcN6c544ouA9LK 3juVuEiCyLF5II4ATOcY6UATEZKezqT9AQaEBZvIrS9gMFxIxjbqFd0yMYwd uMjnpTERNZWLBR5swKjG9Z5QxGScFgctjJxknGTii4D5rawmjjjcJsjG1VUM o2/3cDqpwMqeDgcUASj7Ms7zhx5jqqMfm5AJI/8AQj+dADne3kjaORkdGBDK ykgg9iMUgKbafpzRSRu8siyrsYvPKx29wCTkA4GQOuOadwBtP094jE81wyll f5rmYkFeRg5455/AegouBJ9lsvI8kyysu7eGaaQupxjhidw444Pc+poAbNZW M8EcMkszJGcr+/lznOck5ycEDGenai4BPZWNwYjJLMTCAEInlXHBGeDycEjP Xmi4C/ZLDz/O3Nndv2b38vdnOdn3c55zjrz15oAk8qy+1facjzfX5sZxjdjp uxxnGccZxQBEllYqbsmV3F04kcO7naQBgr/dxgEEcjjHQYLgLFaWETo6szOj bg8ju7ZwR1bJxhm46cmgCS5itLraZZGDLnDRu6MAeoyuDjgcew9KAC3isrZi 0JCsVCk/MSQCTznqcsxJ6nPNAET2ViwsgsrotkQYlR3A4XaAfXj/ADgkEuBL 5Vl5PlZGzzfNx8339+/P/fXNAEcNpYQSrJGzZX7is7sidvlU8LxxwBgHHSgB iWsMV811FNGrHIwVkIAJUtgbtoJKkkgdSD2O4AvedD/z0H5H/CkAedD/AM9B +R/woAPOh/56D8j/AIUAHnQ/89B+R/woAPOh/wCeg/I/4UAHnQ/89B+R/wAK ADzof+eg/I/4UAHnQ/8APQfkf8KADzof+eg/I/4UAHnQ/wDPQfkf8KADzof+ eg/I/wCFAB50P/PQfkf8KADzof8AnoPyP+FAB50P/PQfkf8ACgA86H/noPyP +FAB50P/AD0H5H/CgA86H/noPyP+FAB50P8Az0H5H/CgA86H/noPyP8AhQAe dD/z0H5H/CgA86H/AJ6D8j/hQAedD/z0H5H/AAoAPOh/56D8j/hQAedD/wA9 B+R/woAPOh/56D8j/hQA0yI80QRt2C2eD6UwKVfrPDf/ACK6X/b3/pTGVLf/ AJCF3/wD+VfkoFukAUAFAEF5eQWMBnuXKRggFgpbH1wKYDbe+t7iZoUZxKq7 ikkbI23pkBgMiiwEaatZOV2ykqz7Ffy22u2cYVsYPPoexPQUWAfLqNrFO0Ly HegBfajMEB6FiBhfXnHHNFgJ4ZUnhSaI7kkUMpxjIPIoAV8kKASu51XI9yBQ gH29u8ss6PIyiJtuVkViT15G3jgr19T2wSxE32Ef895f/Hf8KQB9hH/PeX/x 3/CgA+wj/nvL/wCO/wCFAB9hH/PeX/x3/CgA+wj/AJ7y/wDjv+FAB9hH/PeX /wAd/wAKAD7CP+e8v/jv+FAB9hH/AD3l/wDHf8KAD7CP+e8v/jv+FAB9hH/P eX/x3/CgA+wj/nvL/wCO/wCFAB9hH/PeX/x3/CgA+wj/AJ7y/wDjv+FAB9hH /PeX/wAd/wAKAD7CP+e8v/jv+FAB9hH/AD3l/wDHf8KAD7CP+e8v/jv+FAB9 hH/PeX/x3/CgA+wj/nvL/wCO/wCFAB9hH/PeX/x3/CgA+wj/AJ7y/wDjv+FA B9hH/PeX/wAd/wAKAD7CP+e8v/jv+FAB9hH/AD3l/wDHf8KAD7CP+e8v/jv+ FAB9hH/PeX/x3/CgA+wj/nvL/wCO/wCFAB9hH/PeX/x3/CgA+wj/AJ7y/wDj v+FAB9hH/PeX/wAd/wAKAD7CP+e8v/jv+FAB9hH/AD3l/wDHf8KAD7CP+e8v /jv+FAB9hH/PeX/x3/CgA+wj/nvL/wCO/wCFAB9hH/PeX/x3/CgA+wj/AJ7y /wDjv+FAB9hH/PeX/wAd/wAKAD7CP+e8v/jv+FAB9hH/AD3l/wDHf8KAD7CP +e8v/jv+FAB9hH/PeX/x3/CgA+wj/nvL/wCO/wCFAB9hH/PeX/x3/CgB8duI JoyJHfcT97HHHsKaAq1+s8N/8iul/wBvf+lMZUt/+Qhd/wDAP5V+SgW6QBQA UAY/ix1Xw9cBmALFAoJ6ncDgfgD+VVHcTKbZur+/itZhfeZp5UTfISrZYBNy gAZznB9PagC5YXdpJpdlbMTLMgiRoUB3oykDLDqAGHJPH58jAZpdxFp8+owX biKV7t5kRurq2NpUfxZweBk54oeoFqzNst5BHFJcROLRSto+dqpngkf3h065 pAX26x/9dE/9CFCGXbdszXQ3ZxKBjOcfIvucfkPp3LET0gCgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo AKACgAoAKACgAoAKACgAoAKACgBj/wCth+rfyFMChX6zw3/yK6X/AG9/6Uxl S3/5CF3/AMA/lX5KBbpAFABQAUAFABQAUAFACEZKn0YN+RzTAmieKIgqkxIG PmnZuwHf/dH6+pyXES/a1/55n/vr/wCtQMPta/8APM/99f8A1qAD7Wv/ADzP /fX/ANagA+1r/wA8z/31/wDWoAPta/8APM/99f8A1qAD7Wv/ADzP/fX/ANag A+1r/wA8z/31/wDWoAPta/8APM/99f8A1qAD7Wv/ADzP/fX/ANagA+1r/wA8 z/31/wDWoAPta/8APM/99f8A1qAD7Wv/ADzP/fX/ANagA+1r/wA8z/31/wDW oAPta/8APM/99f8A1qAD7Wv/ADzP/fX/ANagA+1r/wA8z/31/wDWoAPta/8A PM/99f8A1qAD7Wv/ADzP/fX/ANagA+1r/wA8z/31/wDWoAPta/8APM/99f8A 1qAD7Wv/ADzP/fX/ANagA+1r/wA8z/31/wDWoAPta/8APM/99f8A1qAD7Wv/ ADzP/fX/ANagA+1r/wA8z/31/wDWoAPta/8APM/99f8A1qAD7Wv/ADzP/fX/ ANagA+1r/wA8z/31/wDWoAPta/8APM/99f8A1qAD7Wv/ADzP/fX/ANagA+1r /wA8z/31/wDWoAPta/8APM/99f8A1qAD7Wv/ADzP/fX/ANagA+1r/wA8z/31 /wDWoAPta/8APM/99f8A1qAD7Wv/ADzP/fX/ANagA+1r/wA8z/31/wDWoAPt a/8APM/99f8A1qAD7Wv/ADzP/fX/ANagA+1r/wA8z/31/wDWoAPta/8APM/9 9f8A1qAD7Wv/ADzP/fX/ANagA+1r/wA8z/31/wDWoAPta/8APM/99f8A1qAF SYSzxgLt25757U0IqV+s8N/8iul/29/6UxlS3/5CF3/wD+VfkoGeddmS1ubq WzjENrP5Mu2clsggEqNoB69yKdhXNR720jmaJ7qFZFGShkAIGM5x9OaVhgt3 DKWjt5oZZgm8IJByMcE4yQORzjvQBV07Wba8sop5ZIrd5FZvKaUZCgkE9uPl JoaEaCOsiK6MGVhkMDkEetIZlX2q3NpdCMWIaNp0gjkeXbvZhnONp4HTP/16 pIRZh1FFtY5NQ8uxkcsPLlkA6HHBOM9j+NKwy15sfneT5iebt3bNw3bemcel ACuA2xWAIMiAg9/mFCAryXNpZan5F0kbRSF/3jLGFh2hW+Yj18wDJx0UYOdx YiW1vtMkso7m6it7LzGdVjuNqN8rFTnPfjkds0agWpG0yKVYpDaJIzbFRtoJ bjgD1+Yce49aNQG2v2OePc1vBGTNJEqkD5ijMOOPRScUAOvktrOxuLn7JE/k xNJt2gZwCcZx7UANH2NpJSLeAW8IPmTMAFDDqBxzjnJ6A8cnOAAWXSXtmuVe yaBDhpQU2qeOCencfnRqANLpKWy3LPZLA5wspKbWPPAPTsfyo1AS6NtDbwzw 2tvNHJLGm4YA2uwUMMA56j0+tAD51tIri2h+z25adiMHapwFJJAP3ucDj1zQ ABtMM6wA2hmbO2P5dxwSDgdeCD+Ro1AI20yWVoozaPIrbGRdpIbngj1+U8ex 9KNQJ/slt/z7xf8AfAoArI+nPGshjgSORxHE7qoEpPTb655x64yMjBIA6VtM hgSeU2kcL42yNtCtkZGD0PFGoDEexaeVfJtxDHAk/nfLtKsX5+mEzn3oAfI2 mRSrFIbRJGbYqNtBLccAevzDj3HrRqBRlv7RLtI1sonhMoiLhcsGL7M4C4C7 sjLEZ2tgHAyAaKRWMmzZHbt5i70wFO5eOR6jkc+4oAihNlIZ8xWoSKYQhgVO TheD6HcduDzx70AQXV7pMGmzXsZspkjDBdrJh3AzsB9T6UagTtLpKWy3LPZL A5wspKbWPPAPTsfyo1AJJdJijWSV7JEYKQzFACGzg598HH0NGoEix2ZuWgNt GsgG5Q0Y+deMkeuCcHuOPUZAJfslt/z7xf8AfAoAPslt/wA+8X/fAoAPslt/ z7xf98CgA+yW3/PvF/3wKAD7Jbf8+8X/AHwKAD7Jbf8APvF/3wKAD7Jbf8+8 X/fAoAPslt/z7xf98CgA+yW3/PvF/wB8CgA+yW3/AD7xf98CgA+yW3/PvF/3 wKAD7Jbf8+8X/fAoAPslt/z7xf8AfAoAPslt/wA+8X/fAoAPslt/z7xf98Cg A+yW3/PvF/3wKAD7Jbf8+8X/AHwKAD7Jbf8APvF/3wKAD7Jbf8+8X/fAoAPs lt/z7xf98CgA+yW3/PvF/wB8CgAEMUUsXlxomS2dqgZ4oAp1+s8N/wDIrpf9 vf8ApTGVLf8A5CF3/wAA/lX5KBz8mkX8kF3KsMqym7M628kimOdCwOGAbGRj P6c9quhFi20q4N05uIrgIb37WgDxhB0PzdWyORgcZ796VwK+g29zLb6TcLBm K1Wdshxl9xICgHHOc9eMd+1NggS2ubXSrCJRFBqdrIQqyODhJGK7gATxll6+ h/E6gdB9hZFVILy4hiRQqRoEIUAY6spP5mpuMqazb3MqWCwRSXBguUldsoCQ vXqQMnPbj6U0Ii1ayunv554IDMs1i9sArKCrE5BOSOOe2aEwLdjbyWz28L2s Z8q0WM3QYZyMDZjGcd6TAvN1j/66J/6EKEMj8uC/1bL+TcW5ikG1mVwQRAww Nx44z0HbjkEsREtneRs6mCUpI8h/cSrGTmV2XzHzuC4ZSNnPLZB6UAP0XSjD p9xBe26qZ0jjfkZZRCikZHoQw/8A10NgSWFjcWk7XDBpTJNKDGxX90jSswZD 75BYHk8f3QpALmqwyXGk3kES7pJIHRRnGSVIFCAp31jcCA2toG8jKSptKhoi kitsXPByAdoPAIx0IAAIBa3pL3Oy7MpKLmUwGYKof7gA2Dl+pOSC3TjIA2Cz uYBPILS5VnnLRtHcK8yKUQcmQ4IO0ggk4IGM4DAAs3a3R023RbBmlMySyLCU ULtkVznLDk4JwCec8nqQB9+9y89hJHYXEgifzXw0Y25jddvLDkFh7e9ADFsJ U09o1hVZXv8Az2xj5l+0BtxP+4B78YoAp6Fco95BA7Za3gMUKLt3Iny8SAMW DAKoOVUA5HORTYG7dW6XVtJBIWCuMEj/ADg/Q5B6EEVIGZqtneajZJAY0Eqt IrPnCEGGRQw6kDLDjkjnqBktANNrdRRJiGUjzrguIGQSlXlLABmIwpHXBDZ2 4xg0AV7DSLyOVpZBsMfzLE0m+ORhLKwDNjccB1IPqQSCRincDRtrJZW1Jrm2 2LeMAQSNzJ5SrglT2O4dfXHWkBRk025jvdsaO0Uk6yPIqqRtExlA5dSpBZge GyMEYORRcCTRtPvLa4iNz9yCAxL8+R92JePQZiZu33x3yAMBr29zdi8il06V I7i6hmxK0ZUopiDAgMeyMfp+VAFq9sZrmTUlQKBc2SwozHjd+8znv/EKAIrx L6ee3u0huYNiyR7IWiMuGKEE7srj5T0JP3fUgADtJ097a8lnlibLwgB5GVny ZJHYEqAB95SQOPQnGaGBYWzy8EKx+Va2m3yucsxAwMHqFAOPU8g8Z3AF6kAU AFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFADH/ANbD9W/kKYFC v1nhv/kV0v8At7/0pjI7aAC6uZZHCK5XaMZJwK/JQLPlxf8APb/x00aAI8Nv IjI8gZWGCpTII9KAGQWdnbIUtzHEpOSscW0Z9eKABrOzadZ2MZmUYWQxfMB6 A9e5/OgCTy4v+e3/AI6aNADy4v8Ant/46aNADy4v+e3/AI6aNADy4v8Ant/4 6aNADy4cg+d0II+Q9Qc0ATed/wBPA/79UxB53/TwP+/VAB53/TwP+/VAB53/ AE8D/v1QAed/08D/AL9UAHnf9PA/79UAHnf9PA/79UAHnf8ATwP+/VAB53/T wP8Av1QAed/08D/v1QAed/08D/v1QAed/wBPA/79UAHnf9PA/wC/VAB53/Tw P+/VAB53/TwP+/VAB53/AE8D/v1QAed/08D/AL9UAHnf9PA/79UAHnf9PA/7 9UAHnf8ATwP+/VAB53/TwP8Av1QAed/08D/v1QAed/08D/v1QAed/wBPA/79 UAHnf9PA/wC/VAB53/TwP+/VAB53/TwP+/VAB53/AE8D/v1QAed/08D/AL9U AHnf9PA/79UAHnf9PA/79UAHnf8ATwP+/VAB53/TwP8Av1QAed/08D/v1QAe d/08D/v1QAed/wBPA/79UAHnf9PA/wC/VAB53/TwP+/VAB53/TwP+/VAB53/ AE8D/v1QAed/08D/AL9UAHnf9PA/79UAHnf9PA/79UAHnf8ATwP+/VAB53/T wP8Av1QACVS6s8+7bnA2YoAqV+s8N/8AIrpf9vf+lMYzZJ/z3X/vz/8AZV+S 6AGyT/nuv/fn/wCyo0ANkn/Pdf8Avz/9lRoAbJP+e6/9+f8A7KjQA2Sf891/ 78//AGVGgBsk/wCe6/8Afn/7KjQA2Sf891/78/8A2VGgBsk/57r/AN+f/sqN ADZJ/wA91/78/wD2VGgBsk/57r/35/8AsqNADZJ/z3X/AL8//ZUaAGyT/nuv /fn/AOyo0ANkn/Pdf+/P/wBlRoAbJP8Anuv/AH5/+yo0ANkn/Pdf+/P/ANlR oAbJP+e6/wDfn/7KjQA2Sf8APdf+/P8A9lRoAbJP+e6/9+f/ALKjQA2Sf891 /wC/P/2VGgBsk/57r/35/wDsqNADZJ/z3X/vz/8AZUaAGyT/AJ7r/wB+f/sq NADZJ/z3X/vz/wDZUaAGyT/nuv8A35/+yo0ANkn/AD3X/vz/APZUaAGyT/nu v/fn/wCyo0ANkn/Pdf8Avz/9lRoAbJP+e6/9+f8A7KjQA2Sf891/78//AGVG gBsk/wCe6/8Afn/7KjQA2Sf891/78/8A2VGgBsk/57r/AN+f/sqNADZJ/wA9 1/78/wD2VGgBsk/57r/35/8AsqNADZJ/z3X/AL8//ZUaAGyT/nuv/fn/AOyo 0ANkn/Pdf+/P/wBlRoAbJP8Anuv/AH5/+yo0ANkn/Pdf+/P/ANlRoAbJP+e6 /wDfn/7KjQA2Sf8APdf+/P8A9lRoAbJP+e6/9+f/ALKjQA2Sf891/wC/P/2V GgBsk/57r/35/wDsqNADZJ/z3X/vz/8AZUaAGyT/AJ7r/wB+f/sqNADZJ/z3 X/vz/wDZUaAGyT/nuv8A35/+yo0ANkn/AD3X/vz/APZUaAGyT/nuv/fn/wCy o0ANkn/Pdf8Avz/9lRoAbJP+e6/9+f8A7KjQA2Sf891/78//AGVGgBsk/wCe 6/8Afn/7KjQA2Sf891/78/8A2VGgBsk/57r/AN+f/sqNALkDWKwqLiO4kl/i aN1RT9AQcfnX61w3b+y6X/b3/pTAoyywW9rcXd3cvDDE4UlVBxkL7E9TX5MI of8ACQ6D/wBBWX/vyf8A4iiwXD/hIdB/6Csv/fk//EUWC4f8JDoP/QVl/wC/ J/8AiKLBcP8AhIdB/wCgrL/35P8A8RRYLh/wkOg/9BWX/vyf/iKLBcP+Eh0H /oKy/wDfk/8AxFFguH/CQ6D/ANBWX/vyf/iKLBcP+Eh0H/oKy/8Afk//ABFF guH/AAkOg/8AQVl/78n/AOIosFw/4SHQf+grL/35P/xFFguH/CQ6D/0FZf8A vyf/AIiiwXD/AISHQf8AoKy/9+T/APEUWC4f8JDoP/QVl/78n/4iiwXD/hId B/6Csv8A35P/AMRRYLh/wkOg/wDQVl/78n/4iiwXHHXtEEYkOpzhGJAbyGwS MZGdnuPzosFwGvaIYzINTnKKQC3kNgE5wM7PY/lRYLjf+Eh0H/oKy/8Afk// ABFFguH/AAkOg/8AQVl/78n/AOIosFw/4SHQf+grL/35P/xFFguH/CQ6D/0F Zf8Avyf/AIiiwXD/AISHQf8AoKy/9+T/APEUWC4f8JDoP/QVl/78n/4iiwXD /hIdB/6Csv8A35P/AMRRYLh/wkOg/wDQVl/78n/4iiwXD/hIdB/6Csv/AH5P /wARRYLh/wAJDoP/AEFZf+/J/wDiKLBcP+Eh0H/oKy/9+T/8RRYLh/wkOg/9 BWX/AL8n/wCIosFw/wCEh0H/AKCsv/fk/wDxFFguH/CQ6D/0FZf+/J/+IosF w/4SHQf+grL/AN+T/wDEUWC4f8JDoP8A0FZf+/J/+IosFw/4SHQf+grL/wB+ T/8AEUWC4f8ACQ6D/wBBWX/vyf8A4iiwXD/hIdB/6Csv/fk//EUWC4f8JDoP /QVl/wC/J/8AiKLBcP8AhIdB/wCgrL/35P8A8RRYLh/wkOg/9BWX/vyf/iKL BcP+Eh0H/oKy/wDfk/8AxFFguH/CQ6D/ANBWX/vyf/iKLBcP+Eh0H/oKy/8A fk//ABFFguH/AAkOg/8AQVl/78n/AOIosFw/4SHQf+grL/35P/xFFguH/CQ6 D/0FZf8Avyf/AIiiwXD/AISHQf8AoKy/9+T/APEUWC4f8JDoP/QVl/78n/4i iwXD/hIdB/6Csv8A35P/AMRRYLh/wkOg/wDQVl/78n/4iiwXD/hIdB/6Csv/ AH5P/wARRYLh/wAJDoP/AEFZf+/J/wDiKLBcP+Eh0H/oKy/9+T/8RRYLj4Nb 0W4njgi1SVpJGCKPKIyScD+CiwXLV5HJFdrDHO+CityF6kkentQA3ZL9qWPz 5NrEDOF5/SkMs1+tcN/8iul/29/6UwMvxJ/yKup/9dE/mlfkyEziNWl86DTX 2JGDbHCoMADzZAB/9c8nvk1aEZ1AgoAKACgDory6MSKs+o74DYxqLLMh+YwA KcEbOGIbr2z14pDKBD3GkadCzSsPtUyKFG9gCIuFGeeSePU0wHX9hax2JuLd 9rxyrHJF54mxuDEHcqhf4exbrzjGCAS3FtbS3lzJO1wYoLKCVACpblYgFJwB 0bGce+D0IBn30EUQt5YA6x3EXmBHYMVwzLjIAz93PQdfxoAuaXqF7DYX8cV5 cIkVuCirKwCEypkgZ46n8zQwJbbTIbmG3mu5vnu8u073kcfl/OyklG+Z+hOQ RnOO2aQFX7BF5H2vc/2byN2MjzN+NvTH3d/8XTHGd3FMCTVntWsdN8iGZG8g kF5QwC+bJxwo5z3/AAx3oQGVQI25/wBzqGqeX8p0+Ly7c/3NsqJuH+0QWOf7 xJGDSGEH77UNL8z5jqEXl3B/v7pXTcf9oAKc/wB4AnJoAxKYgoAKACgAoAKA CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo AKACgAoAvaH/AMh3T/8Ar5j/APQhQxnp97uF8XSOSRhCowgyRln5/wA+tQMh XzXuIT9knUq4+ZlGAM8/59qEgJa/WeG/+RXS/wC3v/SmMhutO/tXSb2y83yv NkX59u7GNp6ZHpX5MhGVdeDbi8iSKbVIdsf3dlgiEDk4ypHGSTj3p3CxV/4V 7/1FP/Jf/wCyo5hWD/hXv/UU/wDJf/7KjmCwf8K9/wCop/5L/wD2VHMFg/4V 7/1FP/Jf/wCyo5gsPm8BSTuHl1bcwVUB+z44UBR/F6AUcw7Fn/hELr7NHAur RIkZDIUsUVlIxyGByD8o5zk4ouFgk8IXUsaxtq0QiDrII1sUVNwzg7QcHrzx zxnoKLhYLjwhdXIYSatEAyCNtliiZUFSB8pHTauPTFFwsVpPAUkqRI+rZWJd iD7P0GS3971Y0cwWCPwFJEkqJq2FlXY4+z9RkN/e9VFHMFieHwdcwRLHHqyY X7jNZqzp3+VicrzzwRgnPWi4WGf8IRP53m/2x8/leVn7MPubNmPvf3eKOYLB /wAIRP8AZfs39sfuvT7MM4znbndnbnnGcZ5xmjmCxB/wr3/qKf8Akv8A/ZUc wrFpvBcheGZdT23EahC/2fIdQAoBXdj7vB7EYyOpJcdgXwXIHmmbU91xIpQP 9nwEUgqQF3Y+7wOwGcDoQXCxV/4V7/1FP/Jf/wCyo5hWD/hXv/UU/wDJf/7K jmCwf8K9/wCop/5L/wD2VHMFg/4V7/1FP/Jf/wCyo5gsH/Cvf+op/wCS/wD9 lRzBYP8AhXv/AFFP/Jf/AOyo5gsH/Cvf+op/5L//AGVHMFg/4V7/ANRT/wAl /wD7KjmCwf8ACvf+op/5L/8A2VHMFg/4V7/1FP8AyX/+yo5gsH/Cvf8AqKf+ S/8A9lRzBYP+Fe/9RT/yX/8AsqOYLB/wr3/qKf8Akv8A/ZUcwWD/AIV7/wBR T/yX/wDsqOYLB/wr3/qKf+S//wBlRzBYP+Fe/wDUU/8AJf8A+yo5gsH/AAr3 /qKf+S//ANlRzBYP+Fe/9RT/AMl//sqOYLB/wr3/AKin/kv/APZUcwWD/hXv /UU/8l//ALKjmCwf8K9/6in/AJL/AP2VHMFg/wCFe/8AUU/8l/8A7KjmCwf8 K9/6in/kv/8AZUcwWD/hXv8A1FP/ACX/APsqOYLB/wAK9/6in/kv/wDZUcwW D/hXv/UU/wDJf/7KjmCwf8K9/wCop/5L/wD2VHMFg/4V7/1FP/Jf/wCyo5gs H/Cvf+op/wCS/wD9lRzBYP8AhXv/AFFP/Jf/AOyo5gsH/Cvf+op/5L//AGVH MFg/4V7/ANRT/wAl/wD7KjmCwf8ACvf+op/5L/8A2VHMFg/4V7/1FP8AyX/+ yo5gsH/Cvf8AqKf+S/8A9lRzBYnsfAv2O+t7n+0t/kyrJt8jGcEHGd3tRzDs dHc/8fL/APXOP+clJ7AV5OsX/XWP/wBDFJbjH1+tcN/8iul/29/6UwJLdZHt rpIpPKkZiFk27tp2DBx3xX5KIZaxCHU3it5Jmhji/febM8g3kgqAWJwQAxI4 +8vXjDA0aQBQAUAFAGLpcX2ieWSZL7KXExEpum8ttsrAKFD9gMYK44pgOXW5 EsYb26s/Kt5oi6bZdz5EZfkYAxhTg59MgZOCwF+3ku2kK3VtFGMZDRTbx9Dl VI9sZ6HpxkApWdzJb2EcaBp5ZLqaGLzZT/C8hG5jk8Kh7Ht9aAFl1aWKN98E MbxS+XK0k5WJDtDD59ueQw6qBnIz0yWAS61k20ywSLaQTBA7i5uhGvJIG07T u+6T0HBHckAsBBe6tNdaPeXFlAwiS3JMnm7ZELRhwQMY4DLzuB4OAcDJYDdp Acpa32o29pplxeyStaxIZGcEFrkGB35HUbduOfvHntVAacOuea0kaJbXEoiM iraXPnDAIB3fKCPvA8Ak4OBnAKsBKNTm+wm58i3dcjEsVxvhxkgkttyMY5+U gZHOMlSwBNqc0VpHK0FuDIcKxuMxvxkbCFLMTngbecH2yWAiXXGkt3njtflg iMtwHcqVAZ1O0FeTmNuDt7dMnBYBt3r6WkkqTfZENuB5yNdbXJ2hjsXb83Bw M4ycjiiwG1SAowf6TqVy8nK2rCKNT0DFAzP9SHC+2Dj7xpgUjc3Npbai0lw8 jrdxR7wmSodYgdi89NxwOffPOQBYYnkM0KtfRKgWR7V5d0jDD42ybzjJA43D Gw9mNAECtI7GFjdsiTMos1nImUbEOS4bnBJPLYxIOcgLTAsxlobS0vVl8x/N WKTk5ZGfaEJPJKFhyRu+U5xuNIDYpAFABQAUAFABQAUAFABQAUAFABQAUAFA BQAUAFABQAUAFABQAUAFABQAUAFABQAUAUrn/j5f/rnH/OSm9gK8nWL/AK6x /wDoYpLcY+v1rhv/AJFdL/t7/wBKYE1mpeK4VXZCXwGXGV+UcjPFfkogsLBr EBReXE0YBASQJ1JyWyFBJ68k85OaYFykAUAFABQBRh054JCYr+5WMytIYsRl csxYjOzOMk96YA2lW0ljbWcm94bddgBOCw8spyR7MemKLgSRWciby99cysVK qzbBsz3ACgE9OoP6nIBBFpAji2fbblmWUyxuRHmNzu3EfLg53t1B68YouA8a aVUmO8uUmZizzAplzgDlSu3oqjgdvc5LgIulLEE+zXVxbsqCNmTYd4BJAwyk DBZsBQBzjoAAXAbcaPFPHNF9ouY4Z12yorj5ztC5LEFs4A74OOQcnJcDRpAU W0q2ksbazk3vDbrsAJwWHllOSPZj0xTuA5bF8N5l/dyMRhWLKuzkHICqAeQO oPp0JBAGpppRZCLy5852DGYFAcgY+6F2njjkHt6LguAi6UqKpjurhJlLnzhs 3HcQWGCu0ZIB4A5GepOS4FG60OVXgNoVkEJZozNIN0bM5ZiCyPnJK8kZG0c8 mi4F86ezOz/a5ozLgzLDhVkbAUnkFlyABwwxj15oAvUgKwt3jvjPEV2SgCVD xyAcMPfoDnqAOflwWBXTSAPP8y9uZfOZZDuEYw67drDCjkbF46ccg0XAcdKV j5j3Vw9yCCtwdm5cBgAAF29HfqD972GC4ANKVT5iXVwlySS1wNm5shQQQV29 EToB933OS4CrYbWhj3Zt4mMpyctLISSSwxjAJ3cd8Yxt5AL1IAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgClc/8fL/ APXOP+clN7AV5OsX/XWP/wBDFJbjH1+tcN/8iul/29/6UwJLfzfs119n2edu Pl787d2wYzjtmvyUQlv58WpG2N1LcoIfMkMqoChJwmNqjrh89fujp3YFybzf KbyNnmHgF84Hvx1x6cZ6ZHWkBBpU0lxpNnPK26SSBHY4xklQTTYFqkAUAFAF XVZpLfSbyeJtskcDupxnBCkimgKlhdCS+EUGo/2hCYmZ3zG3lsCu0ZQDGQW6 /wB3joaAJLK6mXT90izXconliG1VDMFkYDPRRwvU4/MgUARyavFcaJd3lqzg wqwYpscxkDOfvbWwCD19uvFFgLM+oeVdtax2txPKqLIRGFxtJYdWIHVenXnj POACzBNHcQRzxNujkUOpxjIIyKQGbBFdf2tLA2pXLxxRRSYKRfMWZwQcJ0+U dMd6YEg1dDGsv2S58qRS0LgKfOwpYBQGzkqCRkD8DxRYCeS+QMq28b3TNF5o 8kqRtyAOSQOckj12t6UAR6LczXmk209xG6yNEpJbb85Kg7htPAOfb6UMCXUL h7azeSMKZSVjj3fd3swVc+2SM+1AGdcLfxXphhfUZIVhVt8Pknc5Z92TJ+HC 8D0AxQBB9rum864NxqP2FQrpcRxwBfL8tWLkMu48licD2A7UwJoZ7xbgvdyX 8UX2lkB2Q+UR5hVBjG/B+UZ985xzSAv2bvHcz2bsz+SFeNmOTsbIAJ7kFW/D bkk5oAuUgCgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgDPvpUiuWLk8xx4ABJ6yelPoBV+0RyyRIm8sZU/g YfxD2pIZYr9a4b/5FdL/ALe/9KYE1mHMVwI2VX3/AClhkA7RjIyM/nX5KIbp 1pdWu4T3MMwb5mZYSju/HzE7j2GMYGOAMAYpgOt49QWzdZ7m3a5LsUkEJ2hd 3AK7hnj3/PGSAO0y1lsrGK2lmSXyVCKyxlPlAAGRk88df0oAtUgCgAoAgvrf 7ZY3Ftu2edE0e7GcZBGcfjTAlcOY2EbKr4O0sMgH3GRn86QGWNJuGs2t57m3 lHnNMqm3OwlmYkOpc7hlsjkYIB5xTuAsul3L2N7B9sQvesTI7Q5ABjCEKAw9 OMk++etFwLdtayx3MlxPMkkkkSRnZGUHys5zgk/3/wBPegB9jb/Y7G3tt2/y Ylj3YxnAAzj8KABLfbfS3O7PmRJHtx02lznP/A/0oAzLbQfsgH2d7SJo0KxS paL5oO0qCzEnd1ycAZPtkEuBoW9jHazh7c+XGVIkj6+Y2RhyT/F1yepyMngU AGn2klnAsDT+ZHGqxxDZt2qowM+rep4HAwBzkAfe2/2q1eINsY4ZHxnY4OVb HfBAOO+KAIDFfSMJ4pUt3ZQkkUqmVAQTyuGXrnqeo28DGKAIDpMq2jWMV3/o bxCJlkQu4XYEO1sgLwM9DySe+KLgTPYXEj+W90rWomE20xkyZD7wN+7GAQB9 3px70AS2cMnmzXU67ZZtoCZyY0HRTjgnJYn/AHsZIANAFqkAUAFABQAUAFAB QAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUA ZOqf8f4/64r/AOhNTAhtv+PmL/fH86ALVfrPDf8AyK6X/b3/AKUxk9h0m/66 f+yrX5KBboEFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUA FABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQ AUAFABQAUAFAGdeJG9+RJuz5K4wQP4npgMRIY5oiFfcXUDLcdfpQgHV+s8N/ 8iul/wBvf+lMZPY4VZtzKuZMjJAz8or8lEWtyf30/wC+hQAbk/vp/wB9CgA3 J/fT/voUAG5P76f99CgA3J/fT/voUAG5P76f99CgA3J/fT/voUAG5P76f99C gA3J/fT/AL6FABuT++n/AH0KADcn99P++hQAbk/vp/30KADcn99P++hQAbk/ vp/30KADcn99P++hQAbk/vp/30KADcn99P8AvoUAG5P76f8AfQoANyf30/76 FABuT++n/fQoANyf30/76FABuT++n/fQoANyf30/76FABuT++n/fQoANyf30 /wC+hQAbk/vp/wB9CgA3J/fT/voUAG5P76f99CgA3J/fT/voUAG5P76f99Cg A3J/fT/voUAG5P76f99CgA3J/fT/AL6FABuT++n/AH0KADcn99P++hQAbk/v p/30KADcn99P++hQAbk/vp/30KADcn99P++hQAbk/vp/30KADcn99P8AvoUA G5P76f8AfQoANyf30/76FABuT++n/fQoANyf30/76FABuT++n/fQoANyf30/ 76FABuT++n/fQoANyf30/wC+hQAbk/vp/wB9CgA3J/fT/voUAG5P76f99CgA 3L/fQ/RhTAzr1XN4J4ymxYgCS4A4LE9/Q0AMWKRrtJCqhEYYy65xnk9f84oA fX6zw3/yK6X/AG9/6UxjPKH/AD2n/NP/AImvyXQA8of89p/zT/4mjQA8of8A Paf80/8AiaNADyh/z2n/ADT/AOJo0APKH/Paf80/+Jo0APKH/Paf80/+Jo0A PKH/AD2n/NP/AImjQA8of89p/wA0/wDiaNADyh/z2n/NP/iaNADyh/z2n/NP /iaNADyh/wA9p/zT/wCJo0APKH/Paf8ANP8A4mjQA8of89p/zT/4mjQA8of8 9p/zT/4mjQA8of8APaf80/8AiaNADyh/z2n/ADT/AOJo0APKH/Paf80/+Jo0 APKH/Paf80/+Jo0APKH/AD2n/NP/AImjQA8of89p/wA0/wDiaNADyh/z2n/N P/iaNADyh/z2n/NP/iaNADyh/wA9p/zT/wCJo0APKH/Paf8ANP8A4mjQA8of 89p/zT/4mjQA8of89p/zT/4mjQA8of8APaf80/8AiaNADyh/z2n/ADT/AOJo 0APKH/Paf80/+Jo0APKH/Paf80/+Jo0APKH/AD2n/NP/AImjQA8of89p/wA0 /wDiaNADyh/z2n/NP/iaNADyh/z2n/NP/iaNADyh/wA9p/zT/wCJo0APKH/P af8ANP8A4mjQA8of89p/zT/4mjQA8of89p/zT/4mjQA8of8APaf80/8AiaNA Dyh/z2n/ADT/AOJo0APKH/Paf80/+Jo0APKH/Paf80/+Jo0APKH/AD2n/NP/ AImjQA8of89p/wA0/wDiaNADyh/z2n/NP/iaNADyh/z2n/NP/iaNADyh/wA9 p/zT/wCJo0APKH/Paf8ANP8A4mjQA8of89p/zT/4mjQA8of89p/zT/4mjQA8 of8APaf80/8AiaNADyh/z2n/ADT/AOJo0APKH/Paf80/+Jo0AfGoRixllICs TvK46H0UUAVbm5ga1lAmjJKEABhzxQBP5Q/57T/mn/xNGgFyC4t4oVR7KOdh 1kkdgx+u0gfpX61w3b+y6X/b3/pTArV+SAVJdTtYbo2rGUzBd2xIXb5fXgHi nYCe3uIrqBJ4HEkbjKsO9AElIAoAh+1Q/bPsm/8Af+X5u3B+7nGc9OtMCakB A17brPDAZQZJiwjA5yV+8MjgYpgT0gCgAoAdbweeZCZXXa+0BcegPce9MCX7 CP8AnvL/AOO/4UCD7CP+e8v/AI7/AIUAH2Ef895f/Hf8KAD7CP8AnvL/AOO/ 4UAH2Ef895f/AB3/AAoAPsI/57y/+O/4UAH2Ef8APeX/AMd/woAPsI/57y/+ O/4UAH2Ef895f/Hf8KAD7CP+e8v/AI7/AIUAH2Ef895f/Hf8KAD7CP8AnvL/ AOO/4UAH2Ef895f/AB3/AAoAPsI/57y/+O/4UAH2Ef8APeX/AMd/woAPsI/5 7y/+O/4UAH2Ef895f/Hf8KAD7CP+e8v/AI7/AIUAH2Ef895f/Hf8KAD7CP8A nvL/AOO/4UAH2Ef895f/AB3/AAoAPsI/57y/+O/4UAH2Ef8APeX/AMd/woAP sI/57y/+O/4UAH2Ef895f/Hf8KAD7CP+e8v/AI7/AIUAH2Ef895f/Hf8KAD7 CP8AnvL/AOO/4UAH2Ef895f/AB3/AAoAPsI/57y/+O/4UAH2Ef8APeX/AMd/ woAPsI/57y/+O/4UAH2Ef895f/Hf8KAD7CP+e8v/AI7/AIUAH2Ef895f/Hf8 KAD7CP8AnvL/AOO/4UAH2Ef895f/AB3/AAoAPsI/57y/+O/4UAH2Ef8APeX/ AMd/woAPsI/57y/+O/4UAH2Ef895f/Hf8KAD7CP+e8v/AI7/AIUAH2Ef895f /Hf8KAI5YxE5QMWwBy2M9PahjGV+tcN/8iul/wBvf+lMAr8kAwpbu2g8XFpr iKMLZbSXcDDb84+uOaroLqZqyXEUkcm4xWd3eTzbnlaBXUqNhLjlc8kDvTAd ZS3gu7dZtQF62+OMpFOyOmGzu24HmKVwScHIPXAzQBAb110WS8bULpdSjba8 TSMFV/M7r0zt7dMA8cHBbUDTtDHH4ke1TUJp4JrQuFe5LYYtnCnOfu8jvjnN LoBV0e7nupNMU3FxI00cy3QLt90cK3t2G4Yyc85zTYFbQbuKKbRoUunUt5vn x+a23nOwYzgHPb6eoofUEWdNu5pJrHzrqUvItx9uVpSPLA6EjP7vHqMUMBmk Xkhk0V5b6VzM0ySh5iRkfdUj15HXnke1D6gdHpTQvp0TW9xLcxHO2WUks3J6 5A+lSxlplQ6dfbwuFJbJOMEKCDnIxggHORjHUdaaEaKIkcaxxqqIoAVVGAAO wFIB1ABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUA FABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAU7v/j4b6D+QoYyGv1r hv8A5FdL/t7/ANKYBX5IAUAFABQAUAI6lkZQxQkYDDGR788UAVtNsU02zW2i kkeNSSvmYyM844A75/Om3cC1SAKACgAoAVPMNpdJEjszsyjYcEHyxg/eXvxw R1HI6ihF9GLDJRkOSMHHY9ePXrSAdQAUAFABQAUAFABQAUAFABQAUAFABQAU AFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFAB QAUAFAFO7/4+G+g/kKGMhr9a4b/5FdL/ALe/9KYDS6g4LAH61+SCug8xP76/ nQHMu4eYn99fzoDmXcPMT++v50BzLuHmJ/fX86A5l3DzE/vr+dAcy7h5if31 /OgOZdw8xP76/nQHMu4eYn99fzoDmXcPMT++v50BzLuHmJ/fX86A5l3JLe5j gDgkNubd94DHAH9KdxXXcm+3xf3R/wB9j/Ci4XXcPt8X90f99j/Ci4XXcPt8 X90f99j/AAouF13D7fF/dH/fY/wouF13D7fF/dH/AH2P8KLhddw+3xf3R/32 P8KLhddw+3xf3R/32P8ACi4XXcPt8X90f99j/Ci4XXcPt8X90f8AfY/wouF1 3D7fF/dH/fY/wouF13D7fF/dH/fY/wAKLhddw+3xf3R/32P8KLhddw+3xf3R /wB9j/Ci4XXcPt8X90f99j/Ci4XXcPt8X90f99j/AAouF13D7fF/dH/fY/wo uF13D7fF/dH/AH2P8KLhddw+3xf3R/32P8KLhddw+3xf3R/32P8ACi4XXcPt 8X90f99j/Ci4XXcPt8X90f8AfY/wouF13D7fF/dH/fY/wouF13D7fF/dH/fY /wAKLhddw+3xf3R/32P8KLhddw+3xf3R/wB9j/Ci4XXcPt8X90f99j/Ci4XX cPt8X90f99j/AAouF13D7fF/dH/fY/wouF13D7fF/dH/AH2P8KLhddw+3xf3 R/32P8KLhddw+3xf3R/32P8ACi4XXcPt8X90f99j/Ci4XXcPt8X90f8AfY/w ouF13D7fF/dH/fY/wouF13D7fF/dH/fY/wAKLhddw+3xf3R/32P8KLhddw+3 xf3R/wB9j/Ci4XXcPt8X90f99j/Ci4XXcPt8X90f99j/AAouF13D7fF/dH/f Y/wouF13D7fF/dH/AH2P8KLhddw+3xf3R/32P8KLhddxH1KBCA+1SRkZkA/p QMrTXtvJIX86IZxxvHpQMdX61w3/AMiul/29/wClMCKGFJ9QZJASuwnAJHPH pX5KiEk5Mmlh06GdIZNwd8Y+ZyBk4GT0GTwM4yeBmmOyI5Bpsd4to0dx5zdA I5SCOOdwGMDIyc8Z5oCyEtW0q7MYiWbEgzGzpKivxn5S2AeOeOwJoCyJrm30 +0gM1x+7iBALtI2BkgDPPqRQFkCW+nyXMtunzSwhTIokb5d2cZ59j/k0BZDp 7Oxt4JJ5VZY41Lsd7HAAye9AWQ24trC2CGZHAd1jBBc/MxwM46c8ZPFAWRN/ Z1r/AM82/wC+2/xpByohmtbKKSOPynaSQ4VFds47t14AzyfoOpALCyEih06a d4Y9xdM5+ZwDg4OD0ODwcZweDigLIrC40giQ7LkCIhXzDMMEkADkdTuXjrzR YLIs20On3W4RJKGXGVkEiMAehw2Djg8+x9KAsguYdPtdolSUs2cLGJHYgdTh cnHI59x60BZD4bOxniWWJWZT/tsCD0IIJ4IPBB6UBZEn9nWv/PNv++2/xpBy oP7Otf8Anm3/AH23+NAcqD+zrX/nm3/fbf40ByoP7Otf+ebf99t/jQHKg/s6 1/55t/323+NAcqIzZ2KzpAVbzHVnUb25AIB7/wC0PzphZBNZ2MCB5VZVLKgO 9jyxCjv6kUBZEn9nWv8Azzb/AL7b/GkHKiM2dis6QFW8x1Z1G9uQCAe/+0Pz phZBHZ2MryoisWibY43twcBvX0YUBZEn9nWv/PNv++2/xpByojFnYtO8AVvM RVdhvbgEkDv/ALJ/KmFkOewtI42do3IUEnazsfwA5NIOVEdrbWF3bR3ECO0U gypJdcj1weaYWRN/Z1r/AM82/wC+2/xpByoP7Otf+ebf99t/jQHKhr6fbJGz LA7kAkKshy3sMnFAcqGw2djPEssSsyn/AG2BB6EEE8EHgg9KYWRJ/Z1r/wA8 2/77b/GkHKg/s61/55t/323+NAcqD+zrX/nm3/fbf40ByoP7Otf+ebf99t/j QHKg/s61/wCebf8Afbf40ByoP7Otf+ebf99t/jQHKg/s61/55t/323+NAcqD +zrX/nm3/fbf40ByoP7Otf8Anm3/AH23+NAcqI5LOxieJHVg0rbEG9uTgt6+ immFkSf2da/882/77b/GkHKg/s61/wCebf8Afbf40ByoP7Otf+ebf99t/jQH Kg/s61/55t/323+NAcqI57Oxt4JJ5VZY41Lsd7HAAye9MLIk/s61/wCebf8A fbf40g5UH9nWv/PNv++2/wAaA5URwWdjcQRzxKzRyKHU72GQRkd6YWRJ/Z1r /wA82/77b/GkHKg/s61/55t/323+NAcqGyafbLFIwjOVQkfO3UD60xNKxnKn mXQHbykJ+mTSGtibGL2FuzOo/Ef/AFvT0oRRLX61w3/yK6X/AG9/6UwEsv8A kJv/ANcz/Na/JUQviZQ1FLo2viAxTQpCN25GiLMf3CZw24Y49jVFF24vbVPE VrE1zCsgglQoZACGZotox6nsO9LoBT0hbjyNG+1yxGDyUa38uMht/lEbWJY/ wFjkAZI7cBmwNLW0SSwWORVdGuIAysMggypwRSQGRLBHplzcRedM4aKDzJpr jyyx3TcySgZA4ABHoq9DTADeCPw9qolv8+UzJbzB3jLHy1ddpZixySSOTkdO MCjqBoavqFl9ggk+2W+yS4hKN5q4YLKm4g55x39KSA1EdJI1kjZXRgCrKcgg 9waQFMfLrr+Z/HbL5OeejHzMen3o8+vHXHDAy9OS6Fr4fMs0LwnbtRYirD9w +MtuOePYUwGy3lvcjUEtLu3eVr+3dMMH4zAN2AeRnj9KANPThL9uujeOjXYV FIjQqhjy+xhknkktnnt0xglAF7NFa6taz3MqQwiCVPMkYKu4tGQMnuQDx7Gg Cm1zZS3TG5uGtLQoGg/fmBZGLvvYFSN2cK3fhgf4uQCjbXOoefHNNJcBi8Ky hshVYi3BBXoM+ZLxjrz1UYYFmG4UuSt7M199uZFhaU/6vzyDhOjKF3fNg4we Rt4AKN3eypE0tveOrvFMJI/OeSRCInYF+dsTZUfKFGCDg4yKANS9jntLuGO3 muZN6+dNmRnLBJYskDt8rP8AKoGc4x0FIC3ZXTXOrXWFmWJYIiiyqVyS0mSF PI6Y5A6emDQA2+ure01mzkuZ4oUNvMA0jhQTui4yaAGatqFoLK2mS+iUNcRF HSfaHAkUP0PzAAnPahAUZbq4OqyTW88rW5uIwGVy0eD9nAA7ciST65z1AIYF +a9to/EUEJvEVmgdGiM3G7cmz5c43EFscZNLoBTCrYPq62z3BvWDNbxmR5WY eSuG2knPzAjcR1+XPamBAly/zm3uojBhRP5N9Jc7VMiAsWYfu8IX5BB6n+HI ANDSWgbVrz7LcPPCIIdrs5cfekyAx+8M98nnI7YCYF+6vrezkjFzIsKOCRLI QqAjHyknuc5A9j6UAYRJjsdOtppntXW0jx5kskfzY5VUQq0jcYIzxlcDkgsC CC+aawuZ576YX3lI9tH5hQNIYEb5VGA5LH7vI5HA3cgFm5umXUQ8V0ySrdJG 0TSu7spkCnMYIVFweCQcgqchjkgE+nCSO20Wc3FxJLdBVlMkpYMDCzfd6DlR yBnjknJygL+mcveun+pa5by/TgKHwO3zh/qcnvmgBNXkCJbebK0Ns02J5A5j 2rsYjLAgr8wUdR6d6EBn3U9sIIkhvn+zszbZ5bpkiU4X/loPmc8khd2D84yN owAM0cS6hLIl1dXLJFEAFV3iyRLMoJ53A4UDk/XJANNgbGlTSXGk2c8rbpJI EdjjGSVBNJgZUE3m6yIGuHEwncuTc4SWMbiqom7OQQoJCgfI4JPIIBnfa7o6 e8guUS6FtI1wFvZJJAfKYnMeMRkPj0wRgdcFgaOqefYOqW88z+bEWmMszYIE kQLZ/wCWY2u+SoGOvYYQEFu8s9zBFHeYtpJ1U/Z7x5+fLlLDzGHfC8A8YzwS DTAt6igs1SGS8dIXZijzXLxpGMKMFwdztncQpYZBbn5RSAqBUns9Our24mCx XMsckplkhCovmqpI3fKc7Rk/Nzgk5pgF/dzNd3O2ZIZPl+yiW6khfBRSCIQv z/MW4IJJyvbFAHTVIHM7rq30TT7q3uLmW8uIDks5fcfIdwAvTO5V5Aycc5yc 0A63m3mYR30UcHknzHhvZLrady7SSQNgxuzgg4JORtyABzpHf6FqMcEk0rLE 2Fhu3nQvtONr9WzkAofQccgkAW+uogtqttcq1jiQGWW9kiVnyuMSjJbgtxnH B/u8ACW84JUahfPGoiDWrRTP853ycLkAykKI+obPBwd3IBqaH/yAtP8A+vaP /wBBFJgXqQBQAyb/AI95f+ubfyNMUtjDdmEuEbaTGh3ADP8AFxzSBbDoDI1x EGmcjepxgDPP0pjLdfrPDf8AyK6X/b3/AKUxiWX/ACE3/wCuZ/mtfkqIXxMv C6tzOYBPEZVIBj3jcCQSBj6An6Cgod50Wzf5qbd2zduGN2duPrnjHrxQBDFc u+oXFq0aqIkSRXDZ3Btw5GOMFT60wCG8jkM+XiCRTCEMJAcnC8H0O47cHnj3 oAF1Cye2a5W8t2gQ4aUSrtU8cE5x3H50AB1CyEAnN5biJgSJPNXaQCATnPqQ PqaAIbvWLK1ktVe5twLg53GVRhNrEP7glQM+9FgL9ICsZLS7kCCWKSSJyQEf 5lZcZ6HIxuAPs2D1pgOivbWad4IrmGSZM7o1kBZcHByOo5oAbDqFlPHJJDeW 8iRDMjJKpCD1JB46H8qABdQsntmuVvLdoEOGlEq7VPHBOcdx+dAA2oWSWy3L XlusDnCymVdrHngHOOx/KgAm1CytwpnvLeIMWCl5VXJBwRyex4NADpb21hnS CW5hjmfG2NpAGbJwMDqeaAJIYY4EKRLtUszkZzyxLH9SaQEIvI/tNxGzxKlu iu7+YPlzkkMP4cAA5PXPtTASSexuoriJ54XWH/XYkGYiOckg/KQRnPGMe1AF awnso5rj7PIrxLCkrXLXBkyCXGNzE8Dae+OT70AWUv4BZw3FzLDb+ZEJCGlU gA4zhuhGWAz7j1oAWbULKCOOSa8t40lGY2eVQHHqCTz1H50AOlvbWGdIJbmG OZ8bY2kAZsnAwOp5oAgi1W1l1OWxWeEyIoIAlBLNlty49RtyfrRYCQXm28uo ZlSOOCJJfNL8FW3ZzkDGNh7mgCwXQSCMsodgSFzyQMZOPxH50gBnRCoZlUuc KCfvHBOB+AJ/CgCC6vI7exmuVeJhGGxukCqWBxtLHgc8fWmA65vbWz2/armG Dfnb5sgXOOuM/WgCSOGOJ5XRcNK29znqcBf5KKQEEl3IL77NFB5gRVeVt+Co YkDA7/dJPI46ZPFMAa9sZvPg+2Q7o1bzQswDIBwScHK49e1ACw3VkA0ME9uB AVjZEdf3ZztC4HTngCgCSS6t4Y5JJZ4kSIgOzOAEJxgE9uo/MUgIzqFkIBOb y3ETAkSeau0gEAnOfUgfU0wHNe2qeTuuYV8//VZkA8zp9316jp60AQQais0O nPtRWvVD7DIAVGzccA/ewcDj1zQAwR6Wb5VE6GdmLrB9oO0sCckR5xkMCc46 gnrQBajvbWWVoo7mF5FbYyLICQ3PBHr8p49j6UASu6RxtJIyoiglmY4AA7k0 gIE1Cykh85Ly3aIEjeJVK5A3EZz2AJ+lMCaGaK4iWWCVJY26OjBgfxFICO4v bW1z9puYYcY/1kgXrnHX1wfyNMAlvbWGdIJbmGOZ8bY2kAZsnAwOp5oABe2p nWAXMJmbO2PzBuOCQcDrwQfyNADBebby6hmVI44Ikl80vwVbdnOQMY2HuaAL BdBIIyyh2BIXPJAxk4/EfnSAdQAUAU9Suri0jjkggimDOsZ3ylMFmCjopzye f60wH/bbeMxx3FxbxTuQnl+aPv4B2jOCfvDt3HrQBZpAFADJv+PeX/rm38jT FLYwn/14/wCuSfzNIFsSW3/HzF/vj+dMZar9Z4b/AORXS/7e/wDSmMSy/wCQ m/8A1zP81r8lRC+JlW50y6k1KW5VF2faEYDcMlc25J/Dyn96dyh7294IfsiW jMBeiczF1C7DP5nAzkkA9CB0OCeMgFmE3H9tzyNZTLC8SRiUsmMqXOcBs4O4 Y4+uKAM68FxJb3om050W4u4HUTshRhuhXa20t1KnsePypgWJ4r2a5kvEtZYT iNAv7ozDb5mWTJKD74HJ6bvbKAZpmmzR6sbma2ZIwZWjMkvmsu5YQOSSc4Vx 3xyMkYJAL11amEW0lrCziC4aZo1Ybm3K4ONxA6vnkjjPsKALqFzGpkVVfA3B TkA+xwM/lSAxLbTLqPUorlkXZ9odiNwyFzcEH8fNT3p3Ajs9Ou1itbe4S4mW 1QjbO8IgY+WUwNqlyDu/iHTk8jBYFmOG4kSVZrKaSNV/di5kQSryDtR1J/ug gsQdyj5jnKoBpiv3h8wwS+YjjEjCH7SVw3TqnBbqcfKzDGeWAKEnn6VM10U+ ztJK+w3MokHllIhgszr8+UHBbGFfGcDL3AsQ28yCCewN99nNrFCoh8nd8hbl t/B+8MFeDyemKAJhZ3FrHFbwWbsvlJG43o8MoChf3m7DZxkZUdMZBxtCA26Q GHfRXlxLqaJYzbbi08iNy8eCw8zn72cHcMcfXFMCbU7CWSe1NrCvlW6fdXC/ dlhYKB7hGA7epFAC24uI769vTpzoJYolWNWTzHKlwSecZAI7njHOeAARaXaT g6Wbm0aI2dq8JLlDh8RjK4J6gMPz9aAC5sZ7a/eazF2sUqAEWxiJ3b3Zi3m+ pfjHv7UAFnaz6fBLafYWuY5QgB8xCgAiRMOTgn7pyQp4PTtQBcZJ4tWeaOHz EmijjLbgAm1nJJ79H4wDyOcdaAKd3HPcXOopJaXEUFxa+QJgEfGPMy20NuOd wwAM/SgAsrt77WYpRJaSJHbyKRbS+aEJaPG5sDGcHAx/CeT2ANDUYZJIFkgX dcQN5sQzjcQCCvPA3KWXJ6bs9qAKl7aTQ+H5rOCJ7qeWJ0YrtXLuCWc5IABY k4HTPAo6gJdJdXEyyC0uESRApRJUjbIJ/wBY4OQoyCNhJ5bIPSgC5pUMlvpN nBKu2SOBEYZzghQDQwIIdMgj1ue8FpCu6JNsgRc78vvPrkgrk96LgZ1xY3s+ jQaeto6vawMnmM6bJD5Lxjbg55LA8gcdcdKYGnqFgkkERt4V8y3KeWq/L8iy IxUDpzsAGfzFICjb2OoW9jlwzz+crMyFWl+WJYyyl/lySuef4WPQ8UAGmabN HqxuZrZkjBlaMyS+ay7lhA5JJzhXHfHIyRgkAsPaNa3dwYbL7RDdRBCu4bQ2 +Rm37j90mTsD346ZAIEivLe00aIWM0rWio0ux48A+UyEcsMnJHt70ATLYSpp 7RrCqyvf+e2MfMv2gNuJ/wBwD34xQBT0K5R7yCB2y1vAYoUXbuRPl4kAYsGA VQcqoByOcimwNjUoZJ7TbEu5kljk25wWCOrEDPcgcZ/SkBnvaT3mrQXkto0c SvHlJShYbFm+bgkdZFxznI6d6ANeOGOJ5XRcNK29znqcBf5KKQFZLYjWZ7po 1wbeONH4zwzlh691/wAimBlT6VPH9qtLcXYtbgBUWF4ggXy1TDFwXH3eozxj qc07gOtIppreSCO02q2oPMZwy7SFuCTu/i3YXAwD/Dz1wgJbuOe4udRSS0uI oLi18gTAI+MeZltobcc7hgAZ+lABZXb32sxSiS0kSO3kUi2l80IS0eNzYGM4 OBj+E8nsAaNjcy3UDSTWstqwdlCSEEkA4B4Pf/ORgkAs0gKGsee8EUcFrLOf OjkOxkG0JIrH7zDqAcf0poCtLZTS2WtMttsnvFIjBK7mHkqoBIOOG3Dr6+tA GxSAKAGTf8e8v/XNv5GmKWxhP/rx/wBck/maQLYktv8Aj5i/3x/OmMtV+s8N /wDIrpf9vf8ApTGJZf8AITf/AK5n+a1+SohfEyeTUNk8kcdrcTLEQJXjCkIc A4wTuPBB+UHrxzxTKG/2mnmf6ibyPN8r7R8uzfu2Yxnd975en6c0WAgh1+1m tpJ/LmQJAZyrAZKhQxAwcZ2sh6/xDuDgsBM2rRoSJbe4iLDMQdQDL8yqMDPH LKPm2/e9jgsANqqorCS1uEmUoPJOzcdxIU5DbRkgjkjkY6kZLAF5eumkXVwI riCSJGyCilk4zuHO1sDng9sdeKAG6le3Ftd2UcNtNKskpDFCmGGxzt+ZhzkA /h17UAT3c7RXdlGC6rNKykhQQcIx2nJyOmcgH7uO9AEf9pp5n+om8jzfK+0f Ls37tmMZ3fe+Xp+nNFgEtNWjuxbsLe4iiuR+6kkUAOdpbGM5HAPJGDjgnIyW Av0gGuxSNmVGcgEhVxlvYZ4oAyZtRuI9GsLiFJrhpvILSBUUkMyA5BPBYEjj OM9R1pgayMXjVmRkJAJVsZX2OOKQFWTU7eOSSNt2+OZIdvGSW2cgZ6DzFzTs A552GrRW+XCtA7/dG1iGQdc5BGemMHd14oAbDJL/AGvdQtKzRCGKRFIHyElw cYGf4R1zQAWEkrz38ckrSCK42pkAbVMaNjgDoWPvQBLdXK2yp+7eV5G2Rxpj LHBPcgdATye1AFX+1081YBaXLXJ3ZhAUlSu0kE7to4dTnOO3XiiwBdXjSWMN xbSPEftMcbqQM/60I6nr6nkenBxQBPJfxRQ3srK+2zz5mAMnCB+OfRhQBapA Zy6zAVEjwzRwtE0yysFw0SjJcAEnHK8EZ+YcdcOwBLq6W4/0q0uYGONqkK5c FlUkBGPQuvHXnjNFgHHVVU+W9rcJckgLbnZubIYgghtvRH6kfd9xksA3+108 1YBaXLXJ3ZhAUlSu0kE7to4dTnOO3XiiwBLrEUVv5/2eZkGRIxKIIyGKkFmY AncCOCf1GSwEY1OSXU7RLeCaS1ngaQONgDDMeG5O4ABjkYzz0NFgJ/7TTzP9 RN5Hm+V9o+XZv3bMYzu+98vT9OaLAXHcRxs7BiFBJ2qWP4AcmkBTtdTiuLx7 NonguEXeY3ZGOOP7rHHUdcZzxnmnYCe7uVtYg5jeQswRVTGST05JAH4kdh1I FAFe8vXTSLq4EVxBJEjZBRSycZ3Dna2Bzwe2OvFAD59Q8q7a1jtbieVUWQiM LjaSw6sQOq9OvPGecAEX9swMokhhmmh+QeagUDc4BVcMQcncvbHzDJGDgsBK 8kq6zBEJW8qS3kYx4GNysmDnGejHvigBtvqaTvD+4mjiuP8AUytt2ycFhgAk jKgnkDp68UWAvUgMy0vnisFMxluZmuJYUAChpNrvj0UfKpPbp60wJ7fUY57k W5iljmwxZHx8m3ZwSCRyJFPGfz4oAYmqrNHC1ta3E5khSYqmwFFbO3O5gOcH pnp9KLAE10ZJdLmtpm8i5cgjaMOpiZgeRkfdHp70AX6QBQAUAFABQAUAFABQ AUAMm/495f8Arm38jTFLYzLZirSFSQdkfQ/79LoEdkSPLIDHiR+ZUH3j03Ch FBX61w3/AMiul/29/wClMBLL/kJv/wBcz/Na/JUQviZK1ncrcTPbXSRJOweQ NFucHaF+U5wOFHUHn16Uyhn9my58r7Qn2Tz/AD9nlHzN2/zMbt2Mbv8AZ6cd eaAKcmgmDTpkt5GllNlJBtIA3sY40BHp/qh19etFwLUulzXDh7i7V3iGIWEW MYdXy/Pzcxr029+mRguA46fcv50klzC08qrGw+z/ALpkG75WQsSfvt/EO3vk AbJplw2kS2KXUS+aGQnySVRCCNqLuyPbJOOg4wAXAnmtbiaGBmniF1A5kVxE dhOGXld2ejH+Lrz7UAMu7K7mktWiu4lFudwMsG9nbaykkhlHRugHX8qAI3sH j/dvdRLZm4E20x4feZN4G/djlyB93px15oAlh07yrfTYvNz9ixzt+/iNk9eP vZ79KAJdPW4WzQXbs8uWOW27sFjtB28ZAwDjjNAE0wlaJhA6JJ2Z0LAfgCP5 0gKMOmyppMVjLcI7Q+X5UixFQNhUruG455XnBGfbrTAvQrIkSrLJ5j9WbbtB PsOw9OvuT1pAZ82jpLqBuvOYAushTb3Gw9frFH/496ja7gSy2l0+pxXS3MKx xqUEZhJJVipb5t3X5eDjjPQ0AEVpdJqct01zC0cihDGISCFUsV+bd1+bk45x 0FABY2l1b3FxJPcwyrO28qkJQhtqr1LHjC9P1oAlvLZ7gQvFIscsL+YhZdy5 2lTkZGeGPcc4+lAENrpzxX32yWdXlYPvCptUlhGBgZOMCMdzyT06UARzaZcN arBBdRIPtDTsXhLZPm+YBwwxg8H19qLgVdSsbqdLqBEuCbpMO0LosTOUC7mB O9cYHCkjAHXJFAG7SA56y026Zpra5gZYZYWid9wxGGHIi+dsLnouxeAM8rg1 cCzFoSod3+hxMGRgba0EWQrq+DySfugdR1PB4wrgS6ho6X1yZ2aJjhNqSxeY mV8wfMMjPEh9MEA+1FwHWOlLaTxzAwqVWRSkMAjTLFOQAf8AY7k5z1AwKLgP urCSa8S5imRGVdmXi3lBzkxkn5WIOCSDnC8ccgDE0ySGCySG52SW0H2cyeXn KkLkgZ4b5BgnIHOQaLgRJocaXvnBbQr5xm3G1BmyW3ffJ9ePu5A755ouBpzx +dBJFvePepXehwy5HUHsaQFGy02S3uYpmlhCxRPGkMEHlIAzK2QMk5yvPPp0 5y7gWryGSeAxxyIpPBEke9GBGCGXIyOexHbtkEApyaZcNpEtil1EvmhkJ8kl UQgjai7sj2yTjoOMAFwLNtayx3MlxPMkkkkSRnZGUHys5zgk/wB/9PegDFis LqCS1Nsi3UKJEEdSPKkCqoDsN4+bI+9tfACY5FMDWltLp9TiuluYVjjUoIzC SSrFS3zbuvy8HHGehpAV9P0OOxniZFtNsIwjJahZTxj5nyc8dcAZPtkEuBqO HMbCNlV8HaWGQD7jIz+dIDJOiyyWvk3M9tPsnaeMNbEpuYuWDKWO4fOccjGB 1p3Af/YkTWP2Z/JXMu8+TCI0wRtYBQe6Fhkkn5sjoAC4DtQ0hLy7+0hbR3KC Mi5tvOAAJI28jH3jnrnj0ouA6fT7kmzFtcwxpaYKh7fcSdrL/CygDDdAB/Sg DRpAFABQAUAFABQAUAFABQAyb/j3l/65t/I0xS2MuDrJ/uR/+z0ug47IdJ1i /wCusf8A6GKFuMfX61w3/wAiul/29/6UwEsv+Qm//XM/zWvyVEL4mQTavcQ6 rJblImiEyxjghsHygec+swPTouO+Q7FFn7fL9g8/am77X5GMHG3z/Lz164/W gAjj263fmEIkj20J3FcgtmUAkDGeg79qAG6CtwtrN58sTj7RNgJGVwfNfPVj nJ6envQwILe5uYrO2jgW3Es97PE5IYLw0pLAZJ6rnGfbI6gAdJqF4pkt1aE3 EcpTKQs5k+VGGEDfKPnALFsDAz97gAbZahqF/K0Ua29uY0BdpELncJJEI2hs c7M/eOOnzZyABx+3Sa3YyO0MO62kZojGWKDMW5dwbBOehx+BoAtXH+kanBb9 Y4F8+Qf7WcRg+o4c+xRTx3AKei6vcX0kcdwkWXh8zMYIwdsbdCT2lA/4CT3w BoCWOaWEapIqw7orkMx5UMgSMnOWwG28ZyBkAnHNADLnV5QQYF2xvKsKs8Du 6ttZ2JjGGxgKAODyT0xksAW+oXtzKtsgSKQ72E0ts6h1XZ0jJBHMmM5P3T68 AFnRC5sGMiqr/aJ9wU5APmv0OBn8qGBfpANdEkjaORVdGBDKwyCD2IoA5240 +yhstfkis7dHiDhGWJQUBt0yAccdT+ZqgNaGe6S+S3ujC3nRPIvlKR5e0qCp JPzff64Xp054QFe2luU0hngSLzVuJhIVjZgMStuYJuyfXG7ucZwFIBdsJZJr YPI8UhJIDxqVz9VOSpByCMnp26AApapq72El1GEUlLcSRcfx7ZW+bnpiLt6/ kWAsX5YX2m8IVM7DkHIPlOQQQfQEcg9e2KAElRB4gtpAqh2tZgWxyQHjwM/i fzo6AFuiJr16VVQXt4CxA+8d0gyfwAH4UdAJr+4e2td8YUuzpGu7kAs4XJHf Gc44zjqKAKF6L9Z7BXe2kk+0nY4RkA/dSZyuTnHXrz0460AEmoXimS3VoTcR ylMpCzmT5UYYQN8o+cAsWwMDP3uABtlqGoX8rRRrb25jQF2kQudwkkQjaGxz sz9446fNnIAGR61cXAiaI28LyiLZbOpaRw6qS45GVXcc8fwNyOxYB6atcyXX yIzRi4MPlC0kPAfYW837vGC3T296LAaOo3D2mm3VzGFLwwvIoboSATzQBl3+ oPdLNHCikQzW+wOduX+0lDkjPGYx27/hQA+61O7s5/skrRPKxTbLHbuwUMJD /qwST/qj0P8AF7clgCDUNQuLmO2jWJCRITNNbyJuC+XgiMkH+MrgntnPagCW S7luNNWMHZcTzta7oyVPyuyuy/3TtVmGScYA57gE12ohutLjjjiEQmZAu0jZ +6fBXBAHAIwQevbFAFYJPceIpBcW8JSGKNo3EzbowWk5UbRgtgBhnoByelHQ C/qNw9ppt1cxhS8MLyKG6EgE80AUJtaZftRiT5YvLRcoWO5pniJwPvAFcgDk /jwWAs6Zdz3EkyTKzBApWX7M8AbOcrtfJOMA5z/F7UAN1S+ltp4IIjtaVXff 9nefAUqMbUwed3X296EBW/te5WCQyQqkrQn7MrxsvmyCQpyDyoJMRwcY39Tg kFgC81a5iurpIEZhbEDyltJJDKdgbAdeFzuxyDjr3xRYCe2udQnzMFtzEtw8 XlgHcyiQpu3E4GAM4wc46jOAAaLlxGxjVWfB2hjgE+5wcflSAzrSe+uBKhmt 1lUDIe2dGjOe67zuB+Ybg2Mrxu7MCvp89xa+G7BjNDueKMIfJdiF2A4CKSXb jtjjJ7YJ1AS21LUrm6Fn5cMMy+YJHlTptEZBCqx7SYxu98/w0WAdejUJJ9MJ e3hcXDLgxFskRy/Nw44KjO3qM9TigDapAFABQAyb/j3l/wCubfyNMUtjLg6y f7kf/s9LoOOyHSdYv+usf/oYoW4x9frXDf8AyK6X/b3/AKUwEsv+Qm//AFzP 81r8lRC+Jlp7C1eRpGhUu7iQtzncNuOe33E46HbTKGPpdnJN5rxMSHEgUyNt Vwc7gucA57gc5OepyXAa9paWcs2ou0ysql5GM0jDaMn7ucYGTgY4zxQBKLG3 WSV1RlaUEEq7DGeu3n5cnk4xk8nmgClHpNjPHGYGlMUdw7sHldsuN6nBY5Uh mJ3DuM+houBaOl2pjChZQQSfMWZxIc4zlwdx6Dqew9BRcB9pYWtkW+ywrEGG MLnGNzNgDty7fnQA65s4Lvb58e7bnuRkHqpx1U4GQeDgZFABa2/2fzmZt7zS tIzYxnsBj2UKPfGe9ADbewtbYxmCFUMaeWpGfu4Uc+vCKMnnigCKPSLOJmYC Zi7K7b7iRwWUqQcFjyNq8+2OlFwJZ7G3uJGkkRvMYKN6uysNu7GCDkfebp2J FADDpdqYwoWUEEnzFmcSHOM5cHceg6nsPQUXAiu9PsE0+O2bfb26zoyiF2XD mQEDjsWP4dsYBABo0gCgCtNbWot7vzgqxTgmcsxAI2hSSe3ygflTAijltL6f gTLMsTKN6SQtsYjdtyBnkLyOnHTNABHpFnHE0aibaW35NxISrc5KktlScnJG M5OaLgMiurKxsXuFWYW24kzbXlMgx98nliuBjcewGOMZAHTR6feGCWeJi0xM aCRGQtgMcEEDsG69iw6MQQBuowW0t7Zi4S5LSMUjeKdkVGCseQGHJG4ZAPoa AJ5NOt5LxbtvO85ehE7gAccbQcYOBkY5xzQAR6dbx3jXa+d5zdSZ3II542k4 wMnAxxnigB7eReLNA3ziNgjjkFWwGGD6jKkEdPqKAGRadbROjqrs6NuDySs7 ZwR1Yk4wzcdOTQAS6dbSu7srq7tuLxysjZwB1Ug4wq8dOBQBGkNhpIVo4vJW VliGxWIBLMQMDhRuc+g5A9KNwK7aKyTobS6aCJQqgfOWUKAAAQ4BAxkBgwyW POSKLgXP7OtvP87a+d2/Z5reXuznOzO3Oec4689eaALDokkbRyKrowIZWGQQ exFICnBZ2J86KKPJjlTzMlid64deT15Ib3JJPJNMCWext7iRpJEbzGCjersr Dbuxgg5H3m6diRQAkdjDbfvbeLdOqsFaSRiWJxncxyT91Rk5wAMelAFPR45J Z5bqSGKFEMkUaJKXw3mt5pyQPvMFx9O2cUMCxeWlpdXkKztN54VnjCTSIABw T8pAz8+M9eaALYhjWd5wv7x1VGOeoBJH/oR/OkArokkbRyKrowIZWGQQexFA FdNNtEikjWLiTG4liWJHIO7OQc5bPqSepJp3AfbWkNruMQcs2MtJIzsQOgyx JxyePc+tABc2kN1tMocMucNHIyMAeoypBxwOPYelAAtnAiwqsfEDF05OQxBB JPcnc2Seuc9aAGTadbTytJIr5b76rKyo/b5lBw3HHIOQMdKAFs2hUywRI0bI 7MyN1+Zid30JyR+I4IIABO6JJG0ciq6MCGVhkEHsRSAgt7GC2kMieazkY3Sy vIQO4BYnGcDOOuB6UwGDS7MRlFiZQSCCsjBkxnAUg5UAEgAYABI7mi4DrbTb S1lMsEW1zuy24kkttyTk8k7FyfbPc0XAluLaK5jCShsA5UqxVlPqCMEcEjjs SKQD0RI41jjVURQAqqMAAdgKAHUAFADJv+PeX/rm38jTFLYy4Osn+5H/AOz0 ug47IdJ1i/66x/8AoYoW4x9frXDf/Irpf9vf+lMBLL/kJv8A9cz/ADWvyVEL 4mU7q7uk1OW1Uvte5jZeTkKDBwP9kjzifXa3oaZQeevm5+1P/aX2vb5HnnPl +bj/AFWcY8vnOOnze9AET20jeE/tZu7h5XsGaXzJCwcGI8Yzgc4OQM8c5yTT 6gatpO8ck51B1inwXI3/ALoRjupOOmfmJGc9eNtIDMtbmO7gs7eC/dx9umRz HPufy8TFQWyTghRg9eMg5ANMBt1cC1nlhnluHtIZmQItyUcZjiYMXLA7QWYc t1dR6YANvTg40+38yZZpGQM8ituV2PJIPoSeO2OlIDJ1GdUk1AyXTx3kf/Hl EJyhf92pXCA4fL7hyDnp2xQA5BItt9s+0XDS/bzEoMp2qhuNhXb0PBPJBI7H gYANi6iee0mhjlaF5EZVkXqhIxkfSkBjzXN3NYXN6oaHJihMRl+Vdr4lO4fd xuZSwHATcO2GBWt3lnuYIo7zFtJOqn7PePPz5cpYeYw74XgHjGeCQaYFzUIl s4VWS/ZYt5aNJ7h4lIwBtMwO7OcsMk5BIxwCqAS8vbaLSrKQ3jxbp4mjMs21 mXzFDAnPzqFJ55BGDk9aAIb66ib7dJ9tZboDNgi3BXzB5alSqA4fLluxz07Y pgSIJFtvtn2i4aX7eYlBlO1UNxsK7eh4J5IJHY8DCA2p/K8iT7Rs8nafM342 7cc5z2xSAzdOvbXUr5rmK5hcrFthiWQF1QkFmIHTJC8HptHQkgMC5qKTSabd JbFhO0LiPa207sHGD25oApatc2i+F53jkijgltWWDPyBsodoAPt2oW4EeqCz uWsL03LfZhMQ80dyyxquxxnKsAPmIGevOPahAa6eXLsnCfNt+UsuGAOCRzyO g49qQGN50K6zsN47yNLgKtwwkQ/3TCeCuB94DoQexemBuUgOdN/FMl9Faaju Y30PlmOcOyoxiDFc5+XLMMdOo9qoDTsl8jUrm1R5WiWGKQCSRpCGYuDyxJ6K OOn5mkBBq0sSalaJc3UtvbNDKXKyGNSQY8bmH3evXI54zzgiArXF7FHo0H2m 5Rd12vlGWQZeNbgYYE/eGzBz6c570AQa1egG5mt7zy5IovMhzM5Mg27hsjUg Mvfe27owIwOGgLKCRbb7Z9ouGl+3mJQZTtVDcbCu3oeCeSCR2PAwgDThJHba LObi4klugqymSUsGBhZvu9Byo5AzxyTk5AIjfxTJfRWmo7mN9D5ZjnDsqMYg xXOflyzDHTqPamAt+/2G5kgE1wbRRFI8f2hvMbd5oO12bIxtRj8wACsfXIBp 6Od9gsnneaJGZg3m+ZhckKuckZCgA4J5BOSSSUwMdpYYot01zsUT3H7prprf cPOfJRgQGbjG0nuOVz8zAt3MdvFqdleTzXO0wP8AO8jqWfMe1dgwNxAPyAc4 PHFICtc3TLqIeK6ZJVukjaJpXd2UyBTmMEKi4PBIOQVOQxyWBHbXM0kM5t7i VruG1kdl8/f50uAFdEyfk5YgYAO5CAeMAElvNvMwjvoo4PJPmPDeyXW07l2k kgbBjdnBBwScjbkAGjoksUscvlSs4UgNtuTcR59VkPPTGQcYx05yyYDr2Np9 WtYDNMkTQSs6xSFNxDR4yRzxntj8iQQDOhuIWldNTvXhgj3JAzXLQ7issin5 gQWIVY+pPr35YEMF9qBMUE5lEsrwO2QVYcQZAHYH98SMfwt6GgDaPza6nl/w Wzedjjqw8vPr92THpz0zygJ0vLZ7ySzSZDcRqHeMHkA/5/UeooAnpAFABQAU AFABQAUAMm/495f+ubfyNMUtjLg6yf7kf/s9LoOOyHSdYv8ArrH/AOhihbjH 1+tcN/8AIrpf9vf+lMBLL/kJv/1zP81r8lRC+JmnQUFABQAUAFAEFzaQ3W0y hwy5w0cjIwB6jKkHHA49h6UwJIYY4IliiXao98knqSSepJ5JPWkA+gAoAKAC gAoAKACgAoAKACgAoAKAGRQxw7/LXaHYuRnjJ64HbPXjuSepNAD6ACgAoAKA CgAoAYYY2nScr+8RWRTnoCQT/wCgj8qAH0AFABQAUAFAEVxbRXMYSUNgHKlW Ksp9QRgjgkcdiRQA2K0hhgeGMOFfO5vMYuSRjJbO7OMDOeMD0pgNs7GCxDiD zQHOSHld+ckk/MTjJJJ9aALNIAoAqw6dbQSrJGr5X7itKzInb5VJwvHHAGAc dKYFqkAUAFABQAUAMihjh3+WuC7F2Ockk+p/IewAHQUAKEQSGQKodgAWxyQM 4GfxP50AOoAKACgAoAKACgAoAZN/x7y/9c2/kaYpbGXB1k/3I/8A2el0HHZD pOsX/XWP/wBDFC3GPr9a4b/5FdL/ALe/9KYCWX/ITf8A65n+a1+SohfEzToK CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAG Tf8AHvL/ANc2/kaYpbGXB1k/3I//AGel0HHZDpOsX/XWP/0MULcY+v1rhv8A 5FdL/t7/ANKYCWX/ACE3/wCuZ/mtfkqIXxMbPFdf2tFAupXKRyxSyYCRfKVZ AAMp0+Y9c9qZQWeqMVYTxTFRcyQmfaAgPmlUXrk/wjIBHPJ4OCwE9vqaTvD+ 4mjiuP8AUytt2ycFhgAkjKgnkDp68UWAnvLlbO3MzRvJ8yoETGSWYKOpA6kd 6AK6avbzW6ywJLKzuI0jUAM5K7xjJA5T5uSOOOvFFgA6quAq2tw05cxmH5Ay kKGxkttPykHAJOPocFgFfUiGjRLO5kldSxjARSoBwfvMAef7pPY9CCSwDLvW YLNRJNDMsBxmZwqAEjOMMQxOOcAHuOoIosA8amjTrGsExV5TEkvy7WcE7gOc 8bWPIH3TjORksAW+ppO8P7iaOK4/1MrbdsnBYYAJIyoJ5A6evFFgL1IDOg1E rp4uJEmkdp3jCbUVgfMZQpOdvGMZJ5wO5ApgXLeYzxlmhlhYHBSQDI/EEg/g T+YIpARXF8sM5hWCaZlUPJ5QB8tSSASCQT91uFBPHTplgVLW9mktNGaRn3XS gyOFXDHyi2DyMZPPA/hxxmgCyuob7loltbhkR/LaUBdqtx1Gd3cc7cYOenNA DLTVo7sW7C3uIorkfupJFADnaWxjORwDyRg44JyMlgC3uZUbUPMMs4huAsaq o3YKIQoxjux5PQdT3oAbbazb3FwLfY6T+b5TIWRih2s3JViB9xhjOeOnNFgL kNwk0k8ahgYHEbZ7narcfgwpAQT6h5V21rHa3E8qoshEYXG0lh1YgdV6deeM 84YEFxrltbwpcMkv2VwpFwdqLyN3AYhm45+UH06giiwEiatG7/8AHvcCITGB pioCh9+wDrk5OOQCOecYOCwDdNvbi5u72Oa2miWOUBS5TCjYh2/Kx5ySfx69 qAJdVuXtLITIWBE0QO1dxKmRQQBzngnpzQgGx6mjXEdvLBNBO7BQj7SQCrsD lSRg7GHXPHSiwFmG4SaSeNQwMDiNs9ztVuPwYUgIJ9Q8q7a1jtbieVUWQiML jaSw6sQOq9OvPGecMCC41y2t4UuGSX7K4Ui4O1F5G7gMQzcc/KD6dQRRYCRN Wjd/+Pe4EQmMDTFQFD79gHXJyccgEc84wcFgG6be3Fzd3sc1tNEscoClymFG xDt+Vjzkk/j17UAXLm4S2jEjhiC6R8erMFH6kUgI4b2O4SdrcNKISB8pH7zK K42nOOQw64pgUJtRuI9GsLiFJrhpvILSBUUkMyA5BPBYEjjOM9R1oAlOoTpq UkItbiUfZ4pBCgTKElw2WJA7KMZ+nc0AaEE0dxBHPE26ORQ6nGMgjIpAU7fV 7ee7+zBJUfe0YLAYJBYdj38uTH+6c4yMuwEsd/FLDZSqr7bzHl5AyMoX559F NAEVvcTq2oBhLdGG4CxouwNtKI2BnA4LHqc49aADSbue50aC5mhlMphViDsB lO0HIwcDJ9cfhQwI4NT22lgPLuLqa5t/NUoiqWwFyTzhfvZ647ZzjJYB0usR RW/n/Z5mQZEjEogjIYqQWZgCdwI4J/UZLANGuW7pJLFDcSQRANJMFAVVKBw3 JBPDdACeOnIyWAdDe3D63PbNbTLCsSEMSmAcv83DZwdoA+nIFAGjSAow3cjG +IimlaGfYsQCAgbUPB3YI53ZJB5xjimBBYanI2j2U9xBM1xOqKqjZmZtm4sO cAYDHkjp06UWAc+twxyLE9vcCUkq0fy5RvkwCd2OTImMEj5ucYOCwEramh8n 7NBNdedF5q+XtX5Djn5yueo6dMjOMjJYC4jiSNXUMAwBG5Sp/EHkUgK7zsNW it8uFaB3+6NrEMg65yCM9MYO7rxTAitNWjuxbsLe4iiuR+6kkUAOdpbGM5HA PJGDjgnIyWAuTf8AHvL/ANc2/kaBS2MuDrJ/uR/+z0ug47IdJ1i/66x/+hih bjH1+tcN/wDIrpf9vf8ApTASy/5Cb/8AXM/zWvyVEL4mXHt919Fc7seXE8e3 HXcUOc/8A/WmUQf2d/of2fzf+Xn7Ru2/9NvMx1/DP4+1AFfT9DjsZ4mRbTbC MIyWoWU8Y+Z8nPHXAGT7ZBLgX7y3+1QrHu24ljkzjP3XDY/HGKAM7+wIhaCB XSRUlSSMTxCRfliEeGGRu4BPbnHpyXAeNIZLMwRtZhXYtJEbMeS3THyAg5G0 clj1PtguA6fTLiW2ihN1FJsAyZ4S+GGcMhDBlIzjJJPA5zkkuAy70aW4FwFu 1BuIfKeV4Q0oG0DAbIAUkZK46lsYyMFwIYbW8i1kyfZ90ZlZsk/u0Bz8y/P8 rY6/JksW5AbIAJtP0OOxniZFtNsIwjJahZTxj5nyc8dcAZPtkEuBqOHMbCNl V8HaWGQD7jIz+dIDOh0+7js5YHu7dw7u+DbfKd7MWVgWOR83GCOgznkUwLVh bPaWwieRXwSQFXaqD+6oySB7ZOO2BgAAZPaTNdtPbXCwmRFjkzHuOFLEFecA /MeoI6ceoBW/sy6SHT4oLuFVslUDfAWLMEKZ4ccYbp+tFwJmsJm1Bbk3EWFP DCHEu3k7C+cFcnoV/X5qAINL066itdPW7nUi1RSsYQBlfYVILA4IG5hwB25P ORgKNMumW7We7hdblhIQkBUbgFGDlzlSEwV75PIouBFJpc8J+0B2llURqi2y JF5IUOPkDZU8PjDH1IPQAuBb0i2lgS5eUSqZ5vMAlYM/3FU7sZHJUnA4AI6d AMBstreHVpri2mSJWgjT95HvViGcngEEEZHOccng9gCtJoB+zyW8FyqRyW4t 97xB5VUKF2hsgBeASMdSxBGeC4GnZ2/2WFo927MskmcY+85bH4ZxQAyO0kiv ZZknxFK3mPHs5LbQv3v7uFBxjOe+OKAFv7U3lr5KytCd6OHUAkbXDcZ47f8A 66AKVxYXGTdSM090CoVrZVjKBQ4BUOWBP7xgcnGDxyOQCfSLaWBLl5RKpnm8 wCVgz/cVTuxkclScDgAjp0AwGy2t4dWmuLaZIlaCNP3ke9WIZyeAQQRkc5xy eD2AK0mgH7PJbwXKpHJbi33vEHlVQoXaGyAF4BIx1LEEZ4Lgadnb/ZYWj3bs yySZxj7zlsfhnFADI7SSK9lmSfEUreY8ezkttC/e/u4UHGM5744oAfeW/wBq tzGG2MGV1bGQGVgwyO4yBkcfUUAV7LTn0+yeG1nXzGK4eRNwAVVQcAjPyqO/ XJ9qAGw6bKmkxWMtwjtD5flSLEVA2FSu4bjnlecEZ9utAE9taSRXMlxLP5ry RIjfJtGVZzx7fPgD25J60APsbf7HY29tu3+TEse7GM4AGcfhQBTh0dIruO5E zF1maQjbwQTKQPb/AFx59ugouAQaXNE1krXatBZH91GIsEjYyDccnJweowOv HIwXAlsbS6t7i4knuYZVnbeVSEoQ21V6ljxhen60AFrZ3NpZ/Z4rpD5arHDv iyFVeBkAgsxHU5A6YA5yAU4dMv7eSxSO6iItbd4hJ5PykfuwAy7snhWOQRyB 9CXAlXSJI5I5Y7lPMG4s7w7ihZmZjHk/ITuI53cBc5xyXAn0nTv7NtzF5vmZ 2c7cfdjRPX/Yz+NDAkktJDffaYp/LDqqSrsyWCkkYPb7xB4PHTB5oAtUgKNj aXVvcXEk9zDKs7byqQlCG2qvUseML0/WmBXfRS9lDbSTRSpbFfISWAMgCqVG 9c/McN1yBkAgDnJcAi0KNXiZmiQISxS3hES53xsMDn/nkM5yTk8jgAuAr6TL 9htbVJ4WWCJE/fQFsMowHUhgVb3yccYxzkuBpopSNVZ2cgAFmxlvc44pAU5b S6fU4rpbmFY41KCMwkkqxUt827r8vBxxnoaYBDp3lW+mxebn7Fjnb9/EbJ68 fez36UAW5v8Aj3l/65t/I0ClsZcHWT/cj/8AZ6XQcdkOk6xf9dY//QxQtxj6 /WuG/wDkV0v+3v8A0pgJZf8AITf/AK5n+a1+SohfEyLVNTurR53t1SVLdd8k axFjgDJy5YKp/wBnDHGDg5wGkUbFIChboia9elVUF7eAsQPvHdIMn8AB+FPo BHA9wv8AavkxxPOtx8uARu/doRkE8kAgdVBx/DnNAFW/mu7nw/qBE9uwWF9x +zujY2HKlGbKnGCCT0PToSdQNqESrEondHk7siFQfwJP86QD6ACgDnd919h2 +TD9n/tL/Wead/8Ax9f3duOvv/hVAH9u3ZsTdpHvV4HlCG0lQRYjLjMhO1hk BeMZzkelFgLt3eX9jC0s6Qur7QDEjHymZ1UAjOZPvE8Bc7e2RhATaZdz3Eky TKzBApWX7M8AbOcrtfJOMA5z/F7UALrZZdEvmUI2IHJVwSGGDkcEHkZHWhAJ qNxc28iGN4oYCPmleFpQD/tYYbRjnccjrnGBkAuoXMamRVV8DcFOQD7HAz+V ICh9pvBqPku0KIW+SNom+dfUSZxuxk7dueD2+amBAb6/GjvqYNs0bWxnWLYw KfJuALbju7A8Lnrx0oAfd3l/YwtLOkLq+0AxIx8pmdVAIzmT7xPAXO3tkYAK 7axdRgRsrEu6qs/2GVQMq7EeWfmbGzqD/F7clgHwahqFxcx20axISJCZpreR NwXy8ERkg/xlcE9s57UAaNhcPc2u+QKHV3jbbwCVcrkDtnGcc4z1NAFe7uby K8CK0McTYEfmRMwkPoXBwhJwBkHqMZOVABVs57q2t2lzD9n+3SR7NpLtuuCu 7dnAwW6YPTrzwASwXt7LFZTM9uEvx+7QRNmImNnGTu+bG3HRc5zx0oAfoK3C 2s3nyxOPtE2AkZXB8189WOcnp6e9DA06QBQAUAFABQAUAFABQAUAFABQAUAF ABQAUAFABQAUAFABQAUAFABQAUAFABQAUAMm/wCPeX/rm38jTFLYyElSIvvJ 5SPAAJP8fpS6BHZB9ojlkiRN5Yyp/Aw/iHtQiixX61w3/wAiul/29/6UwEsv +Qm//XM/zWvyVEL4mT3Wl2d4ZDPEzCQYdBIwV+MZKg4J6c4yMD0FO5RcpAVY 9Ot47xrtfO85upM7kEc8bScYGTgY4zxTAjj0izj83Ambzfv77iRsnjDctww2 jB6jAwaLgSw2NvFHIgRpBKNr+c7SFh6EsSccnjpyfWgBkumW8mnzWX71Y5gQ 7CRi5zxksSSeABzngY6cUXAtIgjjVFLEKABuYsfxJ5NIB1AEH2ODyfK8v5PN 83GT9/fvz/31zTAgOkWRV0aN2RlKbGlcooIwdqk4XgkcYwDgUXAtzQxzxNFK u5T74IPUEEdCDyCOlICO2tIbXcYg5ZsZaSRnYgdBliTjk8e59aYBeWkN7AYL gOY26hZGTIxjB2kZHPSgCJtMtmCjNwCoxvW5kDEZJwWDZbGTjJOMnFFwLSIk caxxqqIoAVVGAAOwFICv/Z1t5/nbXzu37PNby92c52Z25zznHXnrzTAjOkWR V0aN2RlKbGlcooIwdqk4XgkcYwDgUXAtzQxzxNFKu5T74IPUEEdCDyCOlICs NLtRGVKykkg+Y0zmQYzjDk7h1PQ9z6mncB8Fjb28iyRo3mKGG9nZmO7bnJJy fur17ACgCaGGOBCkS7VLM5Gc8sSx/UmkBBNp1tPK0kivlvvqsrKj9vmUHDcc cg5Ax0pgP+xweT5Xl/J5vm4yfv79+f8AvrmgBkOnW0EqyRq+V+4rSsyJ2+VS cLxxwBgHHSgB8VnBDO80ceHfOeSQMnJwOgyeTjGTyc0AMtNPhtLWS3jeYpIz sS0rFssSThs5HXt9euTQBH/ZUH9jf2Xvm8jyvK3eYd+Pr/Tp2xjii4FxEEca opYhQANzFj+JPJpAOoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo AKACgAoAKACgBk3/AB7y/wDXNv5GmKWxkwSsl1tViN8SdPXLYpAtkTmd/tEM fmNy4LfN2z9f84NCKCv1rhv/AJFdL/t7/wBKYFY3CwXTukrK4G04iLY6H0+l fkpDi73TJVv5mztmc49LY/4UahZ9x/2q6/vTf+Ap/wAKeoWfcPtV1/em/wDA U/4UahZ9w+1XX96b/wABT/hRqFn3D7Vdf3pv/AU/4UahZ9w+1XX96b/wFP8A hRqFn3D7Vdf3pv8AwFP+FGoWfcPtV1/em/8AAU/4UahZ9w+1XX96b/wFP+FG oWfcPtV1/em/8BT/AIUahZ9w+1XX96b/AMBT/hRqFn3D7Vdf3pv/AAFP+FGo WfcPtV1/em/8BT/hRqFn3D7Vdf3pv/AU/wCFGoWfcPtV1/em/wDAU/4UahZ9 w+1XX96b/wABT/hRqFn3D7Vdf3pv/AU/4UahZ9w+1XX96b/wFP8AhRqFn3D7 Vdf3pv8AwFP+FGoWfcPtV1/em/8AAU/4UahZ9w+1XX96b/wFP+FGoWfcPtV1 /em/8BT/AIUahZ9w+1XX96b/AMBT/hRqFn3D7Vdf3pv/AAFP+FGoWfcPtV1/ em/8BT/hRqFn3D7Vdf3pv/AU/wCFGoWfcPtV1/em/wDAU/4UahZ9w+1XX96b /wABT/hRqFn3D7Vdf3pv/AU/4UahZ9w+1XX96b/wFP8AhRqFn3D7Vdf3pv8A wFP+FGoWfcPtV1/em/8AAU/4UahZ9w+1XX96b/wFP+FGoWfcPtV1/em/8BT/ AIUahZ9w+1XX96b/AMBT/hRqFn3D7Vdf3pv/AAFP+FGoWfcPtV1/em/8BT/h RqFn3D7Vdf3pv/AU/wCFGoWfcPtV1/em/wDAU/4UahZ9w+1XX96b/wABT/hR qFn3D7Vdf3pv/AU/4UahZ9w+1XX96b/wFP8AhRqFn3D7Vdf3pv8AwFP+FGoW fcPtV1/em/8AAU/4UahZ9w+1XX96b/wFP+FGoWfcPtV1/em/8BT/AIUahZ9w +1XX96b/AMBT/hRqFn3D7Vdf3pv/AAFP+FGoWfcPtV1/em/8BT/hRqFn3D7V df3pv/AU/wCFGoWfcPtV1/em/wDAU/4UahZ9xDeXK9XlHGebU9PypahZ9yNt Rd1ZWnbDDB/0c9Pyo1DlfcVYEL733/cVQPukYz1yPegpKyJFSNZRIfMZg27l hj+VFxi1+tcN/wDIrpf9vf8ApTAqKYhczeYGJLj6fdX8f/1V+SgTOwaezKkF TMCMdOh6UICWkAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFA BQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAU AFABQAUARx/8fs3/AFxX/wBCNPoAy4eP5uN0nt6+/wCefWgC1L/rX/3jQwGU gCv1vhv/AJFdL/t7/wBKYDFijDOzIGLHJyT6AdvpX5LcByxxK6uIVDK24fM3 X160XAb5MX91v+/r/wDxVFwDyYv7rf8Af1//AIqi4B5MX91v+/r/APxVFwDy Yv7rf9/X/wDiqLgHkxf3W/7+v/8AFUXAPJi/ut/39f8A+KouAeTF/db/AL+v /wDFUXAPJi/ut/39f/4qi4B5MX91v+/r/wDxVFwDyYv7rf8Af1//AIqi4B5M X91v+/r/APxVFwDyYv7rf9/X/wDiqLgHkxf3W/7+v/8AFUXAPJi/ut/39f8A +KouAeTF/db/AL+v/wDFUXAPJi/ut/39f/4qi4B5MX91v+/r/wDxVFwDyYv7 rf8Af1//AIqi4B5MX91v+/r/APxVFwDyYv7rf9/X/wDiqLgHkxf3W/7+v/8A FUXAPJi/ut/39f8A+KouAeTF/db/AL+v/wDFUXAPJi/ut/39f/4qi4B5MX91 v+/r/wDxVFwDyYv7rf8Af1//AIqi4B5MX91v+/r/APxVFwDyYv7rf9/X/wDi qLgHkxf3W/7+v/8AFUXAPJi/ut/39f8A+KouAeTF/db/AL+v/wDFUXAPJi/u t/39f/4qi4B5MX91v+/r/wDxVFwDyYv7rf8Af1//AIqi4B5MX91v+/r/APxV FwDyYv7rf9/X/wDiqLgHkxf3W/7+v/8AFUXAPJi/ut/39f8A+KouAeTF/db/ AL+v/wDFUXAPJi/ut/39f/4qi4B5MX91v+/r/wDxVFwDyYv7rf8Af1//AIqi 4B5MX91v+/r/APxVFwDyYv7rf9/X/wDiqLgHkxf3W/7+v/8AFUXAPJi/ut/3 9f8A+KouAeTF/db/AL+v/wDFUXAPJi/ut/39f/4qi4B5MX91v+/r/wDxVFwD yYv7rf8Af1//AIqi4DkjiQsVj5YAEl2JwDn1ouACOEAAQoAO2T/jRcBzHcxY 9Sc0gEoAK/W+G/8AkV0v+3v/AEpgM8mH/n3g/wC/S/4V+S3AeLaIgH7Pb4Pr GgouwD7LF/zwtv8AvhKeoB9li/54W3/fCUagH2WL/nhbf98JRqAfZYv+eFt/ 3wlGoB9li/54W3/fCUagH2WL/nhbf98JRqAfZYv+eFt/3wlGoDPJg7QW5xxx Gp/pSuwHC2iYZFvb46cxoP6UXYC/ZYv+eFt/3wlPUA+yxf8APC2/74SjUA+y xf8APC2/74SjUA+yxf8APC2/74SjUA+yxf8APC2/74SjUA+yxf8APC2/74Sj UA+yxf8APC2/74SjUBphgBI8i3JHXEaHH6UrsBVt4mBIt7fA9Y0H9KLsBfss X/PC2/74SnqAfZYv+eFt/wB8JRqAfZYv+eFt/wB8JRqAfZYv+eFt/wB8JRqA fZYv+eFt/wB8JRqAfZYv+eFt/wB8JRqAfZYv+eFt/wB8JRqA1oIVIBgtsnoA iE0rsBVt4mzi3t+OeY1H9KLsBfssX/PC2/74SnqAfZYv+eFt/wB8JRqAfZYv +eFt/wB8JRqAfZYv+eFt/wB8JRqAfZYv+eFt/wB8JRqAfZYv+eFt/wB8JRqA fZYv+eFt/wB8JRqAjW8K4zDbc8D5E5pXYCCCFiALeDJ4/wBUv+FF2A77LF/z wtv++Ep6gH2WL/nhbf8AfCUagH2WL/nhbf8AfCUagH2WL/nhbf8AfCUagH2W L/nhbf8AfCUagH2WL/nhbf8AfCUagH2WL/nhbf8AfCUagI1vCoy0NqB/uJRq A3yYf+feD/v0v+FK4Dzaxg4NvbZ/3Ep6gH2WL/nhbf8AfCUagH2WL/nhbf8A fCUagH2WL/nhbf8AfCUagH2WL/nhbf8AfCUagH2WL/nhbf8AfCUagH2WL/nh bf8AfCUagIbaFQSYbUAcklU4o1Ab5MP/AD7wf9+l/wAKVwLkGoXltCsNvcSQ xL91IztUd+AK/WuG3/wl0v8At7/0pgVq/JAHv92P/d/qaYDKQGZq+ovYy2iA xxRzuVeeVSyx4HAIBHU989jTSEEWqiC3UamRHcgOzpFG7AKrEbsYJC9OTRbs A59d02PzN1z/AKrG7CMcA9D05HTkccj1FFmFyG/1lYbq2htZYnLXSwSqyk9e u05AyO/XGRnHdpAa9SMKAIrb/VN/10f/ANCNMCwf9Uv+8f6UAMpAVNWu5LHT J7mGLzXjXIXn16n2HX8KaAqWuqMA8t3NC9s4j+zywxsPMLEgrtySWBHQc+tO wiyNWsiIj5p/ey+Sv7tuHzjaePlP1xSsMR9YsUUM0r8qzECJyyqpwSRjIAII 5osBdR1kRXRgysMhgcgj1pALQBFD/rZ/+ug/9BWmBYH+qb/eH9aAGUgM7WLy 5s/sn2cxfv7hYW8xC2N3cYI6YpoQqa3p7uqLOdxl8naY2BD9geOPx9D6GizH cDren5H78ncSEIjYiQghcKcfNye2aLMLgdb08AkzkYDEgxtkbT8wxjOR1I6g c9OaLMLhYavBqF5NBAsm2JEcOyEBt3PcccY69eccDNDVgNCkBE3/AB9x/wDX N/5rTAsJ92T/AHf6igCtcz+RGCF3MzBFBOBuPTJ7D/8AUMkgEAjNw8EojuMP uQsrRIc8Abvl5P0PvjrjcAEt7GHhSOWP96VIZskFT3BHBzwOvG4eoBAHy3kE RYO5+QgNtUtgkZA4HU+nXkeoyANgulNvFJK6fvG2B1B2sckAjPQHt25ABOQS AON5ACV3ksCwKKpLDaMngDPp9cjHUZAGtc5uLZYijxzKzZHPAAIII7c+mOeo OAwBJN/rYP8Arof/AEFqALEX+tT/AHhQgGUgMnVdRms9Qs4VmtoYbgPukmQn YVGeu4DnIFUkIdBqZFokl3NFG1xzbt5ZGVKBtxUMcAZOTkDjqKVgINN1ma8G m+YYUa5Ehddj87ScbTyO3OTTaAsW+uWsyXDuJIlin8gbkbLtxwBjOc5468ZO KVguTf2tZbEfzTh3aMfu2zvHVSMZDegPJ7ZosMntLqG9t0uLd98T52tgjODj v9KAFuf9Uv8A10T/ANCFAEtIB8v+tf8A3jTYGdqF7JDcWtpbqnn3TNtaQEqq qMsSByTjoP1oSAb9tltJZF1BoxGBGI5I0b94zFhgLyc8DgZ9e+AWAc2s2CRp I8+1HkMWWRhtcdQ3Hyn64oswFXVrJoGmEp2rL5JBjYNv/uhcZJ59KLARprum yKHS5ynGW2NtTJwNxxheR3xRZiuLpF5NeJdC48vdBcvCDGpAIXHOCT60NDLd 3/x6Tf8AXNv5UAS0gCv1vhv/AJFdL/t7/wBKYBX5IA9/ux/7v9TTAZSAz9Tt bi6eNY0hmtyjpNDM7KGzjBGAeQR1poDMj8P3EQtzI6XW21NvIjTPF/FnqoJI wcYPoPwdxWEl0G8eDUIU+zKtykKR4dvl8vA5BB6gepx0560XCxIdGvfmwbf/ AI/Rej943LcZT7vTr83sOBnguB0FSMKAIrb/AFTf9dH/APQjTAsH/VL/ALx/ pQAykBW1CO5ktGWzdEnDKylyQvDAkHHOCARTQGONEu4xKYBbRLJcpL9nDkqg AO7a23KsSeoAxjg07isSR6JMNPvbZmQPLN9ogkWQlo3wO5GeCMbupBPSi4WH XOht9pheICaFLQWpjeZoiQDwSVHORnIxii4WNe2iFvbRQjGI0CDAIHAx3JP6 mkMkpARQ/wCtn/66D/0FaYFgf6pv94f1oAZSAztYs7m8+yfZxF+4uFmbzHK5 29hgHrmmhGeNHv8AYSRbbv7QF6B5rYxzlc7fpzTugI5PDtw7RyJ5Vv5ciytB FO/lyPnkjjMZx0xnt0xyXCxYi0i4i1G0uIoreNIpJJJF852YlwFJyRyeM9uu O2SXAuW1lcwaze3W6LyLnZ3Jb5VxjHQcnOcnp054V9ANGkMib/j7j/65v/Na YFhPuyf7v9RQBVu4WmRDGR5kTh1B4BI7ZHIznqPxyMggDJIppJ0lKxjyQxRd 5O5jkDPHHGOQCeSOmdwBD9jmSzgjTyzJFKZMliAfvd8Z5zzznk5Lchi4FSSY pPK3ljbHOXVFkC4YcE4xu5LqTjrk8HP7xiLf2OZLOCNPLMkUpkyWIB+93xnn PPOeTktyGVxifY7kSEgRFBM0yrvKncc45xwPXAGdxznB3ghbezmje2D+WVhL kkMcsWzzgj6ercn5jzvLjLc3+tg/66H/ANBagCxF/rU/3hQgGUgMzULS7m1S yurdYWW2D5EkhUsWGOynpTQiv/Zt/wDbLO5X7MqWYKRWwdsBSuMl9uSenGOg p3QEVlo17azaaM27xWTS/N5jBnV++NvBHpk/Wi4AdFvd0hD2+Bf/AGxFJb5+ fuk4+Xj2PXtjkuANo16I0Km3Lm/N66mRgB6KDt5+uB9KLgdBUjIrn/VL/wBd E/8AQhTAlpAPl/1r/wC8abAztQspJri1u7dk8+1ZtqyEhWVhhgSOQcdD+lCY Fe+s9Ru0Q7rYYlRvJOcKBuzh8Z3HI5AGMcepasIpf2LfRqqR/Z2Vb0XmXmbP TlPunP8Avd/Si6Cw+TRb0xz+W9uHF/8AbISxYg/7Lccfhn+tFwHTaJPPeXUt wsMq3YTcvnSIIyvH3R9/HHUjp2ouFi7o9nc2f2v7QIv39w0y+W5bG7scgdMU mBcu/wDj0m/65t/KgZLSAK/W+G/+RXS/7e/9KYBX5IA2RXcriV0AGMKB6+4p gM8l/wDn4l/Jf8KADyX/AOfiX8l/woAPJf8A5+JfyX/CgA8l/wDn4l/Jf8KA DyX/AOfiX8l/woAPJf8A5+JfyX/CgA8l/wDn4l/Jf8KAHRRiNNoJbknJ6nJz QAsgZ1VRIyAEn5QOfzB9KAGeS/8Az8S/kv8AhQAeS/8Az8S/kv8AhQAeS/8A z8S/kv8AhQAeS/8Az8S/kv8AhQAeS/8Az8S/kv8AhQAeS/8Az8S/kv8AhQAe S/8Az8S/kv8AhQA6KPy93zMxY5JbHoB2+lADnDMm1XKZIOVxn9frQBH5L/8A PxL+S/4UAHkv/wA/Ev5L/hQAeS//AD8S/kv+FAB5L/8APxL+S/4UAHkv/wA/ Ev5L/hQAeS//AD8S/kv+FAB5L/8APxL+S/4UACQlZA7Su5AIG7HGceg9qAJT koyqxXcMZGMjn3oAi8l/+fiX8l/woAPJf/n4l/Jf8KADyX/5+JfyX/CgA8l/ +fiX8l/woAPJf/n4l/Jf8KADyX/5+JfyX/CgA8l/+fiX8l/woABCd6s00j7T kA7cdCOw96AJlO1gw6g5pAQ+S/8Az8S/kv8AhTAPJf8A5+JfyX/CgA8l/wDn 4l/Jf8KADyX/AOfiX8l/woAPJf8A5+JfyX/CgA8l/wDn4l/Jf8KADyX/AOfi X8l/woAQwFsbp5GAIOCF5wc+lAE1ICN0d3ZvPkG4k4AXA/SmAnkv/wA/Ev5L /hQAeS//AD8S/kv+FAB5L/8APxL+S/4UAHkv/wA/Ev5L/hQAeS//AD8S/kv+ FAB5L/8APxL+S/4UANe3Z0ZGuJSrDBGF/wAKAJ6QBX63w3/yK6X/AG9/6UwG eTD/AM+8H/fpf8K/JbgHkw/8+8H/AH6X/Ci4B5MP/PvB/wB+l/wouAeTD/z7 wf8Afpf8KLgHkw/8+8H/AH6X/Ci4B5MP/PvB/wB+l/wouAeTD/z7wf8Afpf8 KLgHkw/8+8H/AH6X/Ci4B5MP/PvB/wB+l/wouAeTD/z7wf8Afpf8KLgHkw/8 +8H/AH6X/Ci4B5MP/PvB/wB+l/wouAeTD/z7wf8Afpf8KLgHkw/8+8H/AH6X /Ci4B5MP/PvB/wB+l/wouAeTD/z7wf8Afpf8KLgHkw/8+8H/AH6X/Ci4B5MP /PvB/wB+l/wouAeTD/z7wf8Afpf8KLgHkw/8+8H/AH6X/Ci4B5MP/PvB/wB+ l/wouAeTD/z7wf8Afpf8KLgHkw/8+8H/AH6X/Ci4B5MP/PvB/wB+l/wouAeT D/z7wf8Afpf8KLgHkw/8+8H/AH6X/Ci4B5MP/PvB/wB+l/wouAeTD/z7wf8A fpf8KLgHkw/8+8H/AH6X/Ci4B5MP/PvB/wB+l/wouAeTD/z7wf8Afpf8KLgH kw/8+8H/AH6X/Ci4B5MP/PvB/wB+l/wouAeTD/z7wf8Afpf8KLgHkw/8+8H/ AH6X/Ci4B5MP/PvB/wB+l/wouAeTD/z7wf8Afpf8KLgHkw/8+8H/AH6X/Ci4 B5MP/PvB/wB+l/wouAeTD/z7wf8Afpf8KLgHkw/8+8H/AH6X/Ci4B5MP/PvB /wB+l/wouAeTD/z7wf8Afpf8KLgHkw/8+8H/AH6X/Ci4B5MP/PvB/wB+l/wo uAeTD/z7wf8Afpf8KLgHkw/8+8H/AH6X/Ci4B5MP/PvB/wB+l/wouAeTD/z7 wf8Afpf8KLgHkw/8+8H/AH6X/Ci4B5MP/PvB/wB+l/wouAeTD/z7wf8Afpf8 KLgHkw/8+8H/AH6X/Ci4B5MP/PvB/wB+l/wouAeTD/z7wf8Afpf8KLgHkw/8 +8H/AH6X/Ci4FyDULy2hWG3uJIYl+6kZ2qO/AFfrXDb/AOEul/29/wClMCtX 5IAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAU AFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFAB QAUAFABQAUAFfrfDf/Irpf8Ab3/pTAK/JACgAoAKACgAoAKACgAoAKACgAoA KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAr9b4b/wCRXS/7e/8A SmB//9k= ---2139633923-5758-840424870:#18941--   Received: from ietf.org by ietf.org id aa28236; 19 Aug 96 3:17 EDT Received: from cnri by ietf.org id aa28231; 19 Aug 96 3:17 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa02768; 19 Aug 96 3:17 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id DAA10944; Mon, 19 Aug 1996 03:10:26 -0400 Received: from domen.uninett.no (domen.uninett.no [129.241.131.10]) by list.cren.net (8.6.12/8.6.12) with SMTP id DAA10924 for ; Mon, 19 Aug 1996 03:10:02 -0400 Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) id <07244-0@domen.uninett.no>; Mon, 19 Aug 1996 09:08:42 +0200 Message-Id: <7241.840438520@domen.uninett.no> Date: Mon, 19 Aug 1996 09:08:40 +0200 X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Harald.T.Alvestrand@uninett.no To: schaefer@nbn.com Cc: ietf-822@list.cren.net, moore@cs.utk.edu Subject: Re: MIME implementation documentation In-Reply-To: Your message of "Sat, 17 Aug 1996 21:57:20 PDT." <960817215720.ZM20697@candle.brasslantern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Sender: Harald.T.Alvestrand@uninett.no X-Mailer: exmh version 1.6.7 5/3/96 X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN I would say that Z'mail's scheme: > Z-Mail does provide for display of nested body parts, but it does so = > by invoking metamail for the second nesting level and beyond. is an example of NOT implementing nested body parts; it certainly doesn't= count as an independent implementation. I've listed Metamail, with some trepidation. Thanks for the information - MediaMail seems to be interesting! Harald A   Received: from ietf.org by ietf.org id aa03719; 19 Aug 96 9:41 EDT Received: from cnri by ietf.org id aa03713; 19 Aug 96 9:41 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa06748; 19 Aug 96 9:41 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id JAA20208; Mon, 19 Aug 1996 09:34:17 -0400 Received: from fv.com (zloty.fv.com [207.67.199.12]) by list.cren.net (8.6.12/8.6.12) with ESMTP id JAA20171 for ; Mon, 19 Aug 1996 09:33:48 -0400 Received: from nsb.fv.com (p25.hubbard8.t.ic.net [152.160.99.25]) by fv.com (8.7.4/8.7.3) with SMTP id GAA09334; Mon, 19 Aug 1996 06:33:02 -0700 (PDT) Received: by nsb.fv.com (4.1/SMI-4.1) id AA00747; Mon, 19 Aug 96 09:22:53 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.hyzenthlay.nsb.fv.com.sun4.41 via MS.5.6.hyzenthlay.nsb.fv.com.sun4_41; Mon, 19 Aug 1996 09:22:51 -0400 (GMT) Message-Id: Date: Mon, 19 Aug 1996 09:22:51 -0400 (GMT) X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Nathaniel Borenstein To: Harald.T.Alvestrand@uninett.no Cc: ietf-822@list.cren.net Subject: Re: MIME implementation documentation (nested bodies) In-Reply-To: <199608190314.MAA10441@airco.co.jp> References: <199608190314.MAA10441@airco.co.jp> X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN A few more data points: > * Is multipart/alternative widely implemented for generation? The Andrew Messages program generates multipart/alternative routinely with no explicit user action required. > * Is multipart/alternative widely implemented for reception? Again, Andrew Messages does this right. First Virtual has also built a gateway that converts multipart/alternative and other stuff to non-MIME text mail, which might be considered an implementation of the reception of multipart/alternative. > * Are Nested Body Parts widely implemented? Andrew Messages handles these well upon reception, but does not generate them. Safe-Tcl programs generate them routinely, but Safe-Tcl does not provide general-purpose composition tools at the user (as opposed to programmer) level. > * Are External Body Parts widely implemented? Metamail handles their reception very well, and its companion "mailto" program is easily configured to facilitate their composition. The metamail program also includes a simple special-purpose program for composing external body part mail. -------- Nathaniel Borenstein D3789F3368C124D5 Chief Scientist, First Virtual Holdings 7AEDD0DC859E8C02   Received: from ietf.org by ietf.org id aa10543; 19 Aug 96 11:32 EDT Received: from cnri by ietf.org id aa10539; 19 Aug 96 11:32 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa08631; 19 Aug 96 11:32 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id LAA00706; Mon, 19 Aug 1996 11:25:09 -0400 Received: from muswell.demon.co.uk (muswell.demon.co.uk [158.152.10.120]) by list.cren.net (8.6.12/8.6.12) with ESMTP id LAA00592 for ; Mon, 19 Aug 1996 11:24:28 -0400 Received: (from ruth@localhost) by muswell.demon.co.uk (8.6.12/8.6.12) id PAA00268; Mon, 19 Aug 1996 15:57:05 +0100 Message-Id: <199608191457.PAA00268@muswell.demon.co.uk> Date: Mon, 19 Aug 1996 15:57:05 +0100 X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: ruth moulton To: Harald.T.Alvestrand@uninett.no Cc: ietf-822@list.cren.net, moore@cs.utk.edu, ruth@muswell.demon.co.uk, jedds-tech@gu.edu.au Subject: Re: MIME implementation documentation In-Reply-To: <23913.840267370@domen.uninett.no> (Harald.T.Alvestrand@uninett.no) X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN Harald, I am working on a library project called JEDDS which is about sending ocuments in e-mail, using a library agreement called GEDI. (I can tell ou all about any of this further if you'd like to know) JEDDS is comissioning RLG, a company in MountainView California, to develop a product; as part of the requirements specification we have designed a mime message to carry the document. The product will include MUA to both generate and receive the message, and of course we expect other applications to use this mime format in time. The current plan is to have a multipart/x-gedi-document, the first part of which is a multipart/alternative body, with two alternative representations of the GEDI data (information accompanying the document to be used by inter-library-loan software), one human readable, one machine. The other body part(s) carry the document in well known formats, mainly Tiff to start with. So we will be using alternative and nesting. We intend to put the body part forward to the GEDI group for adoption and when/if it gets accepted in time to IANA for registration I know these are only plans at the moment (and are thus flexible) so i) may not count from your point of view but ii) we need to re-think our plans if MIME changes in ways significant from our point of view. JEDDS is an Australian based project, funded by the Australian Vice Chancellors Committee, and has as members national libraries in Australia, New Zealand. The British Library is also involved through it's participation in the UK e-lib projects. Ruth > When in doubt, write a Web page.... > I have written up a Web page for the Last Call on > http://domen.uninett.no/apps/last-call/mime-draft2.html > and attached a text version to this document. > Given the debate that has occured, I regard the question of > multipart/alternative as settled, while there is still missing evidence for > multipart/parallel, generation of nested body parts and handling of external > body parts. > When new evidence arrives (on this list, please!), I will update the Web page. > Harald T. Alvestrand > Apps AD > ------- =_aaaaaaaaaa0 > Content-Type: text/plain; charset="us-ascii" > Content-ID: <23909.840267369.2@domen.uninett.no> > LAST CALL FOR MIME DOCUMENTS TO RECYCLE AT DRAFT > The following Last Call has been issued: > The IESG has received a request to consider the following Protocol > Actions: > 1. Multipurpose Internet Mail Extensions (MIME) Part One: Format of > Internet Message Bodies" for the > status of Draft Standard. > 2. Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types > for the status of Draft > Standard. > 3. MIME (Multipurpose Internet Mail Extensions) Part Three: Message > Header Extensions for Non-ASCII Text > for the > status of Best Current Practice. > 5. Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance > Criteria and Examples for the > status of Draft Standard > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by August 8, 1996. > No objections to the Last Call were received before August 8. > After the timeout date for the Last Call comments, the following > issues with regard to implementation experience have been raised: >* Is multipart/alternative widely implemented for generation? >* Is multipart/alternative widely implemented for reception? >* Is multipart/parallel widely implemented? >* Are Nested Body Parts widely implemented? >* Are External Body Parts widely implemented? > The issue here is if the "two implementations" rule (which > traditionally have allowed two experimental implementations without > terribly useful user interfaces) should be strengthened for a > specification of this maturity to mean "two interworking, commercial > implementations that can be used by someone not terribly skilled in > the arcana of MIME". > The sections below will give the arguments and evidence in each case. > Is multipart/alternative widely implemented for generation? > The question is if there exist MUAs that can generate a MIME > multipart/alternative without excessive thinking on the part of the > user. > The following MIME UAs have been claimed to do so: >* Cyberdog for the Macintosh >* Ishmail >* An yet-unnamed product from Microsoft > This AD regards the question as settled. > Is multipart/alternative widely implemented for reception? > The question is if there exist UAs that display the "best" body part > (that being defined as the last part of the multipart/alternative that > the UA is able to display). > The following UAs have been claimed to do so: >* Pine >* Metamail >* Mac Eudora 3.0 > This AD regards the question as settled. > Is multipart/parallel widely implemented? > The question is if there are UAs that display all parts of the > multipart/parallel "at the same time", as described in the drafts, and > do not jsut treat it like multipart/mixed, and if there are generating > UAs. > To date, no generating UA has been identified. > To date, only Metamail has been mentioned as an example of a > displayer. > Are Nested Body Parts widely implemented? > Many MUAs work according to the "one message with attachments" > metaphor, which is not the same as the MIME "bodyparts may nest to any > level" structure. Forwarded messages are not part of this question. > One may argue that the "inline/attachment" distinction that is carried > in content-disposition is missing functionality in MIME. However, > content-disposition is the subject of another ongoing action, and will > have to catch up later. > The question is if there exist MUAs that: > 1. Generate nested multiparts through a reasonable user interface > 2. Usefully display nested multiparts > The following MUAs have reasonable support for generating nested > multiparts: >* > The following MUAs have reasonable support for displaying nested > multiparts: >* EXMH 1.6.7 > Are External Body Parts widely implemented? > The question is if there exist MUAs that: > 1. Generate External Body Parts through a reasonable user interface > 2. Usefully handle External Body Parts > The IETF internet-drafts announcement uses multipart/alternative with > external body parts to list the ways in which one can get the I-Ds. > This is special purpose code, and only proves that such messages can > be generated. > The following MUAs have reasonable support for generating External > Body Parts: >* > The following MUAs have reasonable support for handling External Body > Parts: >* MH 6.8.3 >_________________________________________________________________ > Harald.T.Alvestrand@uninett.no > Last modified: Sat Aug 17 09:32:26 1996 > ------- =_aaaaaaaaaa0-- =============================================== Ruth Moulton ruth@muswell.demon.co.uk Consultant 65 Tetherdown, London N.10 1NH, UK Tel:+44 181 883 5823 -   Received: from ietf.org by ietf.org id aa14879; 19 Aug 96 13:33 EDT Received: from cnri by ietf.org id aa14874; 19 Aug 96 13:33 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa10753; 19 Aug 96 13:33 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id NAA06676; Mon, 19 Aug 1996 13:23:15 -0400 Received: from nic.carlstedt.se (root@nic.carlstedt.se [193.12.107.228]) by list.cren.net (8.6.12/8.6.12) with ESMTP id NAA06642 for ; Mon, 19 Aug 1996 13:22:51 -0400 Received: from giraf.carlstedt.se (root@giraf.carlstedt.se [193.12.107.225]) by nic.carlstedt.se (8.7.5/8.7.3) with ESMTP id TAA17216; Mon, 19 Aug 1996 19:22:48 +0200 (MET DST) Received: from ginger.carlstedt.se (serial-maf.carlstedt.se [193.12.107.112]) by giraf.carlstedt.se (8.7.5/8.7.3) with ESMTP id TAA24560; Mon, 19 Aug 1996 19:22:42 +0200 (MET DST) Message-Id: <199608191722.TAA24560@giraf.carlstedt.se> Date: Mon, 19 Aug 1996 19:22:29 +0200 (MET DST) X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: maf@dtek.chalmers.se To: Harald.T.Alvestrand@uninett.no Cc: ietf-822@list.cren.net Subject: Re: MIME implementation documentation In-Reply-To: <23913.840267370@domen.uninett.no> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII X-Sender: Martin Forssen X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN > The following MUAs have reasonable support for displaying nested > multiparts: > * EXMH 1.6.7 TkRat does show all nested bodyparts, no support for composing them other than forwarding a message though (yet). One very useful application of this is that when you reply to a message that contain nested message/rfc822 (at any depth) it asks you which message you really want to reply to, this is handy when handling the bounce messages that newer sendmails generate. /MaF PS TkRat is a graphical MUA I am developing the latest available release is 0.70 which is beta quality. For more information see http://www.dtek.chalmers.se/~maf/ratatosk/ (unfortunately this server seems to be down at the moment).   Received: from ietf.org by ietf.org id aa14889; 19 Aug 96 13:33 EDT Received: from cnri by ietf.org id aa14885; 19 Aug 96 13:33 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa10762; 19 Aug 96 13:33 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id NAA06605; Mon, 19 Aug 1996 13:22:13 -0400 Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by list.cren.net (8.6.12/8.6.12) with SMTP id NAA06558 for ; Mon, 19 Aug 1996 13:21:50 -0400 Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <16954(6)>; Mon, 19 Aug 1996 10:21:17 PDT Received: by golden.parc.xerox.com id <2757>; Mon, 19 Aug 1996 10:20:57 PDT Message-Id: <96Aug19.102057pdt."2757"@golden.parc.xerox.com> Date: Mon, 19 Aug 1996 10:20:57 PDT X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Larry Masinter To: ruth@muswell.demon.co.uk Cc: Harald.T.Alvestrand@uninett.no, ietf-822@list.cren.net, moore@cs.utk.edu, jedds-tech@gu.edu.au Subject: Re: MIME implementation documentation In-Reply-To: <199608191457.PAA00268@muswell.demon.co.uk> (message from ruth moulton on Mon, 19 Aug 1996 07:57:05 PDT) X-Sender: Larry Masinter X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN Ruth Moulton wrote... > ... the current plan is to have a multipart/x-gedi-document ... which reminds me that I really wish the current MIME documents were clearer about the inappropriateness of using "x-" names in *any* protocol definition. If you're going to do an experiment, you can use "x-", but as soon as you write a spec that you intend for anyone else to read, then REGISTER YOUR TYPE. There's no value at all in the proliferation of "x-" media type names. Larry   Received: from ietf.org by ietf.org id aa27684; 19 Aug 96 22:38 EDT Received: from cnri by ietf.org id aa27680; 19 Aug 96 22:38 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa23406; 19 Aug 96 22:38 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id WAA25800; Mon, 19 Aug 1996 22:29:23 -0400 Received: from ng.netgate.net (root@ng.netgate.net [204.145.147.10]) by list.cren.net (8.6.12/8.6.12) with ESMTP id WAA25774 for ; Mon, 19 Aug 1996 22:28:58 -0400 Received: from [205.214.160.151] (d31.netgate.net [205.214.160.65]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id TAA02144; Mon, 19 Aug 1996 19:34:31 -0700 (PDT) Message-Id: Date: Mon, 19 Aug 1996 18:59:36 -0700 X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Dave Crocker To: Larry Masinter Cc: ruth@muswell.demon.co.uk, Harald.T.Alvestrand@uninett.no, ietf-822@list.cren.net, moore@cs.utk.edu, jedds-tech@gu.edu.au Subject: Re: MIME implementation documentation In-Reply-To: <96Aug19.102057pdt."2757"@golden.parc.xerox.com> References: <199608191457.PAA00268@muswell.demon.co.uk> (message from ruth moulton on Mon, 19 Aug 1996 07:57:05 PDT) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Sender: dcrocker@ng.netgate.net X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN At 10:20 AM -0700 8/19/96, Larry Masinter wrote: >"x-", but as soon as you write a spec that you intend for anyone else >to read, then REGISTER YOUR TYPE. There's no value at all in >the proliferation of "x-" media type names. YES! X- is only for UNregistered. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org   Received: from ietf.org by ietf.org id aa17446; 20 Aug 96 12:09 EDT Received: from cnri by ietf.org id aa17442; 20 Aug 96 12:09 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa09290; 20 Aug 96 12:09 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id MAA10256; Tue, 20 Aug 1996 12:02:29 -0400 Received: from domen.uninett.no (domen.uninett.no [129.241.131.10]) by list.cren.net (8.6.12/8.6.12) with SMTP id CAA04224 for ; Tue, 20 Aug 1996 02:34:59 -0400 Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) id <24333-0@domen.uninett.no>; Tue, 20 Aug 1996 08:34:16 +0200 Message-Id: <24329.840522851@domen.uninett.no> Date: Tue, 20 Aug 1996 08:34:11 +0200 X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Harald.T.Alvestrand@uninett.no To: Larry Masinter Cc: ruth@muswell.demon.co.uk, ietf-822@list.cren.net, moore@cs.utk.edu, jedds-tech@gu.edu.au Subject: Re: MIME implementation documentation In-Reply-To: Your message of "Mon, 19 Aug 1996 10:20:57 PDT." <96Aug19.102057pdt."2757"@golden.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: Harald.T.Alvestrand@uninett.no X-Mailer: exmh version 1.6.7 5/3/96 X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN I hope the change rules and registration trees described in draft-ietf-822ext-mime-reg-04.txt will make it simpler to register new types, so that people will register. Also, the new docs give rules for CHANGING a registry entry, so that there isn't the "gotcha" effect that I feel registration has today; if you realized the registration was wrong, you can now change it. Please read the rules! Harald A   Received: from ietf.org by ietf.org id aa17553; 20 Aug 96 12:13 EDT Received: from cnri by ietf.org id aa17549; 20 Aug 96 12:13 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa09374; 20 Aug 96 12:13 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id MAA10040; Tue, 20 Aug 1996 12:01:39 -0400 Received: from domen.uninett.no (domen.uninett.no [129.241.131.10]) by list.cren.net (8.6.12/8.6.12) with SMTP id CAA03871 for ; Tue, 20 Aug 1996 02:22:42 -0400 Received: from dale.uninett.no by domen.uninett.no with SMTP (PP) id <23792-0@domen.uninett.no>; Tue, 20 Aug 1996 08:20:56 +0200 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.12) with ESMTP id WAA01289; Mon, 19 Aug 1996 22:01:13 +0200 Message-Id: <1287.840484873@dale.uninett.no> Date: Mon, 19 Aug 1996 22:01:13 +0200 X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Harald.T.Alvestrand@uninett.no To: ruth moulton Cc: ietf-822@list.cren.net, moore@cs.utk.edu, jedds-tech@gu.edu.au Subject: Re: MIME implementation documentation In-Reply-To: Your message of "Mon, 19 Aug 1996 15:57:05 BST." <199608191457.PAA00268@muswell.demon.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1285.840484873.1@dale.uninett.no> X-Sender: hta@dale.uninett.no X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN Ruth, thanks for the info - we certainly don't want anything to disturb the peace of mind of ongoing projects! At the moment, I think it's only multipart/parallel where I have grave doubts about our implementation experience. Enjoy! Harald A   Received: from ietf.org by ietf.org id aa08200; 21 Aug 96 1:45 EDT Received: from cnri by ietf.org id aa08196; 21 Aug 96 1:45 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa01914; 21 Aug 96 1:45 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id BAA16280; Wed, 21 Aug 1996 01:33:08 -0400 Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by list.cren.net (8.6.12/8.6.12) with ESMTP id BAA16247 for ; Wed, 21 Aug 1996 01:32:31 -0400 Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.0-7 #8694) id <01I8IJ8OIWXS8Y5617@INNOSOFT.COM>; Tue, 20 Aug 1996 22:32:19 -0700 (PDT) Message-Id: <01I8IJY8NFFU8Y5617@INNOSOFT.COM> Date: Tue, 20 Aug 1996 22:18:53 -0700 (PDT) X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Ned Freed To: Dave Crocker Cc: ietf-822@list.cren.net Subject: Re: MIME implementation documentation In-Reply-To: "Your message dated Fri, 16 Aug 1996 16:43:48 -0700" References: <01I8CJGV6XIU8Y507E@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN > At 3:10 PM -0700 8/16/96, Ned Freed wrote: > >So that's three MUAs producing multipart/alternative. > I respectively submit to one an all that the question of > /alternative is now answered and the topic closed. I think it was dandy to > raise the question, but it is well and truly laid to rest. > /parallel seems to be a different matter? No it isn't. As I previously stated in an earlier message, we had multiple interoperable implementations of multipart/parallel in 1990, long before the original MIME RFC came out. Specifically, we had Metamail and MHN. I know for a fact that Metamail support for multipart/parallel works because I have used it and I just confirmed with Marshall Rose that MHN did and does support this construct. As for the ability to create such things casually in a user agent being a criteria for interoperability, I remain to be convinced of its validity. Try as I might I cannot stretch the words in the standards criteria to cover such a thing. But even if it is valid, I have already stated that we provide tools in PMDF to do this sort of thing -- no hand editing required. (You have to specify some options on the command line, but that's it.) And believe it or not, when I was checking for what we do with parallel I found that there is even an option in PMDF-MR (MIME aware gateway to Message Router) that creates multipart/parallel based on some craziness in ALL-IN-1 -- I don't recall the details, but apparently there is some construct in ALL-IN-1 that maps best to multipart/parallel, so there's even a case of an *ancient* (dating back to the early '80s) user agent that let's users create and can process objects with parallel semantics. Ned   Received: from ietf.org by ietf.org id aa08444; 21 Aug 96 2:22 EDT Received: from cnri by ietf.org id aa08440; 21 Aug 96 2:22 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa02286; 21 Aug 96 2:22 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id CAA17162; Wed, 21 Aug 1996 02:13:30 -0400 Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by list.cren.net (8.6.12/8.6.12) with ESMTP id CAA17147 for ; Wed, 21 Aug 1996 02:13:20 -0400 Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.0-7 #8694) id <01I8IJ8OIWXS8Y5617@INNOSOFT.COM>; Tue, 20 Aug 1996 23:12:20 -0700 (PDT) Message-Id: <01I8ILCUR1C48Y5617@INNOSOFT.COM> Date: Tue, 20 Aug 1996 23:09:53 -0700 (PDT) X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Ned Freed To: Harald.T.Alvestrand@uninett.no Cc: ietf-822@list.cren.net, Ned.Freed@innosoft.com, moore@cs.utk.edu Subject: Re: The MIME debate - my conclusions In-Reply-To: "Your message dated Tue, 20 Aug 1996 10:38:34 +0200" <26212.840530314@domen.uninett.no> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN > I have reached the following preliminary conclusion, based on the > evidence collected in the Web page > http://www.apps.ietf.org/apps/last-call/mime-draft2.html: > - Multipart/alternative is implemented. > - Nested Body Parts are implemented. > - External Body Parts are implemented. > - Multipart/parallel is NOT implemented. I strongly object to this last. Multipart/parallel had multiple, interoperable implementations in 1990, before MIME even appeared as an RFC. Facilities to generate parallel objects without hand editing also exist. > The evidence is a little weak on programs to generate nested body parts, > and on programs that generate EBPs that are not FTP; I will not pursue > this matter further at this time. > Based on this, I will recommend the following to the IESG: > - The current MIME drafts are accepted for Draft Standard > - The RFC-Editor is instructed to delete all reference to > multipart/parallel from draft-ietf-822ext-mime-imt-05.txt > RFC 1521 will remain the definition of that body part. Again, I strongly object to this last. Ned   Received: from ietf.org by ietf.org id aa19310; 21 Aug 96 11:56 EDT Received: from cnri by ietf.org id aa19306; 21 Aug 96 11:56 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa11978; 21 Aug 96 11:56 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id LAA23638; Wed, 21 Aug 1996 11:39:05 -0400 Received: from domen.uninett.no (domen.uninett.no [129.241.131.10]) by list.cren.net (8.6.12/8.6.12) with SMTP id EAA19136 for ; Wed, 21 Aug 1996 04:50:09 -0400 Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) id <11319-0@domen.uninett.no>; Wed, 21 Aug 1996 10:48:08 +0200 Message-Id: <11316.840617285@domen.uninett.no> Date: Wed, 21 Aug 1996 10:48:05 +0200 X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Harald.T.Alvestrand@uninett.no To: Ned Freed Cc: Dave Crocker , ietf-822@list.cren.net Subject: Re: MIME implementation documentation In-Reply-To: Your message of "Tue, 20 Aug 1996 22:18:53 PDT." <01I8IJY8NFFU8Y5617@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Sender: Harald.T.Alvestrand@uninett.no X-Mailer: exmh version 1.6.7 5/3/96 X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN Thanks - I'm still missing a second generating agent, but now that you've= claimed generation for both PMDF command-line and the PMDF ALL-IN-1 gatew= ay, I believe we have one (from the same codebase). The reason for the fuss is the change from 1602 to 1602bis, which we are currently operating under: 4.1.2 Draft Standard A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. For the purposes of this section, "interoperable" means to be functionally equivalent or interchangeable components of the system or process in which they are used. If patented or otherwise controlled technology is required for implementation, the separate implementations must also have resulted from separate exercise of the licensing process. Elevation to Draft Standard is a major advance in status, indicating a strong belief that the specification is mature and will be useful. The requirement for at least two independent and interoperable implementations applies to ALL OF THE OPTIONS AND FEATURES of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level ONLY IF THOSE OPTIONS OR FEATURES ARE REMOVED. This is a new requirement compared to 1602, the rules under which MIME was raised to Draft the first time. It's a good question what the word "implementation" means here; in this case, I chose to interpret it as "available and used in commercial products" - partly because of the age of the MIME standard. (John's "If this isn't used now, will it ever be?" argument) Note that there is no such feature-by-feature requirement for going to Full Standard! Harald A   Received: from ietf.org by ietf.org id aa19661; 21 Aug 96 12:12 EDT Received: from cnri by ietf.org id aa19657; 21 Aug 96 12:12 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa12291; 21 Aug 96 12:12 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id LAA27209; Wed, 21 Aug 1996 11:55:17 -0400 Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by list.cren.net (8.6.12/8.6.12) with ESMTP id LAA27115 for ; Wed, 21 Aug 1996 11:54:52 -0400 Received: from localhost (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.7.5/8.7.3) with ESMTP id LAA18186; Wed, 21 Aug 1996 11:54:27 -0400 Message-Id: <199608211554.LAA18186@black-ice.cc.vt.edu> Date: Wed, 21 Aug 1996 11:54:26 -0400 X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Valdis.Kletnieks@vt.edu To: Ned Freed Cc: Dave Crocker , ietf-822@list.cren.net Subject: Re: MIME implementation documentation In-Reply-To: Your message of "Tue, 20 Aug 1996 22:18:53 PDT." <01I8IJY8NFFU8Y5617@INNOSOFT.COM> References: <01I8CJGV6XIU8Y507E@INNOSOFT.COM> <01I8IJY8NFFU8Y5617@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="===_-1_Wed_Aug_21_11:54:25_EDT_1996"; micalc=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit X-Mailer: exmh version 1.6.7 5/3/96 X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN --===_-1_Wed_Aug_21_11:54:25_EDT_1996 Content-Type: text/plain; charset=us-ascii On Tue, 20 Aug 1996 22:18:53 PDT, Ned Freed said: > No it isn't. As I previously stated in an earlier message, we had multiple > interoperable implementations of multipart/parallel in 1990, long before the > original MIME RFC came out. Specifically, we had Metamail and MHN. I know for a > fact that Metamail support for multipart/parallel works because I have used it > and I just confirmed with Marshall Rose that MHN did and does support this > construct. Ned: Unfortunately, I'm looking at the source for MHN right now, and unless I'm more caffeine-deficient than I thought, it appears that multipart/parallel is basically punted to multipart/mixed. Specifically, in function user_content(), it basically says "if it's /parallel, pretend it's /mixed" (near line 6122). Since, as I remember it, MIME-conformant agents are required to punt unknown multipart/bogon's to /mixed, I don't see how this *really* qualifies as "full" support. Do any implementations do anything for /parallel *ABOVE AND BEYOND* treating it as /mixed? -- Valdis Kletnieks Computer Systems Engineer Virginia Tech --===_-1_Wed_Aug_21_11:54:25_EDT_1996 Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBMhsxMNQBOOoptg9JAQG6AwQApxru8QfPSxBtrOiugKj4VJXC31Jwg29Q Pw72ZP86YWAmsN7fJ6of9xHDvGaYaph8Ui/mjx94HJi3Buk/jMNsoN0N7RtAKmJH iiB7S3xJGOSQjoNll0g35zTGYonW6k6HRjAEP5JBJ5cZ70/2pvjq6GPsZSSQx14N 3CIvAI8tiqY= =BLDX -----END PGP MESSAGE----- --===_-1_Wed_Aug_21_11:54:25_EDT_1996--   Received: from ietf.org by ietf.org id aa25554; 21 Aug 96 13:01 EDT Received: from cnri by ietf.org id aa25547; 21 Aug 96 13:01 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa17921; 21 Aug 96 13:01 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id MAA01213; Wed, 21 Aug 1996 12:33:00 -0400 Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by list.cren.net (8.6.12/8.6.12) with ESMTP id MAA01194 for ; Wed, 21 Aug 1996 12:32:13 -0400 Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.0-7 #8694) id <01I8J6N9MUYO8Y561H@INNOSOFT.COM>; Wed, 21 Aug 1996 09:31:56 -0700 (PDT) Message-Id: <01I8J7017O6W8Y561H@INNOSOFT.COM> Date: Wed, 21 Aug 1996 09:23:12 -0700 (PDT) X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Ned Freed To: Valdis.Kletnieks@vt.edu Cc: Ned Freed , Dave Crocker , ietf-822@list.cren.net Subject: Re: MIME implementation documentation In-Reply-To: "Your message dated Wed, 21 Aug 1996 11:54:26 -0400" <199608211554.LAA18186@black-ice.cc.vt.edu> References: <01I8CJGV6XIU8Y507E@INNOSOFT.COM> <01I8IJY8NFFU8Y5617@INNOSOFT.COM> <01I8IJY8NFFU8Y5617@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN > Unfortunately, I'm looking at the source for MHN right now, and unless I'm > more caffeine-deficient than I thought, it appears that multipart/parallel > is basically punted to multipart/mixed. Specifically, in function > user_content(), it basically says "if it's /parallel, pretend it's /mixed" > (near line 6122). > Since, as I remember it, MIME-conformant agents are required to punt > unknown multipart/bogon's to /mixed, I don't see how this *really* qualifies > as "full" support. Well, all I can tell you is that I specifically asked Marshall if his MHN implementation fully supported parallel and he said "yes". I took that to mean it handles it as something more than mixed, but perhaps Marshall doesn't see it that way. (This is justifiable; see below.) > Do any implementations do anything for /parallel *ABOVE AND BEYOND* treating > it as /mixed? Not according to the specification, they don't. Full MIME conformance is obtained by just treating parallel as mixed. This is as it should be: Unlike alternative, the semantics of parallel are so "light" that treating it as mixed is, if you'll pardon the overloading, an acceptable alternative. This is why you don't see a lot of people jumping up and saying they support it -- nothing more than this is required by the specification. If we actually go by what the specification says is required to have a conformant implementation of parallel then I would say that there are undoubtedly dozens of implementations of it. I note in passing that another way to address this matter would be to call for better support of parallel in the conformance section of the document. I am somewhat opposed to this as I believe that supporting parallel as mixed is sufficient in most cases. Nevertheless, I do not want to lose the distinction between parallel and mixed in the specification, so I am opposed to dropping the concept from the document. Ned   Received: from ietf.org by ietf.org id aa00449; 21 Aug 96 13:43 EDT Received: from cnri by ietf.org id aa00444; 21 Aug 96 13:43 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa22895; 21 Aug 96 13:43 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id NAA02842; Wed, 21 Aug 1996 13:26:17 -0400 Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by list.cren.net (8.6.12/8.6.12) with ESMTP id NAA02822 for ; Wed, 21 Aug 1996 13:26:04 -0400 Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.0-7 #8694) id <01I8J6N9MUYO8Y561H@INNOSOFT.COM>; Wed, 21 Aug 1996 10:25:02 -0700 (PDT) Message-Id: <01I8J8UVALOG8Y561H@INNOSOFT.COM> Date: Wed, 21 Aug 1996 09:39:20 -0700 (PDT) X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Ned Freed To: Harald.T.Alvestrand@uninett.no Cc: Ned Freed , Dave Crocker , ietf-822@list.cren.net Subject: Re: MIME implementation documentation In-Reply-To: "Your message dated Wed, 21 Aug 1996 10:48:05 +0200" <11316.840617285@domen.uninett.no> References: <01I8IJY8NFFU8Y5617@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN > Thanks - I'm still missing a second generating agent, but now that you've > claimed generation for both PMDF command-line and the PMDF ALL-IN-1 gateway, > I believe we have one (from the same codebase). > The reason for the fuss is the change from 1602 to 1602bis, which we are > currently operating under: I understand what text we're operating under. What I do not understand, do not see, and do not agree with is how this text is being interpreted as being a requirement that certain specific sorts of generation agents exist. As I said previously, I do not believe that many if not most features of IETF specifications can possibly meet such a "generating agent" requirement. And even if this is a valid reading of the new text, I do not like this being brought up at this point in the process for a document that is undergoing a recycle. It should have been brought up quite a while back. John gave some examples at the extremes of the spectrum for how this can be handled. His examples are intended to be ridiculous extremes, but they do illustrate the range of possibilities here. What John did not mention, however, is that the MIME specification itself provides detailed information on what MIME conformance and interoperability really mean. In the case of multipart/alternative, for example, a display agent is said to be MIME conformant if it is capable of displaying only the first part. Agents are encouraged to do better, and many of them do in fact do better, but this is not required for conformance. I have already noted that a conformant MIME display agent doesn't have to do anything with parallel other than treat it as mixed, and this is why we don't have a lot of people jumping up to say that they "support" parallel. If we think we need to have more support for parallel then we need to change the requirements, not remove the concept from the specification. The specification is totally silent on the subject of generation agents. This is because the specification intentionally imposes no existance or completeness requirements on such things. As such, I believe the very concept of requiring such things is out of order given the content of the present documents. I also don't think you quite realize what a can of worms you're opening here. If the existance of generation agents is going to be a requirement for MIME interoperability then this needs to be explicitly stated in the documents themselves, along with what agents need to be able to generate in various circumstances. I can even see some logic in this -- there was at least one agent out there that could display MIME just fine but was incapable of generating it, yet could still claim to be MIME compliant. But if such a requirement is in fact imposed I cannot see how we can advance the documents without describing it in detail in the section on conformance. And since this is an entirely new concept for MIME, which in fact we explicitly agreed to leave out of the original specification and instead put in a separate informational document (RFC1344), it will absolutely require a reset to proposed. And given that non-trivial requirements for MIME generation agents are likely to be a very dicey topic indeed it is possible that this will require the formation of a new working group to debate them. I therefore suggest the following alternative set of steps for us to take: (a) Recycle the documents as-is. All this does is fix the many things in the MIME specification that urgently need to be fixed. It doesn't change the current situation vis-a-vis generation agents or support for various complex combinations and permutations of MIME objects. (b) Write up a specification for what generation agents have to be able to do in order to be MIME compliant. I will undertake to do this if need be -- I think I understand what can be required and what cannot be. I doubt that you'll going to get much in the way of required support for constructing complex MIME objects into the requirements (you definitely will not if I have any say in the matter), but you will end up with a set of things you can test at both ends for interoperability. (c) See if (b) flies. If it does put it on the standards track, get it to draft status and move it into the MIME specification at that time. (I REALLY want to avoid a reset to proposed for the specification as a whole.) If it doesn't we need to look at why it doesn't and see whether or not we think generation agent requirements are really such a good idea. Ned   Received: from ietf.org by ietf.org id aa04050; 21 Aug 96 14:22 EDT Received: from cnri by ietf.org id aa04042; 21 Aug 96 14:22 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa26712; 21 Aug 96 14:22 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id LAA23885; Wed, 21 Aug 1996 11:40:06 -0400 Received: from muswell.demon.co.uk (muswell.demon.co.uk [158.152.10.120]) by list.cren.net (8.6.12/8.6.12) with ESMTP id GAA19569 for ; Wed, 21 Aug 1996 06:18:31 -0400 Received: (from ruth@localhost) by muswell.demon.co.uk (8.6.12/8.6.12) id JAA02281; Wed, 21 Aug 1996 09:41:10 +0100 Message-Id: <199608210841.JAA02281@muswell.demon.co.uk> Date: Wed, 21 Aug 1996 09:41:10 +0100 X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: ruth moulton To: masinter@parc.xerox.com, dcrocker@brandenburg.com Cc: masinter@parc.xerox.com, Harald.T.Alvestrand@uninett.no, ietf-822@list.cren.net, moore@cs.utk.edu, jedds-tech@gu.edu.au Subject: Re: MIME implementation documentation In-Reply-To: (message from Dave Crocker on Mon, 19 Aug 1996 18:59:36 -0700) X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN Not sure if these messages are aimed directly at JEDDS, or just making points. Maybe I didn't make it clear - we are using x- within our project only until 1) the format is agreed/fixed 2) it is agreed by GEDI and the JEDDS project then we certainly do intend to register, dropping the x- However, thanks for the encouragement to register earlier rather than later Ruth -- ================================================ Ruth Moulton ruth@muswell.demon.co.uk Consultant 65 Tetherdown, London N.10 1NH, UK Tel:+44 181 883 5823 --   Received: from ietf.org by ietf.org id aa16923; 21 Aug 96 21:27 EDT Received: from cnri by ietf.org id aa16919; 21 Aug 96 21:27 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa11368; 21 Aug 96 21:27 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id UAA12365; Wed, 21 Aug 1996 20:57:37 -0400 Received: from mail1.reston.mci.net (mail1.Reston.mci.net [166.45.25.52]) by list.cren.net (8.6.12/8.6.12) with ESMTP id UAA12348 for ; Wed, 21 Aug 1996 20:57:17 -0400 Received: from DataArch2.bos.mci.com (166.42.75.66) by MAIL1.RESTON.MCI.NET (PMDF V5.0-5 #8388) id <01I8JV0JRLAO00094J@MAIL1.RESTON.MCI.NET>; Wed, 21 Aug 1996 20:59:34 -0400 (EDT) Message-Id: <2.2.16.19960822005521.42c74260@mail1.reston.mci.net> Date: Wed, 21 Aug 1996 20:55:21 -0400 X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: John C Klensin To: Ned Freed Cc: Harald.T.Alvestrand@uninett.no, Ned Freed , Dave Crocker , ietf-822@list.cren.net Subject: Re: MIME implementation documentation MIME-version: 1.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7BIT X-Sender: klensin@mail1.reston.mci.net X-Mailer: Windows Eudora Pro Version 2.2 (16) X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN At 09:39 96.08.21 -0700, Ned Freed wrote: >What John did not mention, however, is that the MIME specification itself >provides detailed information on what MIME conformance and interoperability >really mean. In the case of multipart/alternative, for example, a display agent >is said to be MIME conformant if it is capable of displaying only the first >... Ned, Let's lay aside the generating agent question for a bit (probably not long, but I think I can say something more clearly if it doesn't intrude). Let's also lay aside the letter of the rules and try to think a bit in terms of spirit. (i) It is clear that the existing MIME documents contain a rule that says, in essence, that a receiver can be conforming if it treats "multipart/Frob", for substantially any "Frob", as "multipart/Mixed". I've heard no one debating that. (ii) One of the implications of (i) is that we don't have to include _any_ of those frob-instances in the standard itself. The conformity rule is satisfied with or without them. That brings us to what I think is the first important question: "what should the criteria be for singling out some 'frob' for inclusion in the standard"? I think you have given one answer --an answer with which I'm about half-satisfied-- i.e., that there is a useful distinction between "frob" and "mixed" (for "frob" = "parallel" in this case). (iii) But we don't write IETF standards on the basis of theoretically useful distinctions. We write them (or at least advance them) on the basis of demonstrated utility, demonstrated in running code. I'm pushing on this one because, if the distinction is useful in running/operational practice, then I would expect to see implementations that treat "parallel" (or any other "frob" proposed for standardization) as actually distinct from "mixed", i.e., that take advantage of the distinction. That desire has nothing to do with whether an implementation conforms or not. It has to do with whether or not the feature is exercised to a sufficient extent that we can determine, by examining the experiments/ implementations, that * the feature (or the distinction which it implies) is, indeed, useful * it is adequately defined, and useful in the form in which it is defined If all, or even most, of the implementations of "parallel" treat it as "mixed", then perhaps the message is that the implementors don't think "parallel", as defined, is worth the trouble. We are, I believe, obligated to at least examine that hypothesis. (iv) Given the way the conformity rules are written, an important capability of a conforming MIME implementation is that it be able to treat any unrecognized variant on multipart (e.g., "multipart/frob", as above) as if it were "/mixed". I will happily stipulate that feature of the standard to have been more than adequately demonstrated in independent, interoperable implementations. But that says a lot about "multipart/frob", and almost nothing about "multipart/parallel". (v) Finally, part of what makes this discussion important is that several people in the community (I fear that I'm among them) have expressed doubts that "/parallel" carries sufficient information that a receiver can do something that is really what the sender intended in most important cases (I'm not arguing that we should try to write a standard that specifies that the receiver must do so, only that it should be possible for it to have sufficient information available to do so if both sender and receiver want that). Without adequate information passed across the protocol, what the sender is saying to the receiver is "probably you might think about not 'displaying' these body parts serially, but now you get to guess what I think your user should experience". I'm not convinced that level of distinction is worth incorporating in a standard. Implementations and happy users could easily convince me. And I'm not coming in late on this: I think the archives will show that some (or most) of these concerns were expressed when MIME was first being defined, but that there was a rough consensus on letting the thing move forward in the hope that we would learn enough from implementation experience to either revise it and get it right, accept it as it was (i.e., better than we thought), or pull it. That type of conditional advancement has to run out sometime; it is worth noting that it ran out on the originally-standard "richtext" long ago. The refutation for those concerns is, of course, running implementations that demonstrate that "/parallel", as defined, is a useful distinction and that it, indeed, conveys sufficient semantics of the right sort. What I'm trying to avoid here is advancing the thing now and then having to deprecate it at some point in the future when someone figures out the right way to do what we both intend. If the thing isn't demonstrably solid today, I think there is a strong case to be made for holding it back and letting it advance under its own steam. --john p.s. I'm not terribly opposed to the scenario you suggest for moving ahead. My main concerns are that we not send misleading signals to implementors and that we not move a feature that doesn't have _demonstrated_ usefulness and interoperability when actually implemented into full standard. Given that, while I'd personally rather see things cleared out now, I could certainly live with not pulling it (or not) until we are ready to advance things to full standard.   Received: from ietf.org by ietf.org id aa26084; 22 Aug 96 3:08 EDT Received: from cnri by ietf.org id aa26080; 22 Aug 96 3:08 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa02982; 22 Aug 96 3:08 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id CAA23383; Thu, 22 Aug 1996 02:50:00 -0400 Received: from domen.uninett.no (domen.uninett.no [129.241.131.10]) by list.cren.net (8.6.12/8.6.12) with SMTP id CAA23364 for ; Thu, 22 Aug 1996 02:49:18 -0400 Received: from dale.uninett.no by domen.uninett.no with SMTP (PP) id <24393-0@domen.uninett.no>; Thu, 22 Aug 1996 08:48:37 +0200 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.12) with ESMTP id AAA07793; Thu, 22 Aug 1996 00:38:48 +0200 Message-Id: <7791.840667126@dale.uninett.no> Date: Thu, 22 Aug 1996 00:38:46 +0200 X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Harald.T.Alvestrand@uninett.no To: Valdis.Kletnieks@vt.edu Cc: Ned Freed , Dave Crocker , ietf-822@list.cren.net Subject: Re: MIME implementation documentation In-Reply-To: Your message of "Wed, 21 Aug 1996 11:54:26 EDT." <199608211554.LAA18186@black-ice.cc.vt.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7789.840667126.1@dale.uninett.no> X-Sender: hta@dale.uninett.no X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN Valdis, look harder. When it encounters a /parallel, it toggles the "serial" flag. That has the interesting property that if you have the structure multipart/parallel message/rfc822 multipart/mixed image/gif application/postscript the parts of the INNER stuff are presented in parallel. Not exactly what I would call expected behaviour....but the support is there. Now back to our "what does implemented mean" debate..... Harald A   Received: from ietf.org by ietf.org id aa26748; 22 Aug 96 4:40 EDT Received: from cnri by ietf.org id aa26744; 22 Aug 96 4:40 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa03991; 22 Aug 96 4:40 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id EAA24667; Thu, 22 Aug 1996 04:25:59 -0400 Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.50.61]) by list.cren.net (8.6.12/8.6.12) with ESMTP id EAA24649 for ; Thu, 22 Aug 1996 04:25:36 -0400 Received: from [129.46.54.89] (ra4000-p9.qualcomm.com [129.46.54.89]) by mage.qualcomm.com (8.7.5/1.4d/8.7.2/1.11) with ESMTP id BAA29990; Thu, 22 Aug 1996 01:24:28 -0700 (PDT) Message-Id: Date: Thu, 22 Aug 1996 01:23:49 -0700 X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: "John W. Noerenberg" To: Ned Freed , Harald.T.Alvestrand@uninett.no Cc: ietf-822@list.cren.net, Ned.Freed@innosoft.com, moore@cs.utk.edu Subject: Re: The MIME debate - my conclusions In-Reply-To: <01I8ILCUR1C48Y5617@INNOSOFT.COM> References: "Your message dated Tue, 20 Aug 1996 10:38:34 +0200" <26212.840530314@domen.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Sender: jwn2@mage.qualcomm.com X-Mailer: Eudora [Macintosh version 3.0] X-PGP-Fingerprint: EA 53 01 A6 C0 76 F9 C2 09 E8 94 80 64 5A 88 57 X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN At 11:09 PM -0700 8/20/96, Ned Freed wrote: >> I have reached the following preliminary conclusion, based on the >> evidence collected in the Web page >> http://www.apps.ietf.org/apps/last-call/mime-draft2.html: > >> - Multipart/alternative is implemented. >> - Nested Body Parts are implemented. >> - External Body Parts are implemented. >> - Multipart/parallel is NOT implemented. > >I strongly object to this last. Multipart/parallel had multiple, interopera= ble >implementations in 1990, before MIME even appeared as an RFC. Facilities >to generate parallel objects without hand editing also exist. Yes, but implementations aren't the only criteria. There must also be significant adoption of the construct by users, as well. So far in this discussion, the only comments are that there is little evidence of use, despite the implementations. If multipart/parallel hasn't found acceptance in 6 years, then I'm inclined to think it is unlikely to do so in the future. It may be wrong to say there are no implementations. But I've yet to see evidence that the user population at large has embraced it. john noerenberg jwn2@qualcomm.com -------------------------------------------------------------------- Once the land touches you, the wind never blows so cold again. You feel for the land like it was your child. When that happens to you, you can't be bought. -- W. P. Kinsella, "Shoeless Joe", 1982 --------------------------------------------------------------------   Received: from ietf.org by ietf.org id aa23900; 23 Aug 96 2:04 EDT Received: from cnri by ietf.org id aa23896; 23 Aug 96 2:04 EDT Received: from [204.153.50.13] by CNRI.Reston.VA.US id aa02251; 23 Aug 96 2:04 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id BAA01821; Fri, 23 Aug 1996 01:42:49 -0400 Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by list.cren.net (8.6.12/8.6.12) with ESMTP id BAA01760 for ; Fri, 23 Aug 1996 01:41:40 -0400 Received: from localhost (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.7.5/8.7.3) with ESMTP id BAA20968; Fri, 23 Aug 1996 01:41:36 -0400 Message-Id: <199608230541.BAA20968@black-ice.cc.vt.edu> Date: Fri, 23 Aug 1996 01:41:36 -0400 X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Valdis.Kletnieks@vt.edu To: Harald.T.Alvestrand@uninett.no Cc: ietf-822@list.cren.net Subject: Re: MIME implementation documentation In-Reply-To: Your message of "Thu, 22 Aug 1996 00:38:46 +0200." <7791.840667126@dale.uninett.no> References: <7791.840667126@dale.uninett.no> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11232.840778895.1@black-ice.cc.vt.edu> X-URL: http://black-ice.cc.vt.edu/~valdis/ X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN On Thu, 22 Aug 1996 00:38:46 +0200, Harald.T.Alvestrand@uninett.no said: > When it encounters a /parallel, it toggles the "serial" flag. > That has the interesting property that if you have the structure > > multipart/parallel > message/rfc822 > multipart/mixed > image/gif > application/postscript > > the parts of the INNER stuff are presented in parallel. Not exactly > what I would call expected behaviour....but the support is there. Ouch. That's so unexpected it hurts. ;) I *thought* I smelled something evil about what that 'serial' flag actually did, but 30 minutes of pondering the code failed to enlighten. All I can say in my defense is that it's hard to be an expectant father and also understand convoluted C code. ;) All the more basis for calling for multiparts/parallel to be moved out to a seperate document - that way, those the "support" it via downgrading to /mixed will still be technically in the right, and those that intend to implement more will be able to hash THAT around in experimental and proposed standard until we get something that actually says what semantics we intended to have... /Valdis (who will now go and sit on the sidelines for 2 weeks, while he takes paternity leave - a long-awaited daughter finally showed up last night ;)   Received: from ietf.org by ietf.org id aa21483; 24 Aug 96 20:31 EDT Received: from cnri by ietf.org id aa21479; 24 Aug 96 20:31 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa12915; 24 Aug 96 20:31 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id UAA22584; Sat, 24 Aug 1996 20:15:20 -0400 Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by list.cren.net (8.6.12/8.6.12) with ESMTP id UAA22546 for ; Sat, 24 Aug 1996 20:13:11 -0400 Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.0-7 #8694) id <01I8MA7OKSM88Y59WJ@INNOSOFT.COM>; Sat, 24 Aug 1996 17:12:10 -0700 (PDT) Message-Id: <01I8NTXOUJCM8Y59WJ@INNOSOFT.COM> Date: Sat, 24 Aug 1996 17:10:19 -0700 (PDT) X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Ned Freed To: Harald.T.Alvestrand@uninett.no Cc: ietf-822@list.cren.net Subject: Re: MIME documents - the decision In-Reply-To: "Your message dated Fri, 23 Aug 1996 16:12:04 +0200" <24299.840809524@domen.uninett.no> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN > The Apps ADs discussed the matter of implementation, features and > when to approve things in the IESG yesterday. > The conclusions reached were roughly: > - The intent of the standards process is that used features are in the > standard, and useless features are NOT in it. > Clearly, this is not a simple decision to make. > - The decision on what features should be in the standard and what not > is something the working group should come to consensus on, not > something that the ADs should decide. > - Nevertheless, publication of the current set of MIME documents at > this time is a Good Thing. > Actions resulting from this: > - The current set of MIME drafts is APPROVED, with no changes. > - Before the next advancement in level (to Full Standard), the working > group will be reconvened (probably by a formal reactivation) to review > the documents and decide upon the criteria for features being part of > the Full Standard MIME documents. > Thus spoke the IESG - hope you all can live with that! This is all fine with me, as you can imagine. I do have a question, however -- should I begin to develop a set of MIME conformance criteria for agents sending MIME messages? As I stated before, there is some value in this. > (and now to wait for the RFCs - the average wait through the RFC-editor's > queue is around 2 months now) I take this to mean that I should forward the documents to the RFC Editor now. Or should I wait for a formal IESG announcement before doing so? Ned   Received: from ietf.org by ietf.org id aa00168; 25 Aug 96 16:29 EDT Received: from cnri by ietf.org id aa00164; 25 Aug 96 16:29 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa09795; 25 Aug 96 16:29 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id QAA15702; Sun, 25 Aug 1996 16:22:37 -0400 Received: from domen.uninett.no (domen.uninett.no [129.241.131.10]) by list.cren.net (8.6.12/8.6.12) with SMTP id QAA15683 for ; Sun, 25 Aug 1996 16:22:16 -0400 Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) id <07938-0@domen.uninett.no>; Sun, 25 Aug 1996 22:22:10 +0200 Message-Id: <7935.841004527@domen.uninett.no> Date: Sun, 25 Aug 1996 22:22:07 +0200 X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Harald.T.Alvestrand@uninett.no To: Ned Freed Cc: ietf-822@list.cren.net Subject: Re: MIME documents - the decision In-Reply-To: Your message of "Sat, 24 Aug 1996 17:10:19 PDT." <01I8NTXOUJCM8Y59WJ@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: Harald.T.Alvestrand@uninett.no X-Mailer: exmh version 1.6.7 5/3/96 X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN Ned, there are two questions that I don't think we should mix, I think: 1) What should people be able to expect from an implementation that claims to "send MIME"? That would be what I think you mean by "a set of MIME conformance criteria for agents sending MIME messages". 2) What parts of the MIME standard conform to the IETF pious wish for Full Standards? (draft-ietf-poised95-std-proc-3-06.txt) A specification for which significant implementation and successful operational experience has been obtained may be elevated to the Internet Standard level. An Internet Standard (which may simply be referred to as a Standard) is characterized by a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community. If we think of that requirement on a feature-by-feature basis (or bodypart by bodypart in this case), what will be the result? I think sending the docs to the RFC-Editor isn't a tearing hurry; you might as well wait until SCoya has the official announcement out. Enjoy! Harald A   Received: from ietf.org by ietf.org id aa27951; 23 Aug 96 10:27 EDT Received: from cnri by ietf.org id aa27947; 23 Aug 96 10:27 EDT Received: from list.cren.net by CNRI.Reston.VA.US id aa07843; 23 Aug 96 10:27 EDT Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id KAA17981; Fri, 23 Aug 1996 10:12:39 -0400 Received: from domen.uninett.no (domen.uninett.no [129.241.131.10]) by list.cren.net (8.6.12/8.6.12) with SMTP id KAA17960 for ; Fri, 23 Aug 1996 10:12:15 -0400 Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) id <24302-0@domen.uninett.no>; Fri, 23 Aug 1996 16:12:07 +0200 Message-Id: <24299.840809524@domen.uninett.no> Date: Fri, 23 Aug 1996 16:12:04 +0200 X-Orig-Sender: owner-ietf-822@list.cren.net Precedence: bulk Sender:ietf-archive-request@ietf.org From: Harald.T.Alvestrand@uninett.no To: ietf-822@list.cren.net Subject: MIME documents - the decision Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: Harald.T.Alvestrand@uninett.no X-Mailer: exmh version 1.6.7 5/3/96 X-Listprocessor-Version: 8.0 -- ListProcessor(tm) by CREN The Apps ADs discussed the matter of implementation, features and when to approve things in the IESG yesterday. The conclusions reached were roughly: - The intent of the standards process is that used features are in the standard, and useless features are NOT in it. Clearly, this is not a simple decision to make. - The decision on what features should be in the standard and what not is something the working group should come to consensus on, not something that the ADs should decide. - Nevertheless, publication of the current set of MIME documents at this time is a Good Thing. Actions resulting from this: - The current set of MIME drafts is APPROVED, with no changes. - Before the next advancement in level (to Full Standard), the working group will be reconvened (probably by a formal reactivation) to review the documents and decide upon the criteria for features being part of the Full Standard MIME documents. Thus spoke the IESG - hope you all can live with that! Harald A (and now to wait for the RFCs - the average wait through the RFC-editor's queue is around 2 months now)