Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12844;
3 May 93 7:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12838;
3 May 93 7:06 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa27629;
3 May 93 7:06 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA09473; Mon, 3 May 93 06:32:41 EDT
Received: from othello.admin.kth.se by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA09469; Mon, 3 May 93 06:32:39 EDT
Received: by othello.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0b)
id AA24501; Mon, 3 May 93 12:32:49 +0200
Date: Mon, 3 May 93 12:32:49 +0200
Message-Id: <9305031032.AA24501@othello.admin.kth.se>
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Olle Jarnefors
To: ietf-822@dimacs.rutgers.edu
Cc: Olle Jarnefors
In-Reply-To: <9304291941.AA12004@mercutio.admin.kth.se>
(Thu, 29 Apr 93 21:41:45 +0200, Olle Jarnefors )
Subject: Re: Non-ASCII Internet addresses?
(1) I wrote myself (Thu, 29 Apr 93 21:41:45 +0200):
> > It's important that the "displayed" form of an address be identical to
> > the way you spell it when you type it in. ...
>
> I agree with this but I don't see how it can be an argument
> against my proposal. There is no reason why mail software,
> implementing the rules for representing non-ASCII characters,
> can't be fully symmetric in the sense that all non-ASCII
> characters that can be displayed can also be input by normal
> keyboard methods. On my Swedish keyboard there is a key for the
> letter A WITH DIAERESIS. To write an address containing this
> letter (by means of my proposed encoding) I will press this key.
> From the point of view of a user of a new mail program the
> displayed address will be identical to the address he enters by
> the keyboard. In both cases he sees the non-ASCII characters.
I would like to clearify a point here: Even in a system capable
of displaying all characters of ISO 10646 for most users the UA
should restrict the characters displayed in addresses to a subset
which the user is familiar with, can recognise with no problems
and knows how to input. Most users in Sweden for example can
handle in this sense a subset containing ASCII, the Swedish
national letters and all Latin letters composed with acute, grave
or circumflex accent, or tilde or diaeresis. But say a Russian
address containing Cyrillic letters will be difficult to use for
an ordinary Swedish users and such addresses should be displayed
by the UA in its fundamental ASCII form, even if the hardware and
software has the capability to handle Cyrillic letters.
2) One thing that I'm uncertain about is if we can trust the whole
Internet email system to preserve the case of ASCII letters in
addresses. RFC 822 requires this for the local-part:
> local-part = word *("." word) ; uninterpreted
> ; case-preserved
For the right-hand side of an address, RFC 1034 seems to
at least anticipate a future extension requiring case
preservation:
> By convention, domain names can be stored with arbitrary case, but
> domain name comparisons for all present domain functions are done in a
> case-insensitive manner, assuming an ASCII character set, and a high
> order zero bit. This means that you are free to create a node with
> label "A" or a node with label "a", but not both as brothers; you could
> refer to either using "a" or "A". When you receive a domain name or
> label, you should preserve its case. The rationale for this choice is
> that we may someday need to add full binary domain names for new
> services; existing services would not be changed.
3) For my encoding scheme to work it's important not only that
all characters outside ASCII can be encoded but also that they
can be encoded in only one way. I have said earlier that all
characters on implementation level 3 of ISO 10646 should be
encodable. This is possible but presupposes rather complex
rules to achieve unique representations. A simpler way is to
only support level 2 of 10646. In that case these rules would
be sufficient:
a) For ASCII characters, use ASCII representation.
b) For sequences of at least 3 non-ASCII characters from plan 00
of 10646, use prefix representation.
c) For shorter sequences of non-ASCII characters from plan 00 of
10646, use two-octet representation.
d) For other (sequences of) 10646 characters, use four-octet
representation.
--
Olle Jarnefors, Royal Institute of Technology, Stockholm
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13115;
3 May 93 7:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13109;
3 May 93 7:37 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa28039;
3 May 93 7:37 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA09481; Mon, 3 May 93 06:32:48 EDT
Received: from othello.admin.kth.se by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA09476; Mon, 3 May 93 06:32:46 EDT
Received: by othello.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0b)
id AA24519; Mon, 3 May 93 12:32:57 +0200
Date: Mon, 3 May 93 12:32:57 +0200
Message-Id: <9305031032.AA24519@othello.admin.kth.se>
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Olle Jarnefors
To: ietf-822@dimacs.rutgers.edu
Cc: Olle Jarnefors
In-Reply-To: <736190323.749103.KLENSIN@INFOODS.UNU.EDU> (Fri, 30 Apr 1993
13:18:43 -0400 (EDT), John C Klensin )
Subject: Re: Non-ASCII Internet addresses?
John C Klensin writes (30 Apr 1993 13:18:43 -0400):
> Note that + and =, and occasionally / are often used to specify
> "subaddresses", special local handling associated with a given
> mailbox, or storage directly into file systems. As long as the
> "opacity" rule (no one but the RHS host tries to interpret anything on
> the LHS of "@") is strictly followed and hosts with extended character
> sets in mailbox names don't use these conventions, this is not a
> problem, but it is a likely source of confusion to users and
> implementations.
Of course new rules for enhanced address interpretation must
involve education of implementors and system administrators. The
same is true for all other measures that are taken to extend the
usability of the Internet protocols beyond what was originally
intended. The Internet has excellent instruments for
disseminating such information in the IETF standardization
process (mailing-lists, Internet drafts, RFCs).
The necessary changes of software and practices shouldn't be
exaggerated, though. This particular improvement of email
functionality will not imply _any_ changes in MTAs, in the mail
transport mechanism, or in the message format, it will only
affect UAs, gateways to other email systems and system
administration. (The level of functionality and user-
friendliness of Internet UA software really must be much improved
in the near future anyway, enhanced address interpretation would
be only a small and relatively simple part of this.)
The impact on users will be very small as I have tried to explain
in my previous messages.
People who almost exclusively use email within their own country
don't need to know about the two different forms (or rather
interpretations) of addresses, they can get on seeing, writing
and knowing only the enhanced form of addresses. But suppose
such a "naive" user is confronted (say on a business card ) with
on old-fashioned address of an American user containing "=" or
another character with a special meaning in enhanced address
interpretation and wants to write a letter to this person. No
real problem will arise: The sender will type in the ASCII
character sequence. If he has a good UA it will display the
address in both the enhanced form and the ASCII form (since it
was input in an unusual way). The letter will reach the American
recipient and when he looks at the message header he will see his
own address in the ASCII form he is used to.
In North America users and system administrators can completely
ignore this step to make the Internet more international and less
English-biassed. They don't even have to change any use of
encoding-special characters in their own mailbox names
> More broadly, the fact that you haven't see the use of any of these
> characters in network routing (akin to "!" and "%") doesn't mean that it
> can't happen and, indeed, that there isn't some gateway out there which,
> after being explicitly addressed, is calmly using them to feed rewrite
> rules into its transport model.
The exact rules of the encoding should be chosen not to break
address translation schemes that are published as RFCs or
otherwise widely used. (I hope that isn't impossible, but my
insights into these matters are very limited.) To adjust the
encoding to any hack used to connect for example Microsoft Mail
systems to the email Internet isn't necessary in my opinion.
> Well, MIME and the SMTP extensions are raising the conformance threshold
> -- reducing the amount of nonsenses one can commit and still expect to
> be able to get mail in and out. And we are seeing some serious
> discomfort and some shaking out. Nothing we have done yet is as
> potentially disruptive in subtle ways as changing the interpretation of
> mailbox names.
Can you or someone else describe a concrete scenario in which my
proposal would disrupt the Internet? I still see it as much less
threatening than MIME in this regard. No one using an old-
fashioned UA will be prevented from sending mail to an address
containing (encoded) non-ASCII characters. No one using a new UA
will be prevented from sending mail to an old address, evenif it
happens to include special characters in such a way that it,
according to the enhanced address interpretation, contains non-
ASCII letters.
> Beyond that, I'd prefer to see us concentrate on ways to avoid this
> problem until and unless we see a real requirement. "Users want to"
> doesn't carry a lot of weight with me here--users want DWIM behavior all
> over the place, even if that implies deducing that the same uttered
> sentence means radically things on different days, depending only on
> their subconscious state.
1) We should be able to do something about problems we see
_before_ the situation gets so bad that users begin to
complain loudly.
2) I see this as a natural continuation of the effort to remove
English-bias in Internet protocols and make them truely
international. A request from the Scandinavian countries for
a legal method to use non-ASCII characters in RFC 822 messages
was one (if not _the_) starting-point for the MIME work.
Protests from the same countries in the fall of 1991 led to
RFC 1342, making it possible to use non-ASCII characters also
in the Subject: field. (That step was not taken because of
overwhelming user pressure, but because of foresight.) The
next logical step should be to make it possible to choose also
Internet _names_ from other languages than English and
Swahili.
3) There are several reasons why users aren't complaining loudly
about this problem. One is that Internet email outside
English-speaking countries still very much is a phenomenon
among fairly sophisticated people in the academic environment
and international companies, who are more or less fluent in
English and can live with the situation. Another reason is
that people, when introduced to a new technology like email,
really aren't inclined to make a fuss about its shortcomings
in minor respects, they prefer to explore the new
possibilities first and accept various hacks in the meantime.
(Compare the pre-MIME devices used in netnews to communicate
images, text in Vietnamese etc.)
4) I'm convinced that the possibility to have an obvious
connection between one's real name and one's email address
(even make the mailbox name almost equal to one's real name)
is a valuable property of the Internet address style. Why
should it not be extended to all Internet users and no longer
reserved for only the English-speaking users?
5) I'm probably as sceptical of attempts at providing DWIM
behavior in software as you are. But my proposal has nothing
to do with that. On the contrary, it provides a perfectly
deterministic way to map the actual names of people all over
the world to Internet addresses conforming to today's rules.
More short-term, local or partial solutions ("ways to avoid
the problem until we see a real requirement") will be more
problematic in this respect.
> And Ohta-san is, of course, right-- one
> shouldn't pretend to solve this problem by solving it for part of the
> world's population and making a bigger mess for the rest.
I suppose that you're referring here to the criticism of ISO
10646 that it's unusable for representing text in Chinese,
Japanese and Korean because of the unification of CJK Han
characters. In my opinion this argument is misdirected in the
general case, but particularly for the encoding of addresses it
is completely lame. Personal names are not multilingual but
_monolingual_. In email addresses we therefore don't need a way
to distinguish between different Han characters solely because of
different language.
> If you want to maintain interoperability at no worse than today's
> levels, then unique mailbox identifiers need to remain in ASCII or
> restricted subsets of it (and should preferably be case-insensitive).
Yes, this was also a goal for my proposed encoding, which I think
it fulfils.
--
Olle Jarnefors, Royal Institute of Technology, Stockholm
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17013;
3 May 93 11:03 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17007;
3 May 93 11:03 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa05519;
3 May 93 11:03 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA11627; Mon, 3 May 93 10:34:08 EDT
Received: from att-out.att.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA11623; Mon, 3 May 93 10:34:07 EDT
Message-Id: <9305031434.AA11623@dimacs.rutgers.edu>
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "t.l.hansen"
To: ietf-822@dimacs.rutgers.edu
Date: 3 May 1993 10:19 EDT
Subject: Re: Non-ASCII Internet addresses?
References: <9305031032.AA24519@othello.admin.kth.se>
<< Beyond that, I'd prefer to see us concentrate on ways to avoid this
<< problem until and unless we see a real requirement. "Users want to"
<< doesn't carry a lot of weight with me here--users want DWIM behavior all
<< over the place, even if that implies deducing that the same uttered
<< sentence means radically things on different days, depending only on
<< their subconscious state.
< 1) We should be able to do something about problems we see _before_ the
< situation gets so bad that users begin to complain loudly.
I know of at least one commercial email vendor who already has paying
commercial (and international) customers requiring this in a future release
of their service. I'd much rather that there were a method in place before
this email vendor has to come up with its own methods. I know that this
email vendor WILL be doing this at some point; the only question is how.
How's that for a "real requirement"?
(Given a lack of direction from the ietf, this email vendor may very well go
the route of using rfc 1342 for addresses; I don't know. This same vendor
has been providing multipart and binary message support for years, and it's
now faced with back tracking to support MIME. The problem is that the market
demand is there, and the needs WILL be filled, but without standards,
creativity is a must.)
Tony Hansen
hansen@pegasus.att.com, tony@attmail.com
att!pegasus!hansen, attmail!tony
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17771;
3 May 93 11:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17765;
3 May 93 11:36 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa07063;
3 May 93 11:36 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA11925; Mon, 3 May 93 10:51:55 EDT
Received: from [192.105.32.2] by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA11919; Mon, 3 May 93 10:51:38 EDT
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: CHRIS R BARTRAM
Message-Id: <000QLJ@KIRK.UII.COM>
X-Mailer: NetMail/3000 [Version A.04 93/04/29]
Mime-Version: 1.0
Content-Type: text/plain
Date: Mon, 3 May 1993 10:50:28 -0400
X-Hpdesk-Priority: 3 (Normal Priority)
Subject: Re[2]: Non-ASCII Internet addresses?
To: ojarnef@othello.admin.kth.se, ietf-822@dimacs.rutgers.edu
In <9305031032.AA24501@othello.admin.kth.se> Olle Jarnefors writes:
>
> 2) One thing that I'm uncertain about is if we can trust the whole
> Internet email system to preserve the case of ASCII letters in
> addresses. RFC 822 requires this for the local-part:
>
> > local-part = word *("." word) ; uninterpreted
> > ; case-preserved
>
> For the right-hand side of an address, RFC 1034 seems to
> at least anticipate a future extension requiring case
> preservation:
>
> [...]
>
> --
> Olle Jarnefors, Royal Institute of Technology, Stockholm >
Just a note (IMHO)-
As one of the authors of a commercial MIME compatible e-mail package, I
too would like to see a non US-centric means of supporting e-mail addresses
and header information. However, at this point I have to question its
usefulness "in the real world" without a tried and tested global directory
service (i.e. an X.500) that would prevent mail users from having to
try to read encoded mail addresses. This said, I would have to admit that
not seeing X.500 (or similar) anywhere near global implementation, and
considering that "figuring out" of e-mail names by phonetic spelling or
such never worked that well across languages anyway, I can't see what
supporting some sort of scheme would harm. It would likely aid those used
to communicating in their own (non english) languages, and wouldn't make it
all that much more difficult for the english speakers (who probably couldn't
spell their names anyway ;-) )
Two notes on your scheme though: As we represent a package that runs on
Hewlett-Packard (HP3000) computers and necessarily provide a gateway to
HP's HPDesk e-mail system, we have to 1) support case-insensitive mail
names, and 2) use "/"s within mailbox names as HPDesk uses this notation
to specify "locations" and "sub-locations".
-Chris Bartram
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18486;
3 May 93 12:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18479;
3 May 93 12:04 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa08122;
3 May 93 12:04 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA12549; Mon, 3 May 93 11:47:34 EDT
Received: from yonge.csri.toronto.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA12545; Mon, 3 May 93 11:47:33 EDT
Received: from sq.com ([192.31.6.1]) by yonge.csri.toronto.edu with SMTP id <14412>; Mon, 3 May 1993 11:47:20 -0400
Received: by sq.com (/\==/\ Smail3.1.25.1 #25.8)
id ; Mon, 3 May 93 11:46 EDT
Received: by sqlee.sq.com (4.1/SMI-4.1)
id AA06664; Mon, 3 May 93 11:46:48 EDT
Date: Mon, 3 May 1993 11:46:48 -0400
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Liam R. E. Quin"
Message-Id: <9305031546.AA06664@sqlee.sq.com>
To: ietf-822@dimacs.rutgers.edu, hansen@pegasus.att.com
Subject: Re: Non-ASCII Internet addresses?
I wonder if an acceptable aproach would be to leave addresses as they are --
we've no real choice there anyway, as I see it -- and to have another field,
which can be encoded, and which contains the RealName of the sender?
One would have to do the same sort of thing for the Subject, too.
Lee
--
Liam Quin, Development & Contracts, SoftQuad Inc, +1 416 239 4801 lee@sq.com
OPEN LOOK UI FAQ; Metafont list; HexSweeper NeWS game; lq-text text retrieval
In periods of either peace or war, have you ever been involved in the commission
of a war crime or crime against humanity [...] ? -- Canadian immigration form
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21599;
3 May 93 14:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21593;
3 May 93 14:43 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa13549;
3 May 93 14:43 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA15135; Mon, 3 May 93 14:17:03 EDT
Received: from eco.twg.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA15130; Mon, 3 May 93 14:16:59 EDT
Received: from LOCAL.eco.twg.com by eco.twg.com (5.67/ECO.m-$Revision: 2.16 $)
id AA03849; Mon, 3 May 93 14:13:46 -0400
Message-Id: <9305031813.AA03849@eco.twg.com>
Received: from apache.twg.com by apache.twg.com id <15017-0@apache.twg.com>; Mon, 3 May 1993 11:13:50 -0700
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: David Herron
Subject: Re: Non-ASCII Internet addresses?
To: "Liam R. E. Quin"
Cc: IPM Return Requested ,
IPM Return Requested
Date: Mon, 3 May 93 11:13:47 PDT
In-Reply-To: Your message of Mon, 3 May 1993 11:46:48 -0400.<9305031546.AA06664@sqlee.sq.com>
Sensitivity: Personal
Conversion: Prohibited
Conversion-With-Loss: Prohibited
Encoding: 53 TEXT
Liam,
There is already a mechanism for encoding funny characters into a header
(it was released in the same group as the MIME RFC). This is suitable
for use in most header areas and results in a US-ASCII (7-but) string.
However it is not quite suitable for use in the *address* itself.
Especially for those people who believe the mail address should be the
same thing as the login name (there is no requirement for this, and there
are many MTA's for Unix which can support mail-name != login-name).
1342 Moore, K. Representation of Non-ASCII Text in Internet Message
Headers. 1992 June; 7 p. (Format: TXT=15846 bytes)
This encoding is =?charset?encoding?text?=
Examples
From: =?US-ASCII?Q?Keith_Moore?=
To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?=
CC: =?ISO-8859-1?Q?Andr=E9_?= Pirard
Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?=
=?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?=
From: =?ISO-8859-1?Q?Olle_J=E4rnefors?=
To: ietf-822@dimacs.rutgers.edu, ojarnef@admin.kth.se
Subject: Time for ISO 10646?
To: Dave Crocker
Cc: ietf-822@dimacs.rutgers.edu, paf@comsol.se
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=
Subject: Re: RFC-HDR care and feeding
And, yes, these are pretty unreadable in ASCII. The users UA will need
to be able to translate in/out of this (and any other) encoding in use.
While this encoding *could* be used in an address (that is:
To: =?ISO-8859-1?Q?Andr=E9_?= Pirard
is legal RFC-822) there are MTA's for which this will break. For
instance MMDF uses `=' to provide extra addressing.
Because some MTA's have known interpretations of the local part
what is being debated is the form of a different encoding system.
All of which was covered in discussion some weeks ago. But it sounded
as if you weren't aware of all this. If I am mistaken, please forgive me.
David
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22048;
3 May 93 15:05 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22040;
3 May 93 15:05 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa14755;
3 May 93 15:04 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA15481; Mon, 3 May 93 14:40:03 EDT
Received: from yonge.csri.toronto.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA15477; Mon, 3 May 93 14:39:50 EDT
Received: from sq.com ([192.31.6.1]) by yonge.csri.toronto.edu with SMTP id <14411>; Mon, 3 May 1993 14:39:31 -0400
Received: by sq.com (/\==/\ Smail3.1.25.1 #25.8)
id ; Mon, 3 May 93 14:39 EDT
Received: by sqlee.sq.com (4.1/SMI-4.1)
id AA06859; Mon, 3 May 93 14:38:57 EDT
Date: Mon, 3 May 1993 14:38:57 -0400
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Liam R. E. Quin"
Message-Id: <9305031838.AA06859@sqlee.sq.com>
To: david@twg.com
Subject: Re: Non-ASCII Internet addresses?
Cc: ietf-822@dimacs.rutgers.edu, hansen@pegasus.att.com
> From: "David Herron"
> There is already a mechanism for encoding funny characters into a header
>[..] However it is not quite suitable for use in the *address* itself.
> [...] All of which was covered in discussion some weeks ago. But it sounded
> as if you weren't aware of all this. If I am mistaken, please forgive me.
I was indeed aware of it, and I didn't express myself clearly this morning,
sorry.
What I was suggesting was that the mail address be retained unchanged - and
therefore still a 7-bit string, with no added semantics to punctuation.
This alone amounts to doing nothing at all.
In addition, I was suggesting an _extra_ header that contained an optional
encoding of one's name.
Hence, instead of
From: lee@sq.com (Liam R. E. Quin)
one might have
From: lee@sq.com
Real-Name: Liam R. E. Quin
where the Real-Name can use an ncoding such as the one you mention.
The mta is unaffected apart from needing to pass an extra header, although I
accept that that's not necessarily trivial.
In this way, a Mime user need never see the actual "low-level" address, and
could simply deal with the person's name -- perhaps looking at the hostname
as well in order to disambiguate multiple Jeff Smiths [sorry, jeff :-)]
A user of an older or non-mime UI would continue to see the 7-bit address
as before.
Lee
--
Liam Quin, Development & Contracts, SoftQuad Inc, +1 416 239 4801 lee@sq.com
OPEN LOOK UI FAQ; Metafont list; HexSweeper NeWS game; lq-text text retrieval
In periods of either peace or war, have you ever been involved in the commission
of a war crime or crime against humanity [...] ? -- Canadian immigration form
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23415;
3 May 93 15:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23407;
3 May 93 15:36 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa16649;
3 May 93 15:36 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA15644; Mon, 3 May 93 14:59:39 EDT
Received: from eco.twg.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA15640; Mon, 3 May 93 14:59:36 EDT
Received: from LOCAL.eco.twg.com by eco.twg.com (5.67/ECO.m-$Revision: 2.16 $)
id AA04719; Mon, 3 May 93 14:58:58 -0400
Message-Id: <9305031858.AA04719@eco.twg.com>
Received: from apache.twg.com by apache.twg.com id <16486-0@apache.twg.com>; Mon, 3 May 1993 11:58:38 -0700
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: David Herron
Subject: Re: Non-ASCII Internet addresses?
To: "Liam R. E. Quin"
Cc: IPM Return Requested ,
IPM Return Requested ,
IPM Return Requested
Date: Mon, 3 May 93 11:58:36 PDT
In-Reply-To: Your message of Mon, 3 May 1993 14:38:57 -0400.<9305031838.AA06859@sqlee.sq.com>
Sensitivity: Personal
Conversion: Prohibited
Conversion-With-Loss: Prohibited
Encoding: 26 TEXT
Ah, but I am 99% sure this discussion is about extending addresses
(not the full name, but the real honest to goodness address) to include
non-USASCII characters. For instance the recent message from Tony Hansen
about this unnamed e-mail carrier who has a real customer requirement
to implement that exact same behaviour.
Further .. there is this tradition that login name == mail name. There
is lots of users having this `knowledge'. As more people experiment
with non-USASCII login names, there will be more attempts to put these
things into (at least) the local-part of addresses. Perhaps also
the domain-part?
Further .. It is said that Windows NT uses Unicode `everywhere'. Presumably
this is also true for their login-names. Again, using the same convention
this implies attempts to use Unicode in mail addresses.
Your suggestion only covers the `phrase' (conventionally used to hold the
users full name) part of the address.. *not* the address (local-part
nor domain-part) itself. RFC-1342 already covers the territory you
propose to cover (as I recall, one of the proposals leading to
RFC-1342 made use of secondary headers ...).
I have presented three extremely likely cases where non-USASCII addresses
(not phrases) will be attempted/implemented in, say, 1-2 years time.
David
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24843;
3 May 93 16:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24837;
3 May 93 16:35 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa18726;
3 May 93 16:35 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA16724; Mon, 3 May 93 16:07:33 EDT
Received: from att-out.att.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA16720; Mon, 3 May 93 16:07:31 EDT
Message-Id: <9305032007.AA16720@dimacs.rutgers.edu>
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "t.l.hansen"
To: david@twg.com
Cc: ietf-822@dimacs.rutgers.edu
Date: 3 May 1993 15:48 EDT
Subject: Re: Non-ASCII Internet addresses?
References: <9305031858.AA04719@eco.twg.com>
< Ah, but I am 99% sure this discussion is about extending addresses (not
< the full name, but the real honest to goodness address) to include
< non-USASCII characters. For instance the recent message from Tony Hansen
< about this unnamed e-mail carrier who has a real customer requirement to
< implement that exact same behaviour.
Exactly. (It was unnamed for various non-disclosure agreement requirements.
You know how it is. :-( )
Tony Hansen
hansen@pegasus.att.com, tony@attmail.com
att!pegasus!hansen, attmail!tony
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25635;
3 May 93 17:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25629;
3 May 93 17:06 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa19737;
3 May 93 17:06 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA16776; Mon, 3 May 93 16:13:59 EDT
Received: from WILMA.CS.UTK.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA16770; Mon, 3 May 93 16:13:58 EDT
Received: from LOCALHOST by wilma.cs.utk.edu with SMTP (5.65/2.8c-UTK)
id AA05021; Mon, 3 May 1993 16:09:46 -0400
Message-Id: <9305032009.AA05021@wilma.cs.utk.edu>
To: ietf-822@dimacs.rutgers.edu
Subject: Re: Non-ASCII Internet addresses?
Cc: moore@cs.utk.edu
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Keith Moore
Date: Mon, 03 May 1993 16:09:45 -0400
X-Orig-Sender: moore@cs.utk.edu
This proposal will do nothing to increase the ability of people to
communicate over the Internet. In fact, it will make it more difficult for
them to do so.
I have no doubt that many users want to be able to use eight-bit names in
email addresses. However, these users may not know how much this will cost
them.
A proposal such as you describe is easy to define and not terribly difficult
to implement. The difficult part is educating the entire Internet about it,
and getting the software widely deployed.
Everyone in the Internet will suffer if such a proposal is adopted. What's
worse is that no new functionality is gained for that pain. A significant
fraction of the Internet may 'benefit' because they can use their login id
for their email address. However, the majority of the Internet will gain
nothing. And everyone will lose because there will be another piece of
"black magic" that users have to know to use email effectively.
By all means, let's work on a directory service that allows us to address
people by their real names, and let's interface it to our UAs. When that
happens there will be some pain, but we will gain something incredibly
useful in return.
Keith Moore
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27556;
3 May 93 19:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27550;
3 May 93 19:35 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa24175;
3 May 93 19:35 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA17685; Mon, 3 May 93 19:00:34 EDT
Received: from SIGURD.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA17681; Mon, 3 May 93 19:00:32 EDT
Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.3-0 #1992)
id <01GXQKIAG0Z49D4YGS@SIGURD.INNOSOFT.COM>; Mon, 3 May 1993 16:00:23 PDT
Date: Mon, 03 May 1993 15:38:23 -0700 (PDT)
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Ned Freed
Subject: RE: Non-ASCII Internet addresses?
In-Reply-To: Your message dated "Mon, 03 May 1993 16:09:45 -0400"
<9305032009.AA05021@wilma.cs.utk.edu>
To: Keith Moore
Cc: ietf-822@dimacs.rutgers.edu
Message-Id: <01GXQT44P4PI9D4YGS@SIGURD.INNOSOFT.COM>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
> This proposal will do nothing to increase the ability of people to
> communicate over the Internet. In fact, it will make it more difficult for
> them to do so.
This point has been brought home to me rather forcefully in recent weeks by the
troubles we've had in getting support for the existing header extensions as
well as the SMTP service extensions into place. Despite years of experience in
this area, I among others seem to have underestimated the difficulty by at
least an order of magnitude.
> ...
> Everyone in the Internet will suffer if such a proposal is adopted. What's
> worse is that no new functionality is gained for that pain. A significant
> fraction of the Internet may 'benefit' because they can use their login id
> for their email address. However, the majority of the Internet will gain
> nothing. And everyone will lose because there will be another piece of
> "black magic" that users have to know to use email effectively.
Making e-mail addresses more complex (even if this translates to simply making
them longer) is never a good idea unless there's a huge gain at the end of the
effort. Such a gain was in fact realized the last time the structure of email
addresses was seriously tampered with (i.e. the addition of domains).
And as the experience with domains shows, such an extension is sure to run up
against limits in something somewhere, and all we get out of it is another
exercise in finger-pointing and eventually another set of hacks to work around
the problem area. Words simply cannot express my distaste for such a result.
The beauty of the existing header extensions is fourfold: (1) Users don't have
to do anything different to send mail, (2) There's no mandatory impact on UAs
or MTAs, (3) Infrastructure is only stressed in terms of overall header
lengths, which while a problem area is known to be considerably more tolerant
that most other things (address size in particular), and (4) Even if it does
break our too-fragile infrastructure we only lose headers, which are not
strictly essential.
None of these apply to extensions to the mailbox parts of addresses.
And despite all this, getting these extensions developed and deployed is
proving to be a monumental task.
> By all means, let's work on a directory service that allows us to address
> people by their real names, and let's interface it to our UAs. When that
> happens there will be some pain, but we will gain something incredibly
> useful in return.
I agree completely with Keith on this point.
More specifically, while continuing this discussion is fine and dandy, it
should be understood that none of this should be taken as contributing in any
way to the existing MIME documents. If this group goes ahead and proposes an
extended format for mailbox specification (which it is certainly capable of
doing despite Keith's and my position) it will have to be done as a separate
document starting out as (at best) a proposed standard.
If we do decide to extend mailbox formats, let's at least wait until there's
some minimal deployment of the existing extensions we've done, and we can more
adequately assess the impact on the infrastructure of such changes.
Ned
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17357;
5 May 93 11:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17351;
5 May 93 11:37 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa13982;
5 May 93 11:37 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA07853; Wed, 5 May 93 11:21:42 EDT
Received: from necom830.cc.titech.ac.jp by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA07849; Wed, 5 May 93 11:21:37 EDT
Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 6 May 93 00:17:39 +0900
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Masataka Ohta
Return-Path:
Message-Id: <9305051517.AA11429@necom830.cc.titech.ac.jp>
Subject: Re: Re[2]: Non-ASCII Internet addresses?
To: CHRIS R BARTRAM
Date: Thu, 6 May 93 0:17:38 JST
Cc: ojarnef@othello.admin.kth.se, ietf-822@dimacs.rutgers.edu
In-Reply-To: <000QLJ@KIRK.UII.COM>; from "CHRIS R BARTRAM" at May 3, 93 10:50 am
X-Mailer: ELM [version 2.3 PL11]
> 1) support case-insensitive mail
> names,
It's impossible with some non-ASCII Latin characters. The case
correspondence is language sensitive.
Masataka Ohta
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01413;
5 May 93 20:05 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01407;
5 May 93 20:05 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa02654;
5 May 93 20:05 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA13464; Wed, 5 May 93 19:33:08 EDT
Received: from rutvm1.rutgers.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA13460; Wed, 5 May 93 19:33:07 EDT
Message-Id: <9305052333.AA13460@dimacs.rutgers.edu>
Received: from RUTVM1.RUTGERS.EDU by RUTVM1.RUTGERS.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 5626; Wed, 05 May 93 19:31:56 EDT
Received: from RICEVM1.RICE.EDU (NJE origin MAILER@RICEVM1) by
RUTVM1.RUTGERS.EDU (LMail V1.1d/1.7f) with BSMTP id 2619; Wed,
5 May 1993 19:31:55 -0400
Received: from ricevm1.rice.edu (NJE origin TROTH@RICEVM1) by RICEVM1.RICE.EDU
(LMail V1.1d/1.7f) with BSMTP id 9015; Wed, 5 May 1993 18:32:55 -0500
Mime-Version: 1.0
Content-Type: text/plain
Date: Wed, 05 May 93 18:17:02 CDT
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Rick Troth
Subject: Re: MIME for VM/CMS
To: moore@cs.utk.edu, ietf-822@dimacs.rutgers.edu
In-Reply-To: Your message of Wed, 28 Apr 1993 20:26:15 -0400
>Believe it or not, I think charset=us-ascii is the right thing to do,
>even if it seems wrong. This is no different in principle than what
>UNIX systems do...the UA hands the MTA a file in "local" format
>(end-of-line = LF) and it gets translated into SMTP format (end-of-line
>= CRLF) before it goes on the wire.
In this sense, I completely agree with you. But it requires
that at least one MTA get involved. If it's the first sendmail,
fine, that's local to the sender anyway.
My concern is that intermediate MTAs (gateways) could get into
the game. That I DON'T want. They'll break. They'll require more
maintenance. They'll eat more (perhaps not much, but some) CPU time.
They'll likely whine more often where they don't now.
>Leaving charset off entirely is an interesting compromise, though...
>you aren't mislabeling the information, but a MIME mail reader should
>interpret a missing charset parameter as US-ASCII which is the right
>thing to do.
Yes, I think so. I've CC'ed the ietf-822 list on this.
Dunno yet if this thread has been woven into the fabric. (I'm going
over the archives and there's a LOT of work been done; lotso messages)
The idea is to leave "plain text" as even plainer than ASCII
so that non-ASCII hosted MUAs won't have to "lie" about CHARSET=US-ASCII.
>A side note: the quoted-printable encoding (along with base64) is very
>carefully defined in terms of characters, not octet values, so that it can
>work with EBCDIC as well as ASCII. For instance, 'A' *always* means 41 hex,
>even if the local charset is EBCDIC.
But what if 0x41 isn't represented as =41, but as A?
Then it's not 0x41 on my system, it's 0xC1. :-( Perhaps there's
more in RFC1341 about this. I'll look.
>One result of this is that if you correctly apply the quoted-printable
>content-transfer-encoding to a text object labelled charset=EBCDIC, the
>resulting file will be full of gibberish...since nearly every value will have
>to be hex-encoded.
>
>If, however, it's labelled charset=US-ASCII, it will look right if you just
>display the file on your screen (even on an EBCDIC system) and a MIME mail
>reader will also do the right thing. In the latter case it will translate
>'A' into 41 hex, which will then be translated from ASCII to EBCDIC before
>displaying...an 'A'.
Keith, you're still not thinking about "plain text" on the
EBCDIC host. I can handle QP now, but I have to translate 0xC1 to
0x41 IF IT WASN'T QUOTED, =41. But if it was quoted, I let it be.
The result is that I go through more translations than I should.
But this is a mainframe, right? So it's got the horsepower to
spare. (NOT!) ;-)
>Keith
Otherwise, everything's fine. The spec is strong.
It's very processable. And GIFs are lotso fun.
Rick Troth , Rice University, Information Systems
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02043;
5 May 93 22:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02037;
5 May 93 22:04 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa06245;
5 May 93 22:04 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA15831; Wed, 5 May 93 21:37:06 EDT
Received: from WILMA.CS.UTK.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA15827; Wed, 5 May 93 21:37:04 EDT
Received: from LOCALHOST by wilma.cs.utk.edu with SMTP (5.65/2.8c-UTK)
id AA00589; Wed, 5 May 1993 21:32:45 -0400
Message-Id: <9305060132.AA00589@wilma.cs.utk.edu>
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Keith Moore
To: Rick Troth
Cc: moore@cs.utk.edu, ietf-822@dimacs.rutgers.edu
Subject: Re: MIME for VM/CMS
In-Reply-To: Your message of "Wed, 05 May 1993 18:17:02 CDT."
<9305052333.AA25578@CS.UTK.EDU>
Date: Wed, 05 May 1993 21:32:44 -0400
X-Orig-Sender: moore@cs.utk.edu
To: moore@cs.utk.edu, ietf-822@dimacs.rutgers.edu
Subject: Re: MIME for VM/CMS
Date: Wed, 05 May 93 18:17:02 CDT
> >Believe it or not, I think charset=us-ascii is the right thing to do,
> >even if it seems wrong. This is no different in principle than what
> >UNIX systems do...the UA hands the MTA a file in "local" format
> >(end-of-line = LF) and it gets translated into SMTP format (end-of-line
> >= CRLF) before it goes on the wire.
>
> In this sense, I completely agree with you. But it requires
> that at least one MTA get involved. If it's the first sendmail,
> fine, that's local to the sender anyway.
>
>> My concern is that intermediate MTAs (gateways) could get into
>> the game. That I DON'T want. They'll break. They'll require more
>> maintenance. They'll eat more (perhaps not much, but some) CPU time.
>> They'll likely whine more often where they don't now.
We agree completely on this. Especially that the EBCDIC gateways will
break things if they try to interpret MIME. My input into MIME was with the
assumption that the EBCDICASCII wouldn't change....since there are too
many of them to update them all at once to "do the right thing".
> >A side note: the quoted-printable encoding (along with base64) is very
> >carefully defined in terms of characters, not octet values, so that it can
> >work with EBCDIC as well as ASCII. For instance, 'A' *always* means 41
> >hex, even if the local charset is EBCDIC.
>
> But what if 0x41 isn't represented as =41, but as A?
> Then it's not 0x41 on my system, it's 0xC1. :-(
That's okay, you have to translate it to 0x41 (in the general case). It's no
worse than base64, where 'A' means 0x00.
> >One result of this is that if you correctly apply the quoted-printable
> >content-transfer-encoding to a text object labelled charset=EBCDIC, the
> >resulting file will be full of gibberish...since nearly every value will
> >have to be hex-encoded.
> >
> >If, however, it's labelled charset=US-ASCII, it will look right if you
> >just display the file on your screen (even on an EBCDIC system) and a MIME
> >mail reader will also do the right thing. In the latter case it will
> >translate 'A' into 41 hex, which will then be translated from ASCII to
> > EBCDIC before displaying...an 'A'.
>
> Keith, you're still not thinking about "plain text" on the
> EBCDIC host. I can handle QP now, but I have to translate 0xC1 to
> 0x41 IF IT WASN'T QUOTED, =41. But if it was quoted, I let it be.
> The result is that I go through more translations than I should.
For text/plain; charset=us-ascii, you can do the following:
+ for 'bare' characters, just display them.
+ for quoted (=XX) characters, decode the hex value and look up the
result in an ascii-to-ebcdic translate table, and display that.
For most other kinds of body parts you have to do the translation for every
displayed character.
For base64-encoded, text/plain; charset=us-ascii, body parts (which you must
support to be MIME compliant) you also have to do the translation for every
displayed character.
But there's nothing wrong with optimizing the text/plain, quoted-printable
case.
> But this is a mainframe, right? So it's got the horsepower to
> spare. (NOT!)
Well, MIME is designed for ASCII, so there is naturally some penalty on an
EBCDIC machine. And I understand that big mainframes want to conserve cpu
cycles. But I don't think the cost is prohibitive, especially if you
optimize the common cases.
Keith
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04433;
6 May 93 1:38 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04427;
6 May 93 1:38 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa12057;
6 May 93 1:37 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA16642; Thu, 6 May 93 01:13:52 EDT
Received: from rutvm1.rutgers.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA16638; Thu, 6 May 93 01:13:51 EDT
Message-Id: <9305060513.AA16638@dimacs.rutgers.edu>
Received: from RUTVM1.RUTGERS.EDU by RUTVM1.RUTGERS.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 6167; Thu, 06 May 93 01:12:39 EDT
Received: from RICEVM1.RICE.EDU (NJE origin MAILER@RICEVM1) by
RUTVM1.RUTGERS.EDU (LMail V1.1d/1.7f) with BSMTP id 4576; Thu,
6 May 1993 01:12:38 -0400
Received: from ricevm1.rice.edu (NJE origin TROTH@RICEVM1) by RICEVM1.RICE.EDU
(LMail V1.1d/1.7f) with BSMTP id 6052; Thu, 6 May 1993 00:13:38 -0500
Mime-Version: 1.0
Content-Type: text/plain
Date: Thu, 06 May 93 00:09:47 CDT
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Rick Troth
Subject: Re: MIME for VM/CMS
To: moore@cs.utk.edu
Cc: ietf-822@dimacs.rutgers.edu
In-Reply-To: Message of Wed, 05 May 1993 21:32:44 -0400 from
>That's okay, you have to translate it to 0x41 (in the general case).
>It's no worse than base64, where 'A' means 0x00.
But the idea of "plain text" (as a content TRANSFER ENCODING
not to be confused here with text/plain as a content TYPE) is that I
don't have to do *any* translation. That's my goal. It's fair.
But if the item is in Base 64, I'll just have to decode it.
>Keith
Rick Troth , Rice University, Information Systems
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00508;
6 May 93 3:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00502;
6 May 93 3:04 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa01051;
6 May 93 3:04 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA16774; Thu, 6 May 93 01:43:06 EDT
Received: from WILMA.CS.UTK.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA16770; Thu, 6 May 93 01:43:04 EDT
Received: by wilma.cs.utk.edu (5.65/2.8c-UTK)
id AA01002; Thu, 6 May 1993 01:38:47 -0400
Date: Thu, 6 May 1993 01:38:47 -0400
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: moore@cs.utk.edu
Message-Id: <9305060538.AA01002@wilma.cs.utk.edu>
To: TROTH@ricevm1.rice.edu
Subject: Re: MIME for VM/CMS
Cc: ietf-822@dimacs.rutgers.edu, moore@cs.utk.edu
>>That's okay, you have to translate it to 0x41 (in the general case).
>>It's no worse than base64, where 'A' means 0x00.
>
> But the idea of "plain text" (as a content TRANSFER ENCODING
>not to be confused here with text/plain as a content TYPE) is that I
>don't have to do *any* translation. That's my goal. It's fair.
>But if the item is in Base 64, I'll just have to decode it.
The 7BIT and 8BIT content-transfer-encodings are "plain text". Yes,
if you get a text/plain content-type with 7BIT or 8BIT encoding,
it's reasonable to simply display them. But if either quoted-printable
or base64 encoding is used, it's not "plain text", and you have to
decode and translate from ascii to the local character set..
Keith
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06492;
7 May 93 11:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12406;
7 May 93 11:02 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06485;
7 May 93 11:02 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06468;
7 May 93 11:02 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-822@dimacs.rutgers.edu
Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US
From: Internet-Drafts@CNRI.Reston.VA.US
Reply-to: Internet-Drafts@CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-822ext-mime-part2-01.txt
Date: Fri, 07 May 93 11:02:20 -0400
X-Orig-Sender: cclark@CNRI.Reston.VA.US
Message-ID: <9305071102.aa06468@IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Message
Extensions Working Group of the IETF.
Title : MIME (Multipurpose Internet Mail Extensions) Part
Two: Message Header Extensions for Non-ASCII Text
Author(s) : K. Moore
Filename : draft-ietf-822ext-mime-part2-01.txt
Pages : 11
This memo describes an extension to the message format defined in RFC
1341++, to allow the representation of character sets other than ASCII
in RFC 822 message headers. The extensions described were designed to
be highly compatible with existing Internet mail handling software,
and to be easily implemented in mail readers that support RFC 1341++.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-822ext-mime-part2-01.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server@nisc.sri.com. In the body type:
"SEND draft-ietf-822ext-mime-part2-01.txt".
For questions, please mail to internet-drafts@cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server@nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-822ext-mime-part2-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-822ext-mime-part2-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00869;
11 May 93 7:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id af00828;
11 May 93 7:06 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa01117;
11 May 93 5:11 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA12132; Tue, 11 May 93 04:30:09 EDT
Received: from kum.kaist.ac.kr by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA12102; Tue, 11 May 93 04:28:00 EDT
Received: from mani.kaist.ac.kr ([192.104.15.2]) by kum.kaist.ac.kr (4.1/KUM-0.1)
id AA17409; Tue, 11 May 93 17:27:30 KST
Received: from buddle.noname (buddle1.kaist.ac.kr) by mani.kaist.ac.kr (4.1/SMI-4.1)
id AA02477; Wed, 12 May 93 17:25:54 KST
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Uhhyung Choi
Message-Id: <9305120825.AA02477@mani.kaist.ac.kr>
Errors-To: Postmaster@mani.kaist.ac.kr
Subject: Internet Draft -- Korean Character Encoding for Internet Messages
To: internet-drafts@CNRI.Reston.VA.US
Date: Tue, 11 May 93 17:26:00 KST
Cc: ietf-822@dimacs.rutgers.edu
X-Mailer: ELM [version 2.3 PL11]
Please distribute this document as an Internet Draft.
Comments should be sent to ietf-822@dimacs.rutgers.edu
Thanks in advance.
Uhhyung Choi
Korea Network Information Center
----------------------------[ cut here ]---------------------------
Network Working Group Kilnam Chon
Internet Draft Hyun Je Park
Uhhyung Choi
May 11, 1993
Korean Character Encoding for Internet Messages
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
Please check the 1id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
current status of any Internet Draft.
This draft document will be submitted to the RFC editor as an
informational document. This document will expire before 2nd March
1993. Distribution of this memo is unlimited. Comments are
solicited and should be sent to ietf-822@dimacs.rutgers.edu.
Introduction
This document describes the encoding method being used to represent
the Hangul, Korean character, in both header and body part of the
internet electronic mail system. This encoding method was specified
in System Development Network (SDN) in 1991, and has since then been
used, it has widely spread from SDN to other Korean IP networks.
This document describes the name and encoding method of Hangul that
are to be used in order to match the message body format of MIME
[MIME] and the RFC1342 [RFC1342] header format.
This document describes only the encoding method for plain text.
Other text subtypes, rich text and similar forms of text, are beyond
the scope of this document.
Chon et al Expires November 11, 1993 [Page 1]
Internet Draft May 11, 1993
Description
It is assumed that the starting code of the message is ASCII. ASCII
and Hangul can be distinguished by use of the shift function. For
example, the code SO will alert us that the up coming bytes will be
either a Hangul character in 2 bytes or an ASCII space character in
a single byte. To return to ASCII the SI code is used.
Therefore, the escape sequence, shift function and character set used
in a Hangul message are as follows:
SO KSC 5601
SI ASCII
ESC $ ) C Appears in the first line of the message
The KSC 5601 [KSC5601] character set that includes Hangul, Chinese
ideographic characters, graphic and foreign characters, etc. is two
bytes long for each character.
For more information about Korean character codes please refer to the
KSC 5601-1989 document. Also, for more detailed information about the
escape sequence and the shift function you can look for the ISO 2022
[ISO2022] document.
Formal Syntax
Where this document in its formal syntax does not agree with the
description part, priority should be given to the formal syntax of
the document.
The notations used in this section of the document are according to
those used in RFC822 [RFC822] with the same meaning.
* (asterisk) has the following meaning :
l*m "anything"
The above means that "anything" has to be used at least l times and
at most m times. Default values for l and m are 0 and infinitive,
respectively.
body = *e-line *1( designator *( e-line / h-line ))
designator = ESC "$" ")" "C"
e-line = *text CRLF
h-line = *text 1*( segment *text ) CRLF
Chon et al Expires November 11, 1993 [Page 2]
Internet Draft May 11, 1993
segment = SO one-of-94 one-of-94
*( *SP 1*(one-of-94 one-of-94)) SI
; ( Octal, Decimal.)
ESC = ; ( 33, 27.)
SO = ; ( 16, 14.)
SI = ; ( 17, 15.)
SP = ; ( 40, 32.)
one-of-94 = ; (41-176, 33.-126.)
CHAR = ; ( 0-177, 0.-127.)
text =
MIME and RFC1342 Considerations
The name to be used for the Hangul encoding scheme in the contents is
"ISO-2022-KR". This name when used in MIME message form would be:
Content-Type: text/plain; charset=iso-2022-kr
Since the Hangul encoding is done with 7 bit format in nature, the
Content-Transfer-Encoding-header does not need to be used. However,
while using the Hangul encoding, current Hangul message softwares
does not support Base64 or Quoted-Printable encoding applied on
already encoded Hangul messages.
The Hangul encoded in the header part of the message is 8-bit EUC.
To use Hangul in the header part, according to the method proposed in
RFC1342, the encoded Hangul are "B" or "Q" encoded. When doing so,
the name to be used will be EUC-KR [EUC-KR].
Background Information
The Hangul encoding system is based on the ISO 2022 [ISO2022]
environment according to its 4/4 announcement. However, the Hangul
encoding does not include the announcement's escape sequence.
Chon et al Expires November 11, 1993 [Page 3]
Internet Draft May 11, 1993
The KSC 5601 used in this document is, in definition, identical to
the KSC 5601-1987, KSC 5601-1989 and KSC 5601-1992's 94x94 octet
definition. Therefore, any revision that refers to KSC-5601 after
1992 is to be considered as having the same meaning.
At present, the Hangul encoding system is based on the experience
acquired from the former widely used "N-Byte Hangul" among UNIX
users. Actually, the encoding method, "N-Byte Hangul", using SO and
SI was the encoding method used in SDN before KSC 5601 was made a
national standard.
This code is intended to be used for the information interchange of
Hangul messages; any other use of the code is not considered apt.
References
[ASCII] American National Standards Institute, "Coded character set
-- 7-bit American national standard code for information
interchange", ANSI X3.4-1968
[ISO2022] International Organization for Standardization (ISO),
"Information processing -- ISO 7-bit and 8-bit coded character sets
-- Code extension techniques", International Standard, 1986,
Ref. No. ISO 2022-1986 (E).
[KSC5601] Korea Industrial Standards Association, "Code for
Information Interchange (Hangul and Hanja)," Korean Industrial
Standard, 1987, Ref. No. KS C 5601-1989.
[EUC-KR] Korea Industrial Standards Association, "Hangul Unix
Environment," Korean Industrial Standard, 1992, Ref. No.
KS C 5861-1992.
[RFC822] David H. Crocker, "Standard for the Format of ARPA Internet
Text Messages", Internet standard, August 1982, RFC822.
[MIME] Nathaniel Borenstein and Ned Freed, "MIME (Multipurpose
Internet Mail Extensions): Mechanisms for Specifying and Describing
the Format of Internet Message Bodies", Proposed Internet standard,
June 1992, RFC1341.
[RFC1342] K. Moore, "Representation of Non-ASCII Text in Internet
Message Headers", Proposed Internet standard, June 1992, RFC1342.
Security Considerations
This document does not include security considerations.
Chon et al Expires November 11, 1993 [Page 4]
Internet Draft May 11, 1993
Acknowledgments
The authors wants to thank all the people who assisted in drafting
this document. In particular, we thank Erik von der Poel, Felix M.
Villarreal, Ienup Sung, Kyoung Namgoong, and Kyuho Kim.
Authors' Addresses
Kilnam Chon
Korea Advanced Institute of Science and Technology
Department of Computer Science
Taejon, 305-701, Republic of Korea
Tel: +82-42-869-3514
Fax: +82-42-869-3510
Email: chon@cosmos.kaist.ac.kr
Hyun Je Park
Solvit Chosun Media, Inc.
748-16 Yeoksam-Dong, Kangnam-Gu
Seoul, 135-080, Republic of Korea
Tel: +82-2-561-0361
Fax: +82-2-569-4847
Email: hjpark@dino.media.co.kr
Uhhyung Choi
Korea Advanced Institute of Science and Technology
Department of Computer Science
Taejon, 305-701, Republic of Korea
Tel: +82-42-869-3554
Fax: +82-42-869-3510
Email: uhhyung@kaist.ac.kr
Chon et al Expires November 11, 1993 [Page 5]
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00946;
11 May 93 7:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id as00828;
11 May 93 7:07 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa01612;
11 May 93 5:38 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA12221; Tue, 11 May 93 04:42:25 EDT
Received: from kum.kaist.ac.kr by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA12217; Tue, 11 May 93 04:41:47 EDT
Received: from mani.kaist.ac.kr ([192.104.15.2]) by kum.kaist.ac.kr (4.1/KUM-0.1)
id AA17952; Tue, 11 May 93 17:41:06 KST
Received: from buddle.noname (buddle1.kaist.ac.kr) by mani.kaist.ac.kr (4.1/SMI-4.1)
id AA02513; Wed, 12 May 93 17:39:41 KST
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Uhhyung Choi
Message-Id: <9305120839.AA02513@mani.kaist.ac.kr>
Errors-To: Postmaster@mani.kaist.ac.kr
Subject: Internet Draft -- Korean Character Encoding for Internet Messages
To: internet-drafts@CNRI.Reston.VA.US
Date: Tue, 11 May 93 17:39:46 KST
Cc: ietf-822@dimacs.rutgers.edu
X-Mailer: ELM [version 2.3 PL11]
There was some indentation errors in line 69-70 in the previous sent
document. This is the bug-fixed one.
Uhhyung Choi
Korea Network Information Center
----------------------------[ cut here ]---------------------------
Network Working Group Kilnam Chon
Internet Draft Hyun Je Park
Uhhyung Choi
May 11, 1993
Korean Character Encoding for Internet Messages
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
Please check the 1id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
current status of any Internet Draft.
This draft document will be submitted to the RFC editor as an
informational document. This document will expire before 2nd March
1993. Distribution of this memo is unlimited. Comments are
solicited and should be sent to ietf-822@dimacs.rutgers.edu.
Introduction
This document describes the encoding method being used to represent
the Hangul, Korean character, in both header and body part of the
internet electronic mail system. This encoding method was specified
in System Development Network (SDN) in 1991, and has since then been
used, it has widely spread from SDN to other Korean IP networks.
This document describes the name and encoding method of Hangul that
are to be used in order to match the message body format of MIME
[MIME] and the RFC1342 [RFC1342] header format.
This document describes only the encoding method for plain text.
Other text subtypes, rich text and similar forms of text, are beyond
the scope of this document.
Chon et al Expires November 11, 1993 [Page 1]
Internet Draft May 11, 1993
Description
It is assumed that the starting code of the message is ASCII. ASCII
and Hangul can be distinguished by use of the shift function. For
example, the code SO will alert us that the up coming bytes will be
either a Hangul character in 2 bytes or an ASCII space character in
a single byte. To return to ASCII the SI code is used.
Therefore, the escape sequence, shift function and character set used
in a Hangul message are as follows:
SO KSC 5601
SI ASCII
ESC $ ) C Appears in the first line of the message
The KSC 5601 [KSC5601] character set that includes Hangul, Chinese
ideographic characters, graphic and foreign characters, etc. is two
bytes long for each character.
For more information about Korean character codes please refer to the
KSC 5601-1989 document. Also, for more detailed information about the
escape sequence and the shift function you can look for the ISO 2022
[ISO2022] document.
Formal Syntax
Where this document in its formal syntax does not agree with the
description part, priority should be given to the formal syntax of
the document.
The notations used in this section of the document are according to
those used in RFC822 [RFC822] with the same meaning.
* (asterisk) has the following meaning :
l*m "anything"
The above means that "anything" has to be used at least l times and
at most m times. Default values for l and m are 0 and infinitive,
respectively.
body = *e-line *1( designator *( e-line / h-line ))
designator = ESC "$" ")" "C"
e-line = *text CRLF
h-line = *text 1*( segment *text ) CRLF
Chon et al Expires November 11, 1993 [Page 2]
Internet Draft May 11, 1993
segment = SO one-of-94 one-of-94
*( *SP 1*(one-of-94 one-of-94)) SI
; ( Octal, Decimal.)
ESC = ; ( 33, 27.)
SO = ; ( 16, 14.)
SI = ; ( 17, 15.)
SP = ; ( 40, 32.)
one-of-94 = ; (41-176, 33.-126.)
CHAR = ; ( 0-177, 0.-127.)
text =
MIME and RFC1342 Considerations
The name to be used for the Hangul encoding scheme in the contents is
"ISO-2022-KR". This name when used in MIME message form would be:
Content-Type: text/plain; charset=iso-2022-kr
Since the Hangul encoding is done with 7 bit format in nature, the
Content-Transfer-Encoding-header does not need to be used. However,
while using the Hangul encoding, current Hangul message softwares
does not support Base64 or Quoted-Printable encoding applied on
already encoded Hangul messages.
The Hangul encoded in the header part of the message is 8-bit EUC.
To use Hangul in the header part, according to the method proposed in
RFC1342, the encoded Hangul are "B" or "Q" encoded. When doing so,
the name to be used will be EUC-KR [EUC-KR].
Background Information
The Hangul encoding system is based on the ISO 2022 [ISO2022]
environment according to its 4/4 announcement. However, the Hangul
encoding does not include the announcement's escape sequence.
Chon et al Expires November 11, 1993 [Page 3]
Internet Draft May 11, 1993
The KSC 5601 used in this document is, in definition, identical to
the KSC 5601-1987, KSC 5601-1989 and KSC 5601-1992's 94x94 octet
definition. Therefore, any revision that refers to KSC-5601 after
1992 is to be considered as having the same meaning.
At present, the Hangul encoding system is based on the experience
acquired from the former widely used "N-Byte Hangul" among UNIX
users. Actually, the encoding method, "N-Byte Hangul", using SO and
SI was the encoding method used in SDN before KSC 5601 was made a
national standard.
This code is intended to be used for the information interchange of
Hangul messages; any other use of the code is not considered apt.
References
[ASCII] American National Standards Institute, "Coded character set
-- 7-bit American national standard code for information
interchange", ANSI X3.4-1968
[ISO2022] International Organization for Standardization (ISO),
"Information processing -- ISO 7-bit and 8-bit coded character sets
-- Code extension techniques", International Standard, 1986,
Ref. No. ISO 2022-1986 (E).
[KSC5601] Korea Industrial Standards Association, "Code for
Information Interchange (Hangul and Hanja)," Korean Industrial
Standard, 1987, Ref. No. KS C 5601-1989.
[EUC-KR] Korea Industrial Standards Association, "Hangul Unix
Environment," Korean Industrial Standard, 1992, Ref. No.
KS C 5861-1992.
[RFC822] David H. Crocker, "Standard for the Format of ARPA Internet
Text Messages", Internet standard, August 1982, RFC822.
[MIME] Nathaniel Borenstein and Ned Freed, "MIME (Multipurpose
Internet Mail Extensions): Mechanisms for Specifying and Describing
the Format of Internet Message Bodies", Proposed Internet standard,
June 1992, RFC1341.
[RFC1342] K. Moore, "Representation of Non-ASCII Text in Internet
Message Headers", Proposed Internet standard, June 1992, RFC1342.
Security Considerations
This document does not include security considerations.
Chon et al Expires November 11, 1993 [Page 4]
Internet Draft May 11, 1993
Acknowledgments
The authors wants to thank all the people who assisted in drafting
this document. In particular, we thank Erik von der Poel, Felix M.
Villarreal, Ienup Sung, Kyoung Namgoong, and Kyuho Kim.
Authors' Addresses
Kilnam Chon
Korea Advanced Institute of Science and Technology
Department of Computer Science
Taejon, 305-701, Republic of Korea
Tel: +82-42-869-3514
Fax: +82-42-869-3510
Email: chon@cosmos.kaist.ac.kr
Hyun Je Park
Solvit Chosun Media, Inc.
748-16 Yeoksam-Dong, Kangnam-Gu
Seoul, 135-080, Republic of Korea
Tel: +82-2-561-0361
Fax: +82-2-569-4847
Email: hjpark@dino.media.co.kr
Uhhyung Choi
Korea Advanced Institute of Science and Technology
Department of Computer Science
Taejon, 305-701, Republic of Korea
Tel: +82-42-869-3554
Fax: +82-42-869-3510
Email: uhhyung@kaist.ac.kr
Chon et al Expires November 11, 1993 [Page 5]
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03792;
11 May 93 9:33 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07601;
11 May 93 9:33 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03779;
11 May 93 9:33 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03760;
11 May 93 9:33 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-822@dimacs.rutgers.edu
Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US
From: Internet-Drafts@CNRI.Reston.VA.US
Reply-to: Internet-Drafts@CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-822ext-mime2-03.txt, .ps
Date: Tue, 11 May 93 09:33:27 -0400
X-Orig-Sender: cclark@CNRI.Reston.VA.US
Message-ID: <9305110933.aa03760@IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Message
Extensions Working Group of the IETF.
Title : MIME (Multipurpose Internet Mail Extensions) Part
One: Mechanisms for Specifying and Describing the
Format of Internet Message Bodies
Author(s) : N. Borenstein, N. Freed
Filename : draft-ietf-822ext-mime2-03.txt, .ps
Pages : 93
RFC 822 defines a message representation protocol which specifies
considerable detail about message headers, but which leaves the
message content, or message body, as flat ASCII text. This document
redefines the format of message bodies to allow multi-part textual and
non-textual message bodies to be represented and exchanged without
loss of information. This is based on earlier work documented in RFC
934 and RFC 1049, but extends and revises that work. Because RFC 822
said so little about message bodies, this document is largely
orthogonal to (rather than a revision of) RFC 822.
In particular, this document is designed to provide facilities to
include multiple objects in a single message, to represent body text
in character sets other than US-ASCII, to represent formatted multi-font
text messages, to represent non-textual material such as images and audio
fragments, and generally to facilitate later extensions defining new types
of Internet mail for use by cooperating mail agents.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-822ext-mime2-03.txt".
Or
"get draft-ietf-822ext-mime2-03.ps".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server@nisc.sri.com. In the body type:
"SEND draft-ietf-822ext-mime2-03.txt".
Or
"SEND draft-ietf-822ext-mime2-03.ps".
For questions, please mail to internet-drafts@cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server@nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-822ext-mime2-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-822ext-mime2-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07165;
11 May 93 12:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07159;
11 May 93 12:37 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa14511;
11 May 93 12:37 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA15436; Tue, 11 May 93 12:26:04 EDT
Received: from ietf.cnri.reston.va.us by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA15432; Tue, 11 May 93 12:26:03 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06425;
11 May 93 11:48 EDT
To: IESG Secretary
Cc: Brewster Kahle , Erik Huizer
Cc: ietf-822@dimacs.rutgers.edu
Subject: Submission of MIME to Full Standard
Date: Tue, 11 May 93 11:48:50 -0400
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Greg Vaudreuil
Message-Id: <9305111148.aa06425@IETF.CNRI.Reston.VA.US>
The RFC 822 Extensions Working Group would like to submit the three
protocols to the IESG for consideration:
MIME to Draft Standard as documented in
MIME (Multipurpose Internet Mail Extensions) Part One:
Mechanisms for Specifying and Describing the Format of Internet
Message Bodies
MIME (Multipurpose Internet Mail Extensions) Part Two: Message
Header Extensions for Non-ASCII Text
Content-MD5 to Proposed Standard as documented in
The Content-MD5 Header
And the Japanese iso-2022jp character set as Informational to be
registered in the IANA database.
Japanese Character Encoding for Internet Messages
Greg Vaudreuil
RFC 822 Extensions Working Group Chairman
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07798;
11 May 93 13:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07791;
11 May 93 13:36 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa16170;
11 May 93 13:36 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA16076; Tue, 11 May 93 13:00:40 EDT
Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA16059; Tue, 11 May 93 13:00:39 EDT
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA08888; Tue, 11 May 93 10:00:27 -0700
Message-Id: <9305111700.AA08888@Mordor.Stanford.EDU>
To: Greg Vaudreuil
Cc: IESG Secretary ,
Brewster Kahle , Erik Huizer ,
ietf-822@dimacs.rutgers.edu
Subject: Re: Submission of MIME to Full Standard
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Tue, 11 May 93 11:48:50 -0400. <9305111148.aa06425@IETF.CNRI.Reston.VA.US>
Date: Tue, 11 May 93 10:00:26 -0700
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Dave Crocker
X-Mts: smtp
Greg,
I suspect the Subject line represents where you (and many of us) WISH
Mime were.
As to the content of the message, I assume we are to vote?
I vote YES on each of the assignments.
Dave
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09382;
11 May 93 14:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09376;
11 May 93 14:37 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa18292;
11 May 93 14:36 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA18104; Tue, 11 May 93 14:12:12 EDT
Received: from ietf.cnri.reston.va.us by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA18100; Tue, 11 May 93 14:12:11 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08118;
11 May 93 13:52 EDT
To: Dave Crocker
Cc: Greg Vaudreuil ,
IESG Secretary ,
Brewster Kahle , Erik Huizer ,
ietf-822@dimacs.rutgers.edu
Subject: Re: Submission of MIME to Full Standard
In-Reply-To: Your message of "Tue, 11 May 93 10:00:26 PDT."
<9305111700.AA08888@Mordor.Stanford.EDU>
Date: Tue, 11 May 93 13:52:26 -0400
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Greg Vaudreuil
Message-Id: <9305111352.aa08118@IETF.CNRI.Reston.VA.US>
My appologies. My fingers were living a fantasy as I typed the
subject line of the message. MIME is being submitted for
Draft Standard Status.
Greg V.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22049;
11 May 93 20:09 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22043;
11 May 93 20:09 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa01046;
11 May 93 20:09 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA20079; Tue, 11 May 93 19:58:33 EDT
Received: from rutvm1.rutgers.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA20075; Tue, 11 May 93 19:58:32 EDT
Message-Id: <9305112358.AA20075@dimacs.rutgers.edu>
Received: from RUTVM1.RUTGERS.EDU by RUTVM1.RUTGERS.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 8680; Tue, 11 May 93 19:57:18 EDT
Received: from RICEVM1.RICE.EDU (NJE origin MAILER@RICEVM1) by
RUTVM1.RUTGERS.EDU (LMail V1.1d/1.7f) with BSMTP id 7843; Tue,
11 May 1993 19:57:17 -0400
Received: from ricevm1.rice.edu (NJE origin TROTH@RICEVM1) by RICEVM1.RICE.EDU
(LMail V1.1d/1.7f) with BSMTP id 3704; Tue, 11 May 1993 18:58:13 -0500
Mime-Version: 1.0
Content-Type: text/plain
Date: Tue, 11 May 93 18:57:05 CDT
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Rick Troth
Subject: CHARSET considerations [was: Re: mail housecleaning - help!]
To: Dan Schlitt , ietf-822@dimacs.rutgers.edu
In-Reply-To: Your message of Tue, 11 May 1993 09:58:12 -0400 (EDT)
>It would be nice if mail to the Pine list were in a form that it could
>be read by Pine. Latin-1??????
Okay ... how's this? There's NO CHARSET= parameter in this case.
Is it any better?
This starts a different thread. One that belongs in the
MIME spec discussion list more than in the Pine discussion list.
I maintain that US-ASCII (and ISO-8859-1 and most others) are not
the best choice for character set description. Latin-1 is valid on
systems where ISO-8859-1 is not. ISO-8859-1 means Latin-1 characters,
but also means a specific bit pattern representation of those characters.
Dan, I'm surprised that you report trouble reading "CHARSET=
Latin-1" mail with Pine. I read such mail with 3.05 all the time.
Which version of Pine are you running?
>/dan
>
>Dan Schlitt School of Engineering Computer Systems
>dan@ee-mail.engr.ccny.cuny.edu City College of New York
>(212)650-6760 New York, NY 10031
Rick Troth , Rice University, Information Systems
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22184;
11 May 93 20:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22178;
11 May 93 20:39 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa01779;
11 May 93 20:39 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA20102; Tue, 11 May 93 20:04:51 EDT
Received: from rutvm1.rutgers.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA20098; Tue, 11 May 93 20:04:50 EDT
Message-Id: <9305120004.AA20098@dimacs.rutgers.edu>
Received: from RUTVM1.RUTGERS.EDU by RUTVM1.RUTGERS.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 8699; Tue, 11 May 93 20:03:39 EDT
Received: from RICEVM1.RICE.EDU (NJE origin MAILER@RICEVM1) by
RUTVM1.RUTGERS.EDU (LMail V1.1d/1.7f) with BSMTP id 7964; Tue,
11 May 1993 20:03:39 -0400
Received: from ricevm1.rice.edu (NJE origin TROTH@RICEVM1) by RICEVM1.RICE.EDU
(LMail V1.1d/1.7f) with BSMTP id 4053; Tue, 11 May 1993 19:04:41 -0500
Mime-Version: 1.0
Content-Type: text/plain
Date: Tue, 11 May 93 18:59:30 CDT
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Rick Troth
Subject: Re: MIME for VM/CMS
To: moore@cs.utk.edu
Cc: ietf-822@dimacs.rutgers.edu
In-Reply-To: Message of 05 May 1993 21:32:44 from
What I think I'm looking for is a case for omitting the CHARSET
parameter for text/plain unless you encode it as Base 64. With B64,
the "channel" is binary so coding a CHARSET= parm (and here I mean
like US-ASCII or ISO-8859-1 rather than Latin-1 or some such) is safe.
Without any particular encoding, the "channel" is "plain text" and
I can only hope that the gateway got it right. Q-P further aggravates
any error introduced by a gateway.
I think there exists, but am having trouble developing or
proving, a case for trusting and using "plain text" apart from
specific character set (encoding) tagging. And it's not just for
EBCDIC hosts, but for those yet-to-be-created machines with a
smallest addressability of a 32-bit word. (ie: the 32-bit byte)
If you want to tag something as text/plain and ISO-8859-1,
fine. But ensure that the channel is truly binary. Then again,
don't do B64 unless you have to for the sake of those who aren't yet
running a MIME compliant MUA.
And this is assuming that "network plaintext" (what passes
over an SMTP connection) is already ISO-8859-1. (except that it isn't,
it's really 7-bit; but you get the idea)
Rick Troth , Rice University, Information Systems
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22525;
11 May 93 21:38 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22519;
11 May 93 21:38 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa03122;
11 May 93 21:38 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA22025; Tue, 11 May 93 21:06:21 EDT
Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA22021; Tue, 11 May 93 21:06:19 EDT
Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-11 #042B2) id
<01GY0SGODSS000064V@INFOODS.UNU.EDU>; Tue, 11 May 1993 21:05:35 EDT
Date: Tue, 11 May 1993 21:05:35 -0400 (EDT)
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: John C Klensin
Subject: Re: CHARSET considerations [was: Re: mail housecleaning - help!]
In-Reply-To: <9305112358.AA20075@dimacs.rutgers.edu>
To: TROTH@ricevm1.rice.edu
Cc: dan@ees1a0.engr.ccny.cuny.edu, ietf-822@dimacs.rutgers.edu
Message-Id: <737168735.506103.KLENSIN@INFOODS.UNU.EDU>
X-Envelope-To: ietf-822@DIMACS.RUTGERS.EDU
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Mail-System-Version:
>One that belongs in the
>MIME spec discussion list more than in the Pine discussion list.
>I maintain that US-ASCII (and ISO-8859-1 and most others) are not
>the best choice for character set description.
If you folks are going to take this onto the 822 (MIME) list, could you
please explain what you are talking about? If "I maintain...not the
best choice" means that you have another preference, please explain what
you think is broken and how you propose to fix it. However, please
review the archives before you do so, as most of the known horses in
this area have been kicked to death, and extensively post-death, many
times already.
If the issue is how character sets are defined or what they are, please
take the conversation elsewhere, possibly to ietf-charsets@innosoft.com
(subscriptions to ietf-charsets-request@innosoft.com): character sets
have been explicitly removed from the scope of this WG and its mailing
list.
> Dan, I'm surprised that you report trouble reading "CHARSET=
>Latin-1" mail with Pine.
Any version of anything that proports to be MIME and contains
text/plain; charset=latin-1
is badly broken; "latin-1" is not a registered, or registerable, entity.
--john
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23900;
11 May 93 22:38 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23894;
11 May 93 22:38 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa04281;
11 May 93 22:38 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA22555; Tue, 11 May 93 22:03:28 EDT
Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA22550; Tue, 11 May 93 22:03:27 EDT
Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-11 #042B2) id
<01GY0SGODSS000064V@INFOODS.UNU.EDU>; Tue, 11 May 1993 22:02:54 EDT
Date: Tue, 11 May 1993 22:02:54 -0400 (EDT)
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: John C Klensin
Subject: Re: MIME for VM/CMS
In-Reply-To: <9305120004.AA20098@dimacs.rutgers.edu>
To: TROTH@ricevm1.rice.edu
Cc: moore@cs.utk.edu, ietf-822@dimacs.rutgers.edu
Message-Id: <737172174.414103.KLENSIN@INFOODS.UNU.EDU>
X-Envelope-To: ietf-822@DIMACS.RUTGERS.EDU
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Mail-System-Version:
Rick,
We've been over and over this. I don't like the solution, but
there appears to be only one solution, even if it is ugly. All the
other solutions either cause something else to break -- perhaps
spectacularly -- or require changes on the EBCDIC side of things
(especially the BITNET/EBCDIC side) that, much as I wish otherwise,
don't seem likely to happen. I'm willing to review those alternatives
with you privately if necessary, but rather suspect that the 822 list is
sick to death of this issue. More important it is sufficiently late in
the game that discussion of aesthetic preferences is not going to
produce changes in MIME: you would have to demonstrate real operational
problems that cannot be overcome in the existing spec.
Given how things have gone, I would suggest the following:
(1) Get used to treating "text/plain" (no charset parameter) and
"text/plain;charset=us-ascii" as equivalent. That is what the spec
says and, for many reasons, it isn't going to change.
(2) Get used to reading the string "us-ascii" in the above as "EBCDIC"
when it appears on a machine that uses EBCDIC internally. If you don't
believe that, you are going to need to convert the string at the
gateway. Several of us are convinced that will cause worse problems, at
least unless the point of conversion is moved backward from the
transport gateway to the point of entrance to the EBCDIC host.
(3) Your 32-bit machine argument, and the "binary channel" (presumably
8bit transport) story illustrate some real issues, but not issues
associated with the charset parameter and "issues", not "problems". The
32-bit machine is going to need to suck octets off the wire and do
something with them. Having grown up with machines whose "smallest
addressability" was 36 bits, it can be coped with, it is just a matter
of doing it. And ISO-8859-1 doesn't need 8bit transport; it needs
*either* 8bit transport or a sensible content-transfer-encoding.
(4) "network plaintext" is [US-]ASCII. It is not 8859-1. It is always
going to be [US-]ASCII, in it old, traditional, 7-bit form. No 8bit
ASCII, no SuperDuperCode, [US-]ASCII. There might come a day when no
one really *uses* "network plaintext", but that won't change the binding
between that concept and ASCII. Again, all of the other solutions are
worse.
OK, let's ask a different question. Suppose we were asked to build a
gateway from the IP-Internet to a network containing a bunch of EBCDIC
machines and an EBCDIC transport and that we wanted to get it right.
Let's pretend this is a new piece of work and that we don't need to
worry about transition issues. What do we do?
First thing we do is to get real serious, network-wide agreement about
what character set(s) we are going to support in the target network and
what we want to treat as "our" "network plaintext". We write reversible
mapping rules between MIME-registered characters sets of significant
interest into that/those character set(s) and get agreement about them.
Then we decide what we are going to do with any characters that happen
to be left over from the mappings and standardize that ritual. If we
end up with more than one EBCDIC, we figure out how to tell sites
without our network about which one is used in a particular message, but
we use a mechanism that treats Content-type as inviolate. Maybe a
EBDCIC-page header.
I would expect the above agreements might be very hard to get in a
network context that hasn't been able to agree on how to map 7bit ASCII,
but that isn't a MIME problem.
Now you design the gateways themselves. You implement the SMTP
extensions --"8BITMIME" in particular-- to reduce as much as possible
the frequency with with you see Q-P or Base64 arriving with text data.
When a message comes in with text/plain, the gateway looks at the
character set. It it is one it knows how to map, it maps it (it might
have to expand incoming Q-P or Base64 to do that), removes the
Content-transfer-encoding field, and adds EBCDIC-page if necessary. If
it doesn't know how to map it, it forces it into Base64 (converting from
Q-P if necessary) and then converts to "generic" EBCDIC, changes the
Content-transfer-encoding as needed, and does not add EBCDIC-page.
That is it. If Content-transfer-encoding is present with a text type,
manifest character codings are in EBCDIC but the interpretation is with
regard to the MIME character set and transfer encodings. If it is not
present, the characters are in EBCDIC and mean exactly what they appear
to mean. The gateways eliminate Q-P, which is presumed hard to read in
an EBCDIC world (and should be totally unnecessary). Character sets
that you don't know how to translate into EBCDIC are forced into Base64;
maybe the target UA will know how to handle them.
The thing that has caused the confusion about all of this is the
obvious, but insidious, assumption that, in an EBCDIC environment,
"charset" should denote a code page. That isn't going to work as
things are now defined; it is not clear that it was ever possible to
make a variation on it work in a multiple-gateway environment. It
denotes an abstraction that is actually bound to character codes in an
ANSI/ISO-derived character transport environment. In an EBCDIC
transport environment, there is an extra degree of abstraction, since it
binds character-abstractions to a mapping table and then to codes,
rather than directly. But that shouldn't be a bit deal, as long as that
other network can agree on the mapping tables.
john
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10843;
12 May 93 10:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10833;
12 May 93 10:32 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12381;
12 May 93 10:32 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10794;
12 May 93 10:31 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10646;
12 May 93 10:28 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-822@dimacs.rutgers.edu
X-Orig-Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Internet-Drafts@CNRI.Reston.VA.US
Reply-to: Internet-Drafts@CNRI.Reston.VA.US
Subject: ID ACTION:draft-chon-korean-encoding-00.txt
Date: Wed, 12 May 93 10:28:15 -0400
X-Orig-Sender: cclark@CNRI.Reston.VA.US
Message-ID: <9305121028.aa10646@IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet Draft is available from the on-line Internet-Drafts
directories.
Title : Korean Character Encoding for Internet Messages
Author(s) : K. Chon, H. Je Park, U. Choi
Filename : draft-chon-korean-encoding-00.txt
Pages : 5
This document describes the encoding method being used to represent
the Hangul, Korean character, in both header and body part of the
internet electronic mail system. This encoding method was specified in
System Development Network (SDN) in 1991, and has since then been
used, it has widely spread from SDN to other Korean IP networks.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-chon-korean-encoding-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server@nisc.sri.com. In the body type:
"SEND draft-chon-korean-encoding-00.txt".
For questions, please mail to internet-drafts@cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server@nisc.sri.com"
Content-Type: text/plain
SEND draft-chon-korean-encoding-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-chon-korean-encoding-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16266;
12 May 93 12:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16260;
12 May 93 12:48 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa17702;
12 May 93 12:48 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA28262; Wed, 12 May 93 12:30:21 EDT
Received: from convex.csc.fi by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA28257; Wed, 12 May 93 12:30:17 EDT
Received: from tellus.csc.fi.csc.fi (tellus.csc.fi) by csc.fi with SMTP id AA10227
(5.65c8+/IDA-1.4.4 for ); Wed, 12 May 1993 19:30:32 +0300
Received: from localhost.csc.fi by tellus.csc.fi.csc.fi (4.1/SMI-4.1)
id AA17658; Wed, 12 May 93 19:30:14 +0300
Message-Id: <9305121630.AA17658@tellus.csc.fi.csc.fi>
Reply-To: netmgr@tellus.csc.fi
To: ietf-822@dimacs.rutgers.edu
Subject: message/external-body & URL
Date: Wed, 12 May 1993 19:30:11 +0300
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Pekka Kytolaakso
I've just been reading the latest Uniform Resource Locators draft
(or whatever URL today means) by Tim Berners-Lee
(internet-drafts/draft-ietf-uri-url-00.{ps,txt}) which describes a
general way of describing objects that are reachable thru WWW,
gopher, wais, anon-ftp, afs ,.... I think this might be a
way to handle some of the different external-body formats.
Are the any plans to add a new access-type for URL's?
As an example we could use something like:
Content-type: message/external-body; access-type=URL;
url="ftp://nic.nordu.net/internet-drafts/draft-ietf-uri-url-00.ps";
Content-type: application/postscript
Content-transfer-encoding: 8bit
Pekka Kyt|laakso
---------------------------------------------------------------
netmgr@tellus.csc.fi Centre for Scientific Computing
Pekka.Kytolaakso@csc.fi PL 40 SF-02101 Espoo FINLAND
Phone: +358 0 4571 Telefax: + 358 0 4572302
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21674;
12 May 93 13:40 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21668;
12 May 93 13:40 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa19395;
12 May 93 13:40 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA00418; Wed, 12 May 93 13:27:39 EDT
Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA00414; Wed, 12 May 93 13:27:37 EDT
Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-11 #042B2) id
<01GY2UW274U80007DW@INFOODS.UNU.EDU>; Wed, 12 May 1993 13:26:43 EDT
Date: Wed, 12 May 1993 13:26:43 -0400 (EDT)
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: John C Klensin
Subject: Re: message/external-body & URL
In-Reply-To: <9305121630.AA17658@tellus.csc.fi.csc.fi>
To: netmgr@tellus.csc.fi
Cc: ietf-822@dimacs.rutgers.edu
Message-Id: <737227603.457103.KLENSIN@INFOODS.UNU.EDU>
X-Envelope-To: ietf-822@DIMACS.RUTGERS.EDU
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Mail-System-Version:
Pekka,
I think that several of us are watching the URx work very closely
and that it is reasonable to expect some external-body types for them as
soon as that work stabilizes.
From my point of view, the level of thrashing around in that discussion
right now--about character sets, about the syntax for the name of a mailbox
for that type of reference, and so on--makes our doing anything in the
MIME context quite premature.
On the other hand, if/when the URx work comes to anything that can be
used operationally to retrieve documents, it would be really dumb to
not have an external reference type in MIME that can use them. I would
hope we could avoid "really dumb".
john
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23797;
12 May 93 14:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23791;
12 May 93 14:11 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa20339;
12 May 93 14:11 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA00654; Wed, 12 May 93 13:52:03 EDT
Received: from rutvm1.rutgers.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA00650; Wed, 12 May 93 13:52:02 EDT
Message-Id: <9305121752.AA00650@dimacs.rutgers.edu>
Received: from RUTVM1.RUTGERS.EDU by RUTVM1.RUTGERS.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 0512; Wed, 12 May 93 13:50:50 EDT
Received: from RICEVM1.RICE.EDU (NJE origin MAILER@RICEVM1) by
RUTVM1.RUTGERS.EDU (LMail V1.1d/1.7f) with BSMTP id 6464; Wed,
12 May 1993 13:50:49 -0400
Received: from ricevm1.rice.edu (NJE origin TROTH@RICEVM1) by RICEVM1.RICE.EDU
(LMail V1.1d/1.7f) with BSMTP id 5109; Wed, 12 May 1993 12:51:49 -0500
Mime-Version: 1.0
Content-Type: text/plain
Date: Wed, 12 May 93 12:26:57 CDT
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Rick Troth
Subject: Re: CHARSET considerations
To: John C Klensin , pine-info@cac.washington.edu
Cc: dan@ees1a0.engr.ccny.cuny.edu, ietf-822@dimacs.rutgers.edu
In-Reply-To: Message of Tue, 11 May 1993 21:05:35 -0400 (EDT) from
Hi, John,
> However, please
>review the archives before you do so, as most of the known horses in
>this area have been kicked to death, and extensively post-death, many
>times already.
I've been doing that, but it has taken no small amount of time.
Perhaps I should have tried to shorten the path and not review ALL
of the ietf-822 archives. But you are correct, and I'd appreciate it
if more folks did not make the mistake that I appear to be making.
>If the issue is how character sets are defined or what they are, please
>take the conversation elsewhere, possibly to ietf-charsets@innosoft.com
>(subscriptions to ietf-charsets-request@innosoft.com): character sets
>have been explicitly removed from the scope of this WG and its mailing
>list.
Thanks for the corrected reference.
Look ... I sincerely don't mean to be a whiner or to beat the
skeletal remains of yet-another-dead-horse, but I DON'T see closure
on it and DO see a solution / solution(s). But I am a newcomer
(for reasons which escape me).
>> Dan, I'm surprised that you report trouble reading "CHARSET=
>>Latin-1" mail with Pine.
>
>Any version of anything that proports to be MIME and contains
> text/plain; charset=latin-1
>is badly broken; "latin-1" is not a registered, or registerable, entity.
Any user of Pine 3.05 (and as far as I can tell 3.07 or 2.x)
can shoot themself in the foot (head if you prefer) by setting
character-set = Zeldas_private_codepage. Should the Pine developers
remove this feature? I think not. Leave it open-ended.
Pine tries to do MIME; that's how this thread crossed. Sorry.
Small ROT is that software should generate the cleanest possible
protocol while accepting as much as possible and silently ignoring whatever
doesn't make sense but is otherwise harmless. So, yeah, my .pinerc
was broken and I'm a jerk for ruining everyone's day, but that's balanced
against my former life on a US-ASCII_is_foreign system along with the
legitimate goal of leaving Pine (and everything) as open ended as possible.
I'll subscribe to ietf-charsets and =just listen= until I have
some handle on the reality there. Meantime, every MIME compliant MUA
is causing numerous (not all) mail gateways to deliver incorrect data.
I WOULD NOT ask any of these MUAs to stop [mis]labelling their mail,
but I would like to get the problem corrected. A short-term solution
is to leave CHARSET= off if it's not absolutely essential.
> --john
Rick Troth , Rice University, Information Systems
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11824;
13 May 93 10:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11818;
13 May 93 10:11 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa13385;
13 May 93 10:11 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA08483; Thu, 13 May 93 09:30:51 EDT
Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA08479; Thu, 13 May 93 09:30:50 EDT
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA22738; Thu, 13 May 93 06:30:37 -0700
Message-Id: <9305131330.AA22738@Mordor.Stanford.EDU>
To: netmgr@tellus.csc.fi
Cc: ietf-822@dimacs.rutgers.edu
Subject: Re: message/external-body & URL
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Wed, 12 May 93 19:30:11 +0300. <9305121630.AA17658@tellus.csc.fi.csc.fi>
Date: Thu, 13 May 93 06:30:37 -0700
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Dave Crocker
X-Mts: smtp
Hmmm.
---- Included message:
As an example we could use something like:
Content-type: message/external-body; access-type=URL;
url="ftp://nic.nordu.net/internet-drafts/draft-ietf-uri-url-00.ps";
I just realized that this is not a globally unique identifer.
It asserts that internet-drafts is the top of the tree at nic.nordu.net
and I bet that depends on the way you log into it. Most anonymous
logins anchor your to a different part of the file system tree than if
you log in normally.
d/
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22694;
13 May 93 14:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22680;
13 May 93 14:36 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa25055;
13 May 93 14:36 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA12494; Thu, 13 May 93 14:27:32 EDT
Received: from brazos.is.rice.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA12490; Thu, 13 May 93 14:27:30 EDT
Received: by brazos.is.rice.edu (AA25381); Thu, 13 May 93 13:27:09 CDT
Date: Thu, 13 May 1993 13:18:03 -0500 (CDT)
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Rick Troth
Subject: Re: printable wide character (was "multibyte") encodings
To: Steve Summit
Cc: nsb@thumper.bellcore.com, ietf-822@dimacs.rutgers.edu,
henry@zoo.toronto.edu, scs@adam.mit.edu, troth@rice.edu
In-Reply-To: <9301111450.AA01003@adam.MIT.EDU>
Message-Id:
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
[from way back in January]
> ...
> 2. Take the plunge and embrace wide characters with open
> arms: define a Content-transfer-encoding which encodes 16
> (or 32) -bit characters, and model the communication path
> between the content-transfer-encoding decoder and the
> richtext parser as a stream of 16- or 32-bit characters.
> (Whether this stream is implemented as an octet stream in
> some canonical order, or as some word-oriented IPC
> mechanism, is an implementation detail.) The point is
> that the richtext parser's front-end "get a character"
> primitive would get a wide, multioctet character. (The
> special ' 32-bit quantity with value 60).
Yes!
> Keith Moore last month bemoaned the suggestion of a
> departure from the familiar and comfortable byte stream.
> If we're going to use characters larger than 8 bits, some
> departure somewhere from an octet stream is obviously
> (and by definition) necessary. Recalling the proper
> definition of "byte", however, we can if we wish continue
> to think about byte streams, as long as we remember that
> a byte may have more than 8 bits. ...
Yes again.
> Compilers were once thought to be nearly impossible to write,
> until (among other things) we learned to separate lexical
> analysis from parsing, which turned out to make the task much
> cleaner and more tractable. In an analogous way, I'd like to
> keep transfer encoding issues clearly separated from character
> set issues, ...
I'd like to second this. (perhaps a bit late)
> ...
> Steve Summit
> scs@adam.mit.edu
--
Rick Troth , Rice University, Information Systems
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id ab11354;
13 May 93 18:41 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11347;
13 May 93 18:41 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa04790;
13 May 93 18:41 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA13568; Thu, 13 May 93 17:46:30 EDT
Received: from WILMA.CS.UTK.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA13564; Thu, 13 May 93 17:46:28 EDT
Received: from LOCALHOST by wilma.cs.utk.edu with SMTP (5.65/2.8c-UTK)
id AA19661; Thu, 13 May 1993 17:41:29 -0400
Message-Id: <9305132141.AA19661@wilma.cs.utk.edu>
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Keith Moore
To: Rick Troth
Cc: Steve Summit , nsb@thumper.bellcore.com,
ietf-822@dimacs.rutgers.edu, henry@zoo.toronto.edu, moore@cs.utk.edu
Subject: Re: printable wide character (was "multibyte") encodings
In-Reply-To: Your message of "Thu, 13 May 1993 13:18:03 CDT."
Date: Thu, 13 May 1993 17:41:28 -0400
X-Orig-Sender: moore@cs.utk.edu
To: Steve Summit
Subject: Re: printable wide character (was "multibyte") encodings
Date: Thu, 13 May 1993 13:18:03 -0500 (CDT)
> > 2. Take the plunge and embrace wide characters with open
> > arms: define a Content-transfer-encoding which encodes 16
> > (or 32) -bit characters...
[...]
> Yes!
No!
> > Keith Moore last month bemoaned the suggestion of a
> > departure from the familiar and comfortable byte stream.
> > If we're going to use characters larger than 8 bits, some
> > departure somewhere from an octet stream is obviously
> > (and by definition) necessary.
The mapping from other "character sizes" to an octet-stream can be
defined on a per-content-type basis. There's no need to define
additional content-transfer-encodings for this purpose.
Think of it this way. You want to define a new data type that needs
to express things in 32 bit quantities. You can either:
a) Define a new content-transfer-encoding that encodes not octets,
but 32-bit words. Define your content-type in terms of that encoding.
While you're at it, define how a MIME mail reader is going to talk
to the program that implements your new content-type; the mechanism
is sure to be at least different than the mechanism now in use.
If necessary, define extensions to the .mailrc and .mnh_file formats to
specify a 32-bit-wide pipe rather than an 8-bit-wide pipe. Get
those who produce MIME user agents to upgrade their products to support
the new content-transfer-encoding.
-or-
b) Define the canonical form of your new content-type in terms of an
octet-stream. Then the mapping of 32 bit words to octets is defined
by your content-type.
> > Compilers were once thought to be nearly impossible to write,
> > until (among other things) we learned to separate lexical
> > analysis from parsing, which turned out to make the task much
> > cleaner and more tractable. In an analogous way, I'd like to
> > keep transfer encoding issues clearly separated from character
> > set issues, ...
Agreed. That's why all MIME objects should have a canonical form expressed
in terms of a single, simple data structure. That way you can "plug in"
whatever encoder works without having to worry about whether it works with
your chosen byte size. (Well, you do have to worry about transparency
issues, but that's bad enough without having to deal with byte size issues
also.)
The chosen data structure for canonical form of MIME objects is an
octet-stream. It could have been something else -- like an ASN.1-defined
stream encoded in BER. But for better or worse, we didn't take that
approach.
As a result, there's less complexity to implementing MIME.
Keith Moore
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17688;
14 May 93 0:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17682;
14 May 93 0:10 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa13502;
14 May 93 0:10 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA16444; Thu, 13 May 93 23:22:09 EDT
Received: from alsvid.une.edu.au by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA16440; Thu, 13 May 93 23:22:01 EDT
Received: by alsvid.une.edu.au id AA28662
(5.65c8+/IDA-1.4.4 for dimacs.rutgers.edu!ietf-822); Fri, 14 May 1993 13:21:49 +1000
Received: by wnet.uucp (\/<>\/ SmailAmiga 1.02j21)
for dimacs.rutgers.edu!ietf-822 (via alsvid.une.edu.au)
id ; Fri, 14 May 1993 12:30:21 GMT
In-Reply-To: <9305131330.AA22738@Mordor.Stanford.EDU>
(from Dave Crocker )
(at Thu, 13 May 93 06:30:37 -0700)
X-Mailer: //\\miga Electronic Mail (AmiElm 1.19)
Organization: LocalNet Admin, Australia
Message-Id:
Date: Fri, 14 May 1993 12:30:21 GMT
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Mark Constable
Reply-To: wnet!markc@alsvid.une.edu.au
To: ietf-822@dimacs.rutgers.edu, uri@bunyip.com
Subject: Re: message/external-body & URL
-> Content-type: message/external-body; access-type=URL;
-> url="ftp://nic.nordu.net/internet-drafts/draft-ietf-uri-url-00.ps";
->
-> I just realized that this is not a globally unique identifer.
->
-> It asserts that internet-drafts is the top of the tree at nic.nordu.net
-> and I bet that depends on the way you log into it. Most anonymous
-> logins anchor your to a different part of the file system tree than if
-> you log in normally.
->
-> d/
I'm not sure why you used URL as an access type as it's not defined in the
new MIME draft. Your example would be correct if it was;
Content-type: message/external-body; access-type=anon-ftp;
url="anon-ftp://nic.nordu.net/internet-drafts/draft-ietf-uri-url-00.ps";
then the URI would be unique.
While I'm at it, a note about 'alex' as I've not seen the subject mentioned.
The above file could have been referenced and fetched thus;
[nfs mount alex etc]
cp /alex/net/nordu/nic/internet-drafts/draft-ietf-uri-url-00.ps ~
I'm finding alex-paths are 'cleaner' to work with, but without DNS lookup
is a bit foggy where the domain part ends and the file-path starts (which
URIs make perfectecly clear). How to tac on UUCP hosts, well, I've tried
both of these (as I'm uucp based);
/alex/au/edu/une/alsvid!wnet!ms/internet-drafts/draft-ietf-uri-url-00.txt
and (ms = mail-server)
file://alsvid.une.edu.au!wnet!ms/internet-drafts/draft-ietf-uri-url-00.txt
Request to a 'normal' mail-server results in a ftp fetch of the file in
question which is impossible in a non-tcp/ip world but using the above
syntax I've been able to get and put files under limited test conditions
with pure uucp hosts.
There is also a quality about some alex and uri paths that I haven't seen
addressed and that's something like a 'master' copy (is this what a URN
is meant to represent ?). In an alex world there is no need for me to
keep a copy (cache) of any file other than to retrieve it to my local
computer interface for 'viewing' and as soon as the 'master' copy is
updated then my local copy is junk anyway.
Summary, URIs make sense to me for describing where objects can be found
and what type of service is needed to display the info but for access-type
'file:' I'm finding 'alex-paths' are far more 'natural' to live with as
most of the typical unix tools apply straight off the bat without any extra
translation, ie; ls, cp, rm(?), du etc.
BTW if you haven't experienced 'alex' then anon-ftp archie.au, cd alex.
Better still (if you can) mount alex in your home dir and go for a
'walk' around the world, I'm sure you will be impressed :).
. Regards, . . . . .
: Mark Constable : mconstab@alsvid.une.edu.au : LocalNet : +61 66 802584 :PGP:
mQA9Aiuy0T0AAAEBgMcgRtxkAsFWPXIHEHAmHraWIiFT2oduui0ZlZC5Z2549EhX PIW4YaphNMxuc
FNbFwAFEbQrTWFyayBDb25zdGFibGUgPG1jb25zdGFiQGFsc3Zp ZC51bmUuZWR1LmF1Pg== =TLHi
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18021;
14 May 93 0:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18015;
14 May 93 0:26 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa13900;
14 May 93 0:26 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA16491; Thu, 13 May 93 23:36:15 EDT
Received: from rutvm1.rutgers.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA16487; Thu, 13 May 93 23:36:14 EDT
Message-Id: <9305140336.AA16487@dimacs.rutgers.edu>
Received: from RUTVM1.RUTGERS.EDU by RUTVM1.RUTGERS.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 4418; Thu, 13 May 93 23:35:03 EDT
Received: from RICEVM1.RICE.EDU (NJE origin MAILER@RICEVM1) by
RUTVM1.RUTGERS.EDU (LMail V1.1d/1.7f) with BSMTP id 4661; Thu,
13 May 1993 23:35:02 -0400
Received: from ricevm1.rice.edu (NJE origin TROTH@RICEVM1) by RICEVM1.RICE.EDU
(LMail V1.1d/1.7f) with BSMTP id 2263; Thu, 13 May 1993 22:36:02 -0500
Mime-Version: 1.0
Content-Type: text/plain
Date: Thu, 13 May 93 22:35:26 CDT
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Rick Troth
Subject: Re: printable wide character (was "multibyte") encodings
To: Rick Troth , scs@adam.mit.edu, moore@cs.utk.edu
Cc: ietf-822@dimacs.rutgers.edu
In-Reply-To: Message of Thu, 13 May 1993 13:18:03 -0500 (CDT) from
Keith, you left this part out:
>> The point is
>> that the richtext parser's front-end "get a character"
>> primitive would get a wide, multioctet character. (The
>> special '> 32-bit quantity with value 60).
This is the part to which I specifically agree, saying:
> Yes!
The reasoning is:
>> Recalling the proper
>> definition of "byte", however, we can if we wish continue
>> to think about byte streams, as long as we remember that
>> a byte may have more than 8 bits. ...
And if SMTP remains an "octet stream", fine.
(I think we're closer in agreement than you think we are)
--
Rick Troth , Rice University, Information Systems
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01068;
14 May 93 4:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01062;
14 May 93 4:37 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa02679;
14 May 93 4:37 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA17531; Fri, 14 May 93 03:30:30 EDT
Received: from necom830.cc.titech.ac.jp by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA17527; Fri, 14 May 93 03:30:21 EDT
Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 14 May 93 16:24:32 +0900
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Masataka Ohta
Return-Path:
Message-Id: <9305140724.AA07926@necom830.cc.titech.ac.jp>
Subject: Re: printable wide character (was "multibyte") encodings
To: Rick Troth
Date: Fri, 14 May 93 16:24:30 JST
Cc: troth@rice.edu, scs@adam.mit.edu, moore@cs.utk.edu,
ietf-822@dimacs.rutgers.edu
In-Reply-To: <9305140336.AA16487@dimacs.rutgers.edu>; from "Rick Troth" at May 13, 93 10:35 pm
X-Mailer: ELM [version 2.3 PL11]
> Keith, you left this part out:
>
> >> The point is
> >> that the richtext parser's front-end "get a character"
> >> primitive would get a wide, multioctet character. (The
> >> special ' >> 32-bit quantity with value 60).
>
> This is the part to which I specifically agree, saying:
What do you think you agree with?
A wide character and a multioctet character are different things.
So, the statement:
primitive would get a wide, multioctet character.
is meaningless and should be ignored.
Masataka Ohta
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05042;
14 May 93 10:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05036;
14 May 93 10:43 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa10854;
14 May 93 10:43 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA19350; Fri, 14 May 93 10:01:34 EDT
Received: from WILMA.CS.UTK.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA19346; Fri, 14 May 93 10:01:32 EDT
Received: from LOCALHOST by wilma.cs.utk.edu with SMTP (5.65/2.8c-UTK)
id AA20631; Fri, 14 May 1993 09:56:49 -0400
Message-Id: <9305141356.AA20631@wilma.cs.utk.edu>
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Keith Moore
To: Rick Troth
Cc: Rick Troth , scs@adam.mit.edu, moore@cs.utk.edu,
ietf-822@dimacs.rutgers.edu
Subject: Re: printable wide character (was "multibyte") encodings
In-Reply-To: Your message of "Thu, 13 May 1993 22:35:26 CDT."
<9305140337.AA01826@CS.UTK.EDU>
Date: Fri, 14 May 1993 09:56:48 -0400
X-Orig-Sender: moore@cs.utk.edu
To: Rick Troth , scs@adam.mit.edu, moore@cs.utk.edu
Subject: Re: printable wide character (was "multibyte") encodings
Date: Thu, 13 May 93 22:35:26 CDT
> Keith, you left this part out:
>
> >> The point is
> >> that the richtext parser's front-end "get a character"
> >> primitive would get a wide, multioctet character. (The
> >> special ' >> 32-bit quantity with value 60).
>
> This is the part to which I specifically agree, saying:
>
> > Yes!
>
> The reasoning is:
>
> >> Recalling the proper
> >> definition of "byte", however, we can if we wish continue
> >> to think about byte streams, as long as we remember that
> >> a byte may have more than 8 bits. ...
>
> And if SMTP remains an "octet stream", fine.
> (I think we're closer in agreement than you think we are)
>
Perhaps I was being imprecise.
I am specifically opposed to having the canonical form of a MIME
content-type be anything other than an octet-stream. This implies
that all content-transfer-encoders take an octet-stream as input.
Keith
"You can have any kind of byte you want, as long as it is 8 bits :-)"
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05695;
14 May 93 11:15 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05687;
14 May 93 11:15 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa11530;
14 May 93 11:14 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA19623; Fri, 14 May 93 10:36:12 EDT
Received: from ATHENA-AS-WELL.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA19619; Fri, 14 May 93 10:36:11 EDT
Received: from ADAM.MIT.EDU by Athena.MIT.EDU with SMTP
id AA20742; Fri, 14 May 93 10:35:48 EDT
Received: by adam.MIT.EDU (5.61/4.7) id AA21985; Fri, 14 May 93 10:35:45 -0400
Date: Fri, 14 May 93 10:35:45 -0400
Message-Id: <9305141435.AA21985@adam.MIT.EDU>
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Steve Summit
To: ietf-822@dimacs.rutgers.edu
Subject: Re: printable wide character (was "multibyte") encodings
References:
<9305132141.AA19661@wilma.cs.utk.edu>
<9305140336.AA21388@adam.MIT.EDU>
<9305140724.AA07926@necom830.cc.titech.ac.jp>
<9305141356.AA20631@wilma.cs.utk.edu>
Cc: troth@rice.edu, moore@cs.utk.edu, mohta@necom830.cc.titech.ac.jp,
scs@adam.mit.edu
I've since recanted parts of the note of mine which Rick
presumably dredged out of the archives (perhaps he's found some
of the later messages by now :-) ). In particular, Keith is
right: regardless of the protocols used at higher levels within a
UA, it is important to retain the notion of an octet-stream at
the transport layer, which is what Content-Transfer-Encoding has
primarily to do with.
Since that earlier note doesn't really have anything to do any
more with anything other than UA internals, it doesn't really
matter whether Rick likes it (thanks, though!) or whether
Ohta-san thinks it's "meaningless," and there's no reason to
reopen discussion on those points here now. I do have some more
wild & crazy ideas about charsets, which I may air on the new
ietf-charsets mailing list if I ever have the time and intestinal
fortitude to do so; I'd also be willing to discuss them privately
with anyone who is interested.
Steve Summit
scs@adam.mit.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11066;
14 May 93 17:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ab11060;
14 May 93 17:36 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa23475;
14 May 93 17:36 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA24253; Fri, 14 May 93 17:29:33 EDT
Received: from ATHENA-AS-WELL.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA24249; Fri, 14 May 93 17:29:31 EDT
Received: from ADAM.MIT.EDU by Athena.MIT.EDU with SMTP
id AA07363; Fri, 14 May 93 17:29:28 EDT
Received: by adam.MIT.EDU (5.61/4.7) id AA22544; Fri, 14 May 93 17:29:24 -0400
Date: Fri, 14 May 93 17:29:24 -0400
Message-Id: <9305142129.AA22544@adam.MIT.EDU>
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Steve Summit
To: TROTH@ricevm1.rice.edu, pine-info@cac.washington.edu
Subject: Re: CHARSET considerations
In-Reply-To: <9305121752.AA00650@dimacs.rutgers.edu>
Cc: ietf-822@dimacs.rutgers.edu, ietf-charsets@innosoft.com,
dan@ees1a0.engr.ccny.cuny.edu, scs@adam.mit.edu
Reply-To: ietf-charsets@innosoft.com, scs@adam.mit.edu
In <9305121752.AA00650@dimacs.rutgers.edu>, Rick wrote:
> Any user of Pine 3.05 (and as far as I can tell 3.07 or 2.x)
> can shoot themself in the foot (head if you prefer) by setting
> character-set = Zeldas_private_codepage.
This is almost certainly a bad idea, especially if (as Rick
implied in another part of the referenced message) the user can do
so by setting a default charset value in a user configuration file
somewhere. (If users dink with the message headers themselves,
all bets are off.)
> Should the Pine developers remove this feature?
I'm not sure what the feature in question is, but if it's
something which lets users specify the value to be sent out as the
MIME Content-Type: charset, I think it's a bad idea, and should be
removed or significantly altered.
An easy mistake to make (I speak from experience) is to assume
that the charset parameter on a MIME Content-Type: line encodes
the character set used by the entity composing the message, or
the character set to be used by the entity displaying the
message. I find that the best way to think about charset is that
it is *neither*. charset is an octet-based encoding used during
message transfer; it need bear no relation to the composing or
viewing character sets. In the most general case, a message will
be composed using some native character set, translated
automatically to a MIME-registered charset, and translated at the
other end into a native display character set. It should be more
likely that the charset value be selected by an automaton, not by
a human.
(If anyone finds the above paragraph startling, you're welcome to
write to me for clarification. I'm not going to prolong this
message with additional explanations right now.)
It's not necessarily *wrong* to think of charset as having
something to do with the composing or viewing character set (in
many cases, not coincidentally, all three will be identical), but
it is very easy to make conceptual mistakes, implement
nonconformant software, or just generally misunderstand how MIME
is supposed to work if you don't explicitly separate in your mind
the concepts of composing/viewing character sets and transmission
charsets. (You'll notice that I reinforce this distinction in my
own head and in this message by using the terms "character set"
and "charset" noninterchangeably.)
The charset situation is much like the canonical CRLF situation:
the fact that the canonical representation is identical to some
but not all of the available local representations guarantees
misunderstandings.
To be sure, automated selection of and translation to a registered
MIME charset is a non-trivial task, and mailers which are trying
to adopt MIME right away cannot be faulted for deferring
development of such functionality for a while. However, just
letting users specify non-default, non-7-bit-US-ASCII, (non-MIME)
charsets is an open invitation to misunderstanding and
noninteroperability.
For now, composition agents which wish to allow users to use
extended character sets (such as Latin-1), but which elect to
relegate character set and/or charset selection to the user,
should either present the user with a menu of registered MIME
charsets from which to select (presumably it will be up to the
user to ensure that the editor or composition tool is actually
using a character set corresponding to the selected charset), or
(in the case of what it sounds like PINE is doing) at least filter
the user's open-ended charset selection against the list of
registered values (and perhaps also the X- pattern).
I've copied this message to the IETF character sets mailing list
(ietf-charsets@innosoft.com, subscription requests to
ietf-charsets-request@innosoft.com); any followup traffic should
be sent there, and *not* to the ietf-822 list.
Steve Summit
scs@adam.mit.edu
P.S. to pine-info@cac.washington.edu: despite my e-mail address,
I'm actually in Seattle, near UW. I'd be glad to stop by one day
and talk with you guys in person about this stuff.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17845;
15 May 93 0:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17839;
15 May 93 0:13 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa02365;
15 May 93 0:13 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA26857; Fri, 14 May 93 23:52:54 EDT
Received: from tomobiki-cho.cac.washington.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA26853; Fri, 14 May 93 23:52:52 EDT
Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU
(NX5.67c/UW-NDC Revision: 2.27.MRC ) id AA16916; Fri, 14 May 93 20:51:19 -0700
Date: Fri, 14 May 1993 20:47:02 -0700 (PDT)
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Mark Crispin
Subject: Re: CHARSET considerations
To: ietf-charsets@innosoft.com, scs@adam.mit.edu
Cc: TROTH@ricevm1.rice.edu, pine-info@cac.washington.edu,
ietf-822@dimacs.rutgers.edu, ietf-charsets@innosoft.com,
dan@ees1a0.engr.ccny.cuny.edu, scs@adam.mit.edu
In-Reply-To: <9305142129.AA22544@adam.MIT.EDU>
Message-Id:
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Steve -
Thanks for your comments. You needn't convince me; I've been involved
with the MIME charset issue for a long time (you'll note that I am one of the
authors of the ISO-2022-JP spec). In defense of the other Pine team members,
the sin is one of omission rather than of comission; they wanted to do
something about character sets and didn't want to wire in a table of legal
values (since it might change).
I've suggested that as a first pass the charset should only be settable
in the system config file, and that the charset always be coerced to US-ASCII
unless the text contains 8-bit characters and/or has ``funny'' control
characters such as ESC or SI/SO. More work would definitely be needed in this
area, but you'll appreciate that there are other, higher priorities just
now...
-- Mark --
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11057;
16 May 93 10:05 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11051;
16 May 93 10:05 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa03478;
16 May 93 10:05 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA07641; Sun, 16 May 93 09:52:18 EDT
Received: from dkuug.dk by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA07637; Sun, 16 May 93 09:52:14 EDT
Received: by dkuug.dk id AA14771
(5.65c8/IDA-1.4.4j for ietf-822@dimacs.rutgers.edu); Sun, 16 May 1993 15:51:31 +0200
Message-Id: <199305161351.AA14771@dkuug.dk>
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Keld J|rn Simonsen
Date: Sun, 16 May 1993 15:51:30 +0200
In-Reply-To: John C Klensin
"Re: MIME for VM/CMS" (May 12, 5:08)
X-Charset: ASCII
X-Char-Esc: 29
Mime-Version: 1.0
Content-Type: Text/Plain; Charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Mnemonic-Intro: 29
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: John C Klensin , TROTH@ricevm1.rice.edu
Subject: Re: MIME for VM/CMS
Cc: moore@cs.utk.edu, ietf-822@dimacs.rutgers.edu
John Klensin wrote:
> First thing we do is to get real serious, network-wide agreement about
> what character set(s) we are going to support in the target network and
> what we want to treat as "our" "network plaintext". We write reversible
> mapping rules between MIME-registered characters sets of significant
> interest into that/those character set(s) and get agreement about them.
> Then we decide what we are going to do with any characters that happen
> to be left over from the mappings and standardize that ritual. If we
> end up with more than one EBCDIC, we figure out how to tell sites
> without our network about which one is used in a particular message, but
> we use a mechanism that treats Content-type as inviolate. Maybe a
> EBDCIC-page header.
>
> I would expect the above agreements might be very hard to get in a
> network context that hasn't been able to agree on how to map 7bit ASCII,
> but that isn't a MIME problem.
Much of this is done in RFC1345: definition of a number of charsets,
including many EBCDICs, reversible mapping rules and fallback notation.
Keld
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11336;
16 May 93 11:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11330;
16 May 93 11:06 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa04579;
16 May 93 11:05 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA07845; Sun, 16 May 93 10:53:01 EDT
Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA07841; Sun, 16 May 93 10:52:56 EDT
Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-11 #042B2) id
<01GY7GT4EH3K0009SN@INFOODS.UNU.EDU>; Sun, 16 May 1993 10:52:14 EDT
Date: Sun, 16 May 1993 10:52:14 -0400 (EDT)
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: John C Klensin
Subject: Re: MIME for VM/CMS
In-Reply-To: <199305161351.AA14771@dkuug.dk>
To: keld@dkuug.dk
Cc: TROTH@ricevm1.rice.edu, moore@cs.utk.edu, ietf-822@dimacs.rutgers.edu
Message-Id: <737563934.11103.KLENSIN@INFOODS.UNU.EDU>
X-Envelope-To: ietf-822@DIMACS.RUTGERS.EDU
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Mail-System-Version:
Keld writes, referring to a message of mine...
>> I would expect the above agreements might be very hard to get in a
>> network context that hasn't been able to agree on how to map 7bit ASCII,
>> but that isn't a MIME problem.
>Much of this is done in RFC1345: definition of a number of charsets,
>including many EBCDICs, reversible mapping rules and fallback notation.
Keld,
I think there are really three separate problems here, and thinking
about them separately is the only way to move forward.
(1) An adequate inventory of the various options, including the relevant
EBCDIC and ISO character sets and possible mappings. RFC1345
accomplishes that at the 95% level, if not at the 100% one.
(2) Agreement (in this case) within and between the CREN, EARN,
NetNorth, GulfNet, etc., communities about which EBCDIC(s) to use, which
translation table(s) to use, and how to document what is being used.
Note that each of these has its own decision-making arrangements and its
own mechanisms for enforcing its decisions (or the absence of these
things). Failure to be able to make network-wide decisions in this area
has been a problem long before either MIME or RFC1345 existed--the
arguments and problems are at least a decade old.
(3) Agreement about how to handle MIME and its charset parameter in the
above context.
In addition, if whatever solutions are adopted require any sort of
deployment at all, there is a deployment problem in a connection of
networks have hosts that have proven, in the past, very resistant to
uniform deployment of almost anything that has been thus attempted.
It is my personal belief that the total confusion in the universe is
increased by believing that the second and third problems can be solved
simultaneously. But perhaps I'm wrong. But no solution to one of the
problems constitutes a solution to the others.
john
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00773;
17 May 93 12:38 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00767;
17 May 93 12:38 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa08011;
17 May 93 12:38 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA20263; Mon, 17 May 93 12:08:41 EDT
Received: from uu3.psi.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA20259; Mon, 17 May 93 12:08:39 EDT
Received: from bacon.UUCP by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP;
id AA24615 for ; Mon, 17 May 93 11:55:28 -0400
Received: from stimpys by bacon.IMSI.COM (4.1/SMI-4.1)
id AA27372; Mon, 17 May 93 11:12:20 EDT
Date: Mon, 17 May 93 11:12:09 EDT
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Rens Troost
Message-Id: <9305171512.AA27372@IMSI.COM>
In-Reply-To: nsb@thumper.bellcore.com's message of 14 May 93 11:05:54 GMT
To: nsb@thumper.bellcore.com
Cc: ietf-822@dimacs.rutgers.edu
Newsgroups: comp.mail.mime
Subject: Re: filename parameter in content-type?
Reply-To: Rens Troost
References: <0fwrnJG0aG42A9k14B@thumper.bellcore.com>
Distribution: world
--Can't touch this--
In article <0fwrnJG0aG42A9k14B@thumper.bellcore.com> nsb@thumper.bellcore.com (Nathaniel Borenstein) writes:
nsb> This was removed because most people seemed to agree that it would be
nsb> better placed in a new optional MIME header, Content-disposition, which
nsb> someone was supposed to be writing an RFC about but dropped the ball.
Ugh. I have indeed dropped the ball (new job, much confusion.)
However, I do have a fair amount of it done. If someone could spare
the time to help me edit/finish it, it could be put out in short order.
Any takers?
-Rens
--
o===============================================================o
| J. Laurens Troost - UNIX Systems | At Work: rens@imsi.com |
| Investment Management Svcs, Inc. | At Play: rens@century.com |
| 12 East 49th Street, 35th floor | Phone: (212) 339-2823 |
| New York, New York 10017 | Fax: (212) 444-1980 |
o===============================================================o
-- IMS is unlikely to share any of the above opinions --
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01253;
17 May 93 13:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01247;
17 May 93 13:08 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa09116;
17 May 93 13:08 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA20309; Mon, 17 May 93 12:16:43 EDT
Received: from norman.nwnet.net by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA20305; Mon, 17 May 93 12:16:42 EDT
Received: by norman.nwnet.net
(5.65/UW-NDC Revision: 2.27 ) id AA25880; Mon, 17 May 93 09:16:14 -0700
Date: Mon, 17 May 1993 09:06:59 -0700 (PDT)
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Laurence Lundblade
Subject: Re: CHARSET considerations
To: Mark Crispin
Cc: ietf-charsets@innosoft.com, scs@adam.mit.edu, TROTH@ricevm1.rice.edu,
pine-info@cac.washington.edu, ietf-822@dimacs.rutgers.edu,
ietf-charsets@innosoft.com, dan@ees1a0.engr.ccny.cuny.edu,
scs@adam.mit.edu
In-Reply-To:
Message-Id:
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
I haven't followed this discussion, but Pine does do a few things with
character sets. For example if you set Pine to use ISO-8859-1 and send an
all ASCII message it will tag it US-ASCII (instead of ISO-8859-1). Also,
it's smart enough to display the lower 128 for all incoming messages in
the ISO-8859-X characters sets and greek the ones it can't if the
character set of the receiving Pine is US-ASCII or ISO-8859-X. Thought
that was what required for minimal MIME compliance.
Hope I haven't upgraded the sin from omission to comision....
LL
On Fri, 14 May 1993, Mark Crispin wrote:
> Steve -
>
> Thanks for your comments. You needn't convince me; I've been involved
> with the MIME charset issue for a long time (you'll note that I am one of the
> authors of the ISO-2022-JP spec). In defense of the other Pine team members,
> the sin is one of omission rather than of comission; they wanted to do
> something about character sets and didn't want to wire in a table of legal
> values (since it might change).
>
> I've suggested that as a first pass the charset should only be settable
> in the system config file, and that the charset always be coerced to US-ASCII
> unless the text contains 8-bit characters and/or has ``funny'' control
> characters such as ESC or SI/SO. More work would definitely be needed in this
> area, but you'll appreciate that there are other, higher priorities just
> now...
>
> -- Mark --
>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14695;
17 May 93 18:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14689;
17 May 93 18:44 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa20627;
17 May 93 18:44 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA25602; Mon, 17 May 93 18:11:53 EDT
Received: from mailhost1.cac.washington.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA25598; Mon, 17 May 93 18:11:51 EDT
Received: from tomobiki-cho.cac.washington.edu by mailhost1.cac.washington.edu
(5.65/UW-NDC Revision: 2.28 ) id AA29327; Mon, 17 May 93 15:10:29 -0700
Date: Mon, 17 May 1993 15:05:50 -0700 (PDT)
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Mark Crispin
Subject: Re: CHARSET considerations
To: Laurence Lundblade
Cc: ietf-charsets@innosoft.com, scs@adam.mit.edu, TROTH@ricevm1.rice.edu,
pine-info@cac.washington.edu, ietf-822@dimacs.rutgers.edu,
ietf-charsets@innosoft.com, dan@ees1a0.engr.ccny.cuny.edu,
scs@adam.mit.edu
In-Reply-To:
Message-Id:
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi Laurence -
Perhaps all that is needed is a list in the system .pinerc file of all
the valid charsets, and not let the user set her charset to one that is not in
the list. So, perhaps Pine could have US-ASCII, ISO-2022-JP, and the various
ISO-8859-x sets wired in as an initial list, and the system file specify
additional valid sets?
The concern is to avoid letting users do things like set it to things
such as ``Latin-1'' or ``ASCII'' or similar bogons...
What do you think?
-- Mark --
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06107;
19 May 93 12:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06101;
19 May 93 12:47 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa17370;
19 May 93 12:47 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA15691; Wed, 19 May 93 12:05:04 EDT
Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA15687; Wed, 19 May 93 12:05:02 EDT
Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-11 #042B2) id
<01GYCM53EGKG0009OB@INFOODS.UNU.EDU>; Wed, 19 May 1993 12:04:12 EDT
Date: Wed, 19 May 1993 12:04:11 -0400 (EDT)
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: John C Klensin
Subject: RE: CHARSET considerations
In-Reply-To: <01GYBXHRZVEA8Y5JAE@INNOSOFT.COM>
To: TROTH@ricevm1.rice.edu
Cc: ietf-charsets@innosoft.com, ietf-822@dimacs.rutgers.edu
Message-Id: <737827451.851103.KLENSIN@INFOODS.UNU.EDU>
X-Envelope-To: ietf-822@DIMACS.RUTGERS.EDU
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Mail-System-Version:
Rick, et al.,
I've been pretty quiet on this one. Frankly, I've been hoping that it
would burn itself out. But it doesn't seem to be doing that. So let's
go back and review a couple of things. I'm posting this to the 822
list, since most of the issues are really MIME ones, not character set
ones, and to the charset list because that is where you posted your
note. Everyone else has been removed. People who are already throughly
sick of this discussion should stop reading here.
(1) MIME, like every single other Internet protocol at or near the
applications layer, describes "on the wire" behavior. Neither it, nor
any of the others, describes what should be one on a particular machine
once things arrive there beyond hints about what other systems might
expect vis-a-vis things that are going back out on the wire. The way
you _represent_ a MIME message on your host and in your UA user and
UA MTA communications is not the subject of Internet protocols, even
though ease of use with those protocols may influence whether some
decisions are as smart, or smarter, than others.
In particular, once something gets to your machine, you can dissect
the headers and store them separately in some unique-to-you canonical
form and report whatever you please to your users. You can also store
the characters in 17-bit reverse-slobbovian notation for all anyone
cares. The only requirement--of MIME or anything else--is that you be
able to reconstruct network-canonical form (e.g., MIME) if you send the
stuff back out.
(2) MIME defines text/plain in the absense of an explicit charset
indicator to be identical to "text/plain; charset=ascii". This didn't
happen by accident: it was discussed at tedious and exhaustive length.
It turned out to be the only option: any other model would have caused a
violation of RFC822 with potential information-loss. There was fairly
general agreement in the WG that breaking RFC822-conforming
implementations was a terrible idea.
To claim that it is better to write text/plain without a charset
parameter than with one is justified under only two circumstances that I
can think of:
-- you intend to violate the protocols and hope that, if the charset
parameter isn't listed, no one will notice.
-- you have gotten confused, not about a "charset" versus
"character_set" issue, but about the difference between an on-the-wire
mail format protocol specification and a user-level notion of reality on
a particular terminal at a particular time.
If looking at "charset=us-ascii" is offensive to you, take it out at
display time in your UA, just as many of us hide Received lines unless/
until we need them for something. Whether you just hide that string, or
replace it with "charset=Plutoian-666" is really not an issue for the
network.
(3) For similar reasons, ISO-8859-1 can't be unqualified text/plain on
the wire; it would violate RFC822 and unextended RFC821. And, just
incidentally, it would trade an "English exclusive" mail environment for
a "Western European Latin-based language" primary mail environment.
That wasn't considered to be enough gain to be worth the trouble. Maybe
that was a wrong decision, but I don't think so. Note that trading
"ISO-8859-1" (an assertion about coding of characters on the wire) for
"Latin-1" (an abstraction about a particular character repertoire)
doesn't help with this problem--one is as Western European as the
other-- it just costs you knowledge of the coding on the wire.
(4) There is another major piece of confusion associated with the
assumption that BITNET MAIL is RFC822-conforming. It isn't now. It
never has been. RFC822-Mail over NJE is an oxymoron. RFC822 messages
are in ASCII. It is useful sometimes to pretend that there is a virtual
document, let's call it B-822, that defines the format of BITNET mail.
It contains two lines. One says "On BITNET, we use EBCDIC where RFC822
uses ASCII" and the second one says "except for the changes implied by
line 1, RFC822 is incorporated here by reference". Now BITNET seems to
be (gradually and without complete agreement) issuing B-822bis, which
changes "EBCDIC" in that first line to "EBCDIC CodePage 1047". B-822bis
still isn't RFC822.
And, since the MIME of RFC1341bis/RFC1342bis requires RFC822, BITNET
isn't using it unless all of the headers (822 and body-part) are in
ASCII. That is a firm requirement, no amount of fussing with "charset"
changes it.
So, there is a very interesting question about what the gateways should
do and what near-MIME should look like in a near-RFC822 environment.
But it isn't really a MIME question, much less a charset question. See
item 6, below.
(5) Now, there is something that could have been done back when the WG
was making its decisions that would have made the work of the gateways
between RFC822-based mail and B-822-based mail much easier, although it
would have required changes in those gateways. We could have decided
that this was a transport problem, that we should extend SMTP to
announce, in some fashion, "here comes the MIME" or "here comes the
charset XXX". If the receiving SMTP in this situation didn't accept
that assertion, the mail would bounce. But it would be immediately
clear which gateways were able to cope in a useful way, and which ones
couldn't. And it would make it relatively easy to establish a
B-1341bis/B-1342bis that used different "charset" conventions if that
was appropriate. The cost would have been that all of the MTAs would
have had to be changed to implement MIME.
Those who have been putting up with this long enough will recall that I
argued fairly strongly for transport involvement in this process. The
problems, and semantic unpleasantnesses, that Rick is concerned about
now were most of my motivation then. Given the engineering tradeoffs
between making things easier for some gateways and a little safe overall
versus speed of deployment, I was probably wrong. I was certainly
soundly outvoted.
(6) Ok, now what should be done with "MIME" over B-822? There are a
couple of realistic possibilities. There are also a bunch of
unrealistic ones that depend, to a greater or lesser degree, on getting
agreement from every gateway and every host that sits on an
Internet/EBCDIC boundary to either bounce MIME messages or handle them
in the same specific way. I don't think those are worth discussing now,
although maybe it is too bad that we didn't try to deploy MIME when the
number of gateways and hosts in this situation was closer to three than
a few hundred.
(i) You can let the gateways keep blindly converting everything that
they get from the Internet into EBCDIC, as they are doing now. If you
do this, you need to extend the first sentence of B-822 to say that
anytime "us-ascii" is seen in a message, it means "ebcdic". In this
scenario, you don't teach the gateways to accept 8bit traffic. If that
means you end up with a lot of quoted-printable stuff and base64 stuff,
that is just the way it goes. Fix it in the receiving UAs if they
recognize the MIME value of the "charset" parameter. If not, life is no
worse for them than for real MIME UAs.
(ii) You can do the above, but let the gateways access 8bit traffic.
This means that they have to be a little more activist about potential
conversions. They might want to convert ISO-8859-1 to an appropriate
Latin-1-oriented EBCDIC. I strongly recommend that they identify that
they have done this with a new header that they filter on the way in and
out. That header has to do with which EBCDIC is being used, presumably
with CodePage 1047 as the default. If you don't do that, you are going
to be in deep trouble when Latin-2 (much less ideographic character sets
and non-Latin-based ones) arrives. Remember that there are EARN sites
in Poland and Hungary and Russia and Turkey. It won't take long and
then BITNET will have an EBCDIC-labelling problem even if there were no
MIME.
(iii) You can teach the smarter gateways to put a new verb into the
BMSTP for sites that want it that identifies unconverted MIME and then
pass the message exactly as received by the gateway (e.g., no character
conversion). This would move the conversion problem away from the
gateways and to the delivery MTAs and UAs, which may be able to do
smarter things for their users. This would work well for smart gateways
talking to smart sites. It might be rational to assume that the others
fall under (i) above, i.e., they are on their own and they are going to
see some things encoded that don't strictly need to be. As the saying
goes, life is hard sometimes.
(7) There are a couple of other things in your note that are invitations
to interoperability problems. For example...
>Specifically, I feel
>(quite strongly) that the user should be able to specify any old
>charset and have display at least attempted at the other end.
I feel (quite strongly) that this falls between "looking for
trouble" and a potential real disaster. Suppose you receive
"text/plain; charset=Mickey-Mouse". What is the recipient going to try
to display? We made the mistake with RFC822 of permitting people to put
anything in, subject only to the rule that we might later come along and
assign some semantics to it. That means that message structures that
had a specific meaning a half-dozen years ago now may have a different
meaning, with no real clues to anyone. Bad mistake. If a user wants to
use "any old charset", use an "X-" as a warning that there had better be
a private agreement between sender and receiver. If the "X-" is
offensive, let it be defined and registered so that there is some hope
that "attempting display" will get it right.
Similarly,
>If you specify "Latin-1", then you can (must; I'm arguing for a
>definition here, not an explanation) assume that SMTP will carry it
>as ISO-8859-1, BUT THE RECEIVING (or sending) HOST MIGHT NOT.
>(and yes, sad but true, any SMTPs will strip the high bit)
If you specify "Latin-1", then you cannot make any assumptions at all
about how SMTP will carry it. "Latin-1" is an ambiguous reference, one
of whose instantiations of ISO 8859-1. If you specify "iso-8859-1",
together with a content-transfer-encoding, you know exactly what is
being carried on the wire. In neither case is any assertion made about
what the receiving host might do with it. That is a MTA-delivery-UA
problem, not a MIME/822/821/etc one.
And
>That's why I ask that
>(today, 1993) we NOT LABEL true plain text as US-ASCII/ISO-8859-1.
>Just leave it alone and let it default at the receiving end.
Get into your time machine. Go back to 1981 or 82. Make this case
then. In "today, 1981" we labelled true plain text as ANS X3.4 ASCII.
We put the label in the protocol document, not in the mail messages, but
the specification is clear, was clear, and will still be clear when your
time machine gets back to 1993.
>(nor the MIME developers; not mad at anyone, just trying to push a
>point that I think is important and has been missed).
For whatever my assurances are worth, it hasn't been missed. The
questions and options were examined very carefully; nothing above is
really new. What is missing, I fear, is an understanding of what has
been going on with email for the last decade.
There is a dirty little secret that many of us have known, or feared,
for many years and that, for better or worse, MIME and the SMTP
extensions have brought to the foreground. The mail environment has
worked for the last decade not because of a high level of conformance or
understanding of subtle aspects of the protocols but because of a very
high level of robustness and tolerance for nonsense. Protocol changes
and extensions almost inevitably raise the conformance threshold and the
understanding threshold along with it. And we are shaking out a lot of
beliefs that are handy but not quite true, e.g., the one that assumes
that BITNET uses RFC822 on NJE-wires. It has never been true, but
believing it up until recently hasn't been harmful. Well, it is getting
harmful and that is one of the prices we pay for MIME.
john
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00958;
20 May 93 6:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00952;
20 May 93 6:08 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa03861;
20 May 93 6:08 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA24909; Thu, 20 May 93 05:46:22 EDT
Received: from aun.uninett.no by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA24905; Thu, 20 May 93 05:46:20 EDT
X400-Received: by mta aun.uninett.no in /PRMD=uninett/ADMD= /C=no/; Relayed;
Thu, 20 May 1993 11:46:12 +0200
X400-Received: by /PRMD=uninett/ADMD= /C=no/; Relayed;
Thu, 20 May 1993 11:46:07 +0200
X400-Received: by /PRMD=uninett/ADMD= /C=no/; Relayed;
Thu, 20 May 1993 11:46:04 +0200
Date: Thu, 20 May 1993 11:46:04 +0200
X400-Originator: harald.t.alvestrand@delab.sintef.no
X400-Recipients: ietf-822@dimacs.rutgers.edu
X400-Mts-Identifier: [/PRMD=uninett/ADMD= /C=no/;930520114604]
X400-Content-Type: P2-1984 (2)
Content-Identifier: 10264
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Harald Tveit Alvestrand
Message-Id:
To: ietf-822@dimacs.rutgers.edu
Subject: New type suggested: Multipart/Related
Here is my entry to the content-disposition debate.
This memo defines 2 things, which may or may not be a good idea:
- A way to tell the recipient MIME reader which body parts contain only
info that is "about" the other body parts
- A way to tell the recipient MIME reader which is the "main" body part
(and therefore, by extension, that all the others are "attachments").
I have not submitted it as an Internet-Draft; I thought I would solicit
comments off this list first.
The private consultations I have had on this provoked no more than
lukewarm reactions, so I'll see if there are more flames here....
In my (biased) opinion, this makes more sense than
Content-Disposition: {main/attachment}, since it attaches the information
to where it belongs: The composite level.
If there are no significant claims that this does not make any sense,
I'll bother the CNRI about internet-drafting it, and let it stew for a while.
NOTE: This one *has* to be standards-track, because I want other RFCs to
be able to use it.
Please comment!
Harald Tveit Alvestrand
(No, this memo is *NOT* about character sets :-)
draft Multipart/Related May 93
The MIME Multipart/Related content-type
Thu May 20 11:17:05 MET DST 1993
Harald Tveit Alvestrand
SINTEF DELAB
Harald.Alvestrand@delab.sintef.no
Status of this Memo
This draft document is being circulated for comment.
If consensus is reached it may be submitted to the RFC editor as a
Proposed Standard protocol specificiation, for use with MIME.
Please send comments to the author, or to the 822ext list .
The following text is required by the Internet-draft rules:
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its
Areas, and its Working Groups. Note that other groups may also
distribute working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use
Internet Drafts as reference material or to cite them other than
as a "working draft" or "work in progress."
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
Alvestrand Expires Nov 20 93 [Page 1]
draft Multipart/Related May 93
1. Introduction
Several applications of MIME, including MIME-PEM and MIME-
Macintosh, have had the need to provide content-types that
provide, basically, two pieces of information:
One, the "basis", which is of a content-type otherwise defined.
One, the "header", which provides interesting information about
the other part of the message. In PEM, this is the algorithm,
signature and key information; in MIME-Macintosh, this is the
Finder information. In both cases, it is possible for the message
to be useful without this part being understood, but there is a
lot of added functionality if this other part is also understood
by the recipient.
In other cases, a desire has been expressed for giving a hint to
the recipient UA on whether it is intended to display the parts of
the message at the same time or as attachments to a main message.
In order to keep the MIME philosophy of having one mechanism to
achieve the same object for different purposes, one single
mechanism should be defined for doing such things.
2. Definition
The following text is copied from RFC 1341, appendix F1.
MIME type name: Multipart
MIME subtype name: Related
Required parameters: None
Optional parameters:
Header=
Mainpart=
Encoding considerations:
Multipart content-types cannot have encodings.
Security considerations:
Alvestrand Expires Nov 20 93 [Page 2]
draft Multipart/Related May 93
Not considered
Published specification:
This document
3. Intended usage
3.1. The Header= parameter
In cases where the header= parameter is given, the part or parts
with the given type(s) are understood to give information about
the other part or parts of the Multipart.
The placement of the type in the header serves 2 purposes:
- To identify the particular type which has to be treated
specially
- To enable configuration-based UAs to switch to the correct
processing module for that particular header type.
In certain configurations it makes sense to list several "header"
types, for instance when a Macintosh file is sent with a PEM
signature applied to its Data fork (but not to its resource fork).
How to associate each Header with its related Content part must be
defined when defining the Header type; the most common cases will
be that it is only legal to have it together with a single part
not mentioned in the Header= list, or that it applies equally to
all parts not mentioned in the Header= list.
When an UA is able to process the Multipart/Related type, but not
any of the types listed in the Header= parameter, it is allowed
for the UA to suppress the part entirely when viewing the message,
since it does not make much sense to store it separately.
Alvestrand Expires Nov 20 93 [Page 3]
draft Multipart/Related May 93
3.2. The Mainpart= parameter
This parameter is a hint to the recipient UA that the sender
intended the part with the Content-ID of the parameter to be
displayed at once, and that the sender intended that the recipient
should have to take specific action in order to view the other
parts.
One possible implementation of this is to display the main part at
once, and the others as an icon row.
This RFC does not specify where the mainpart should be in the
sequence of parts.
4. Registration forms
Form for registering new parameters to the Content-Type
Multipart/Related type
Parameter:
Parameter value grammar:
Purpose:
Authors' address
Detach and submit to IANA for archiving.
The IETF-822 list is suitable for discussion of such extensions
prior to registration.
5. Example description
Example describing the relationship between a body part mentioned
in a Header= parameter and other body parts in the message
The content-type Application/RecLenList is intended for use
together with the Application/Octet-stream type inside a
Multipart/Related, but can be used with any primitive MIME type.
Alvestrand Expires Nov 20 93 [Page 4]
draft Multipart/Related May 93
In all cases, it refers to the canonical encoding of that type.
The RecLenList consists of a set of INTEGERs in ASCII format, one
per line, and each INTEGER gives the number of octets from the
other body part that should be considered part of this "record".
Multipart/related consideration
The RecLenList applies to only one other body part, so when it is
used in Multipart/Related, there should only be one body part
present that is not mentioned in a Header= parameter.
6. Security considerations
No security considerations relevant to this memo have been
identified.
7. Acknowledgments
Acknowledgements are, as always, due to more people than can be
listed. However, I especially want to thank:
- Nathaniel Borenstein and Ned Freed, for writing the MIME that
I can base this on
- Ned Freed and Patrik Faltstrom (diaeresis on the a end o in
his last name), for trying to define the MIME body parts that
led me to write this memo
- SAS catering, who provided the service during the airplane
trip during which the first version of this document was
composed.
8. References
RFC 1341 - MIME
RFC 1421 - PEM
Alvestrand Expires Nov 20 93 [Page 5]
draft Multipart/Related May 93
9. Author's address
Harald Tveit Alvestrand
SINTEF DELAB
N-7034 Trondheim
NORWAY
+47 7 59 70 94
Harald.T.Alvestrand@delab.sintef.no
Alvestrand Expires Nov 20 93 [Page 6]
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01201;
20 May 93 7:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01195;
20 May 93 7:10 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa04733;
20 May 93 7:10 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA25039; Thu, 20 May 93 06:43:56 EDT
Received: from pianeta.di.unito.it by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA25035; Thu, 20 May 93 06:43:52 EDT
Received: by pianeta (4.1/SMI-4.1)
id AA12401; Thu, 20 May 93 12:41:28 +0200
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Piola Roberto - Corso TSE
Message-Id: <9305201041.AA12401@pianeta>
Subject: proposal for inserting non-text datas in internet messages
To: ietf-822@dimacs.rutgers.edu
Date: Thu, 20 May 93 12:41:27 MET DST
X-Mailer: ELM [version 2.3 PL0]
I saw a printed copy of a paper describing a proposal for inserting non-text
elements (pictures, application datas, music, animations, etc.) into internet
messages.
I'm very interested in that (I'm developing a message editor, and I would
include graphics and formatted-text capabilities in the MS Windows version
of my editor). Where can I get the file to reprint the paper?
Please send me numeric addresses for ftp, since our computer has only a
reduced /etc/hosts.
Thanks in advance.
Roberto Piola
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04680;
20 May 93 10:23 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09927;
20 May 93 10:23 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04663;
20 May 93 10:22 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04616;
20 May 93 10:19 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-822@dimacs.rutgers.edu
Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US
From: Internet-Drafts@CNRI.Reston.VA.US
Reply-to: Internet-Drafts@CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-822ext-iso2022jp-03.txt
Date: Thu, 20 May 93 10:19:04 -0400
X-Orig-Sender: cclark@CNRI.Reston.VA.US
Message-ID: <9305201019.aa04616@IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Message
Extensions Working Group of the IETF.
Title : Japanese Character Encoding for Internet Messages
Author(s) : Jun Murai, Mark Crispin, Erik van der Poel
Filename : draft-ietf-822ext-iso2022jp-03.txt
Pages : 6
This document describes the encoding used in electronic mail [RFC822]
and network news [RFC1036] messages in several Japanese networks. It
was first specified by and used in JUNET [JUNET]. The encoding is now
also widely used in Japanese IP communities.
The name given to this encoding is "ISO-2022-JP", which is intended to
be used in the "charset" parameter field of MIME headers (see [MIME1]
and [MIME2]).
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-822ext-iso2022jp-03.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server@nisc.sri.com. In the body type:
"SEND draft-ietf-822ext-iso2022jp-03.txt".
For questions, please mail to internet-drafts@cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server@nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-822ext-iso2022jp-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-822ext-iso2022jp-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05754;
20 May 93 11:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05748;
20 May 93 11:12 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa11737;
20 May 93 11:12 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA27017; Thu, 20 May 93 10:50:41 EDT
Received: from dorner.slip.uiuc.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA27013; Thu, 20 May 93 10:50:37 EDT
Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA06376
(5.65c/IDA-1.4.4 for ietf-822@dimacs.rutgers.edu); Thu, 20 May 1993 09:51:36 -0500
Message-Id: <199305201451.AA06376@dorner.slip.uiuc.edu>
X-Sender: sdorner@dorner.slip.uiuc.edu
Mime-Version: 1.0
Content-Type: text/plain
Date: Thu, 20 May 1993 09:50:30 -0500
To: ietf-822@dimacs.rutgers.edu
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Steve Dorner
Subject: Re: New type suggested: Multipart/Related
I'm sorry, I haven't been on this mailing list, but this happened to come
my way. If I'm way out of context, I'm sure someone will let me know...
>>- A way to tell the recipient MIME reader which is the "main" body part
>> (and therefore, by extension, that all the others are "attachments").
I suggest that the "main" body part should simply be the first one. This
makes life far easier for users without MIME UA's and make my life a lot
easier in my MIME-mostly-aware MUA. I see no particular benefit to being
able to explicitly designate some subsequent part as the main part.
Content-Disposition is fine by me, assuming what I've heard about it to far
is what it ends up being.
--
Steve Dorner, Qualcomm Inc.
Yes, I am testing a version of Eudora with MIME. No, I don't know when it
will be ready.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07010;
20 May 93 12:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07003;
20 May 93 12:44 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa14472;
20 May 93 12:44 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA27747; Thu, 20 May 93 12:31:07 EDT
Received: from umail.umd.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA27743; Thu, 20 May 93 12:31:06 EDT
Received: by umail.UMD.EDU (5.57/Ultrix3.0-C)
id AA02007; Thu, 20 May 93 12:31:03 -0400
Date: Thu, 20 May 93 12:31:01 -0500
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Dana S Emery
To: ietf-822@dimacs.rutgers.edu
Subject: Re: New type suggested: Multipart/Related
Cc: ietf-822@dimacs.rutgers.edu
Message-Id:
In-Reply-To: Your message <199305201451.AA06376@dorner.slip.uiuc.edu> of Thu,
20 May 1993 09:50:30 -0500
Content-Type: TEXT/plain; charset=US-ASCII
> >>- A way to tell the recipient MIME reader which is the
> "main" body part
> >> (and therefore, by extension, that all the others
> are "attachments").
>
> I suggest that the "main" body part should simply be the
> first one. This makes life far easier for users without
> MIME UA's and make my life a lot easier in my
> MIME-mostly-aware MUA.
If we are to support Main/attachment structure, then its seems obvious that
tagging a part as "main" is a usefully minimal strategy.
To allow UA's the flexibility to have an arbitrary ordering of body parts seems
desirable, but Steve Dorner says it is an awkward luxery.
Both views have obvious merit, so I say we need some counter examples of how
that flexibility would be usefull.
--
dana s emery
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08914;
20 May 93 13:46 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08905;
20 May 93 13:46 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa16233;
20 May 93 13:46 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA29976; Thu, 20 May 93 13:29:43 EDT
Received: from att-out.att.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA29972; Thu, 20 May 93 13:29:42 EDT
Message-Id: <9305201729.AA29972@dimacs.rutgers.edu>
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "t.l.hansen"
To: ietf-822@dimacs.rutgers.edu
Date: 20 May 1993 13:20 EDT
Subject: Re: New type suggested: Multipart/Related
References:
<< I suggest that the "main" body part should simply be the first one. This
<< makes life far easier for users without MIME UA's and make my life a lot
<< easier in my MIME-mostly-aware MUA.
< If we are to support Main/attachment structure, then its seems obvious
< that tagging a part as "main" is a usefully minimal strategy.
<
< To allow UA's the flexibility to have an arbitrary ordering of body parts
< seems desirable, but Steve Dorner says it is an awkward luxery.
<
< Both views have obvious merit, so I say we need some counter examples of
< how that flexibility would be usefull.
The last time this topic came up seriously (either here or in
comp.mail.mime), there were several examples of differing systems which make
different assumptions about attachments. The two major paradigms were
a letter or cover sheet followed by the attachments
a series of attachments clipped on top of a letter
To be able to handle both of these paradigms, it is clear that the "main"
portion must be able to be labelled as such.
Tony Hansen
hansen@pegasus.att.com, tony@attmail.com
att!pegasus!hansen, attmail!tony
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10485;
20 May 93 14:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10479;
20 May 93 14:43 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa17993;
20 May 93 14:43 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA00701; Thu, 20 May 93 14:05:53 EDT
Received: from uu3.psi.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA00697; Thu, 20 May 93 14:05:47 EDT
Received: from bacon.UUCP by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP;
id AA18553 for ; Thu, 20 May 93 13:55:41 -0400
Received: from stimpys.imsi.com by bacon.IMSI.COM (4.1/SMI-4.1)
id AA14638; Thu, 20 May 93 13:25:46 EDT
Received: from localhost by stimpys.imsi.com (4.1/SMI-4.1)
id AA14261; Thu, 20 May 93 13:22:52 EDT
Message-Id: <9305201722.AA14261@stimpys.imsi.com>
To: Harald Tveit Alvestrand
Cc: ietf-822@dimacs.rutgers.edu
Subject: Re: New type suggested: Multipart/Related
In-Reply-To: Your message of "Thu, 20 May 1993 11:46:04 +0200."
Reply-To: rens@imsi.com
Date: Thu, 20 May 1993 13:22:51 -0400
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Rens Troost
>>>>> On Thu, 20 May 1993 11:46:04 +0200, Harald Tveit Alvestrand
alvestrand> Here is my entry to the content-disposition debate.
alvestrand> This memo defines 2 things, which may or may not be a
alvestrand> good idea:
alvestrand> - A way to tell the recipient MIME reader which body
alvestrand> parts contain only info that is "about" the other body
alvestrand> parts
I think this makes the relationship between an organizer ( the
encolsing or containing entity) and an included component too
asymetrical. What if someone wants recursive references in their
document? The stuctured approach which you have used strongly implies
that documents are directed acyclic graphs. A quick look at
'multimedia' authoring tools will show you that this is not the case.
After the discussion a few months ago, it was my impression that
adding a new body-part header (content-disposition) was generally
acclaimed as being cleaner, easier to implement and administer, and
easier to parse at the MIME level than using the multipart syntax. I
lamentably have dropped the ball, but am picking it up, and will have
a draft out in a few days if it kills me. :)
Has the general consensus changed? I'd be happy to devote my time to
working on compound document formats, which is how I got drawn to this
in the first place.
-Rens
--
o===============================================================o
| J. Laurens Troost - UNIX Systems | At Work: rens@imsi.com |
| Investment Management Svcs, Inc. | At Play: rens@century.com |
| 12 East 49th Street, 35th floor | Phone: (212) 339-2823 |
| New York, New York 10017 | Fax: (212) 444-1980 |
o===============================================================o
-- IMS is unlikely to share any of the above opinions --
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12361;
20 May 93 16:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12355;
20 May 93 16:17 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa20492;
20 May 93 16:17 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA01219; Thu, 20 May 93 15:44:05 EDT
Received: from WILMA.CS.UTK.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA01215; Thu, 20 May 93 15:44:02 EDT
Received: from LOCALHOST by wilma.cs.utk.edu with SMTP (5.65/2.8c-UTK)
id AA12658; Thu, 20 May 1993 15:38:36 -0400
Message-Id: <9305201938.AA12658@wilma.cs.utk.edu>
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Keith Moore
To: rens@imsi.com
Cc: Harald Tveit Alvestrand ,
ietf-822@dimacs.rutgers.edu, moore@cs.utk.edu
Subject: Re: New type suggested: Multipart/Related
In-Reply-To: Your message of "Thu, 20 May 1993 13:22:51 EDT."
<9305201722.AA14261@stimpys.imsi.com>
Date: Thu, 20 May 1993 15:38:33 -0400
X-Orig-Sender: moore@cs.utk.edu
>
> After the discussion a few months ago, it was my impression that
> adding a new body-part header (content-disposition) was generally
> acclaimed as being cleaner, easier to implement and administer, and
> easier to parse at the MIME level than using the multipart syntax. I
> lamentably have dropped the ball, but am picking it up, and will have
> a draft out in a few days if it kills me. :)
>
> Has the general consensus changed? I'd be happy to devote my time to
> working on compound document formats, which is how I got drawn to this
> in the first place.
Yes we have had this discussion before. A per-body-part indication
is simpler and more versatile.
Keith
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04144;
21 May 93 10:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04138;
21 May 93 10:18 EDT
Received: from [128.6.75.16] by CNRI.Reston.VA.US id aa03523;
21 May 93 10:18 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA08880; Fri, 21 May 93 10:01:57 EDT
Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA08876; Fri, 21 May 93 10:01:56 EDT
Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7)
id for ietf-822@dimacs.rutgers.edu; Fri, 21 May 93 10:01:30 EDT
Received: by greenbush.bellcore.com (4.1/4.7)
id for de19@umail.umd.edu; Fri, 21 May 93 10:01:49 EDT
Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.greenbush.galaxy.sun4.41
via MS.5.6.greenbush.galaxy.sun4_41;
Fri, 21 May 1993 10:01:45 -0400 (EDT)
Message-Id:
Date: Fri, 21 May 1993 10:01:45 -0400 (EDT)
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Nathaniel Borenstein
X-Andrew-Message-Size: 1265+2
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="Interpart.Boundary.kfzC3860M2YtMl6UZX"
To: ietf-822@dimacs.rutgers.edu, Dana S Emery
Subject: Re: New type suggested: Multipart/Related
Cc: ietf-822@dimacs.rutgers.edu
In-Reply-To:
References:
> THIS IS A MESSAGE IN 'MIME' FORMAT. Your mail reader does not support MIME.
> Please read the first section, which is plain text, and ignore the rest.
--Interpart.Boundary.kfzC3860M2YtMl6UZX
Content-type: text/plain; charset=US-ASCII
Excerpts from mail: 20-May-93 Re: New type suggested: Mul.. Dana S
Emery@umail.umd.e (791*)
> If we are to support Main/attachment structure, then its seems obvious that
> tagging a part as "main" is a usefully minimal strategy.
I think that's right. The real issue is that some models (Andrew for
example) don't really have any notion of "main" -- the main message is
itself often multipart, and includes in-line pictures like this one:
[An Andrew ToolKit view (mailobjv) was included here, but could not be
displayed.]
As you can see from the above picture, the Andrew users sees (and tends
to compose) a multimedia message at the top-level. If you treated the
first part -- in this case richtext -- as being the whole message, you'd
end up with an incoherent partial message, followed by some attachments
that really ought to be viewed in sequential order if you're to have any
hope of making sense of the message. Other mail readers have a model
that there's a main part -- typically text -- with attachments, but in
Andrew there's no real such notion, although you can do attachments,
e.g.:
[An Andrew ToolKit view (mailobjv) was included here, but could not be
displayed.]
Anyway, I'm hoping that by including the picture of what my screen
looked like when composing this, I'll give people in the
attachment-oriented world a better idea of what things might look like
from the other side of the fence... -- Nathaniel
--Interpart.Boundary.kfzC3860M2YtMl6UZX
Content-Type: multipart/mixed;
boundary="Alternative.Boundary.kfzC3860M2Yt0l6UVO"
--Alternative.Boundary.kfzC3860M2Yt0l6UVO
Content-type: text/richtext; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Excerpts from mail: 20-May-93 Re: New type suggested: Mul.. Dan=
a S Emery@umail.umd.e (791*)If we are to support Main/attachment structure, then its seems obviou=
s that
tagging a part as "main" is a usefully minimal strategy.
I think that's right. The real issue is that some models (Andrew for example)=
don't really have any notion of "main" -- the main message is itself often mu=
ltipart, and includes in-line pictures like this one:
--Alternative.Boundary.kfzC3860M2Yt0l6UVO
Content-type: image/gif
Content-Description: My screen when composing this message
Content-Transfer-Encoding: base64
R0lGODdhnQJuA8IAAPXes3pvmgAAgLinpmBgYN3IrgAAAGwAACwAAAAAnQJuAwAD/li6
3P4wykmrvTjrzbv/YCiOZGmeaCikbOu+cCzPdG3feK5vwbr/loBiQCwaj8ikcslsOp/Q
qHRKrVqv2Kx2y+16v+Cw+BroDcfotLJ8Jpff8Lh8Tq/b7/i8fs/v+/+AgYKDhIWGh4iJ
iouJA2U+apGSbAVZjJeYmZqbnJ2en6ChooqVj22SqGGUlgEArq+wsbKztLW2t7i5uru8
vb6/wMHCw8TFxsfIycrLxUOmlanRX6tYZczX2Nna29zd3t/g4eLHzmbQ0uha1G7j7e7v
8PHy8/T1xuWQTgL7APv8//4CAigiUOAWf/0GillnxZq9hxAjSpxIseI8fKeW9BPg/opf
wo0g+RUBSVIhFo8iFwop9YeIQ4swY8qcSbMmRIznmojcOfAVQJMDfgK94nFAwjGr/kB7
abOp06dQo0qdhRMKwoQAOf408s8VV4REChokyHHkQLFgd5Z1kjSAlDNMp8qdS7euXW9V
n4TU6lOrX6Bjw3Lc2/FvyqBryRYmzHPompWO3EaB2+qu5cuYM2umyjLfk59rQSdGDJIs
WoRbBQ9Vy7jsaCZt3y6tvLm27du4Yeb9nFWhaMCDU3rsGys16SOshXaFEtsIgefQj1A+
FlDgrsG4htO6uhF791nVtwevrd1W9fLEUBc/3w59cVjW4cenXnKYe/GWdzshOVi1/vHj
paX1XVCEjSRcgIa5VtQTbTUA3XMQuERbegny4t17HX2E32+EEScfeBm6c+E2I5rnYTEo
jehdid6w+N1iJZV3HzDjGeMiiHfpp49XoZ0HFmJZBcedddYZ0R12RF5l1GFsQUbJAhA+
AFlk9PFno0/ZYYlkiBq6V+KN34C5jJjwlXkllhjGA+aWaHo5ZpW6kNmUjk14ZZRCtxBh
y52v6AkLaXYa+SefPGJHUKBNltMGAQ0UQU1cKF4Yn6RIpsheLSiliWaXfHH6W299rTik
dn5dFWRhw5n6Inehyqeci5K22iGqsszY5WKg0opVeKx+iGqlsXL5UaXD8lchq6bW/gjj
p6T2+uKvxtZnE53p6PSaFIf9yJyTU8I2JaQU+pophmyyeUuvMiqr7rIh9pZiuzUqi+ut
nNI7LF/y0juuubWSG+9fVq7HYni4Ktcmvpv6yq699YbU5sPwfvdusRpyKaTEF1esb7yb
2loRtdUqERi2Py64raI5PTZdMs3CiCPB/G7nssb6dmxxuzaLW+uXZlK8saonujquz7Bq
GrDG97l589Iw90xpv/AiKzTOTEPMcMDBEm01pUBrrfBMIIeMRCxVkM3nFA2mnMSjE9oo
6szkQu0pkTn37LXX61rc6ZcqOq031XZLS3O5CRtNbN4OYyq334AX3mnQOQ/88tJ4/tfd
lc9VZ4603IhDrltnGYktehNpJzqbMi0LbnXdijcuLMVDE25v3gNnXbOsg+9s9O00J2wu
7Y4H3vvvr2+uYt+uF3577Fs3jznvsm+eZueqWxT26Ng7ym3oSLCN+ttHH6yl8roLtauW
FyMLMOIZZ4wV1W8PjfSWK8JP//rrc04s3vlObDf7Lnsc+Wb2KtalLlcdIh7W7He0cuUv
RgkEWPU+FxkfjOKCgkCZ6STEMvWlSmDQ+pXHknUa+WEqSKgBlXqOpKtdxa99o8rVkEIF
rHslToTpKlWpaFU/Z/kIYztkofrOVUMhWcp8A1zPkXZIwiVebi8pDKJ6gFXEgnnM/nqg
w6AWlcIS7h3Be7lRouciUj9wyKkmZ/ze18KIxQoC4Y0WiIwXjQBGNk4tJv7rRhplIsBw
zMeObXwGHAfZgO2prXvfahsgbeKsRQrjio6M5Cuulz3slY50iZSkJjfJyU4CgJKVFN0l
vbUyT5rylKi8DChDGbJRLqGOqYylLGdJk1WyMh2uVNnpaMnLXvqyHra8pTRyubZM/vKY
yEwmN4LJGx1CMTzIOZUoDblBKlFnhTs73jX/mIsYcnJG6Eoa8iJFMPw8co/KpAcz9zOx
9P3lKwVzzDCpiclShgtua5ygzEykT3MWzxfohIecbpQufsbMQnHTZ9G6mc6arFMf/go6
S0/iqZievFNsxESkPe1TRvAEVIyt6925rvaLj4ooTiain0FRxDiR/vOli2soBZ/xBVW5
66LH8ZNahJPC0ngho180Jjldtaok1VBWdOMcUf/5QF1F8Vk/5JWo+IY/Glq1hUA04h15
ptJoubCnzRrPD2e3VE+F0IMmlWk7Hlon0BDHOEwizbvmypdp0JOUu3RbqmC4rH9FDIJQ
+2DyYBc51pE1gcHjX70UyDGmNfY9bs2cA72avopNVrKPvWxa1SoOtlrLYf7BaVxRSMWS
2FWD9czrNvvK2ghSdk1oJei8REi5rEXPiAUtLOBw6765US9uAKzc6+THr/k0TWe0/iUp
ZyXiWSY8NbQ+zalicvufLgCVjkJFRk9fa8Xt5jOhMJ2ech/ru8MSlLF+fV4AlXdQM+1N
t7d9q7CKO1/93c2wy2Uu6A6ZhYBB9zA+TZBrEBTdn971ldm1z4faydfcLjik7cXR+5iK
wPoyloi1DesAmSdeCFtut5qTF30p57yDRji/9miuc3nkGx8B+DQs5OHIuHBd7W30nG/l
a7Rsui8T/g2CPDuRYMerqQLW14ZDdlxX1XW/8H04nopt55Ft6769ZbbJkEQxPFSsETx5
uRaCyoWfaAGGGkvoxsG4FMZc6KFJDXF+ez1rNv8ntZfmUYIxxl0E98pnrbbZm31c/lUL
UUhbPEdxqlc1lgovd8RWbVbL2+CyMFWCWrxyUE2PhontWDq+JE7ko5mGtF0kPekyH1iX
lz5plp3Sx1D/2aszAbWoO0nqUhu40ghGsxlXzWqudRDRaOT1rE9Za1vT+NTF1PWwl81s
SRbb2OpAtkZV2+xqW9uOONmitvWAa1Rb89rgDndtMLLtct+h28mmtrjXzW654ISQ8GaA
HPmLXWW3+974jsm74z1IaQfV3iXFphBDimHz8LmsQqtdeOki7Hwz+9nQroa/661uHAdw
fxJW6nlbA2W4Kc3VaTajw0f+yf1GfHRmnneq7yk+4TF04beKLz6HJw+Qo5Tk+Yb4/smr
kHJYctRf4L04bxvZ5t397r3QYhawQ/isr7qz0U4t6vGmWlWcg1vnO0fbxG1ccRopPOMg
Vu6c18hhzUZsuz2GnxIfx2TzIkx6Nryv1ZuN9axHoecJtrjubn5cl7a8eDIXrgKLDtL/
Oe9eXVNd338792Hr/NDPDAyMeXotSneR3lxf+c89eh3Ad+xSgy+veSE2eEZzvshbI+9w
x6lbvzcexTqnbDxfvL+UFBgNeAe4hYIlo9aNU0zRS2z74Nv6fEGuoyJOMuA3Db3XVxvr
rCEQn/7D04maJK5I2fqZu+51Idc+sF11Pccz9EG6vjDsca8yYS3b1Pl1Wu1ArmrD/p2P
TOhn6qYFrn5a9o/9Y6N72ppHIeE0Q0vlZtwEQk6UgOKXVU/VRLg1aE1nZAYYRFCVaCuE
RPQHaVjHGDmWf6B3LBejCtqnct/mSKlTER2VgSqIC3XnVv81GnEmVwKmLbd2edUELoB0
gBKRRyvYg5zhRph3Er3xgsDRYmcBgmZzWjaYWgHogwjnhFA4SSYXBv4lgx5ohFY4hJUX
bf/3b9wXhWAYhq5QdwQiUYLhYi1GWkrXH6bWhRTXhGIYh1FIhnZSh3tCKMFgeSRoaSUo
h34IhWRodxvEEN6Gg394iM4XiIJoaYSYbnCIiJBodYq4iKjWiADYh+c0f2O1ewGF/oYc
5WsyM38hl02llXHGpWGJRkS9tzsuNUJ3lHCo00/XcUaiOG5TSImpkHtfCFAmZSm8GHCz
oncztzoul4l7Z2S4w2A7dlTZAUNLN0ZJNCoXV3jpAXOdd42mNIm46IV7mGu72Au1GGfg
2IkLo2Dhx08xdSaGl4IGFGLWaHjstXf75GF/V4wKpo4vl437ZW78KAdumHmYaHHeZXBB
44CH81TNKDAnBmTvV1R6o0NSRFdNJzzsKDlTll5+Bo5GB1kedXAtRTTvJZEIlCzz5U5Q
9Ip6JhYdh21Z1I8uqYuPCIwylpD14Yzc9Y4HZHwex4EL01htVyEnqTTwOEEjFoHl/pdG
6MF6T0R4RTlXJSY+aOeTHYZ/TmZ2s2NzDrVf/BZv3ViIiqR3PNiROdla4jhQ4ANOQYZ0
yNVbTVlbYGdZrMgwGOlxe8R8ZfR7yVWS+1J8brmWU8mXsNh837UZ+7aVQDCCPrd5r3WK
UAUzOnZDalaQvTWYYlWS6wdYcIl+QTaU5DNigadk5SR6LYWXIpWWfRl4h+M6qEliuYN+
0JgZ2riNmWeJ3BiQaVZ7wOdnSfmYE0mQr+ZPo0l8hJeZd7OZotmZoveZ78iZD4kuxBiP
DDR67vg8q3k1pBkztRgVsSmbKkebb2ib3ddavglEf3VnqzaWpWlbnwd/mbVgwZWC/vI3
fOu5jFDGeL/peUrlWiQ2lkPEYenHnk01WWlHfvH5moR5i9yZBjAJnry4aOd1cBP4gJ6m
kK+4cYLWmBA5kqeoVQ2YXBKaZ7zFdEbJjK4XoXmZYVZ2RHhmjYSGkIeGTS3qoBMGoozm
TIu0nbK5oIa4g2SClZE4JuDzo7GAo9uoo19JESOUnUKqR0QnpLUGef2XBFEqVfKkh94J
kDsKETo4jEvapYFkDlwge1WKBDwBTwUyCYiZd166puFWbNG3hUlwPvC0JIMSCUbKpni6
bm56fz1CaGHBQqZhUTvFHjXYlY7IoHmaqFpWbDwJKL8xfWy4JCTJp7cncf+4fTGp/qia
ylnP5oLH8aiKcQQzyRPVZalLyIdZuqmqqkydOoSfWiFzeiiS+kwU5X+n6o2Zyolbqmef
lkOKo6QaSYqpSGeoiFW7ipKtGZf9RHWkiJUrepuzKFPPVoXJgVPS9apeZYXWlaa6t3tY
VT549DS+N496dYxVl4wNZpLfekJ99Yxc2opliXHvClDLmSXYyKoIehAsZiANSHvXN3ns
QYOmaqiXmKre+q7A6kcxl4/K+kiLI0CbeZdPiVDHuXzoOI93aZxwUo33mkwQZ4dhdodj
Zhbm5B62SrC1abDRSkBQ55BNtGYp2WfhVX4NSZJmJVW6KWDkemQblpxz2ZsMm6zk/ieW
vOqZ8nU+HOdB5UifGrqbzCqRtESkYRB9InipJKiyccKW4pmu6WcwWPNAX4c+kCmVl9kV
BTSQ0PljEoZ8xfqs45m2N8SUoumUYSegEqiaUHm3jLOXaptKUgsGMWal3YKriDqOb6aM
sIa4Z/t0BQdcFgs7yLe3+CW0zLef5UmXwQq3xudAdSZn0lmcYtQ/h0c9i8eaCQub+bqI
SdiGt+qV2kWBH4hDQmezGPiBsGKRapk4bWe5mvmW7EhzU3Z4oMlNvxt6msOK7Vm3loN0
6vm5dim88+pIf7uId3pNTqVNgiOO4rKiXoKWa/tkyce7oJuOxfu9Eyu0N4efCth6/hsZ
nRc2naLbu9aZn9jpo3UxvYJYvW7jaAMKNB6ZrmJ1f0tLdsvLnq7ptbwDl1BLXL+5uK5p
rhRpvshYXGdJgYjlWAZ8wRvztWILtbLobPv4kv1otYl5mxBKQhI6gddrozE2Kb7pvyeM
s4G5wuQZoohXijf8oSOakqpIRTa8vCkaoknZTRBJngz4RDEakW9Ho1aWZ7JEbiI8wq17
qFi7qot0glY8pFppmIOEst9ZxVmcg02axYXJxTrArd8YxmocS/hrd/q7xnDcS22cdW8c
x3bMxqmboFU7xQV7pHf8x5s0xztXx4BcyJokyCdHyIa8yIC0nYQ6yIbEbWnMyJSM/rpA
iArRchJjusdytAfdWsmgnCN5PAZUWwVRKriykauhvMp0gaNUOxYGAWOo0BxQ8MmsfMtQ
4cpFssD0uclKGBmpXLi4PMxOocsBhrNDV6m4Z0gYoMrE/MxgM8pi8C6AMjUFlYtOsgHO
DM3c/DHSPLVlcZIEwrjjDKecLHHdnM7F/M01BaUobIHm/MvorM70HM2XLAm7gIdjZoe+
XKjzXM8A7c33rMfLPEfbEtAIPRGIHHFXyiArYcYQHdESPdEUXdETPdAErYfVYNEc3dEe
/dEgHdIcgNEZzbolfdIondIqvdJuDKYsbatRHNMyPdM0XdM2fdPbZkE4PQoFsNM+/v3T
QB3UQj3U/bgCRN0JLpbUSr3UTN3UTv3UUB3VUj3VVF3VVn3VWJ3VWr3VXN3VXv3VYB3W
Yj3WZP3VIn3WaJ3War3WbN3Wbv3WcB3Xcj3XdF3XPW3QL53Xer3XfN3Xfj3Lg8tzRz3Y
hF3Yhn3YiJ3YcODF26LYjv3YkB3Zkj3ZiWCDIy3MCZ3Zr6dBPLDNmv3ZI8fZQRhUng3a
pt1uoi0FZVDap93aV2fZo41drO3atP1wsK3akgHGtb3bs5ba2LXYso3ZvD3coubb2vMG
KbPawk3czL1cxr19GaHcut3c1O2xt01HjRLc0z0OnigipwutY6y0qjh2n/iEToRO/ips
R03qQ+L0oGOcie9tbc/dJLPdHvL6JhhmvyuLlpOamwj4c3yKvR/83wP+lmRExG8LtAYK
a9Ybvc933dtS39yt3/LIrjUnW/p5Qkd5Tw7mfQ1qjzSJpP6t4U0GnP703evlcPONSRLu
R5wrdUjlTCgcmlF1VGDla0hUo7y5dpPZL5QqX2gbukHqfczoJv7johjqzu563vjzooPm
5NIYlvlzKmFZeHHGofFD3qEN4Q7d4rvmZgSKL68SsH7lYGioon+U1DB7k8e44FOO5QMs
5Ot63jOZvWDLIfEb4EF5fiIJgkiIeK3R429OlrDlnhJ0424b36+tcgrgB14eJv1j/p5W
hLTIKORiXp9sybVsbuHKVz5NzF1J6k08vr0GhZF/zloOXJN8nsIF2sA2uyGfXunAKYFU
2d4kx9ktsdze/XVhpb29bOcejuks265V1uMgxWDHRbvFnsMdDuyKdkWlVU6R9WrOeIDK
CHWbGCNFzODgp2NV/jUTrK62guLSyse4bRFJE4y7Se3iGuw3WbsmqbiFTulrcr1bq+gZ
Po0D/r9TF05W5cGw3pxJp3A8+O1RQ5bR2zJHLu62Q+4NZbWYhO7nt0RsluPxDu/DHpXD
voxoITHSQubLuuwJaOxjV2EKL+vuB7MYqLsArOqRZ5RExSxCtO0fL/IyjLa+OPLI/g6j
GZlz5n53fkwPZ35Tpdjr/GvmoLiYrq6zyq6QJNqRxD7p8zqAXFNE0ohwMjtYV7+hVd+B
yMzqOQ/m5lntwm7xac5EOTui+C7fP3/QYaSJFA4VS3kXNfq6Z+Xwrq1BgPDovaaReD8V
a/8UV7+/T17dwKD3fjDJdXGsBA7HjK+rNG/4vYD4wbzdkn/5eNydklHLio/5nv/ENqjc
nM/3n1/6Nxr6m/8Etmz6rM9JiK8BpM8N3X0NodlBCm64B2u7Vk6NrX9trx8Eqy9Q9/1r
IC6QoXaeQweURoXFvc/2mo/XVxv09vD3FT6hinn9NHmQ+v6t1N/8fov60F/CWnp0/kBp
71SqaBOmkjf+YA458Gt25VNX/eWJcTQe996vj88/2uL/EJGp5lGZ7AgAIKK9aj3mmLWy
0crj/tclZRG5eU8JdqNasm8sz3Rt33iu73zv/8CgcEgsGo+yQmEQCCiZzuVgSq1Cn1Ck
9vVRTb4tCkZDHnUdqDDYvF551R1RKz2H1UP02mnL7/v/gIGCg4SFSUtNT4lSVlaLU02G
QBgxbiEne2IcZxBwnnKYa3FtX24VlG9cMqE4e5KvsLGys7S1WopRV4yNVI9ZtjaudGJl
XCkZYMRoccNllqLMo2wwwnl2LNXGwNvc3d7f4EG447u8upAB4ambpCbF6yDvyGTt/pfu
9PMkcHhs8nfHp9bRyKauoMGDCBMOIXfOXK9cv9RdehYQFMB/N5Q9c0YsmcdPGovJEZjJ
1cgZBBWqXMmyJTiGvhw2jORSiCZtLmquulgkpc6fQIMKFQITokxfNIfqQFXppFCfk3gq
nUq1qtKiWI5CTGq16xCoPcB6HUu2bC2s5XghTWe2rdu3cOOSRSsTHRaucvPq3cu37yy6
ddf6HUy4sOHDOwBrvcsWsePHkCO3VexQsOTLmDNrVkjZnOXNoEOLHk2os9qtjUmrXs26
dQ7TjT67nk27tmjYjlDb3s27N2LcVWT7Hk68+FxEuWJW1m28ufPnP4E/ZAy9uvXr/uGk
25WCF7v37+AFaZ+ZOrz58+iJImcYmHn69/Dj0xgvXL79++bpu8fPv791/dT5J+CAxQHI
XXkEJqggawais+CDEI7WYEQRVmjhYxN2d+GGHOqVIYIdhihiWR8ixJRYcJmUklTLaIEi
WS+uYhBULEaFXokmulAjIDsawhNAMaoyUE5LudhKED2GReRX4STZ05JDGofjQcc46YeV
gvyYggaTBANlRkaC2SUSVRqBpY+ElClmgeu1WRd5OZ6y5QTYSKXJO8KMVA0lXSgzDTz9
ANkJl2+IhGehyCS6CQp0dvRnnWqoWAqXflbZkUhosDIQnxixg5NFF50IZCmPMmUN/qEr
lDQMo8b0aSkETvU2ZUFq5kRnGNpgsqqQjy6zpa+3nuFnJy3qmGkaui5K7LC1VhosodO0
gawHlbRY66DRqPlrNCghiquyRG4r6KDPWuuMr7mSeiu2paJLLLXTttvcrBJ9GSywvK5L
Lq/L8stuvwCL++Wx6wqcLbz/vmvwrsLi++2P/GqLcLEF28riq+xaku/A7+7rccMdI1xx
xiK7GzLF95ospZvKebZfkwM3Kme11jIKMcU0m7wwtAnfTGnJNf+7rcJAhxr0s5kEnTPR
8OqLM8CKRunuSU5DXWy4qFCtstFNd02y19dOnLLVbJ7T8mkB0hqzGVdb/LSMQNM8/rLQ
R3MsrcMSB6yvtlWPPLatbQMuttJPD33y0l8LOe7Jdrbt89WLz41q0Y77mzIn87Js1HJp
1zsxsnNCDmungn4k+Ll3p7p3yJKPfmemZVI6ucz4jO46uphi+/PpPbPdp+67Z1s67g8f
S+3uTpf78dS2j7pP6ARj+nrHk98u++G80fsNp3CP6jPP+pCkZejxeOG82KHelPXBxjeN
J98BBaz0+g6bn8eroYhSaatQJrus/1zLX1MsRUCvkUtLOPkc9DwVvvsVzR/E0Z7afsK1
EJ1pRIORIDjA15IKYvCDmNHg9i44wgKC8ISRESEKV8jCgqiwhTCMoS1eKMMa2rAQ/jS8
oQ53uIUc8vCHQASCD4FCQmAMawcX80cRbWInaPigRiQMUhDlMsRaLNEWSzwiEbT4Cg7G
zYhrOtIUqVJFWlzRimM6Y/fQKDU1biFJWHLjGL1RxljoCVV8GoPpohavXvkuUE054OlC
gijVJaxOCMTYnDCWKE78yhTuAMnzOOKt9E0KVuSLWkksMkd11NGOoGMe1NQHOSWWy3+s
y12PNMLA/2EPbOmS29TmlrihpY9t5hrluf4UwMG1EnqX+1wnufHJLoarXzuTmeiWSTem
beyVqRhbwar2zJyNy3Aek9/8FBhM9hVPm/1b0sL2tbNhvkRzWeHcgahEuVrCknrC/nzk
FysYtm65s25eiqc+nak1A9qycs0MaDfJ9rZRiox+4zQnMdGZlti8bHtuo4bhpim3yOFt
bXWA5tfupjK4hTOjfQtcOQsny96Z9HLU3FpE63mHwCn0LAx9U328MTtMWq55tqtW8KR1
veOpoqc7utfPUNc+GVXPp9Ai6vJq9jrksY54Th0qVF3HM6Hi7Hqp06kwXyqLYvoIfllL
mt6+Zz+3MdKsNNrmNzVKqooWqq3xU9ihCurPuopSb6Vc4DXlEdbFaZSrpYlpezrHEnm6
9JhidE0W2zJRwNJRsItZZ00My9atenQ1XvSSHBMiz806Fgle3UZfc2CqTXl2L1KU/iIF
IflZYIS2tbAV0WtjS9sLzba2uH3QbXPL2wHttrfAxc9vg0tc+Ay3uMjND2TV6aDkOrdC
x32udKET3elat2yPOJtDCXvd7sqnut4NL23AK97yroa85k1vaNCr3vaGcLku465754vd
5GwuvpKlr37ry57INne/AJYVfNGW3wAbeLwD3m6BD8zg8yY4N/JtsIQ3w94JW9grFb6w
hqfi1dJeo4kZOdOLQBwWe6iWtH41E4qJSOJ8cgwlpz1xHwgCxThulosJLCwgQktPxL0Y
m/Y87GX9VdnE8SHFT9KDZYlMU6kpmclPftJpkzxkH+fTjSl9McyEXAQeWxOJbUzs/o2t
rLiOhkkWQK5yk4Ps5KKGkUlrZjOZg4xlLv+1G1OugZfNB1RK1q+R/7gk/453R1fN7M18
NYk+RDXRRbLKFKYSoM1syio+hi+P/ShrKBnN50r/z4NFPaIIapdHfPS1rbWrtB5RzZE9
OnqrhW7lpGEH10vTuoGJVlf5BsjAVYdS1fxYNAR5sGesPUyV1jSUmQ85vZvwskhvJdwf
LwrPjeKz2sn7NcgGOclvUc/Uptv2QAEq108saqTV5mVV7SoscPeacOcLNwRvmVT20VLd
OpN2u73tPEPi1d8/KHbcpBlXxH5bpDfLNzgR7b5I8zneijuruJziRLXuiiR2PaCi/q/t
N1Bc46lv89vDLa7W8Uk6mu3MWD9Tfm+QywniAdV3xz3Mb32z++Z21vODg/NQMFeT4Dk1
eCYPl6eVXpvhy6arsiLHyIQa++fxQiDHDfhlhTt9gfFcuchhbeZ/Mk7OpJz6IRWIc5f7
Mlf57jG46r0pgbp8681Msw4EXnJ8qj3ubRenp53eZr4rPaESh/vSNg7OlDqy7nQue0it
kW7Em5R/pfV6wjWN7q03DrHo3ie5Ca72f8q98D595kgz3wO6GxTvIH3gsrP9RdBH+WiN
deC2RXlK/fFO6N4EW+7wGnL3PQ8bRm786ffnQGnnEnOy973bnz0HbDqr5kRu+jdZ/jrx
gqJS3BglZ8ehH/CdT2fBSMzTqCdCD0yPvNTZLLiwL+lrXMLY0aU24aHvAf+Tq3uTDbQZ
qdUn//XfY/7/h36PNjPtly8C1H6rRkDNMkCsZnL/R38BGCnzNz6C9IDwsEn1xw/it39s
N2v2M34Vh4AY2ID5lxjetx3/1RcsBVh5RkE80IJHxg0weAsnCCeDwVqtNYMd5HNqo4Mv
eGe0kGEqQXOf5YNDiCJG2BNJuBRLSARCuGFQGB01OFNRWIV+8YRWmIUJgYVa2IWeNIU9
54ViaBbHlTSL1S1TJmNvNkFt1gpYB2ODUHRohmR5pwcXJGJZ9oNx2ChRBGp5MVzr/naG
RqViOTcmcRIlceRmWpWELQdtWwRlchaJaygmcnQxb5R0iQeJbwGIWmUkY1aIN+hzcLRk
ZAKKr2cTSJJYVxKHl6hlVXcYPBYPSZRpwOZHZjIGgRZLnBYt/ZZquHZyjPZq96MqoLJ3
lhZ/xehHIdEOmDR+udiMsRI/oiYqveJxkDZansaLYEJI2YhvBKiBslNrDrdv6jdqnlCC
mIZ/puhaYBhhbuhtbadH9jZsj/hupRRJ02dK+GgwKIUvXvdOOMePgXR4sAdS7qZN1acx
07YT/shRDWlvymd5EZdRJUV8B0eOrbOQf2NtNmePyaNsBNmER9BhVJeJBxdzRyB5/hTX
etiHe/nQKZ/ScBu3J7mkf12XcRpIdmIHdzBnZyGpk1e3k5xUUtAEdMFmd6+4N0NZZr/o
cHaXcDOnhn/RjuDniHlocWH3eS8ni065cFC3dB3plRJVSRv5dIIDfEyJea1HNpIHkJJz
VK8UdigpeFZXkh8GezmJeh5Vlm0Ja70UdJbIcZ1nlyxBkpg4cEi5jlZJmI4HdIhJdIp0
UJ93Vsy2eINpfM7HcnW5mYc1ekBplzzpUjNJivcUmME3fHZzTQq3l1RHeHTZEh22e2FG
bY1Yj7zHTxG5miVnWP3IlrHHevzImwP5lqGXbglplMr2eDB3nGlpe/J2jnCJkhWp/nzl
Ro45ZZHNx2yzhJaI95HQpysiaQSxKGg7AW66hgdEyEQiiH/rOQ+OUhHvmYxNqXEeaIHS
6IsgSHGyOAqOMloi+JLomYtUw0EJ6H+LtJ77J4GCFmnoSWPkt36l04DAVH4KWI4PGimW
dCnvOWgIqpgwZTb3RWApiEEraBhXFJ5KgaLOwYXYgYOIIYihoaKZA6LphF8jSqJSyVg5
uhnpCSEsOoZA+qHZFaIKdqNBeqRV8aNIuqQ4RJVGyqRQqhNKGqVUygdTWqVYKp5OSiFZ
2qUIcaVeGqalt6UaIqZmug1geqZqOh9kCiJr+qawkKZwOqdyOqdvWqd2qqZ4mqdm/rqn
fBqmsUl+gjqohFqohnqoiJqoirqojNqojvqokBqpkjqplFqplnqpmJqpmrqpkypEbWqI
f6qmS2SYp1eq/3iqj2mqqYqqWLmqrtqqsKqqscqqslqrtHqrr2qruYqrs7qrvtqrwKqr
wcqrqCmsxjqqn/oDwWRVukM8zfqsyhStxiOtOFWt1XOtJMOs1Iqt2jqt3mqt2eqs2xqu
0Pqt3Cqu5kqu49qt4Mqu51qu7Yqu8Qqv77qu8lqv6equ6pqv4vo79LqvOIWsNNpQEFaV
pIVU1pOwUrWwCtuwDPuwDhuxEDuxEluxFHuxFpuxGLuxGtuxHPuxHhuyIDuyIluy/iR7
sibrsZyCshjbfQMrU2EoRixrYjTboDabnwmYsxq6sxTKs+7Zs0D7s0I7EUNbszjrs0Sb
tEars0GrtDfLtEX7tEi7tFMrtU1LtVdrtVF7tFnLtVsLtU7rtWELtlgbLSlLsUAYA6TK
stAIjeF4J+YYoHIbt3SLi3Nrt3ULt3i7t3rbt2/7t24buBQquPkwuIZbuIh7t35LuIoL
uIfbuIybt46buJIbuXw7uZD7uJWruZdruYvLuZ+rKCt7thHrskNaoyLKpaJosjIaqhBS
fgRjPZcSKNaYWTiwtiKLOZPHdVa2uyKlZr77db0LvMQ7vMbLZMGbvMWLvMubfc7L/rvM
e7zP+7vSC73TK7zRm73XS0oTmzqUJFWma1+oW6SqWyRs61erwzR5o1Lqe5Yn5b7pu77v
25okRb/ta7/yG7/wW7/sm7/8O7/9u7/3G8D4K8D+O8AAnMD6W8AMTMCz1FQK627kw4dp
+wK4O7K627zWu8HUq70cjL3bq8EdHMLVO8IfrLwlDMInLMIqbMIu3MIwjMIe/MIyrHe4
dLGGJo8QLLCnS7A8547buJWGS7c3NTzGcsTF6Wbgs8TwZMRJHHRQzMROrMRN/FNWjMRU
PMVRXMVYvMVaLMVX/MRg3MVjLMZcbMZffMZZHMZrTMZq7MVsDMd4STsR7H7cuEs+/mCY
C6u3sntVcVzGbYzGf/zGgCzHguzGaZzIg6zIiLzIjtzIkHzIkhzIlGzIlVzImEzImszI
kwzFRvU7D7uMvIhVnvqyg2Wwqmi3txOwJeq6NiStOxzBHJi4njx3yfpEFZGx7sdU9wqw
+Dqv9vqv+jrMvUzMwlzMyHzMyhzMzMyvy+zMzQzM0DzN0lzNv3zNvpzNxvzJdBzKuNKg
sFPBJUCSyVCxlOZM4uzKG3Kto9vNxyaoNsXD4uvD3/ekYjZUJtbHP0Z7Sbuv+JqVzdi2
gOa2UdVs2pzM0YzN2grQfGgP1pytcfuz3aTQxQwy+KzK7onQ5oqLD60u99owxpzQ/gd9
mquMzwkLj2wmz/3FXOV7sOJY0sZCoJUFztDWY9RESACXnTSZzqVYCFcZPbd4l7W8hEk0
oQzjWT9d05rF0xAFu+DLsFTVavFcyj0Ms0DsYqAciD31xPAKLE7FkVO1bs361PocO+Tk
rSFNzV9N0f96v+CL1hqNraknkWld0jWFsM2zxHW9U3Ktr24temo90iJdU/0Wu90bsGPt
oQqgxzqNPxRsT77rvajUfFzJ0YF0nbjpKQeqjbs4gWbISaDyarM8aEL8ccwg2rl22ctk
SLvYsyWISKJN2dqGOh+xocKGMpqNn5Z9ac5oi3HCtUwLtMLtbGNqyv7V0ve8x6Fc/pYq
1X/lQ9ikJ1QqQmjTVn0qF0np+NinhJDOlpDQ+kggXa2iwz2izMp8c0fY7d0CqSrn3Czl
zJkeIdVn3VnsIN+UlVVJZdEa3dGJCd5E5dRtK9VkHb4rbaPIHcSEjVT3nZZRxn+y6dWq
LNYNxy3W7W/v7ZuOk75AfXj9HNCt8pO/i0eQ550MaVEdOCl8dc43bNccjUcWbdJ+5nxy
Kds/ydfmKC8Vp9ioSImuWbyqWcuvcctKksukTNs/3jU3jdpHvHifJrcY7pi1Jw3PrZHg
rZctjs4rXjH//Xhefd3Yna5KHG683D7DxncAFOMBucfAU6wGzcsLeNK5jJDMs81a/o6u
SkXfcA7TY2fLxs3SZSpmiX3R36pmZcbexL1plIZ8qleZH0PXrmc0JzIt0To94Zx+MFmb
oPzoW2wHirZTwIc/A2nY33wqwSnqGSmQoq5LcG7WeNx/qrjjyro+Re6waKvSbnLK9kyJ
o047DX17YB11pPbdoTea6U3dfRZrhnZ8/KfnSlmNaCfWyYnT/Vlv7+ONLw6WQHVQjT1V
6fd88Kbdut0ub7vi2qfT5e7h8Vzb03dXff3r1tbXsXy+4l3cVY3rB77UizbV0pPUIRaM
3ESe+fx+XzvjctW16KehvN3ihgLgIOjZni3ixE20gpSfL0mLDzft4Gjb2VDOOoyM/pFH
e7Tb8PQX4cNtoE2ua4CEZqTJzaZOusFD7/Ns1ai8Jple1i010c56k6znikf1lwwpjYzJ
mogI2J1omkD+TkfehgcLkEoPb8MuvcpU9DDpik+m4VWvm8Jr1uW6rIEt9fz8RzPr1LZ7
A4yd6TC+yn3XhrYbiMWZWX445x+/Mcy9llwG7oNu03seznjOxOJt9UwpkSFHk/J7ZXYI
0HUTVafIrK83+Cvf0+4LZXAl7wpp6w1x3H9O8/EO08nS82FMfaK5hquj9Ubvh0HFvn1P
0rut9krG72joYpDdmXoI9JeHTDnPO/wuYtpZ+nuu+6p51+0+boEJ6eaS+Ri8j1Qd/vP2
fvlLneCCTo+niM43Xb9M/sG1r/WKGJ2auLrYRsVNn5h5z5eKSJQgj+VXHLxrxPPzzpFQ
9PpxOd5hKQlR38UK3vIfu7Ksr7ZCHvvtvOrrrp3Pv/sIALq8og82ECmLdcrdsvSOhV3b
aJ2mdk7ZU43ey6pryGkuncM4Sd+oX843TPlKH+GvJ+rYVDtgbZa0yYLNFI83tTJbgnB2
HC03Ka5hd8koFAaBgBsufw/u+Dx9TmfrgmZlYml+ITFVSE5nXkYzLUeJjRwgIIhQl0yM
N1GFJFeWY4lYXIqVX5Bch1SSppitbGqASKZqV5yuhqCKkJ2vf2tYq1tkxFuDZp0N/nNx
y3V6z3t2ccm7YcOCH6nBnpilv0qSU4+wm17m3qqHWn6ttaNKu9TkXbZP9sCo+PcmRZfa
obzm+RIoZZ44R6KMuHu3ChcGa8Ui7hCU5pa8ZhjtQMPDTFoAeYyuZYExUJS3cw0jFTRZ
g9IZl0tg6qtUUqWqg/C2tQzGz6aUdfGAjCOFs2dAhyDvvQs3SdaKgUaB2ouVSWlJVjpL
iJFYhRNFNEo7ZYy2MU/HO9OSygg0si1DmpEgpoN44erKinQXQclrzajQI+7Sqcy50mnA
WrTyQtjKgl87hE/6KvZUE5Fclk561kMJTyphzSBjwaQqM9fLlKgnJmHLOtSgwmzG/p4t
i9ZZH7XZVpMhWYgp2MXrGIvYCrquzoeZtBD9NdQX1ZgmSevldjPXJzS8ozaNfnCt1uNd
wT4Pa84uFXS6oG8zr7007Eeb1dMq+FBk69Y7K0+QbZv27LShOUCcboH0088pw2UloD5r
IIcQMuNA9puB3TxVmDa+wVVhZjhtZ9h4i1l23j6yWPTdSSe95psmqE0HzlIzWYcZVNyY
Jho7mNmYWl9c3bebeLAtwR8f/tkGoDz2FcObfPgoJteTPNLF43D1LXcdX45h1xJxx1Qk
oGTYgfklDsdoCRyXUqoIZZVfvvbgS16GGWWcZuIlZWTZeJcmmnUJhx4wJtITHoPM/hEq
ISnXBdlgjjoStkmSPkKoW1JDalTWfx/hBtykEy0ZH2QvTPlkiBNmiYKXN1IJ51+EAJQk
T4Z0+RSGa7kJ5HbIfeLgP4REaSGs4uWa66wj6XqiqbKexmCGHvbGooLn+GXQYTO66F2M
6zV2GZRyzinZt+AaqkKltNXGx5HUUNgWaxGi+MWopW4qZplpojTlmameOquvk4RK6oBa
TcaXsvpSuad1YCKzJcGqGeNaiANaJGq3E2qJJsBNzpIcQcUB6s9PQb014orjedbQK0Mt
yO22qrJ7q37KvHHWbEWem2mACT4cZ6vXjtYdvclySbFwrTryT8i1/jQsh4t49Sup/sRu
C/CBQoNMn8au5pZQggo1CkY1Bwrq9LIdahegz/MFBSLTV0NLo4s1miymh4kaex7Mbcjs
DM2XGnkzkn1yBQh7OnxdNbz0bhp1tseWE++wodKpl8JFN0c50Sru9d2rPTv4eL8Pa5y5
jDcCtSvU4Uh7VKFOYYVyOe0OpiGjzTL0sbiA3bpTiViPjfcC5JaLaVL6Qgqkm6qXhzrP
u6Ia8dQYG1fvpAsujyflBUPsOdXa/7sPnzwlHf31UWdXfH26t+5vncGqhnqwRHSW36DE
w5Vo2xnHT23Y96dYqLokeZ7FekRA3O1Hb2MRnt/qdypICZAghfPVqOh0sTblCU5Y/joT
7CLWQPeJ7XT8upfiesUmvBhMXnUS1eg6VQQ1yQlfOXMeliLXqTClsIUwtNjr1lYTDA0m
Kymr3bPuMqJeUC8lv9Oa0yJVwCQCIHg18wgDvcfEiiVPZEVxnO4WUhXWhW1D3ahb05AI
REuMbSru+lVpqgOVFcVPP+0yG3eWU63WJeNtqyNf/rAGiva8B1pbg9EAmUhIgl0EgYgs
F1lugzOeSWRJI3uao+72m6p8USQ4MmToamciOuKiA0AbYR6PwsZIUudEsjOO8hinKDC6
Em6flFbHHOdJ/5FnUXekHR9vSRnjFXJNrRxXIvm2keFpapBKqiEre6C6o6EKPN/4/sMV
X3lLw2nwjXUck6oiyb05flJCZMJKPsQVR05Bs5lt66YRX6Qok5nSZ5qYZu/AqC6u+ZKA
zOOlkIbZn77ZjIFLVJJpmNTDdEXTdoFkp19myRI8rnNytgxmEWuEzW+msX+8k6QBATlQ
zshPWepo5RdJtMyO6pOMTKKoJTn4y90804lQ9KcUj3knl+2MfifLFq/0h1HypMyNuXTJ
ZkqXyoO+7k9WMimzrHUhiz5URG7DabXk+NScwrJrjzFptNQYJKoS8YOZa2mBhkEpfhJJ
prWZ4mlclrOPZrWdo1Rez+Iaz0E1gilv7eIPcUVLg540jR5Fp6CAddeQ7ZWaErXr/hhr
iSBSQrVFiCVrJjVp13v+slcbzRtZiAkNYzbyePgM3VHdI9h56pUcDFWru0a60KiqJ5Zj
7Ks69QdZjdLuMbhtqix36UMnolScdpOfUK82UluuTaWgDGto2YVZmJrVUsVcIG5AKNC2
epGejnJOeuZaGdOZ1qPTyiVXwQNUXIo3bXnd5SnXy6GsHte2f5XrVjOLLZ6+tqKwNWxR
5cvS5SZzgGXdbD+j+0+actClWqOscVlmw7sWV2VPm2EDmybCgsXOtFgNZHkBq8nxiQxE
xWXtR08LXo4ilKJDFSLSyNgxdLrXjBAc8YNJ3DL/RsqRAZ7ZgDsr3c+KNX3oaQf6/iBm
JhWzpXDwExrmQJnF7gBukn4ECG2ZxpgNy6ixtL3iJVW8OnmWsaqU/RTxJqpL2OVotgRt
aFf6W0W2WvmAAj4rgWeKM/Yt8YGHjdsWi0w3e1UvFXri2oQVZmGl2rFrOk0sL1OXW2A5
tcSPDks9iJqxEFv1OTwkG/fMhmhMZ5N1bo3vVKdmY2K8L8d72/EzPPvkgGJ2cH+80FwK
rUodhgvJtqKEcko0QRKC4deR66WS18TClt1JlN7i88bgq6Degjo9NPYynsiJS/QqeqIv
/kyjcvpWP8KzTKAFzY+dG2fo8rjAda7pWpV75dytykDDdZjo9iqwB/rudOfzdeMO/gfa
BOfaCthwN6krydhpp82gqUPQlUSq3t8+uuDFcSZfP4ZoIpLs2vrd5jVcHVr6KiCmc07r
dAlU3Vczkx2JeSzA+bWsIftpvBVbF8GnkzhtYpNCDUtY9qp0GSJ3teHtvfLRWnRx4gLd
vjQCrnDH7CwT36/oHlsrTtvTpap3C1zElhW5dSznc9O51VYs+czTOQvkVe92rGjevGJb
IO/5e96r4d+foQZz6FWjkh21O0ib/l6/ipPKz1abROsZ7dsqltNltiOHWytV8TKz18C8
j9QYDBKQe13kdUbmje9Ozhjc1MEv42qLYSy9f5luIXonGt15t8LRZY/IlCbsKWaM/vpV
AjWkCqdkdXR0e29G/c2aKrhPMW5cSe62pz/cfeJpYPlV97jVOP+RdRUqFA9W2VYAJx0s
SBgrt3yrT+C+BQirDOuFYcxP5Jc35F4Ir8aDk1r6Hbq1D2reGdt3j7UtvrhJPljblzig
FrJh/RNAgZE1grR3W5dqXed86AY41DVWMXSA+WAnsTIwynQv3yduVZd1fVSBV2drz2RD
IpiB7VMqapIsRVZsKFSCOZFw/UdSeER7MDY70CF8U+ZJksV0NZhxS9d0+TV/vURyDfNI
ppaACRRFmPdkdhYRCRZj9cVlwdEh2FVt1sR3F2VA32Y7FVdE8eFVU5Z3Uuh/O3hU/irl
hZf2Ve93clGGKIwyaXmGVLLVZbo1QuMmdYRGDc2nB6zmd8vlQnBHg0ekUX/HhYwTb9qi
IYQnh6lhNX8GiHzVhSM3WDTYaVPILIMYTNK2SlO1fD64bGBnYnkkGBFVY6XWUqh2hGjF
SEqobm03fZN0VYsCiJDoSjtkTs5CiV8oiSEhWL6VSm70d9oFKsj1J0QHeEU3dNjmgzv1
ZdKBYaCIRXrmWJr2OWIVeci3T+WmSHsYVFQkdmb3KZ7WVMW4aGA4PxvVTellFYw4WXWE
eM9ojIt4f1qljhzlgrCEdAj3glTliPknaryAjLcDW432a6zXcfx2j7HxXNr4fHxY/kFY
93orFpEBOG3jRG/JmF/vqGapMlxeA1GFF1e+w3D3dXJXmFKIaJI44o6r9Q3gaBijiI5/
AUEgVmZ0ZD5F2Ic6lJFwxnXmxoBf51faY0Lug2NrNHEZV5SxJniaSGaCJIpM+YLDd4PQ
BHejtI+85ZLSGB7H5YLIB5BgZjXXmGb0F14AKE0imW3JJVCEVFP2l5DZqEAN6HdnJHmN
VVC7w5Ff1YyldF3u95HjdWEVd2FPeDbQRldkc5eGqWVRp2BnKHFOJpaZaGl2yIPsZZY4
+EcmdJNt9mrYh4cKCZc/yY2ad2RlGWrusV0cFpV9RV8+lHzKiD8nKRhuCCt9h4y2/vlp
kkaTMdl3OqODEZmJgBcjMDOLA4mJ1cYqylWNiRMoYvGZSKiKQJmcmvlyCBhBThkZ3weP
ORSTyaVzJ7YXntc5ytaPW0kfMxQhNHR9BHlCXYSBMAeRELaFFUaChMJpN+Vo3wMjQ4YU
5lh79BeW84R7ZrmEkoIfK4OQ2MiTCxmX56V5THhGv1loecU8HqY53AlrcxNqEyZoZHKX
4aiL+1J+4Yc566N1oSRKG6R2NEQsEpiWN+R2kwFpjWFebGODesabr4iV6AmNDihln1eK
JahkxJOHZsGQjmeKRRNYMaGXu3M88BSiw5gZQqqTBchJ/ScTMSiMswWAQyUVYiRa/mhE
nXOHLGtWo793Yp0EinOpS1FGXmiIcYg3nOEGpM3DmH5ApBxhpOv0UvgEmBPncih4PSX6
onuSbFK3eu4JaD6iTT13dVZXL+HyNa/HRbVmORIao/FQWIYGbxJmGW74jcLCLYyKfb3W
PjynLeCXk2Iaf88WjvsnmgtnQf71oJXpmW/5nOhypJalRHRFE8FGfh3qJKaXT2MHDjgE
YDNKGQ0Wc0uza9wXpD9FHf7ibMbQQrVSWt9ofkBmRbEKqd0nOvoWNKikRs5jemV6bCU6
cNHYhmkIf17pbnEnhIJjUwj6A3hqLqFpROtnoHiHmB7ZXEuzi89TrvGCQltKkKRW/jmC
5mBEmX4Mgz1N6pFS1izI8nkHJ4hlCKPDijwrCm7nM1/iYHaeGmGBuHawNwpPepHNaFWE
6VoGa2P8CnyapaCgmYQNKZ13toV3NK0Xs2TnOWyQgxju+TKew2Roc67+Jn7x2RQbuTCI
mn3NxbRPVyxDe5BMeHaydJIG6GoUWjwsKixusSpBZ1vHVpITWpgc53TIySfE9oFY97Ye
90TOmYq5+lRsppn782FOSnfqUEK6FpSBc7FLxj60dqzAGnoRqLBUKRrwMYNlIz04hrKE
aEY3kZ0Oc7jw0azs1lbTCmFO5qXjyq11tZ+5CJZc9p0NSZLcd6AsI0Eyh6MacK+L/lS3
fLectPpyUFepAUthxqZvn5OCu1lDZRu6gxqCRDl24Tp3/fk41OV9YPtCBfkoPpc08/O8
mDupoQq51IM+2VGuDgu2VWNPz8qsFGeYMvosZjh1wGulu0mRRphINQudsLqrjnRwP2WN
TydhGKhC/XUoTpJB5CqUigOCorqdhKp1FNNB23mqIriCk6eI+1uo12KCCpyBjZtFG2hr
8kKfppowrMsmDpyZR8tNPuFwNJaaZcdFrVnCWJkMsruND9W6GeWKckd2G6KzzeGyXDmS
UEaPS1l3RjmOfCSbNFpUjHeR60iGoDd99hi3vqmFFAlIp5mbhlJY0bd4dha1ENh2/m2Z
oArYk3qop7e4sH3qj2fWgZMrvQ+CqQMYZkC3cMo3UKcZm5Z0wyNmvnX8oWGIe23MnsMX
OwW6SWnbU8E1Wkr6nvx1woBFNStkkHgLuzv5xQuar8pYSLmRYlIsjn62oyHEZNyReO+F
V5O7VO46oLFqpthyweoUxysbsfVqf5S2l0wnp32JkTuYSY4YmD9nmbxah418ivCLq3+T
j3PKxf2qr0Y3kUhcutU0WZoqYlP5ymY2j13MtFWMm2TJlOUkh8cIlZm6baCbhfWKRdl2
mag7zoIJoVEhw74cvZU3tyEnvzHcyNgzcKXJNik5yrOnzEGks1+JYm+ymP94mFaW/r6y
l4OPeXQXbHj1iFJwxXl4vFiUyZx3jHYBXUoOtYvy2s4UfafwfHnyPMZNq4ZJlFQ8amj9
qIQwuHd/eZgvEkSmPIf4eZy9KGbTiD96hJG56xk7rViGFa3zB6E3ysPfjMoCesl02kRD
+tE+abO6Wp2BQVbv+lko0mh6m2FmzIdNmruBSH33BdMmjMj6fI9a22RyWjKU5NC4k7I/
7cPCqKFD5MrqGG93y9ET68JMHcYMuqcb/bq/422Tqcgd9sTRemh/GE1POsWHt3SCmdLw
OorUltCR5YsPF2l/ur1kNzsL/ZRoyqqGzKqpmtSL+r6LJMxqNW4wqbYNen8FBZM1/jlm
b4OUWIrBVujS96yVcI3PZsikj3mxTabblUZ8FnWducnb6eWf2olcGWbXbbbUt0q3w9yg
qE3VRZlwWXrXWs3a2eQ60hiM/xNrAIrPWvrdiDXOR4nGf5yMonyo3iWLiE2PsZ2YIgle
wNbXzO3cNGvaNFWKm/aGJIVltnhSUo22rClEmnrGLhmZbrxVr33N3TzUjWnWRoVfbg3g
E06SE6hFDt7CO5o/lAqEGCra84rfkhy/tIvLdLpb+sneN3nXbEiaxSgxs4rVykybiNze
pkY+KQbIK05ogfaq1rxlwfnjmM0q5gTjfS0iMv7hSq59eszi+4fVBTh6rCjiR/bO/s8d
zyduEHUoeq6ZUGj0uV+Oj6NHelB8gFum4rPpmCwiisYiWTyd3IcFy7itkpzR33bT4TrK
4LkThSSryn0+w9vsXVLon3rCzlZup26Z39A9Rb6sxWU8hFKDYJsnwGtJxrYr6Wr5uj+i
6Zclecnp6UT4Ujhb6qFOgo8eVji76ZDOXOH2FZeF6cZc6Xv76ZjO6t2IpPZN4qio5dE9
z23rwb72tsTOgd6ygVlX7Mta7A8p7MluwczuqMze7NMOt9VuMPhb7ULp7HMi7Szkunai
7dbOfuJ+7OXuwUPD7edu7uG+7hTo7uqu7dK+wTJEwPEOyTGT5SC95fIhvIOE7Cl+/oLv
3rqr/u1D0yMCX2NjBeocDe4If2MSFHkPz6cEr3PfThGoHvDJ9umPvuwPnOrFhtrBDrOI
vvDrUu8r40KWbt6xm9dFute3CO8yP/M0X/M2f/M4n/M6v/M83/M+//NAH/RCP/TuHrcv
LMb5rOHX3GecGF7aHcPwV5FdScXGF8UvGeYznW7z/VdkqKFH3F0JZb9jXtNieI5iCPb7
5d1hGd6CTZn26vJ5CvPOjNtJXp1eHrOTmdrNHdgSHaBgWqWtiUlebtg97shRHtijnTVX
TM5+T6tNKchpD6QtXZBIzvh4b/ktHn0hqetVhOWM7usAhfCjLvqxft/MjQ2tzt+J/p7p
q9/6ps/ps+76q0/rHf/6BS/7to/7V3tI+t7UIT33Iq/s7D7t3i7z5L7ubovsNV/8yK/8
xM787S7u0C/9xP/s0N78OD/90D/91+7z3J/y927t3U/08k7anOX7/M7YJP9IGQzxpn+C
JA//Fq/xVh6p7H//ynn7oI7/Jb/sfdr/CCCgvM4ivglju8vSjbvuXOhJ4JiZJUWKZ+qy
b6k4QG3fOF4UQxDsvR9vQCwag8Bgbsmc0WzOXBTCrFqv2Kx2y+16v+CweEwum8/otHrN
brOjXaBPLjzakUNfOMV6UGszDU+DNHxwhYgYiIuBgI6Jjo1SUJOQEyGDjZqPipJN/pGL
l52gkpuClJajjKChTqWhqK8bN5uzpo+cuTi1cDF9ubeQIISyxbq8pJSGtKkwzs+uYXTT
Q3dFc3kBe7HOVBKElbhcp267W55P6GSHV+zmsO7ga/Fa9Kj3S+zk4fxm+u/29oGxtw4c
QX/jym0DQw2PNSPYiOgZyM3Xh2iWMrGaIk6ZrlWqBJ0yJo/gKFkfQbICKA+fR5bHPIp0
GcwTOZI0V8ISxqyjymY6L7nsKVAcR1y9gClNRxTmS2NQmVaJdnQmRqT3qGJdeZBJw4gP
JdZRQrEbJg0J2+Xz2a9lmn0z3Vr516VoMo2HisYzORTLwbxN69XltvBlz6VriR2W/ipX
MNu9fsvezZnlKmPLh+l++To2LNiJXzBazCCUJOCdehH3RbaqWVK+MYVyja0u5ae2Omtl
bhk3Y8zTj5eKlmo3cNTKiwn/s8w37vG1VRXP+tk7OD2c79JeZ6uFcxLPY0F7eXXBwooK
pJNP2n46oPSuaFg3Njw1skHCgX1zt1kJcuK+peVXGEvowGeLUQL2N5dxod0mkDvFDcjY
XbAl1VptrXGXhXfVPPSZNpJp5UJ5AeqXYXYMJkjbbxeKMpiJTQ23UysKvmhbfTBFh+KM
ALZ4Io8aKQckP/49iJ9c/KE04X9A8udjgeqpBeN8icG2GQ8RgQVeEuK9KANH6H1j/iOO
YO4IYXBRbsOaZkwZaOF296EEZY4d/bXejjcqOWaCVu4GT4ptsVkdgJqNFOhq9v332lbN
4eUjdDQyhGUdWnoYHogNYmWVCIYCdSCblOFnnnnZrZkRhvmcd1uK6iw3apVitqAoWlDE
aih5tNhKawWkBiXFq6MqAiNgukXKpHuOCkgrJ8vKulGs6QSbFZ+TBevfoS6uiqNqd0rq
UKXWfLjQiByQIKaBUr6ZHF3ffKDhOXQWsoJTQx5rVCDVAWuudaXM2+C+fvRyLrHw6JoQ
duP9+dS2vsqLob/NKhMQvqDWmaofsaXUFWaeuiWnNJM2FJZDZGXaxzDtKiijjEyG/lpw
hSsqFvEuTqbZ4lHhQPvUH9D2e25603pq7rwpA1Ieqsws+3PGtToY85nIzdlzJkb2CrBN
KAds9GJQQrj0gmb+RFyieuLWXchoj0xyl9rJRBoKRWuLZ74yI/ozqWjt2i6vJxhtLcX6
+k1xCwJ7M8VFQzsbC8/CJm24vFrrHAm+uSLlysCDv3Y14pMf/XffteZlbXr65o05r69u
vfetmvC9dzuXk5j54W+HTp166JL5bo0cb8Gh2uJShOstHgCaIdIVmxO73m+ft7m0RQPc
tOB4Ay5twH9L/zrp0ZLSHsbOcp6ybtu727nVm0vMs9/ND3p134k7bzjqhLdfv/kX/tkP
tOryk/7+s5XjHPzCVBXJESlIpuFW0oQjpSt9qzOW4hKmEna+0VlwSOgqlsIeNj7b1c5+
7oof5bAmK8YJ0GD+S6EKp5K42QRQJAQcIWSABboXTq6GMktf8+63tR2ubns9HGD7RMi/
XJkQPQj0Buh0SBOiMY5919NZmE4EnJala3fK+xEXfjey4P2rG6qSnmpMBSc8KSduSzyd
7HpIw54NrGmPUyEBqVc78bUidv6DXvgoB7R9ja5ygHRYHjsoKsQ574Pg8+PQUofH1/2Q
erqSoenYh4/BpXCSeqFdC4W4utzk7j0I3AhyXIQsB2YJguG6VGFGYwIktS1ZC7tY/pvq
R8lAOvJwI1lj+WRIsyLuMoipap3qyJQ/TCpuOPQzXx+RuKr+7Q+SzMLeJaH2vz360XJy
ZCNzpJnNiBWPl3XkZbOEeZyb7EmUVKpIj7DAxS1lQ03J8IVsqMhAsNkMGG/84dF2GLn5
PROIIOTj+CRJuBgmEpqbxOcfBunErRiRf1QhpwgF9kIi+uuDvyymL6tHO9spcogFfSPk
wlnQAS5Um4tsoSF1OLPGlEls9UJn79Z5hXZG8J1lYWW50jlKusWoThacaOiYecxFdg5j
gIOiUSGqVJMydXn71Ngub0kiWBXuqh5l3lFr2SvUwG+IrYtkPoPK0aSib6w4nOQe/qe5
zNTBUZFUHWoIETSha/U0pjqKUE3TBq47eJGC8TSLrViEDDelE2r3WdJJ6xpIe4LNQqU6
EtfSkkWHEi03blugZCvZspXlCYZ2cxpDcWibh1lsSYr6CGJrZsZzMtarotyYwqzoO76i
0q+qzGn2dqtSs6mlsLzDLG8Yhssg5fBAlR1U3fxEr0XpKTWauuhkuxVanM3Tt90KoTnZ
1YSo1pG218Wd28yprTkxl0BK+dhwHcsedDbTvV6waSolCE/BkrKyQStborD1U3VWsqtI
aqlmI2Pdhs2oij6BCxarJN67HlBlocwW13YVWTqVzpun/V5iR+lfNKWpcTR1MHqH/oI0
BtvJW6f8zk3Fssownox7D35szOh5T1ciamE6Cu+jzksvEtN1s9zlyYYjJZ8b3wi7YWvg
2Dic5JJoKEkOpWmOyVskzSbQyR4bMKt0fGVTUuq2dvjrYHQpWJwVeFPxQVHZfKoxJVus
xFE2TJAbVuCwffLHAxJWlenqHPrIR7bP1VR9zqRXP6nLuI6FrxoUPFv8OgbBC/aKbVU8
X5yazMV8AN95YWYqCQsXUo5Zl2XBi1zOphbL1GLacp6k5qc12mnJA6yDNbgoAmOZ0EwD
ta1fS01XoxnSrZ7nn0Wrxdo+kNK4pa/whhmDqkJXpm+xl7D9i2BgH3h3kFVuj+1K/lwP
D5qy3d6slrPVaQa1imEZjrO6Z6o7UE6J3YSSWz/U1SkJwTnEVZBvsi0NWKX1aLEJtk9U
+oy7P5L60xXkkWllk9DsJnhpXUupJWspCul+CkEaRG2xrf0J+NR6yTL2sWrVqd/9qohF
sSxtm+FdI+Sa19wG3tCkO1RpFi87aztVIsZNfIbtBvFuiTXS4qybcQxy8shWtbE+4Xo/
AA8WXiFvOYOnO7yfKonjmS1UpL8I3JPH/F2ITZiTsC5j2aL4y8gOc24v3UEZ3FDdOr74
ksP+1f3Y+L8wPfma4aSK6U0GkLOrYSQFaeaMlRxV2o77oqNU8tYmd8ZFhvrjsyi1/p2P
rcv8FRKuOl5PL4vMnTb/4n1bCfCg9djNhV/c9IoZ1vkx/atmnSPzYo898ZkQkUukpHP4
2FYUIpqCqbGLtvvcKfWSF+kjP3SEuJ2zGSsci3fOacDp4yXJx3fmwFt7v9uecxgDZ+E7
JvqEnf65/IVUoW/XX/aEmEYPLp31y/unG9uv8zu2muBwXj7Y7e74f4tXuR+nOy81gL+X
aEAmWV3XaQT3bTdGPPyHfyBzbDS3b6EndkgFA8JEXRC2YHYFJliTPnGVTE+kAnIEThn1
VtokOMOUglXld7TUR9F1b7PWct/3gFdUIuZVYvcWeUwmNzVxenhWYz3HLalnWIWG/m+S
JoHZp2xsN14keIFBB32epmj6IF1UxUgNNUfEQVArBXu8h0lTxUzXA3jTcXsBNnku92Tb
wlrIB2I8tU7spme7toCjJoS+cm6Z5Wv1lHhKpmFtuCLRp29qx4QWCHuckn79JyQMiG4t
+IQfFU1DBVFtt1C3VIIUpz0ptUL7A0MdFS0TRx5xuF/FUnRTN2IaOHd8FmXDp4gZxGMf
h4erhW5DSG3VYjYEk2WJaAWCeARiRllA53br43NTkmtFJjqXo36yR0IoJXgcxYKl41TP
OE22d1J684GNBRDFx3MFGG/FNoXiVmcSkoui5T4+KB1Rs17LBYFCZodR1xuIN3KK/rdX
SthF2ld9c+V2miaO3ciByvNHnWRIXMU9U9NLQgV/JfRELPVRj9SJzIhVo4gshrVBUMd3
zWdqJ9F59LR5Mnhdt4ItaCZ1kGWLJkdujDKLoXZ98wh6JbN9TuhsMBZKvcMymtdkNSaT
3wVFeTgfVzFndahYFvlsR4iTWvQc8nYW61UbVQSOJnNwIWdaJyZupzZZOeZeUBZzIamH
66iOb6gD2EePhDhmOEku+aiUASh15bVcijhcAGZEkuNZl2F6FfaWzEVRImdlx3CVXxdc
ULmB7IVoUyZksGhcFxmKGxZoU1cz+ceUiWiY7Lh4Z/d5K7aSNvKL3WdxNolrToaY/lZ0
hDoIWxsZaqT4W1cEMWbJQjTCXXSIGzbpcOZoarIocO/FYavoeNkYfYomkT+ykS8FbRrJ
ii7keWnjlfxmj5jmiN7Xh/UifFG5cEUXmmp4X6w2g8OCfLqWX9S5lwtSeWiSmEP2PX5I
itwpg9q5jyOGeY62daF1Kkh2krQViF2pkmwjeZvigPnYX/7HZakoZdimdLPxmfuJMCLm
cGuWi42Hg3nZXkd5bVnWa631jngFd+iZa5e2nTP5J5/knbeTLFQWoTewixBRj22TNxc4
RRDHeUDojWb3jk7JoTDHcH9XdhSijQZ4lX1nongpoGnJl26mIp35jUaHonbpmz1a/nXT
UYqydovEN25LCW5x8J6RGZ+gKSLeIzEmeorUiaTJ2STc2Jtb+Wgx1W7j6GjHx3mfyYNk
s39iM5sYWmfIE4/Tp5h34p82epgxKmqSkXwSWk55qYtOWnOSeTBhySk/6Id6t3ITyZ8B
F31d1ncnRj4Uenc2U5V0WqSTql7GkylCV0r3uWofU3ie9ZECWJLPeWdJiXI7CC8R2aU2
4KHXAKLyKaVZI2CxeKKPyocFWjVE1poH96kuVZpBCpcOymNz86U9SKeWWpQl4mc/upR9
Eqqamp9xCo8ySapTSJ/0pnLumZJPOkHEaRGE1GYFqGGpB5uIGmvxxqu+eoOxlnj1/hYn
b3qtgsGl5Oio0hmY09Wg4BqdNhhkMANyUQhpZreHD9oGSilz2uqnUCqbPFE8UBhsYvqa
UpqlfGgs4wmo2siGyvKjmkqRSCaHCNFAWrlrIGuRyymSHZauuSqfW4elr3aoh0ZYGEms
SZhiEziIwxmiDuiST3dm3elVF/qlzlkxY/d8z5YTQhd1hkZ1j1qn98dACwigIUqh4KeW
oPmbYFqa/HqdREp93iawVDtvE5qtNLuEN/uq3mqcMWan8ja0Gntk80qbNwiS4DW0K1qT
SKuf6xltGdqocSto7jqMxgpq4+q2Yeql+dE1ssaaoMSljZkDrCoWXwmo87lT9fly/njo
amBLbFdrsreZcSwHj13quS16skdymYJ5PDDrjfUahfjJnuoKoVrqMgMWmuaJhPECqhOr
jxUJnCQDn9zqi9zHiVqDjqtmuy+numZ6dQinpHUJtUlrLOV4QAzqsFzLcmQXXGYKp56G
MLX7unIrZ+g5m2bZvUzaonnVjWKLdjXLi65quMFbhjCpuak4oB+2p3DIiPlZlvZCu5kr
qQM7vbp6T6KLp24aqhqapaIZqbzZt7brQon5svg6eSELuLobWxE4tsJZgZP5vrpkQHt5
vW96pShHhCFsfbQYYvZawA3oY1N7vhZcnbtKkrClj8oLnr8ar2qofIQLayVMlW82/gYc
q7w7VsFcebAU+Keo+mJRNcGGN32Oups5OpJ0dnkjLKeYx7fQi5S+Zbnjcrsom8B5okD3
K7NEWmX6i7TOqbQmfMLBcJuu23xBuQSPuza/a7aBJYceLLNcO5KNUmrPp6ruS6miSJ7/
q2Vtap1sq71a7LXnyMDkycTee44/GMGMWZ7utqP+V8aPR6MXrL5kq8GSu7AqsEaCHFie
6XzuFsc8+bxdR8FeHMAWZsDDGi8rK6MVGpXkSo6qW8BlKq3tlrt9SSWMZicse3wuvJjF
CsgAMMe9aMfNhoiCWxCJFp6lu7QsipkFS3cFap/bRqsSbHlVyoDYvMvLtrhTTM4s/lzL
vhzAm3eeMkzEjVl5ekqAjxmcvrtKoqyz2ctZvxZhq8mDyZPCk1yxcDxtsxSmQxq9kOKG
RQmAbkzIlSrDtomdo4ed2GFti7y5hbxl+pGkecvHnQyZCFvHXsrBI+rBlbykiiyqO2yS
pIvJ0Syd3RwdnHZa6Diy7Xidh5qGC6rTk9rQLP2w+vfLRirAO22dqPvSxobB91zO90i5
5dbN0Oai2zvEQO3PWLmaOYpMsGvVPDpkZ4mcDwudf8txCfjCDTwM5LqPbbyn9LvJpljU
JmKv7Gq8RoaSTL2tLdaSB4XSdve5Quhxudm1kZaiz7mfURzTEMzPQUGAIVm0jbyZ/ips
wlF9sWB9qR4pwuKonA4NxhT9h867zXxqxDYLyi5bnB08lYQc1e180JxppPLc2BJKeStc
sGhtgMKKX+7BMZhRu6P4tVemy2trh7GN02S8zl4tnhztoxt3zr6aviJ9xAl7prCqaetD
oD7ti2k1yS19pxV5qncnvA9VEVSmnBqXFc163rhtZBNtZwomfrg3t2SNoO6T3sKKTIB9
a408vQ6d33Lcp9JN0ndl0iQ6la0duNDpoI0YhLgZEj9Xi2obXkLcS9Ztcses3zdEhwru
0TR2Gb0Zsk/nbTMErj/by8c5cM0LzvgErbTIsWvMojXAzO0rm6g9UqWHt8B81La9/o0w
nsedhVoPvOK1OK0GXXEHiskT3nGlqtCT2bCvlXezrK96eaNiIHxfmKjrTdSvjOL13Lt6
fXP53NfcS6xnnbzcZH7GRE4lhFFrTpqmIzvgBEcHOTWHJOeVaDmeU1SjDOfV40H8ZDXW
5DoFslvM8o93NFCCxE+r14XxB0x55EOkxWz+pFJv/ujng4jyQ9NBCsztDePLDOCljcRR
Clw6h0ZGLdqhfIyo+JK+1D0Ue91se+ePCJhozUTXFEciheb9wlZIRGbljWfOFNuWxJMN
1T0fWaOM4E/GvnuQY+jNHufPgTn9hLEN/M4kGdwhbc9fHrYkyLCU2J9ura/6JVIo/gjt
qDhxjkJvAlXR3V6/SgTrkVOHv72CmcOCkBg99kk+sf7sfNapuffsi8V7wlZ8uw6Gz3ST
EQW61+2zbCSqANq9Oy7M2e7lI93FhIQCkR61WwmRLjg8eBNPH6g5m1jDVw50qkchbRyx
yT6l6d7wqr7utZcIal0anThCro6nHy9LGe50d9nxDtxVbrXwWRyrGWgV7sjPI+jjYUxs
8Lrpk+24oM6+kZvEAmmU0em85pvKtkR5ttrwB2WhcXL0qoXr0LxVnSA1oHXiRLHIlSjE
Aj9lHhgqcaPaKQ+IwCTwrWv0Ts/wyuiO3FvzF5JAmfrFaCrFZ0PaUl+2ow5GGejU/hHK
ybBURK0O8i+fXKXuM3BDf9SY4DQv6HFE+YG3T5eVpIjuYgBw+kg1n66H8IGTe+PU1yc+
uaXO794Hiqf/Tal/+2Z4SAoJUHo/AoWGoKj/KMd++9Y+/Mif/Kcv41Ov/Mofq4c4Rbej
m9bOaOwn8+Ui8lYYPaWP/LOH7uM0gMboMLt+msbfT6hvMCf0zp10/jY+vDep+22l++JU
OMOP6MaP8VqR/vJP//Yf7wgAstotCi4IqmUPX1vxvBL1bYxERmjZrc4qtizFzXRt0/J9
F8UQBDwfsDcoGo/CoFDHlI1M0Iwrx2JuHi4r7Fo92agccKwq3oZnprOzm+6OYS80/tlN
zdnPTbkj3lrPa2KBgHqDeGZuh4h7b4Zagnlwemtlb3d9jVo6lFxqWYuffHFtmRxBP6ZD
SKpJRD+kOItRsli0bJWKkG1+kSqSg5O4vJe1xFy6fMbBiY+dnluWt8Cku7te1lFZ0ISf
taF0xKOQJ2nhyKKHm4rIX+K05y/ksNzz25mU6Tqo+kSrRqetAV758oBFFrxwjq68S1SP
DkFB+LxoSyjPjoYIEwvFYzQvYr2MVhYyZPdMmTh4nG5E3FQHlK1pKnN1WkfP5bCNJmF6
9NUsnjl3Akv1+Meq3xGiS4KyQTnrQwiFQL3BtNkME09DPkkyOpeM5zpLOLValcP1/mc1
lFQpbkQ4kptUgVzxoHWraZufu3OwQUVX1wzNnGOZOvvqaW2hoGV20thX1GgRpK6U7nFa
sOAkxezmeiQMNiXdviDvYdU5tieslsWmirVnEzMikVallWX492Rq1DGVsvTLMVhYw8J2
usb0s/W33q8YI3UMOaBkXdkqU+4FPZbJznNDyist9zqn7JkL844WnmxukWwJu0z/a8zv
ti8xQ1zWzVnf7+67x735Oif23NqdtxdUs5XUEGv4SaZcKo41FpluICyE01OHycQMaPUN
CA5yA21H334UvUJTYhxqR+J93WmIoGkGegVUiubxpdGAb6W02WqivaiMeiDi1VBt/gFu
JV5YkcC3w1CpLGdUc5LFogI2ITzp415AFgciISeWVuBpdgFmHH9feliTi1dWJpGMq1nX
Gz6jAAmgmBWOuZKYYKCFF25qoqhjbBXWedyMWRXZpH0HZrKgEswx+CBiZzaFghRpzohm
TGz2x6JoWXpmp5dNULimixg96lmJbUk1AgkiZFTdU4G0ZKqo7+154h1EEkprkyCRZ02M
NLZI2y1GdmnclGcGW8Oh/CypqHMQQuoolC/eSehVwJq3n3ok6aXhiNMU+E4J1dhXG7if
sTUMlXWF+1CcIsKpzocoPukutQmmuKmgpI5Kj7lVcWksXdllqqWeySHJWINMPhdh/nQG
TTFoWjZiqQl7nYV4YJv57atTcRermSuB9bY3WZgVo5sxn8GhdmtHEUus8a+Drsyiy2rh
Uiu649r26sxbBoVsgw4yy6h0RLMaKrDApbvruXmdOkGqHjgV5dFPu9NwLylI8fQx4E4X
A7nURZlq1gR10PVFZsMhStVpm03uyGK3PfXbUYfadQoWjTwZ1FA40fcTB7GN9ngYSyie
pSRWt553MLtZEahDR+6zwZQDnXCzVBf9qKd/iuy4zcLi7d7aIED8dulwn4UDhRyn7rrc
5TwOCutplz325vYmU7jRx+gtdQa0dwjW6X4jbebH/wYp+8Mmy45pfhdK2vOXNQr0/jPC
y+Lqsebrxq4fym+BJxvu69a+8NWwM8zwQWRM337f6RevsQYI1Q3yqsDI6+hgY68d1+87
Oxz8BBM2jDTsXc27xKqqdaWdoUdTYwJZzVTGqRKlYzgVuF6ilLAouDiMe+TzE3foNcJp
netbsIoKtkR4NAU6pFjFMAz9UGe0/pSFGhzhm/2E1D5hWOcyRHOSdHpXLxy6bUo1xNNh
oqew8bBrNPSJYLUoRcXtLS86UrSCBpXFQaF58HzcY98fKJiak02RLAP8G+pS2Ie7TC2I
YIOGG1HFq/59rYe/YuHXhtcoa6nvXsWjjgBz5zuVQMtqgbrjnhJ0s5YJZnFiEZ8J/klI
SAHBSz4IJBgpttiPyw1NkM+C30jcxC8LiuuHosqL1sxUOr3cDn0tVGPZ+NI9u0FLkOd7
1hDlVUiu6RJSOLMb2SwzzLiJkikWGWDtAga3EqbFNY/w3hMTOLPwkHJHgxRZV7Rlvcop
qZPZU9grw/hBGFLzjGZEoxru9satvJGPR6xEm6w0t0bM8pVga5v0TtXKvEVNSnfy1Djn
2EYe0m0crEvmGm8YQr+RI1a6itO9MnTBK5YpnZBzHuH09ThX6QuDAODkKjz5RWGGkpgw
u0+OVvoNFu6PY0Z8JjpP6aH5rIgq3CqSHisSzT9EETfhmpeFDMqhGTKyhBDVJJn6/oXN
a26IkkL10eeUxlEtepNBGwSI9m5ZNDFOETb/kZSe2Ie13eSzo4WaiURlVL9sdu5NEAST
C1+2zkW+BEwL3B5Iy2OQoJakSn68Tb5AV82M2hOB7+HmULHIoyaJVBUkbZfb/uisVEYK
rjAC1Ur+GSiFLi2eak2pNJia2XjFqLEcdall47rawjKPNbPx1hfqVjLfWCpAz2Na68Ra
nsD4B0MTTWs7ulmUb440nM0aKGWDpxnGHqenN7oofJSoIsbh67J/6Rl1/UWccgF3W/Gh
6qZk676Y5XBeUtVmADvUp5pCzIqkhddTK1hd8vjVUFdFFBe12sTMnRSYrxWsWd97/kW3
hleEFATqpb4H1Uwa7yMelG7HpKe95FIvizotrSWHi2HAIm+wtORPRcMbFRv+C6SPRUJk
p0K7UCqTlf+z1XOx+T0/3ei3GjZhpThsxsKpxofl3U6spGWiB184u19kJpxiu8TBEBbJ
MYRiW3FK35kmb2A6mqoNUnwU5EZOl6IEcFQlJ2RVblhXPXXyNM9L5TzZtWU17txwgiuw
PCTytbsBMoGFVVsMVTWw2fpxnSV74TMD51p/vm7BiovV/T7Gi5JtcVfDXBNuPtDGTJPJ
ZXn7ZFtoGXMaZa3y5OjcHfcqTLiFnqoZbF5ZrTm4UkYnrIXEL9QeUnE0zml/K5ZX/qVw
2R9eLukT4CjEja65t5YcbQKDbCWlQvLQlQYxURm4aX/tVqnp3emPNZsxU7OswxjGrDZN
yVIed9dxrwIkYW9KXKIYF7LBbheYteZVpLI3Z6QaNJwpOasMCwdBOwbPpj0Ko8+RsbkZ
GrWZ1XXbJPuUxZM0mSTd/GePTplIPUr2lddqbIov2t2NBmcXK+zf4z2EmSgHeKajXR9s
YZFa6Lbmp5KWuwtpl64fDTXDzUtzJ0oMwfdbtaYPmepJCRXmMna2cA10Yya7mrss93V+
kyVy/kJIufMeXKm4/W+oCxpQ7qIzp7qe51Ie21cIV8wCZTvdhkvx0zXDOVojmHJ//he1
tzWKcTB17Fw8a5gZKJ665eKtGv119YPN3rjxVnbwHjsT6Mob42f23Mg+Jp7gJ+57gA27
q34H2rsrfyuxxEtmqta3yQCCppc6e84661sLv370yJso6abUe4Tqhnuet9340/c89AOP
+J5fzTjY2Fni3S4+n43tbZdh7LBNdup4a+7gbSK2jMXKaa+djVqACZ8JsQ8ayYdNQClF
u/J+rhW3Zv1XcaMf+9Aex9D9/G0ofzqvHzb6I839door1mIZxh0SdnaZVT1LNyQq90Rb
cjNm93lSx2j6VXWPtlUI+FKrZXaGg30F9n3XMGPt910b6HDS53Zb1ziH40wSNHqj/iR0
pqSBqbV4Heh14IZqRmZvoKdlxqcicBeCj+Ry7ZYkIXdcs2dhtXRAwRNqEUZg9neC/cV5
OZZ7SRhwEORhY2dt0rY8UBYpMedmAldhkLdgsJUQBKdtReeDNMYlbJdmKxJ4EEh1Qmh1
kuM1tkdplTdRuudEmHRpc4UnZbKDt/Yu+4dsp6U0ekd2NXh8UORxViaAfbdevlWCvzd9
Y0ZkRFdFLDMhETcnUYRKKLhlgoc9Q/hJWbE/lcVpmJVeTKc7h5hoOGJ6S4VvBHhOg9WF
EDeAYCcnj9d/eVdxaYKJbHWG9HV5D8N+R6dp2Rdo93V6sPeJWTWB4iQ3YURpP0KD/pm2
Vw53aog2iKyWgNQGX56jUTliRTi4aqVUW71HYe3VUgdWjPTCa8vHfiMGVoBBLKjIgKmm
iaqjIMzoaEmBOXI4RHTESuE2SWNYaKxnLN62gycIizyXa4gIfBFDjIi4XX0mi8qIe5b4
YDbXDnkIaDdmGgaoKvTHiXwlWlVmAeG3YmE4irskZrzYhdfWiWPljV8lIJU4jY2VhhqH
hFU1cWEoV+kYGt9HiyVGTQz5iP22W2w3Ych3gNUWgExUSVX0elbVhoMXisJWhHq1hC4Y
dTJ1kHonhjpTQYUobm8llTkWV061d+G4bEG5k/jxf7w4d1kGiDfVgAWYjl7ndNBB/pQW
NY9dIVZsCHIR+IbOaGHkQ0wnJ4PomJebN38v45fwhZcFpmsXyXKu5JC+slhZVDLlJohF
J5UKaYoylHOQtHweeJm0916J83JGtH6OtY8S2I9fppVQs0q88Xv1RYkLJ47Mk2aamILk
9peYloVRuILj05U8uYLnBzqvyZijopO4mDz5CJq75x3qVmihOZoAqHghJZuGSZsiSEAo
pU8D+YRVtldcxZKzuIikQUYQ1nbJSWRTeXWSp0TuyJGJ+HCfIpDK+ZOf1zqoWFo+6Z6t
Fog7yZt58n75AJ7whpWElnWKqWvfYmOYZhkXV5qks22tNItbUzXZqXJo03iYpBVs/qNz
OEYnk7hHgDBLgikibZWdakSXmxgsrfKLdUVhw1aULJFELGqWpbdJDqpihCei5HlMrZWM
xdRHkTQ7FkOPvrmLHoN+CgaTKGWIVrOQEZlWXKWDvMKFVjiFp8SS1aN26gRYdfSK7CV/
OSRhkgmGlRKIhrOUk2OVoAiHWTl974Q7ISZwisVQLcqm0sIewnUr0eQTPYc8A9hcXcdd
5qJc7JaKjKJ9OSMzx4d/00KFHxiLmRpDatibt2NfZWZ4EHmS7HgkdtqM4ilvhwdmnmei
BgQ8ojNDlBGrnAM4FxE3UzAdIIqrytaBuVpWVBM2sjGjtgQ7xBohDiU1M3qioNWr/niz
rGggNr4aBtX6PmCKqA3VrP9kQE6Dq7uKKjrEWd46rJvjUJdyracDPCd3m7LaUCWXrLZ0
N3skl8uYqvzYQYT2mPzar/76rwAbsAI7sARbsAZ7sAibsArbag9ImG74oHgKox86sRRb
sRZ7sRibsRq7sRzbsR77sSAbsiI7siRbsiZ7siibsiq7sizbsi6bsbGJr7OprwtbszZ7
szibszq7szzbsz77swSbkkUKtERbtEZ7tEibtEq7tEzLPEILoU0btVI7tVRbtVZ7tVj7
nTIbnjSbtV77tWAbtmI7tmSbQUPaZVBbtmq7tmzbtm77to/5tBELt3Rbt3Z7t3jr/rVy
e5h527d++7eAG7gKu7erKriGe7iIm7iKKxRbC7F8u7iQG7mSO7llS7hdS7mYm7mau7k+
a7mQxrmgG7qiO7r+6rmke7qom7qqW5UOe5Vzu7qwG7uyO7mmO7u2e7u4K7i1m7u827u+
u7a7+7vCO7zEK7XBW7zIm7zKu7PHu7zO+7zQG7DNG73UW73W+4MHo6qXe73c273cO73e
G77i+7zgO77me76/W77ou77sG7vqy6Fjq3XDqJ7WGKkCK7+R1yl2O2f1a55X27+GdKoT
Y6rSe7bAlrYlVbaUGSLWCMD858ClqnScGrYYtF32K5M6C8EvOowEDLDvK5Zqq8FK/tqd
CAvBIwyaEhy/JEfAI7a0GtxgoNazH1xk06pQ4Hquq0M/tNUq6Low1sqskzWrI8qrP9yi
QOTDQNxCy6RPvSo43JoYROzD47auIDqst5nEOBzE/tWtNSzFSsxPS9E/yTTGQUzF30rG
SqysSMwqO1zEUsxPPDyt0Zo+7BpHXxysxIO/BjvDKkWgCnGEdbChYgw5ZdqhdDM3QAXI
cvw6B8VD/aRI4WM+9xVIBqhbCXVHvbZzJCPJHohE/QmNosOngTnIfLpCnFPKl/w7odzI
UkpDcqzKAyrGilzKoFyzfJx61op6niyAZTrGOkQzcqXJbgTGrjxtezOirWd9ypol/sOs
ddW5XlvjUwqWStGsNoG6zEcUqoERQIm8o+UCePsmeeL8zT+cq7NFMw50asfsiHoctAYs
e6/bLWDszCfEnzcakkEVjqRWz4lISr6IQ8k4oKN8V7jsoXCMjUh5W/Ljc0maz9dMHP8M
Z6p1QhO9mcGM0HhUo+bTz+K8y1EXCgv8r7fMcWsUg5On0PxZyy94V5HM0SZ50WqmyyjN
Zn2cL9MMeupAr/vpoq9xowxd0oLCzcA8znnj0qzV0h4tyvHZIrss1MgRyzc70ip6d48c
ygtFy518xEGdy/ck0X/8HYBKxbm8FKh8DUeYQjcdqvi5TWdtVKHHykwcgFSi1Rg3/tam
csoLjT9YbQx4DURdjcmkvKHVuEJfbTvqrNarrNKD+87i9xw67K6L7MXrGquT1cRuDFqU
nc14XNk6nc1WXCcA5Vk2Ms/nyjc0RK3l3NNJ7KyxxE7d6qyw/VFsTMZnnMOp/az0nEv0
Wqun7dpXnMbIasQ9DMRRrMVw7DRG3EaILMucZdnXOq+/bcuMrZIB+8Kra91PGbvYLbUO
vN10K9Uc7N2nK96sqN1/C8Dk/bbgHTPpLbrE3L4TrMDtfMGbu97wfd/4vbj2nd/83d9+
u9/+HeAC7rYAPuAGfuBgW+AIvuAMbrzTPbTynbDzPcATs9BJK78TztVRKxxkaLBQ/rzh
wakb6M0m7T0oCl60FU3CMRykP/eY6sluJxxa/LevHGwbTgmwbRmMChvihbd5PP6zJ060
KZ6/TbjiZcavLw6AMV7eTJ7CLt7kN9vhQFrdOA7lTl7iMdu6d/q43TLHkv3YXw7mtp3Z
VbzZtw04rYUlr83FbUfmu20/ePzmnuXEaBxPtzrEZb7mOkzN7craIm7Vdp7FwH2ix93D
4vrYYkTnnF3Nv2nmAVnGbHzbge7oi25Som3ozPvgCBwSiNzR8oTJgQnKLjXLfI3D7ezU
KnjkUkbqPaTXkzdOWMHqN/GHrwzrvOR3gF5Qhv0MgtyNhizqpO6I7H1GjeyktCVk/rL+
mqkcljq738qO5kBdy798zRU97QMdwdPezAZ31EQNzIwu7YLj1fU6zUU908XcwVeR1orE
pdr87XKtzOVq3P26Q6u+o0nNz+7+nNPm7jjr7PA+1uZZQJ2pfv+OzmP0oXfn0Daepo78
cPec0sKsjKPn1qOcVJo9rvCp7gV1MUSUUh+d0gR98SL/ytGugnf9J6nePE2N7gXcuES6
6Qs/LkVNDRTvfKqOpjB9ZiadaH6lOIUc8jkf6vhe0KA901AaYD8PlMjs7Tj/8W9d8wxb
7uN82IOj77PVTivvnQPr7wd/jIX0QmTt9HoT1MueCzGF1ra1bquM12AdkCBNR0s//utF
RGJFD+dA74XiToO06i3VOfaZPFrcSe39uUO+uIkEhYerXtYsH7eaHs+dsty4jem1SujE
PPmBvNqVD9mnPOaxndq83cWsjedcfflxDkalja6k/06FPrFfnqOLLvWObdnlTK3tJOm8
WudWbOdvrvuqj/QAlcO0Hc3Pjc3DX/Gq765+HtWNz+U8m381i+W/ObnQb+DO/9/LX7g7
S+89O/3PKLncL+Dan7hBjuMZvrDv7bPl37fn3+Aunv59O/7sH//yz7PwP//2f/8JW//4
v//8L9LXv70IALrc/jDKSau9OOvNu/9gKI5kaZ5oqqJFMQRB+8buYN/4LM9r7//A/qBw
SCwaj8ik8iGDNWm5qK4GWyoFggbWs0VlGV3QlxO2QsZatPlRXmzboTJ8vZkH7aa3Ovns
16Q3TlQBdEd7exmIIl9jihqOFpBccW4RklZZiownapdGjYmcFKCjlACeQX5TgDiCNlWF
RIiolj2kSbShYhW5hhKbeVqxp5UYvZGlCp7HbMprqq6sr1A8dZnXaFjZYdpuct3Kdt3g
5Iyz4GBdeunf4afXadjv4+PvbOrw6fbf3Nz23pvKmfunrVG+cAELFgRYzJ2ebRAZImRn
UJPAYhUn0jMHsRPBh/EkrkM37x5HhRMBJnQoT2S+hSVVEuOHENRFicRmgiwCjZq0/miw
rJVUh9FZzoFHMzXUhPFlQ29Gl7J0l1PqPo9RgRn8BzUpV6PrCE69mtVh1YFE03wEq5RU
2k7y0h4Fy7buLaZjtTote5YqXLFR6ZK9ureqX76A376MC8yr3MZZFwvWp7Tu3MuGh/Tc
8ZNa0EdWUX6d87gmXsyNDz2dV7ovmKKBXV++eya1MNeqJ5+ELNqtg1uHrXbFihtmu9+2
WZ/2jRrxbsR8gY+GXZykPtnDf1N3a3z7LOHBX6v8O3u1kM1/WAElRCb0vetmE/OSnVx8
5tzN7deHzRx7fOnJ4Regdub1J9wbgd1VGXEGdkXVf1olg5tu/BW4Gm3nuBfdLws+/oVg
ZhNueBtmXzkHFWQJvhehM8yQgJ400+zwmS4hInedgtKdQR90PArY43bItZTffUCK12CN
KBrmI4j98VYkg9SplV1kORIYYn0bWRgbhrWJWKOVWEbp5ZENtkHblymOuOJMSLwI43od
nOnPikgBaFMzJ6J1yEEPVubYX/iUCF2YN/5YXCVhcYcofH4mmeiah5K4I1cdzrYfpUTm
ZVc2HtrEp1fmWQpYpEquuRWobFJoWar5QWmZo4zKpyQfLrgSTWcysvcISAJxhNNQNcnE
JFzbCFoPRUPh4+dUnx6o7E4MLYSOQi3BFFOWrMUULLZyjPZQR75am2WvKWkLbLbB/paq
rGm+6hdPRh3Bx868yVZr3bmB4jsuStzuq+c5/S6YkbD1Gteii7VCcat6nulaCKd42jeM
xBPHcjAdEFtZcagbdwzExSO4iesgE+c7Iosex5byEiCbYTLFFS+78sxegEiEyAznGjMe
NqZ8L81F/Ay0uUM/WPTRYrQsAs6AwIn001BHLfXUVFedSsKqvNmw1Vx37fXXYIedMtNS
OC322WinrfbabFNAdhRmty333HTXbXfHb+cQ99189+3334CDkHcrW9+htKA0jmDmMBaR
0cupH/Ds+BqSK34wHIf7QFrmmPxcuQmDB1L4HRqrHHF7wcCMRJWmI2MMyqZcsAzG/prb
LHvpjM/aetEms65C6DGSLAR+HJ+MSczzoQ7aIstPwDnztuwy9JJSZ+x7CsCvUo3jdVa0
Erro3sundRv1E+5OJFlL1uYDb4vUtYuJ609IOp0kkrbfRrvuWq/dJKz43jpfu+j3KCHp
hF5hKRcCpwWP9M1vJOMTn/nGUi7PPUsmEQSUAR3YPg62rxbCkFYAWfQ5t2HthDDS3oyM
URi05EllWzFTC9WkKjk1ZUsUFIyiWnXD1rxFLYHai6IgtqREFagtF3ohZeo0JinpqUeS
CeKljAjER+mwhy68TYCECMVRLWWGSwQjnYLzIf/gLjVilBkHsre319XwSWBKIlvI/sef
7kTHjpmyE0UGNEcfXghFBuIOOfBUxCJJTDQHomGh+tg4JCmySaZ5ZBy3NEAeUnKPd8Sk
u5gUGvVNqjfF6pkgJZcbOeExBGwcXfO2+EZFZkpSIRTTFWEoxxzNb5NkMuSHXGU9WhLo
Ozb05e7O5Ky+XG+XUilkKyMGK+d0iIg3HJaWzuK7XHppkrD0FmXIeDstakh1HUilzpSH
pVs20z9H6p8s6zVNrFRJLt88Jx8lFUhZfsdmjTKkh0CITl2aMZ6LkuQyJ0k9PkJSgYvc
ZHgIis0kJdJ2x8FR8U5HzHOiEoULa5oqExFFANlTidG85T4xNShPlWiKq2rgEzF1/tAf
LjFBkoGdNynaUY2JNIa8dJKDQrmfe/4pL8ChokKZCCpC/bJPV0KqEguqVBOxdJat2ant
+PfJO4UMoz7JmfC499Js9cuJmPMgMy8IHvAdSzkb5EcMl+qvSBaMgDSxH/moJaVfJdBc
nvwIseCXT2SFRFov08j+Dkgwl0wwYOGjlr1kGK+2FjYlnuQXWQW72AFyMCnmc+hjJSvX
ElZAnFut2UQDhzuvPY93k1hZxkg70qeBdhorCCxr+fk1NarNtt302ftmS1WkvXZ7KRAa
b+lX29MCzbMmmZlwSbtcmv12hcONrnSnS13fYpUzWoVtdbfL3e561wrPddh3x0ve/vKa
9wPhPa9618ve9iogve6Nr3znO1z41g65zrsYfoPWyJ7FSWn7jRPVaHHXktVVBQG2nPKS
FwnjCu666dHoOGs31TpEzmOOcJXzsHnhHxg3c49zI3FcF71/8jPEqWPwL0pLWxWDF8Ip
bGOJoSfgjmXYlSvGcY2PBmIE49CNHxutjiVEAgK7OBS5cDB6Yay1CXOUMAtMkf/wysCE
VJKwkEUf+6pI5XhVEFkZTJdXR1g/hP4KoRCMyPo0iEC0tkyxyqGq/AJ5k/I1lxe8AiyC
tuzmSnZHil0G6mBD2D2zqrQWxVJrmfnKTtAxeWTaFQo9uHkfJL6K0o6hZ0znSR4N/tZU
VvRk62S+OCoX2vKSlU4WpQtsxUz3OJOKuXSom1hhGjEHp050pqytOOlD+VFF88QiM7sa
674SswT2XeUfR60uGd5xkA5SaHie856h0ro3rux0Q90KLv9W+6FT8iiqV9thR2YT01Sa
4O6UPUsTR3VKuOwktFEDiZYe1XRBheN4nOroVWS0bBsFsoLKc0gVXRPVQ83nMWUWTEtS
rKKVsjYnR7u5Vw7cVNmO+LBAiUgpayhDkHI3zODs5nsfVJo91TitYUnnEx98SJq8tupC
jjB/Z1XCobW1vkesTJZ729ysuvGPzW3Nhxa96LU+qRyJbiiHJz23Qa+QQDVMr6fL/g5a
Rl350Z3ac6PFm9kwH7q9Q4WtEyRb57seOkv1Imfd5TRNTfViVdfSO4uHVJg7ZBVJxQTP
uRM81fnSaexgmhiT/j0yAT33jqHZxSHFWqaEmtPOtbjSUk6T64XZ+/UebHPs4jzSHGWM
AOfsV30JDOuMZbSdwtqoPPt5l2WP5EV2G2dyiZW484KXlrGh5/5FRH0JFiWn9kd6kg/H
scFv6LMMqC+/wN71yI8+/t5FbO9BC3+up6yXeYTsR2cXuPQNf46vYDzxz5i6Zze/+oV8
3/KvXxTcTf/7xX9nW+x1/viXgPzzz//++98M+/d/AjiABLgCAViACJiACqgBB7iA/g74
gBAIAA0YgRRYgf43gaMAYEqGZ0mjOEVGHh24M4ZjgQWIgTqybkAWNINnYSi4PJuXgrnD
blDngSQYf973eeAncCsoCzuYOCVwKamFPDJIYkVWgzbYeREGcE7GQnumZotVG4mmZogy
aNMSJHI2SM5GE2jlEoiDE7yHZfDTJ1i4V3VGe4a2UtRnZnzFcX5VU5c1GAaTYewzYkY4
NSY4VqVmFqcGeGioh3eXR5n0U9WXh3DYLKsmaj7Uekq3KY1HVKzGds7meGwniHkGa8Em
bfvAYnVoXUgYYwGXW6PEG3lFGvrUbNomL1v3dQ4HhLn2SfoWdmP3SqK0dKxIiAkF/lCM
NCb1Flnst4mcaCs3p4Q5p4NgR24/B3Rwt03S9HLitoorZyMYt0yOaCENR4f/QYvch0yE
J09cx1DR5n4L5YtWc4fbNnEtuDiq0lrflFDcqIqcxn0iUo3OdGyQV4o9x0vYOCk+l47t
CILgqIbiaIc3KIygh3aosiwiNWuC2ClTyGyQ+D591UmEKFSANEaWSEFUx5CAFisuxYc5
BGqnApFAJ5JjB4IRCXYBWTTkGCS7l1as91eD1mW6p4WCJnr683plGBdWGIe7V33ZJy9U
dlJV5lWpd2Ua4XxHSZS895O9Vw7Tl4beg5IpCTQrqYAbaFNE5l5G1otTuTJViYBX/il8
KxaWdZNkZtiVv6gwwQg3n4iWXlA5yaeVcemWdPCVdHmXeHk2dpmXfNmXVLOXfhmYgkmV
A8mWSziYiJmYUQOYitmYjkkrndhkw/iYlFmZhcCYlpmZmtl9kQlpObiZoBmaPoCZolma
pql/hak3bXmarNmaGUCarhmboQmbslmblkmbtpmbjYmbutmbgsmbvhmceQmcwlmcaEmc
xpmc4oicytmcNciczhmdEQid0lmdCkid1pmdA4id2tmd/Med3hme6wee4lme9EWe5pme
7QWbLdCe7vme8Bmf8jmf9Fmf9nmf+Ome6rmf/QaMnkeQn7kB+TmgBFqgBnqgLSBe/vy5
oOGUmoRzmGuUhCk0oRRaoRZ6oVrDoBrqAewpoRj6oSAaoh8KXRtaohPQoSKaoiq6op1h
oi5qASjKojI6oyJKoi96o+/loKIDoQLqoTT6o0DKljg6pA4QozewBUH6oUiapBpFpE6a
o535fTb6mhG2pCm6pFZaoVkKpFk6pU+qoUY6AAuholiaBRi6pT/apQr6pSYapptwpPIg
BWOqWN0gpnUKp2ZqpyVhA2kGAHiapyBhp3fqpWzKn0aKpGUapzgQeJATKHw6p4G6L37q
qF+lAAVZqCV6qGZaplCRAwugp6Aaqp+KqKCgp+5gqpS6qaraqWqKqTcao10wAPYQ/qpo
ihK0mqeCSqp+KquTCqirCqqkCqm7qquE46ovCqtwdqu7CqenyqmP2qy4+qzSSqy6ygDK
GqqXaqwLiqz6cK2L+qvOCqy/Kqa9Oqzgeq7LKq3imq6Eqq3iiaKxagNkoa5/qqsNtIWy
aqvOSq2qCg/XiiDZ6q7qCa/RqqfhegOqRim656cx8a/omq/gcK3/ELACa54o+qk44ADy
aqmeqrEY+7Eay6scC7IMa6mfSrIjm7K7irEBWrHlGaZMGrNA2q4um50wK7M4y6I0W7PV
ebM5+7MhurM8G50+C7RGa6FCO7TN2aEw0LRO+7RQG7VSO7VUW7VWe7VYm7RKm5zs/pm1
Xvu1YBu2Yqu1W1uc6Fm2aDsxZ5u2bPsMOho8FNu2cts1azu3dssTb6tCa3q3fCs1ddu3
gGuAeStjgVu4hBmlOEi2hru4L4a4AKq4jBu5R/C3klu5DDi4q2m5mqsElLu5nhsBnfu5
ossAoTu6o1u6pvu5qJu6m7u6rGu5rvu6khu7ssu4tFu7hnu7uBu4uru7fdu7vnu3wBu8
czu8xNu2xnu8aZu8ylu2zNu8SkuaZNlgZ9klLDg5uwKDHJKBLbi9QTiCHNg1noVcEdWF
2XtcXEA8HPJEcym9LgNOJ9g8xLhh/3g6WXmCzPCC9Gu/HriV+0szSeaDNLdjynW9/uo7
focXoY5rmJOJZMfTvfALf093wDT4v0P4g6I1g/ELwNprwdZIwGCjvy4nlRiAmQgZP1uI
WI12RiqlGlrIaxnUWGQGfHqFfYORLjFFlDcMPmNGk0CFQaC0aBZkP5QFLC/MQFC2whVU
D1PmlJhjVw/0Qbz4eETTVmG2wwTjxPZCZoK1w8DHxBCJB/fUMowZVGIkkWE3c4zBZYVY
eHQHJpsGQ2AkbLKyQw8ZH/oxx5oCkj2ETpmHefzjKGvcT0XlhzX0KZXHRYHoTvyYbXu8
kGTUUZ9GRXeciWqiyEI3UxyKuTwKiu7Ib9PWYqDMdO2GUo3ojYBYjDKHjFVFR+1m/nQx
x4y4CG+wjHDmGGe4LG4tpVamjJPoSHR4ZI0n947TwcrBREqExHn+6aM72sBXlz7JZCTb
mHj8q4+r/HdEBW7aaG2Wp8qkbMeOPFW3Vo7GuI5SRx8qp4+2lZC6M3K1BEfGqMsyVWHR
uI+yqHVat8ti5x0IvE5UusCq2ckuVlHq8pTG1M+jHIv1DEDXnEjdvI8l+UVMJc7nXMvD
tE5lF4vaDFEWdcDy3Ep7mMq1WMSyrHb4jIwd+UHd+I0zB8GoCdAP6swDDR7U40XxPGz7
3MYpzTGm5M3dcm8HSYmKLHKBWCpuDHmZd1N/TNN/ONH4llJGTUKJ506TjJRSjY6T/sjO
+QbVenTVkVfV2MzTH+fNmtygMN3McZtfMxmGOnYsP31mjtVoVbh8lcWST7hbX2zXda3F
2hcwe+LXhJZl/cASt7dAT0wlqieGNok4YlXYTalub+iUZ0hNJDdZCbfX1zfZ7ATGVdcr
LWnXKZyQc5VX/7zMnijQKQbC0xvBWHl+uMDaREg3qx1+z1POPjianCzTRahf7Uw6V+d1
wTDb3Gu+Hbw2uFWHtV29GozbZw23LfuDIDOXSWOWZCnd0H049RfCwj1f2f3MKpnbaQ29
4t0AzzveLlve5i2w6J3e2rre7O2quLndQFnN1jsE1p3aiwBi/ui9Pjbf/9VgkUPB/hj8
bZZAYI1kiPytYHEg30UK3s8tvzxowTi9eLfdgxUuyhssPbDNfiLszpTgvwgd0sElygKe
4dJsdfNcbtHNlb/j4JD7MLGz4i4948vd3/f7vS49OzRu4gt2ZPzb4R52RsV9zxKu4kYO
maYtmeG9vi3MaF2lQHyN2C/FWG0hhYbNhv9Ddy5Zk2pNQkNZiFR4WSqsk2J2ZmDo2XVm
w2L2hnB1WLwyw1VW5cyyfQ6UxJkl1TwsxVEc2AdJ5U+4ZsQi52a+hmdOFN1d2mr5nwy8
5F2i0Gw8RJVnKKy2VMsmibsmyRO51NBoahfpdxqWyKnSd6J+xoBMRNE46nI3d4GH/ndC
FEV8N8hZBIe/BNbdnHXUdEBShMiUfkmPkUYojuhZ45mQO865iEvBHI+8SMjVIQ5A2Hcj
yW3+rIqY9Wu5nI9OV4u/TG044uytEln4GM5dPdHETIrx+IqvaJSW0m3SNszgnuyOB+0t
3tx6+9/NUU0fBdIg1IzpdCIlZc+Rh8qVHSX92E4mt47NznD3bkZjjNEIj5ILze/mSOyF
DNzHfOpAPSALr3eZ3EvW7Irx++/1e1HyTrjUG80XTdYGle/WrlnPjvIrLe0fnyb3yGEk
/SWmbHcRf3nm3nQOldE77/ESBZTVaE6+FNEzNdJb/e4St/Evz+I9OvKZm5WrpdRt/gfD
UG2PaBzV5cTV/vRUJLzrXK8bJkXuRg1PfSh3hVaPSDXGOfzHQoVj4JzzpfzOS5+PpUTr
jFxUSR+FCZ31fO93emd2Lr631Cskgc7naz4n7fLFvYdJ5PJXVu3W/hJ9TCkJOek+WzzZ
Ne3kswf5hSU/zpfZna/5bV5QPUl7nEVXjz/aBXNBlerkgq3YdKVX4HLEi71vj191tef6
980Eg0/Al9Pj7z3iTk9Rd7mXslXjNz78eaDcv03cmwiYh26Focf89qffDB5+7m39T7r9
3E+k3v/9OBr+4n+sv1/+5k2b+/38Bxa+uqXSBF7cvY/+dHv+O5i/7RzA2U/v6wbk/vC7
/wgAutz+MMpJq7046827/2AojlFRDEFgouo5vHDMrizpCBve6ABf+bbgrrcADhVGUFLI
bDqf0Kh0Sq0GVylsS8aduVIegbjHE4+R593ZXDYT02QgG60bw+d0Km7NcMf3ZH1re3Vt
ZVaIiYqLjI2Ojxtaki5dMFlfAR11SGicRJ5FhKBFoYGfp6CHgYOeqlGbp3yxoqaFtamj
kLq7vL2+v5CTXpUxly9gHHe4f3KkqMufbM10stE3eK+dRtWunbGteEvA4+Tl5ufmwsbE
x1s1mqrxEfJH3899zvitN/DS1H763giyBs3OMlgB0SlcyLChQyHq3LFbhwzevosP/ugF
1Mgvl71tiA65QqiRJMZ8D1OqXMnyYUQaE91V1ADLFqtRdhDmi9etDSmeP0WeFOEjjayR
3kxGE9qyqdOnUBm9pESMYqZkgwoB+nNNq5w5frBx5eomLMBwQ5UoC7XVn1lCOcOVhRO1
rt27eDVMZdeOxsy8gAMLHky4cIa9fK0aXsy4sePHLk8YWxfT71XImDNr3syZCeLKmDqL
Hk26NOnPVWVeNs26tevXUFFXUgy7tu3buH3J7kI7t+/fwINfkbyFcmrLwpMrX878wW4u
vZtLn07d9XMZ0atr38698fViqruLH0/+7ndL4curX89+4fm+odvLn0//0fth7+rr/t/P
v8n97P0FKOCAFvyXHoEIJqggAAYit+CDEOrXYHwRVmgheRO2k8yFHHZoHXHCJHYgBgB5
aOKJmGWY3wX+oOjii4Wp+BcF0tAF4404OiXjaj/EleOPQK60Y5BEFinYkEYmqeRTSC7p
5JMNNQnllFQCI2WVWGbZyJVadumlFFx+KeaYJIRJ5plo6gXimnzhN2OacMYpgZly1lkn
nXbmiSaeevb5JZ9+BooloIIW+iShhiZqJKKKNvojo45G+iKkklbqIaWWZlohppp2qiCn
noYqIKiiliohm8bNNqKprD5IaquwlvdqrLRyN2utuE53a668Krdrr8D+9muwxNo2/myx
yLZ2bLLMjrZss9Bq9my01Do2bbXYxoiqRMdRmO23tV0L7rh2iUvuuTpua0IKARDg7rvs
AojuvJm9FO+77hYQ76r09vtYRDLkawJVAzjo78HWbhvwwDC9YDDCEGs7TAptxvBwxBgD
NhXDHHfsbcYgl4uqxyQzrGHIKNcVYsWqpuwyk2yy3PLLNAsZs8zQ8VjzzgqtjDN4PAft
HpslF/2x0Ej/IozRJAdwctJQ60Y0wSI+HfXVwUyNM8UrYu31IktTHZPVX5dtRdhbO921
2WxHgTZ48WKn9ptt1w2R1nBnITfZdvdtw9vomQwe334XDgLgx3C899qGN84B4m1y/k23
45QXiDfLkutc+eYUQF4145yH7tzlFWcu+ulzTr3v6qwTjjrqS7Mue9ygvy66zz/Dx/Tu
vPfu++/ABy/88MQXb/zxyCev/PLMN+/889BHL/30+OVuyfTYZ6/99tx37/334Icv/vjk
N1+99einr/767Lfv/vvwxy///PTXb//9+Oev//78l97C7AAMoAAHSMACGvCACEygAhfI
wAY68IEQjKAEJ0jBClrwghjMoAY3qK8NevCDIAyhCEdIwhKa8IQoTKEKV8i6GrnwhTCM
oQxnSMMa2vCGOMyhDnfIwx768IdADKIQh0jEIhrxiEhMohKXmEPbOfGJUIyiFKdI/sUq
WvGKWKwPWEyRARtZQBwJqYsX1aKVPJBgi3l4ixcNMsYwziMERRlIV85SI7ZIABslioMZ
9bjHPuqRLj7qo1HAWKdBeuSLG4JAN+xCSE0kpJGHzIhPdqIPQArkHh2hESZJVApOLGGS
qLDJJ23hjU7mBCUEKWUpi7JIkFxSUJbcpCZtAEmn1JImI6klJGM5lFZm8gM6oYkcZRlK
VEKjHt9gSk8o+ZNmHvOZafGTK2khyLBog5p8PGVW5sLFsVyTj9U0hB3ZIk4W0VGUgtgl
M+FiRrm48pH36EmLylmKU/KjjoG0Jy68UsdZMPMW7dxIMn95FGsyJZVyZGVcbnkm/nHY
EygE8QkrCgrQpdRiKwPh5kcuQkqb/HMCFJ2oUu74TzbSAiluVENGVLlRezhDny+t50Op
6VGMGOIOYqGjJwWqTZXiI45BWcVL84hRgDIUTQ4dqjXVANRU1iSmNn0mSufJSkkeRCwk
jepHsGpVQBhFoLMgKkjjmceWtgiqz0BpS50q1VyWlKUGWSdCMTmNfZjkJqjkCCzfmBaQ
NFUpgEVrR+uhV1Xi1KJz/YFgD9JFgTR1rUnNal0z+VRFSvWtWh1pVVGyyIJ4FaxtSWla
K8nWx442mn2KZWGnKVeOLtalZZ2qIjeby87Okq1r/SIoi6lVq8ITJ3yNKF99WZDX3fKT
JJO1bUl4C1tj5hWsA30uaBv11asGdacXze5RjPtR6JLykpXlhk/Bm4uZVvS7Rb1GJ3Fy
0vV+RbrQbG11e8vcqYoiCRB16jJXMVi82he+wC0uXsvb3kjaCY/5PCc7hYrT42bThQ9u
8B+3uccSlYUa5HQtU5dSRjUa+JgWPqw30/mVDq8RhhgmZyDTChYfFfgIMWTGTc+ZzjfQ
mMMyrnFGC8pOrBJ1oelF1lET+WEhmLY/Qw5wFs2RZFyyFAoDDlCTj7xkX5TVyG18wpVR
tOUqe/nLYA6zmMecgQQAADs=
--Alternative.Boundary.kfzC3860M2Yt0l6UVO
Content-type: text/richtext; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
As you can see from the above picture, the Andrew users sees (and tends to com=
pose) a multimedia message at the top-level. If you treated the first part --=
in this case richtext -- as being the whole message, you'd end up with an inc=
oherent partial message, followed by some attachments that really ought to be =
viewed in sequential order if you're to have any hope of making sense of the m=
essage. Other mail readers have a model that there's a main part -- typically=
text -- with attachments, but in Andrew there's no real such notion, although=
you can do attachments, e.g.:
--Alternative.Boundary.kfzC3860M2Yt0l6UVO
Content-type: application/octet-stream;
name="sample"
Content-Description: An attachment
Content-Transfer-Encoding: quoted-printable
A simple text file attachment.
--Alternative.Boundary.kfzC3860M2Yt0l6UVO
Content-type: text/richtext; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Anyway, I'm hoping that by including the picture of what my screen looked like=
when composing this, I'll give people in the attachment-oriented world a bett=
er idea of what things might look like from the other side of the fence... --=
Nathaniel
--Alternative.Boundary.kfzC3860M2Yt0l6UVO--
--Interpart.Boundary.kfzC3860M2YtMl6UZX--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14460;
21 May 93 17:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14454;
21 May 93 17:12 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa18721;
21 May 93 17:12 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA14664; Fri, 21 May 93 17:01:37 EDT
Received: from alpha.Xerox.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA14660; Fri, 21 May 93 17:01:36 EDT
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11738>; Fri, 21 May 1993 14:01:18 PDT
Received: by holmes.parc.xerox.com id <16134>; Fri, 21 May 1993 14:01:08 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
via MS.5.6.holmes.parc.xerox.com.sun4_41;
Fri, 21 May 1993 14:00:54 -0700 (PDT)
Message-Id: <8fzIA6EB0KGWB6cJZz@holmes.parc.xerox.com>
Date: Fri, 21 May 1993 14:00:54 PDT
X-Orig-Sender: Bill Janssen
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Bill Janssen
To: ietf-822@dimacs.rutgers.edu
Subject: list of MIME content-types?
What is the procedure to use to obtain a list of all
currently-registered MIME content-types?
Bill
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17422;
21 May 93 19:40 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17416;
21 May 93 19:40 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa22779;
21 May 93 19:40 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA15168; Fri, 21 May 93 19:23:25 EDT
Received: from SIGURD.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA15164; Fri, 21 May 93 19:23:23 EDT
Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.3-0 #1992)
id <01GYFLYL7CUO8ZDVUL@SIGURD.INNOSOFT.COM>; Fri, 21 May 1993 16:23:10 PDT
Date: Fri, 21 May 1993 16:22:56 -0700 (PDT)
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Ned Freed
Subject: Re: list of MIME content-types?
In-Reply-To: Your message dated "Fri, 21 May 1993 14:00:54 -0700 (PDT)"
<8fzIA6EB0KGWB6cJZz@holmes.parc.xerox.com>
To: Bill Janssen
Cc: ietf-822@dimacs.rutgers.edu
Message-Id: <01GYFZ5L9BO48ZDVUL@SIGURD.INNOSOFT.COM>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
> What is the procedure to use to obtain a list of all
> currently-registered MIME content-types?
Contact IANA, per the RFC.
Ned
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18876;
21 May 93 21:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18870;
21 May 93 21:11 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa24910;
21 May 93 21:11 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA15383; Fri, 21 May 93 20:33:12 EDT
Received: from alpha.Xerox.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA15379; Fri, 21 May 93 20:33:10 EDT
Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <12005>; Fri, 21 May 1993 17:32:53 PDT
Received: by holmes.parc.xerox.com id <16134>; Fri, 21 May 1993 17:32:50 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41
via MS.5.6.holmes.parc.xerox.com.sun4_41;
Fri, 21 May 1993 17:32:37 -0700 (PDT)
Message-Id:
Date: Fri, 21 May 1993 17:32:37 PDT
X-Orig-Sender: Bill Janssen
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Bill Janssen
To: Bill Janssen ,
Ned Freed
Subject: Re: list of MIME content-types?
Cc: ietf-822@dimacs.rutgers.edu
In-Reply-To: <01GYFZ5L9BO48ZDVUL@SIGURD.INNOSOFT.COM>
References: <01GYFZ5L9BO48ZDVUL@SIGURD.INNOSOFT.COM>
Excerpts from direct: 21-May-93 Re: list of MIME content-ty.. Ned
Freed@sigurd.innosof (136*)
> > What is the procedure to use to obtain a list of all
> > currently-registered MIME content-types?
> Contact IANA, per the RFC.
> Ned
Sorry, I was unclear. The question was more, "Does the IANA export a
periodically updated document listing all the registered MIME types, or
does one send mail to iana@isi.edu every time one wishes to know what
they currently are?". The RFC doesn't say; it just specifies the
procedure for registering new types.
Bill
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19036;
21 May 93 21:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19030;
21 May 93 21:39 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa25365;
21 May 93 21:39 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA15456; Fri, 21 May 93 20:50:27 EDT
Received: from SIGURD.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA15452; Fri, 21 May 93 20:50:25 EDT
Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.3-0 #1992)
id <01GYG1KEB55S8ZDVUM@SIGURD.INNOSOFT.COM>; Fri, 21 May 1993 17:50:10 PDT
Date: Fri, 21 May 1993 17:48:03 -0700 (PDT)
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Ned Freed
Subject: Re: list of MIME content-types?
In-Reply-To: Your message dated "Fri, 21 May 1993 17:32:37 -0700 (PDT)"
To: Bill Janssen
Cc: Bill Janssen ,
Ned Freed , ietf-822@dimacs.rutgers.edu
Message-Id: <01GYG27FJMI48ZDVUM@SIGURD.INNOSOFT.COM>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
> Sorry, I was unclear. The question was more, "Does the IANA export a
> periodically updated document listing all the registered MIME types, or
> does one send mail to iana@isi.edu every time one wishes to know what
> they currently are?". The RFC doesn't say; it just specifies the
> procedure for registering new types.
I hope that the list starts appearing as part of the assigned numbers stuff:
i.e. as an RFC. However, it is not for us to mandate this. IANA gets to select
the specifics. Until the list starts appearing as an RFC or some other
mechanism is selected for its distribution I think the only way to get it
is from IANA directly.
Ned
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11804;
23 May 93 17:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11798;
23 May 93 17:51 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa08613;
23 May 93 17:51 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA03155; Sun, 23 May 93 17:31:35 EDT
Received: from aun.uninett.no by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA03151; Sun, 23 May 93 17:31:34 EDT
X400-Received: by mta aun.uninett.no in /PRMD=uninett/ADMD= /C=no/; Relayed;
Sun, 23 May 1993 23:31:18 +0200
X400-Received: by /PRMD=uninett/ADMD= /C=no/; Relayed;
Sun, 23 May 1993 23:31:13 +0200
X400-Received: by /PRMD=uninett/ADMD= /C=no/; Relayed;
Sun, 23 May 1993 23:31:10 +0200
Date: Sun, 23 May 1993 23:31:10 +0200
X400-Originator: harald.t.alvestrand@delab.sintef.no
X400-Recipients: non-disclosure:;
X400-Mts-Identifier: [/PRMD=uninett/ADMD= /C=no/;930523233110]
X400-Content-Type: P2-1984 (2)
Content-Identifier: 10289
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Harald Tveit Alvestrand
Message-Id:
To: rens
Cc: ietf-822
In-Reply-To: <9305201722.AA14261@stimpys.imsi.com>
Subject: Re: New type suggested: Multipart/Related
Well, I for one did not think the Content-disposition approach cleaner.
(obviously....)
On the DAG issue, I seem to be somewhat clueless:
How is it possible to have a containment hierarchy that is not a DAG?
In hypertext, you obviously want to be able to go in circles, but I did
not think that all possible relationships between body parts were
covered by either Content-disposition or Mainpart=.
Looking forward to your draft (since I do not understand the
Content-disposition).
Harald A
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25772;
27 May 93 0:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25766;
27 May 93 0:50 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa05340;
27 May 93 0:50 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA19158; Thu, 27 May 93 00:03:46 EDT
Received: from ANDREW.CMU.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA19154; Thu, 27 May 93 00:03:44 EDT
Received: by andrew.cmu.edu (5.54/3.15) id for ietf-822@dimacs.rutgers.edu; Thu, 27 May 93 00:03:34 EDT
Received: via switchmail; Thu, 27 May 1993 00:03:32 -0400 (EDT)
Received: from hogtown.andrew.cmu.edu via qmail
ID ;
Thu, 27 May 1993 00:03:26 -0400 (EDT)
Received: from hogtown.andrew.cmu.edu via qmail
ID ;
Thu, 27 May 1993 00:03:23 -0400 (EDT)
Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411
via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411;
Thu, 27 May 1993 00:03:17 -0400 (EDT)
Message-Id:
Date: Thu, 27 May 1993 00:03:17 -0400 (EDT)
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: John Gardiner Myers
To: ietf-822@dimacs.rutgers.edu
Subject: MIME-Version is useless
The MIME-Version: header serves no purpose. In RFC 1341 it was mostly
a harmless appendix, but in the April Internet Draft, it has spread a
number of special-case warts throughout the standard. It is becoming
burdensome and should be removed from the MIME standard.
The MIME-Version: header presumably has two purposes. One, its
presence is an indication that a message was composed in compliance
with some MIME standard. Two, some theoretical future standard may
change the value of the header, making the header indicate which of
several competing message format standards the composer is in
compliance with.
The first purpose (indicating a message was composed in compliance
with some MIME standard) is already served by the various Content-*
headers. While some composers which existed prior to the MIME
standard would generate Content-Type: headers, none of these would
generate Content-Type: values which are at variance with the
registered MIME content types. If a message has Content-* headers,
it is safe to interpret them according to the MIME spec. In fact, RFC
1341 does not permit MIME readers to ignore Content-* headers in the
absence of a MIME-Version: header.
The only semantic that RFC1341 gives to the presence of a
MIME-Version: header involves the case where there is no Content-Type:
header. In the presence of a MIME-Version: header one may presuume
that the contents of a message lacking a Content-Type: header are
really "text/plain; charset=us-ascii", as opposed to the contents
being indeterminate but still having to be interpreted as "text/plain;
charset=us-ascii". Were the MIME-Version: header not required, the
composer could have more directly stated its intent by writing a
"Content-Type: text" header instead of the MIME-Version: header.
As for the possiblilty that some future standard will change the value
of the MIME-Version, I maintain that either this will never happen or
that should it happen, there will be no difference in interpretation
of messages which is based soely on the value of the MIME-Version:
header.
The MIME and RFC-822 standards supply ample alternate mechanisms for
extension. It would be silly to assign a semantic meaning to
MIME-Version when that meaning can be more cleanly assigned to a new
header, content type, or parameter. The fact that the April Internet
Draft relys solely on these mechanisms and doesn't change the value of
the MIME-Version: header is a strong indication that these mechanisms
are sufficient and the MIME-Version value will never change.
Nor can there be an incompatable change for the MIME-Version header to
signal. Due to the fairly substantial installed base of RFC 1341
readers, any future standard is constrained to specify a message format
that can be reasonably handled by an RFC 1341 reader. Were it to do
otherwise, it would have great difficulty getting through the IETF
process.
In RFC 1341, the MIME-Version: header is a useless, but harmless
appendage. An RFC 1341 composer is required to generate the header,
but a reader is free to ignore it when reading.
The April Internet Draft adds two warts related to the MIME-Version
header. The lesser of which is to require interpretation of
message/partial to handle MIME-Version: as a special case.
The more serious of which is the section describing what happens if
the MIME-Version: header exists, but has a value other than "1.0".
The standard states that the message "cannot be assumed to conform
with this specification", giving the implementation all sorts of
leeway as to what to do when this happens. Furthermore, it encourages
the reader to "check the version number and at least warn the user if
an unrecognized MIME-version is encountered".
Should the MIME-Version: acutally change, software conforming to the
April Internet Draft will start behaving in all sorts of unpredictable
manners when encountering messages with the newer MIME-Version. At
the very least, they will continually spitting out incomprehensible
warning messages. (I challenge anyone to devise a warning message
suitable for a non-technical user.)
This header should be buried. All references to MIME-Version: should
be removed from the standard prior to its publication.
--
_.John G. Myers Internet: jgm+@CMU.EDU
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01136;
27 May 93 4:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01130;
27 May 93 4:44 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa02736;
27 May 93 4:44 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA20906; Thu, 27 May 93 04:07:28 EDT
Received: from tosca.er.sintef.no by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA20902; Thu, 27 May 93 04:07:25 EDT
Received: from delab.sintef.no by tosca.er.sintef.no with SMTP (PP)
id <29639-0@tosca.er.sintef.no>; Thu, 27 May 1993 10:07:13 +0200
Received: by boheme.er.sintef.no (4.1/DELAB-1.7.n) id AA15337;
Thu, 27 May 93 10:07:09 +0200
Message-Id: <9305270807.AA15337@boheme.er.sintef.no>
Date: Thu, 27 May 93 10:07:09 +0200
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Harald.T.Alvestrand@delab.sintef.no
To: ietf-822@dimacs.rutgers.edu
Subject: nordunet.redist.ietf #4138 - Re: Triple DES
I found this example of why I think we need to be able to hide
"optional but not essential" header-like body parts.
That is what the multipart/related;header= construct set out to do.
So far, there has been next to no comments on this aspect.
In article <9305242343.AA17749@xap.xyplex.com>, rlstewart@eng.xyplex.COM (Bob Stewart) writes:
|> >-----BEGIN PRIVACY-ENHANCED MESSAGE-----
|> >Proc-Type: 4,MIC-CLEAR
|> >Content-Domain: RFC822
|> >Originator-Certificate:
|> > MIIBxTCCAWECARIwDQYJKoZIhvcNAQECBQAwTTELMAkGA1UEBhMCVVMxIDAeBgNV
|> > BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMRwwGgYDVQQLExNQZXJzb25hIENl
|> > cnRpZmljYXRlMB4XDTkzMDQxMjIyNTI1N1oXDTk1MDQxMjA1MDAwMFowYzELMAkG
|> > A1UEBhMCVVMxIDAeBgNVBAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMRwwGgYD
|> > VQQLExNQZXJzb25hIENlcnRpZmljYXRlMRQwEgYDVQQDEwtSYXltb25kIExhdTB5
|> > MAoGBFUIAQECAgMAA2sAMGgCYQC4Lq5eHwr4u4bY7VggmpOwmyqhq9nMVR7VuaUy
|> > 4MOTPLPHi/dZM5E2gdODG1uV2YoGDNNTuVFRO4osQwxTOWMt9oEththrXOYI6oZ8
|> > lzyYfmgLVL15S7HCV/GYJdlPuO0CAwEAATANBgkqhkiG9w0BAQIFAANPAAUVNpom
|> > zLBp6r72gqG6bBU1eFbv9bNKk4WSQCXYRbulGmhyLCXItASYloprlBxKHm8EP178
|> > P8z1rlbRNAoWw2G5q2550I6UUiJ5OOkVwB==
|> >MIC-Info: RSA-MD5,RSA,
|> > lTseoQ7YapjkRdsuA8YgFUP2MILA7WIMhLwyZVo2dvmYyeRewagzLzlm1cTwU74n
|> > RIsG50Fa/RJmzxukw08ojOVuBeEfTO/h263Fm5lhvHrv1FHKuW2sCl5JgzhswK8d
|>
|> I'm in danger of getting really nasty. How nice for Richard Lau that he is so
|> important that his mail is authenticated. Is such a glop of cybercrud to
|> become standard at the front of every message we peasants get from the
|> authenticated elite.
|>
|> Will you guys go fluff your egos elsewhere.
|>
|> Bob
--
Harald Tveit Alvestrand
Harald.Alvestrand@delab.sintef.no
C=no;PRMD=uninett;O=sintef;OU=delab;S=alvestrand;G=harald
+47 7 59 70 94
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01912;
27 May 93 7:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01906;
27 May 93 7:17 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa05160;
27 May 93 7:17 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA21338; Thu, 27 May 93 07:02:10 EDT
Received: from faline.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA21334; Thu, 27 May 93 07:02:09 EDT
Received: from guppylake (guppylake.bellcore.com) by faline.bellcore.com (4.1/4.7)
id for ietf-822@dimacs.rutgers.edu; Thu, 27 May 93 07:02:00 EDT
Received: by guppylake (4.1/4.7)
id for jgm+@cmu.edu; Thu, 27 May 93 07:02:36 EDT
Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.guppylake.noname.sun4.41
via MS.5.6.guppylake.noname.sun4_41;
Thu, 27 May 1993 07:02:36 -0400 (EDT)
Message-Id:
Date: Thu, 27 May 1993 07:02:36 -0400 (EDT)
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Nathaniel Borenstein
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: ietf-822@dimacs.rutgers.edu, John Gardiner Myers
Subject: Re: MIME-Version is useless
In-Reply-To: Message from "John Gardiner Myers " dated "Thu, 27 May 1993 00:03:17 -0400 (EDT)"
No it isn't. It's merely almost useless.
This was discussed at the last IETF meeting. If we had been smart and
specified how a UA should handle MIME-Versions other than 1.0 -- for
example, to say that the "1" was critical and the "0" was informational
-- it could have been useful. But we didn't, and there are already
implementations out there that won't decode the MIME data if any variant
on "1.0" is used. This is too bad, but it's done. However, it still
give you one very useful bit of information, namely that the message was
indeed composed with MIME in mind.
> While some composers which existed prior to the MIME
> standard would generate Content-Type: headers, none of these would
> generate Content-Type: values which are at variance with the
> registered MIME content types. If a message has Content-* headers,
> it is safe to interpret them according to the MIME spec.
This is where you're wrong, my friend. I know of very very large
company that prefers not to be mentioned in this context. They run a
large commercial mail service with an SMTP gateway. They've been using
"Content-type: text" and some less common values for years, and they
told me they found "MIME-Version" critical in deciding whether or not to
do MIME translations. I don't remember all the details, but I think
the main thing is that their native transport is 8-bit, and thus they've
had different transport encoding requirements. This means that
MIME-Version helps them tell whether or not they might need to do an
encoding without scanning the whole message. In particular, if there is
MIME-Version but no Content-Transfer-Encoding of "8bit" or "binary", it
is 7-bit safe.
> In fact, RFC
> 1341 does not permit MIME readers to ignore Content-* headers in the
> absence of a MIME-Version: header.
How do you come to thatt reading of it?
> The only semantic that RFC1341 gives to the presence of a
> MIME-Version: header involves the case where there is no Content-Type:
> header. In the presence of a MIME-Version: header one may presuume
> that the contents of a message lacking a Content-Type: header are
> really "text/plain; charset=us-ascii", as opposed to the contents
> being indeterminate but still having to be interpreted as "text/plain;
> charset=us-ascii". Were the MIME-Version: header not required, the
> composer could have more directly stated its intent by writing a
> "Content-Type: text" header instead of the MIME-Version: header.
Umm, not quite right. I believe MIME makes it clear -- as did RFC 822
-- that even in the ABSENCE of MIME-Version, you've got plain ascii
text. So this is actually not a need for MIME-Version.
> As for the possiblilty that some future standard will change the value
> of the MIME-Version, I maintain that either this will never happen or
> that should it happen, there will be no difference in interpretation
> of messages which is based soely on the value of the MIME-Version:
> header.
Alas, the lack of semantics guarantees that you are right. Actually,
this level of stability is probably a good thing anyway, but I do wish
the consequences had been forseen.....
> The MIME and RFC-822 standards supply ample alternate mechanisms for
> extension. It would be silly to assign a semantic meaning to
> MIME-Version when that meaning can be more cleanly assigned to a new
> header, content type, or parameter. The fact that the April Internet
> Draft relys solely on these mechanisms and doesn't change the value of
> the MIME-Version: header is a strong indication that these mechanisms
> are sufficient and the MIME-Version value will never change.
We wanted to change it. That's when we found we couldn't do so without
breaking some existing implementations!
> The more serious of which is the section describing what happens if
> the MIME-Version: header exists, but has a value other than "1.0".
> The standard states that the message "cannot be assumed to conform
> with this specification", giving the implementation all sorts of
> leeway as to what to do when this happens. Furthermore, it encourages
> the reader to "check the version number and at least warn the user if
> an unrecognized MIME-version is encountered".
Sigh. These are weasel words, but they can't really do anything to
close this barn door because the horse has already escaped. The truth
is that we couldn't come up with any meaningful guidance for this case,
in the presence of widely-varying existing implementations. There's at
least one MIME implementation that will consider the following to be a
non-MIME message:
MIME-Version: 1.0 (as interreted by jgm)
Comments such as this are definitely legal, and the main point of that
note in my mind was to point this out to future implementors.
> This header should be buried. All references to MIME-Version: should
> be removed from the standard prior to its publication.
I disagree. It is a wart, but still serves two useful purposes. One,
as I said above, is in distinguishing MIME messages from pre-MIME uses
of Content-type. The other is that its presence in a message you send
advertises, to your recipients, that it is safe to send you MIME. All
in all, it isn't what we hoped it would be, but that may be for the
best, and it is still useful. -- Nathaniel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03655;
27 May 93 8:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03649;
27 May 93 8:32 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa07440;
27 May 93 8:32 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA21351; Thu, 27 May 93 07:06:22 EDT
Received: from faline.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA21347; Thu, 27 May 93 07:06:21 EDT
Received: from guppylake (guppylake.bellcore.com) by faline.bellcore.com (4.1/4.7)
id for ietf-822@dimacs.rutgers.edu; Thu, 27 May 93 07:05:34 EDT
Received: by guppylake (4.1/4.7)
id for Harald.T.Alvestrand@delab.sintef.no; Thu, 27 May 93 07:06:07 EDT
Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.guppylake.noname.sun4.41
via MS.5.6.guppylake.noname.sun4_41;
Thu, 27 May 1993 07:06:06 -0400 (EDT)
Message-Id:
Date: Thu, 27 May 1993 07:06:06 -0400 (EDT)
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Nathaniel Borenstein
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: ietf-822@dimacs.rutgers.edu, Harald.T.Alvestrand@delab.sintef.no
Subject: Re: nordunet.redist.ietf #4138 - Re: Triple DES
In-Reply-To: Message from "Harald.T.Alvestrand@delab.sintef.no" dated "Thu, 27 May 93 10:07:09 +0200"
Excerpts from mail: 27-May-93 nordunet.redist.ietf #4138 ..
Harald.T.Alvestrand@dela (537)
> I found this example of why I think we need to be able to hide
> "optional but not essential" header-like body parts.
> That is what the multipart/related;header= construct set out to do.
If you read the MIME-PEM draft, you'll see that this is solved there
with "multipart/pem", which I still tend to think is better than
"multipart/related" because I don't see where a general purpose
"related" construct tells you enough to be useful anyway, and a new
multipart subtype makes it easier to switch on the type, in the style of
metamail. But I'm not a fanatic on this score.
> So far, there has been next to no comments on this aspect.
Well, I've made the above comment as often as people would listen. :-)
But as to your specific proposal for multipart/related, I must confess
that I've been carrying it in my briefcase for a week now and still
haven't read it due to being swamped. But I will get to it soon! --
Nathaniel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04409;
27 May 93 8:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04401;
27 May 93 8:57 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa08289;
27 May 93 8:57 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA21439; Thu, 27 May 93 07:41:53 EDT
Received: from aun.uninett.no by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA21435; Thu, 27 May 93 07:41:50 EDT
X400-Received: by mta aun.uninett.no in /PRMD=uninett/ADMD= /C=no/; Relayed;
Thu, 27 May 1993 13:40:50 +0200
X400-Received: by /PRMD=uninett/ADMD= /C=no/; Relayed;
Thu, 27 May 1993 13:40:33 +0200
X400-Received: by /PRMD=uninett/ADMD= /C=no/; Relayed;
Thu, 27 May 1993 13:39:11 +0200
Date: Thu, 27 May 1993 13:39:11 +0200
X400-Originator: harald.t.alvestrand@delab.sintef.no
X400-Recipients: non-disclosure:;
X400-Mts-Identifier: [/PRMD=uninett/ADMD= /C=no/;930527133911]
X400-Content-Type: P2-1984 (2)
Content-Identifier: 10335
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Harald Tveit Alvestrand
Message-Id:
To: Nathaniel Borenstein
Cc: ietf-822@dimacs.rutgers.edu
In-Reply-To:
Subject: Re: nordunet.redist.ietf #4138 - Re: Triple DES
Nathaniel,
the argument I was making was really:
If I get multipart/foo, and don't understand /foo, I have to display
it as multipart/mixed, and then I find application/foo, and have
to display *that* as application/octet-stream, which may or may not
strike the reader as "a glop of cybercrud".
If I get multipart/related;header=application/foo, I can display this as
multipart/mixed, with the proviso that when I encounter application/foo,
I can display it as
(header application/foo ignored)
(or equivalent) which may be a little less "cybercrud" than the default handling of application/octet-stream.
(In Metamail, I think the default is to ask the recipient if he wants
to save it to a file, view it as ASCII or ignore it, not?)
Harald A
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04728;
27 May 93 9:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04722;
27 May 93 9:17 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa08898;
27 May 93 9:17 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA21765; Thu, 27 May 93 08:19:15 EDT
Received: from dorner.slip.uiuc.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA21759; Thu, 27 May 93 08:19:11 EDT
Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA01317
(5.65c/IDA-1.4.4 for ietf-822@dimacs.rutgers.edu); Thu, 27 May 1993 07:20:33 -0500
Message-Id: <199305271220.AA01317@dorner.slip.uiuc.edu>
X-Sender: sdorner@dorner.slip.uiuc.edu
Mime-Version: 1.0
Content-Type: text/plain
Date: Thu, 27 May 1993 07:18:59 -0500
To: ietf-822@dimacs.rutgers.edu
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Steve Dorner
Subject: Re: MIME-Version is useless
At 7:02 AM 5/27/93 -0400, Nathaniel Borenstein wrote:
>We wanted to change it. That's when we found we couldn't do so without
>breaking some existing implementations!
Isn't it a little too early in the process to worry *too* much about
breaking existing MIME implementations? I'd hate to see useful changes
eschewed because of the choices of early implementors.
--
Steve Dorner, Qualcomm Inc.
Oldthinkers unbellyfeel IngSoc.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06260;
27 May 93 10:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06254;
27 May 93 10:12 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa10930;
27 May 93 10:12 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA21974; Thu, 27 May 93 08:43:33 EDT
Received: from faline.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA21970; Thu, 27 May 93 08:43:32 EDT
Received: from guppylake (guppylake.bellcore.com) by faline.bellcore.com (4.1/4.7)
id for ietf-822@dimacs.rutgers.edu; Thu, 27 May 93 08:43:28 EDT
Received: by guppylake (4.1/4.7)
id for ietf-822@dimacs.rutgers.edu; Thu, 27 May 93 08:44:05 EDT
Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.guppylake.noname.sun4.41
via MS.5.6.guppylake.noname.sun4_41;
Thu, 27 May 1993 08:44:04 -0400 (EDT)
Message-Id:
Date: Thu, 27 May 1993 08:44:04 -0400 (EDT)
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Nathaniel Borenstein
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: Harald Tveit Alvestrand
Subject: Re: nordunet.redist.ietf #4138 - Re: Triple DES
Cc: ietf-822@dimacs.rutgers.edu
In-Reply-To:
References:
Excerpts from mail: 27-May-93 Re: nordunet.redist.ietf #4.. Harald T.
Alvestrand@del (780)
> which may be a little less "cybercrud" than the default handling of
application/octet-stream.
Yeah, I guess the argument comes down to whether or not you think
there's enough of a difference here to care about it. It doesn't really
sound all that different to me. And while I'm trying very hard not to
judge the format proposals operationally -- i.e. in terms of what it
will be like to implement them in metamail, Andrew, etc. -- I really do
think that this makes implementation harder. Metamail may be the worst
case, but there, instead of switching on a type name (multipart/foo) you
have to switch on a parameter (IF multipart/header, switch on header
parameter). Now, metamail can already do this, so I'm not really just
being lazy here, but it now becomes harder for users to configure things
too; instead of just adding a mailcap line for multipart/foo, they have
to add [yet another] mailcap line for multipart/header with a "test=..."
clause. Or I could add specialized syntax for multipart/related (yech).
All of this might be worth doing for a significant benefit, but I just
don't see the benefit as being worth the cost.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13828;
27 May 93 16:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13822;
27 May 93 16:54 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa25142;
27 May 93 16:54 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA28835; Thu, 27 May 93 16:17:43 EDT
Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA28831; Thu, 27 May 93 16:17:42 EDT
Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7)
id for ietf-822@dimacs.rutgers.edu; Thu, 27 May 93 16:17:40 EDT
Received: by greenbush.bellcore.com (4.1/4.7)
id for ietf-822@dimacs.rutgers.edu; Thu, 27 May 93 16:17:39 EDT
Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.greenbush.galaxy.sun4.41
via MS.5.6.greenbush.galaxy.sun4_41;
Thu, 27 May 1993 16:17:35 -0400 (EDT)
Message-Id:
Date: Thu, 27 May 1993 16:17:35 -0400 (EDT)
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Nathaniel Borenstein
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: harald.t.alvestrand@delab.sintef.no, ietf-822@dimacs.rutgers.edu
Subject: Multipart/related proposal
OK, I've finally read Harald's draft, and in addition to the general
comments I made earlier, I have one or two more things to add:
-- Section 3.1: It isn't clear what syntax you'll use when you list
multiple header types, which you say is OK in the 3rd to last paragraph.
-- I'm troubled by the advice in the last paragraph of that same
section, which I'm not sure I understand. Does this mean tha tif
there's an embedded plain text part, it won't be shown? How do we know
that's the right thing to do by default? There are all sorts of
semantic differences that are papered over here, but will vary for
different "related" multipart types. For example, with some types, the
act of displaying the "main" type might automatically cause
program-displayed control of the other types, so they should not be
displayed separately. With some, just the opposite might be the case.
I don't see anything here that really tells me whether or not I shoudl
display each part separately in addition to (or after, or in parallel
with) the "main" or "header" types.`
-- I'm also troubled by the fact that "mainpart" and "header" are
different. I have at least one application in mind where they'd be the
same thing. In this application, if you have a viewer for the "special"
type, you display ONLY it, because it will display the other parts as
needed. Does this make it a header, a mainpart, or both?
My gut feeling is still that the semantics of each multipart/related
"header" will be so different one from another that they might as well
each be their own multipart subtype. -- Nathaniel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16163;
27 May 93 19:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16157;
27 May 93 19:18 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa29206;
27 May 93 19:18 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA00165; Thu, 27 May 93 18:07:57 EDT
Received: from black-ice.cc.vt.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA00161; Thu, 27 May 93 18:07:56 EDT
Received: from LOCALHOST by black-ice.cc.vt.edu (AIX 3.2/UCB 5.64/4.03)
id AA18029; Thu, 27 May 1993 18:07:44 -0400
Message-Id: <9305272207.AA18029@black-ice.cc.vt.edu>
To: Nathaniel Borenstein
Cc: ietf-822@dimacs.rutgers.edu
Subject: Re: Multipart/related proposal
In-Reply-To: Your message of "Thu, 27 May 1993 16:17:35 EDT."
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 27 May 1993 18:07:43 +22312049
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Valdis Kletnieks
On Thu, 27 May 1993 16:17:35 EDT, you said:
> My gut feeling is still that the semantics of each multipart/related
> "header" will be so different one from another that they might as well
> each be their own multipart subtype. -- Nathaniel
I tend to agree. Is there *really* a problem with us producing
seperate RFC's specifying 'multipart/pem', 'multipart/attachements',
'multipart/ChainSawWidget', etc? Yes, I realize that wanton
proliferation of types is frowned upon, but I think it would be
a win overall if the 3 or 5 most common varieties had their
own subtypes with specified semantics, rather than trying to
create a one-size-fits-all /related. If anything, 'multipart/related'
is really a misnomer. After all - how often do you send several
*unrelated* pieces of anything in one e-mail? ;) As such, it
strikes me as being just about as informative as 'appplication/octet-stream' is...
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24505;
28 May 93 1:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24499;
28 May 93 1:32 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa07151;
28 May 93 1:32 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA03484; Fri, 28 May 93 00:35:28 EDT
Received: from att-out.att.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA03480; Fri, 28 May 93 00:35:27 EDT
Message-Id: <9305280435.AA03480@dimacs.rutgers.edu>
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "t.l.hansen"
To: ietf-822@dimacs.rutgers.edu
Date: 28 May 1993 0:26 EDT
Subject: Re: Multipart/related proposal
References: <9305272207.AA18029@black-ice.cc.vt.edu>
< From: Valdis Kletnieks
<
< If anything, 'multipart/related' is really a misnomer. After all - how
< often do you send several *unrelated* pieces of anything in one e-mail? ;)
< As such, it strikes me as being just about as informative as
< 'appplication/octet-stream' is...
It's a different degree of relatedness, however. We need to somehow
differentiate between the multipart which comes from in-stream parts (a
hebrew sentence in the middle of an otherwise english paragraph) and the
multipart which comes from the attachment model. Whether it's called
multipart/related or something else is really irrelevent, as long as the
functionality is provided. If you can come up with a better name, great.
Tony
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24577;
28 May 93 1:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24571;
28 May 93 1:43 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa07561;
28 May 93 1:43 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA03584; Fri, 28 May 93 01:06:07 EDT
Received: from att-out.att.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA03580; Fri, 28 May 93 01:06:06 EDT
Message-Id: <9305280506.AA03580@dimacs.rutgers.edu>
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "t.l.hansen"
To: jgm+@cmu.edu
Cc: ietf-822@dimacs.rutgers.edu
Date: 28 May 1993 0:56 EDT
Subject: re: MIME-Version is useless
References:
< The MIME-Version: header serves no purpose. In RFC 1341 it was mostly a
< harmless appendix, but in the April Internet Draft, it has spread a number
< of special-case warts throughout the standard. It is becoming burdensome
< and should be removed from the MIME standard.
< ...
< The first purpose (indicating a message was composed in compliance with
< some MIME standard) is already served by the various Content-* headers.
< While some composers which existed prior to the MIME standard would
< generate Content-Type: headers, none of these would generate Content-Type:
< values which are at variance with the registered MIME content types. If a
< message has Content-* headers, it is safe to interpret them according to
< the MIME spec. In fact, RFC 1341 does not permit MIME readers to ignore
< Content-* headers in the absence of a MIME-Version: header.
I disagree strongly with this sentiment. If there is no MIME-Version:
header, the message is not in MIME format, and expecting the Content-*:
headers to be in comformance with the MIME format when there is no
MIME-Version: header is asking too much. The Content-Type: header has been
around for a LONG time, and many providers have done various things with it.
Unfortunately, these things are NOT necessarily compatible with MIME.
If it doesn't say it's MIME, then it's not MIME. Sorry, but it's true.
Tony Hansen
hansen@pegasus.att.com, tony@attmail.com
att!pegasus!hansen, attmail!tony
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02734;
28 May 93 8:40 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02728;
28 May 93 8:40 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa07326;
28 May 93 8:40 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA05528; Fri, 28 May 93 08:22:18 EDT
Received: from dorner.slip.uiuc.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA05524; Fri, 28 May 93 08:22:14 EDT
Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA02221
(5.65c/IDA-1.4.4 for ietf-822@dimacs.rutgers.edu); Fri, 28 May 1993 07:23:43 -0500
Message-Id: <199305281223.AA02221@dorner.slip.uiuc.edu>
X-Sender: sdorner@dorner.slip.uiuc.edu
Mime-Version: 1.0
Content-Type: text/plain
Date: Fri, 28 May 1993 07:22:09 -0500
To: ietf-822@dimacs.rutgers.edu
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Steve Dorner
Subject: Re: Multipart/related proposal
At 12:26 AM 5/28/93 -0400, t.l.hansen wrote:
>Whether it's called
>multipart/related or something else is really irrelevent, as long as the
>functionality is provided. If you can come up with a better name, great.
Like Content-Disposition? :-)
Personally, I'd rather the individual parts were labelled
(Content-Disposition) rather than putting all this stuff in the multipart
header (Multipart/Related). It seems much simpler and more
straightforward.
And I agree with the sentiment that the semantics of these structured
multipart entities will vary so much that it's hard to imagine a general
mechanism that can describe how to handle them. I think explicit subtypes
of multipart are going to be needed.
--
Steve Dorner, Qualcomm Inc.
Oldthinkers unbellyfeel IngSoc.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04362;
28 May 93 9:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04356;
28 May 93 9:43 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa09385;
28 May 93 9:43 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA06127; Fri, 28 May 93 09:12:20 EDT
Received: from aun.uninett.no by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA06123; Fri, 28 May 93 09:12:16 EDT
X400-Received: by mta aun.uninett.no in /PRMD=uninett/ADMD= /C=no/; Relayed;
Fri, 28 May 1993 15:11:38 +0200
X400-Received: by /PRMD=uninett/ADMD= /C=no/; Relayed;
Fri, 28 May 1993 15:11:33 +0200
X400-Received: by /PRMD=uninett/ADMD= /C=no/; Relayed;
Fri, 28 May 1993 15:11:30 +0200
Date: Fri, 28 May 1993 15:11:30 +0200
X400-Originator: harald.t.alvestrand@delab.sintef.no
X400-Recipients: non-disclosure:;
X400-Mts-Identifier: [/PRMD=uninett/ADMD= /C=no/;930528151130]
X400-Content-Type: P2-1984 (2)
Content-Identifier: 10379
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Harald Tveit Alvestrand
Message-Id:
To: "(Steve Dorner)"
Cc: ietf-822@dimacs.rutgers.edu
In-Reply-To: <199305281223.AA02221@dorner.slip.uiuc.edu>
Subject: Re: Multipart/related proposal
OK, I bow to the storm of lukewarm opinion :-)
The multipart/related idea will *not* be submitted as an
Internet-Draft.
Harald A
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06924;
28 May 93 11:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06918;
28 May 93 11:13 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa12491;
28 May 93 11:13 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA07191; Fri, 28 May 93 10:31:44 EDT
Received: from ANDREW.CMU.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA07187; Fri, 28 May 93 10:31:42 EDT
Received: by andrew.cmu.edu (5.54/3.15) id for ietf-822@dimacs.rutgers.edu; Fri, 28 May 93 10:31:38 EDT
Received: via switchmail; Fri, 28 May 1993 10:31:37 -0400 (EDT)
Received: from hogtown.andrew.cmu.edu via qmail
ID ;
Fri, 28 May 1993 10:29:46 -0400 (EDT)
Received: from hogtown.andrew.cmu.edu via qmail
ID ;
Fri, 28 May 1993 10:29:36 -0400 (EDT)
Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411
via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411;
Fri, 28 May 1993 10:29:31 -0400 (EDT)
Message-Id:
Date: Fri, 28 May 1993 10:29:31 -0400 (EDT)
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: John Gardiner Myers
To: ietf-822@dimacs.rutgers.edu
Subject: Re: MIME-Version is useless
In-Reply-To:
References:
Beak: Is
hansen@pegasus.att.com (t.l.hansen) writes:
> I disagree strongly with this sentiment. If there is no MIME-Version:
> header, the message is not in MIME format,
RFC 1341 does not support your position. If there is no MIME-Version:
header, the message was composed with software which is not compliant
with RFC 1341. This does not necessarily imply that the message is
not in MIME format--there will be other RFC's which will supersede RFC
1341.
As I mentioned before, RFC 1341 does not permit MIME readers to ignore
Content-* headers in the absence of a MIME-Version: header. RFC 1341
defines a number of headers (Content-Type, etc) and a number of values
(multipart/alternative, etc) with associated interpretations.
Appendix A sets a minimal set of requirements for an implementation,
including that the implementation recognize certain values of those
headers and interpret them according to the specification. Nowhere in
RFC 1341 is there an exception allowing an implementation to ignore a
Content-* header in the absence of a MIME-Version: header. Thus, an
implementation that ignores Content-* headers in the absence of the
MIME-Version: headers is not minimally conformant with RFC 1341.
> and expecting the Content-*:
> headers to be in comformance with the MIME format when there is no
> MIME-Version: header is asking too much. The Content-Type: header has been
> around for a LONG time, and many providers have done various things with it.
> Unfortunately, these things are NOT necessarily compatible with MIME.
Please give an example of a pre-MIME Content-Type: header that
both matches the BNF for a MIME Content-Type and has an interpretation
not in conformance with the MIME format. All pre-MIME Content-Types I
am aware of do not have a "/" character in them, so they fail the
first condition.
> If it doesn't say it's MIME, then it's not MIME. Sorry, but it's true.
A syntactically valid MIME Content-* header is sufficient for a
message to say it's MIME.
An implementation which wishes to distinguish between a MIME message
and a pre-MIME message can do so by checking for the existence of a
*syntactically valid* Content-Type: or Content-Transfer-Encoding:
header.
--
_.John G. Myers Internet: jgm+@CMU.EDU
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09881;
28 May 93 13:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09875;
28 May 93 13:19 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa16210;
28 May 93 13:19 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA08836; Fri, 28 May 93 12:41:33 EDT
Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA08832; Fri, 28 May 93 12:41:32 EDT
Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-11 #042B2) id
<01GYPC01BG0W000E26@INFOODS.UNU.EDU>; Fri, 28 May 1993 12:41:09 EDT
Date: Fri, 28 May 1993 12:41:09 -0400 (EDT)
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: John C Klensin
Subject: Re: MIME-Version is useless
In-Reply-To:
To: jgm+@cmu.edu
Cc: ietf-822@dimacs.rutgers.edu
Message-Id: <738607269.132103.KLENSIN@INFOODS.UNU.EDU>
X-Envelope-To: ietf-822@DIMACS.RUTGERS.EDU
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Mail-System-Version:
At the risk of getting caught with a protocol-lawyer hat on, I'd suggest
that this discussion is a waste of time as well as a little too late.
(1) We know that there are implementations out there that predate MIME,
interpret Content-type differently, and that we decided, explicitly, to
provide something they could use as a switching mechanism, rather than
breaking them. They were perfectly well-behaved until RFC822 rules, and
it might even be worth noting that RFC1123 _standardized_ Content-type.
Maybe either that decision, or the mechanism chosen, were not ideal,
but, at this point in MIME's development, it would take proof of
brokenness in the spec to change either, not just a quibble about
utility.
(2) There are no protocol police. Still worse, there are no protocol
judges and protocol jails other than the hope that people who misbehave
long enough will eventually lose market share (there has been no
evidence of this in the email realm so far). As a result, over-close
reading of conformance assertions in protocol documents is typically a
waste of time. That is what the robustness doctrine is all about.
Providing MIME-version is conservative on the sending side because it
tells the recipient exactly what you are sending, with no need for
heuristics. And every recipient system gets to decide whether, in its
environment, it is more sensible to treat a message that arrives without
"MIME-version" but with Content- headers as MIME or non-MIME, presumably
by evaluating the implications of both options. And that is why the
document doesn't make a "you have to" rule about this, one way or the
other.
(3)
>As I mentioned before, RFC 1341 does not permit MIME readers to ignore
>Content-* headers in the absence of a MIME-Version: header. RFC 1341
>defines a number of headers (Content-Type, etc) and a number of values
The rule you are inferring here can't be written, since the only thing
it governs is what a MIME-reader has to do under circumstances in which
its producer claims that it is a MIME-reader.
Regardless of what RFC1341[bis] says, if I were writing a proposal
or bid, and expected someone to sue me if I claimed MIME-compliance and
wasn't, I'd say "this critter is RFC1341-compliant in its processing of
incoming messages that conform to that standard". That is the strongest
comformance guarantee you would ever get, and, if you send a message
that doesn't contain MIME-version, you wouldn't have a leg to stand on.
>Nowhere in
>RFC 1341 is there an exception allowing an implementation to ignore a
>Content-* header in the absence of a MIME-Version: header.
Such an exception would be so much noise, unless you intend to
prohibit software that claims MIME-compliance from interpreting plain,
ordinary, RFC822 messages. An RFC822-reader is free to ignore any
headers it doesn't understand, and to make the "don't understand"
decision either globally or on the basis of context.
>This does not necessarily imply that the message is
>not in MIME format--there will be other RFC's which will supersede RFC
>1341.
True. But, unless we encounter evidence of a catastrophic problem,
"MIME" and "MIME format" are what RFC1341 and its successors say that
they are: there isn't some Platonic-ideal-MIME out there that we are
trying to approximate in the real world. In particular, (i) I'd expect
those RFCs to preserve the MIME-version requirement unless there is
evidence that it is harmful and (ii) if MIME-version isn't there, it
doesn't necessarily imply that the message is not in "green cheese"
format either. You really know nothing at that point other than
"RFC822" and, depending on how you received it, you may not be able to
guarantee that.
--john
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10647;
28 May 93 13:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10641;
28 May 93 13:49 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa17182;
28 May 93 13:49 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA10848; Fri, 28 May 93 13:10:32 EDT
Received: from PO2.ANDREW.CMU.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA10844; Fri, 28 May 93 13:10:31 EDT
Received: by po2.andrew.cmu.edu (5.54/3.15) id for ietf-822@dimacs.rutgers.edu; Fri, 28 May 93 13:10:25 EDT
Received: via switchmail; Fri, 28 May 1993 13:10:24 -0400 (EDT)
Received: from hogtown.andrew.cmu.edu via qmail
ID ;
Fri, 28 May 1993 13:08:40 -0400 (EDT)
Received: from hogtown.andrew.cmu.edu via qmail
ID ;
Fri, 28 May 1993 13:08:35 -0400 (EDT)
Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411
via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411;
Fri, 28 May 1993 13:08:31 -0400 (EDT)
Message-Id:
Date: Fri, 28 May 1993 13:08:31 -0400 (EDT)
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: John Gardiner Myers
To: ietf-822@dimacs.rutgers.edu
Subject: Re: MIME-Version is useless
In-Reply-To: <738607269.132103.KLENSIN@INFOODS.UNU.EDU>
References: <738607269.132103.KLENSIN@INFOODS.UNU.EDU>
Beak: is Not
MIME-Version: as specified in RFC 1341 is admittedly not that harmful.
The April Internet Draft is turning it into a problem. It has to be
handled as a special case when interpreting message/partial. The
modified wording of section 3 means that all sorts of havoc will be
wrecked should the value of MIME-Version: ever change. These
practical matters will likely mean the value of MIME-Version: will
never change, in which case section 3 is recommending implementors
write dead code.
A MIME reader should be able, even encouraged, to ignore MIME-Version:
entirely. To keep from breaking existing software, the next MIME
standard should still require generation of "MIME-Version: 1.0", but
it should mark the header as depreciated and strongly recommend
implementations ignore it. It should also suggest implementors
distinguish MIME messages from pre-MIME message by determining whether
the value of any Content-Type or Content-Transfer-Encoding header can
be parsed using the apropriate MIME BNF.
--
_.John G. Myers Internet: jgm+@CMU.EDU
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12704;
28 May 93 14:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12698;
28 May 93 14:51 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa19196;
28 May 93 14:51 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA12385; Fri, 28 May 93 14:20:17 EDT
Received: from dorner.slip.uiuc.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA12381; Fri, 28 May 93 14:20:13 EDT
Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA02651
(5.65c/IDA-1.4.4 for ietf-822@dimacs.rutgers.edu); Fri, 28 May 1993 13:21:42 -0500
Message-Id: <199305281821.AA02651@dorner.slip.uiuc.edu>
X-Sender: sdorner@dorner.slip.uiuc.edu
Mime-Version: 1.0
Content-Type: text/plain
Date: Fri, 28 May 1993 13:20:07 -0500
To: ietf-822@dimacs.rutgers.edu
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Steve Dorner
Subject: Re: MIME-Version is useless
At 1:08 PM 5/28/93 -0400, John Gardiner Myers wrote:
>distinguish MIME messages from pre-MIME message by determining whether
>the value of any Content-Type or Content-Transfer-Encoding header can
>be parsed using the apropriate MIME BNF.
I disagree. If the header is required to be present, then it should be the
key for deciding whether or not the message is MIME. Syntactic analysis of
header fields to determine something already explicitly stated is
pointless.
Note also that MIME-compliant messages are NOT required to have
Content-Type headers, and that this has explicit meaning:
Content-Type: text/plain; charset=us-ascii
So requiring a syntactically valid Content-Type header to recognize a MIME
message either a) is a violation of the MIME spec or b) requires that the
absence of a Content-Type header is a syntactically correct Content-Type
header, in effect declaring all mail as MIME mail (except for messages that
have RFC 1049 Content-Type's, of course).
What's the difference between MIME mail "text/plain; charset=us-ascii" and
non-MIME mail? Practically speaking, very little; it's just a nit. But
since this entire argument is based on a nit with the MIME spec (that it
doesn't explicitly state that the MIME-Version header must be present for
the other headers to be considered according to spec), I don't feel too bad
about that.
As for ignoring the value, that's another story. That's certainly my plan,
until some reason to do otherwise comes along.
--
Steve Dorner, Qualcomm Inc.
Oldthinkers unbellyfeel IngSoc.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15567;
28 May 93 17:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15561;
28 May 93 17:13 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa22897;
28 May 93 17:13 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA13731; Fri, 28 May 93 16:34:54 EDT
Received: from zoo.utoronto.ca by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA13727; Fri, 28 May 93 16:34:52 EDT
Message-Id: <9305282034.AA13727@dimacs.rutgers.edu>
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: henry@zoo.toronto.edu
Date: Fri, 28 May 93 16:34:46 EDT
To: 822 list
Subject: Re: Multipart/related proposal
>...We need to somehow
>differentiate between the multipart which comes from in-stream parts (a
>hebrew sentence in the middle of an otherwise english paragraph) and the
>multipart which comes from the attachment model...
Rather than calling the latter multipart/related, consider an alternative:
keep multipart/mixed for the latter, and use (say) multipart/sequential
(by analogy to multipart/parallel) for the former.
Henry Spencer at U of Toronto Zoology
henry@zoo.toronto.edu utzoo!henry
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06050;
31 May 93 23:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06044;
31 May 93 23:47 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa09150;
31 May 93 23:47 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA17985; Mon, 31 May 93 23:20:34 EDT
Received: from PO2.ANDREW.CMU.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA17981; Mon, 31 May 93 23:20:33 EDT
Received: by po2.andrew.cmu.edu (5.54/3.15) id for ietf-822@dimacs.rutgers.edu; Mon, 31 May 93 23:20:26 EDT
Received: via switchmail; Mon, 31 May 1993 23:20:25 -0400 (EDT)
Received: from hogtown.andrew.cmu.edu via qmail
ID ;
Mon, 31 May 1993 23:19:33 -0400 (EDT)
Received: from hogtown.andrew.cmu.edu via qmail
ID ;
Mon, 31 May 1993 23:19:22 -0400 (EDT)
Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411
via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411;
Mon, 31 May 1993 23:19:15 -0400 (EDT)
Message-Id:
Date: Mon, 31 May 1993 23:19:15 -0400 (EDT)
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: John Gardiner Myers
To: ietf-822@dimacs.rutgers.edu
Subject: Re: MIME-Version is useless
In-Reply-To: <199305281821.AA02651@dorner.slip.uiuc.edu>
References: <199305281821.AA02651@dorner.slip.uiuc.edu>
Beak: Is
sdorner@qualcomm.com (Steve Dorner) writes:
> As for ignoring the value, that's another story. That's certainly my plan,
> until some reason to do otherwise comes along.
If you ignore the value, you are contradicting a recommendation in
section 3 of the April Internet Draft. This is a problem which I
think should be addressed. The new MIME spec should instead be
de-empasizing the header, recommending that software ignore its value.
As for whether or not a message is or is not "MIME", why should anyone
care? The term has no definiton or practical meaning.
In practical terms, what one usually needs to know is whether or not
RFC 1341 or its successors specify an interpretation of the message.
That is true (to varying degrees) for messages with a syntactically
valid Content-Type: header and for messages without a Content-Type:
header. It is not in general true for messages with RFC 1049
Content-Type's.
One may also want to know whether or not one can infer that a message
obeys some constraint of RFC 1341, for example that it is 7-bit clean
in the absence of a Content-Transfer-Encoding. One could use either
Content-* or MIME-Version for this purpose, using MIME-Version is
admittedly one step easier than using Content-*. As this inference is
at best a heuristic (it is unlikely, but not invalid for a
non-RFC-1341 message to have a MIME-Version: 1.0) it is not by itself
sufficient to keep MIME-Version.
(Existing software is, on the other hand, sufficient reason to keep
the MIME-Version requirement for at least one revision.)