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)