Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02896; 31 Mar 92 18:13 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa27862; 31 Mar 92 18:16 EST Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa27843; 31 Mar 92 18:16 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA01631; Tue, 31 Mar 92 18:03:49 EST Received: from dkuug.dk by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA01627; Tue, 31 Mar 92 18:03:45 EST Received: by dkuug.dk (5.64+/8+bit/IDA-1.2.8) id AA27348; Wed, 1 Apr 92 01:02:43 +0200 Date: Wed, 1 Apr 92 01:02:43 +0200 From: Keld J|rn Simonsen Message-Id: <9203312302.AA27348@dkuug.dk> To: dan@watson.ibm.com, ietf-822@dimacs.rutgers.edu Subject: Re: Working Group Last Call: Mnemonic to Proposed Standard X-Charset: ASCII X-Char-Esc: 29 Walt Daniels writes: > Advancement of Mnemonic to any form of standard is a "showstopper" > to me! > > It only really solves a Eurocentric problem. Do you also want to show-stop RFC-MIME? It is also eurocentric in only supporting European character sets - to a much lesser degree indeed than RFC-CHAR and mnemonic. I expect Japanese and Vietnamese specifications coming up. Are you also going to show-stop them as they are very japanese-centric and vietnamese-centric? Regards keld   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02926; 31 Mar 92 18:43 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa28678; 31 Mar 92 18:46 EST Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa28656; 31 Mar 92 18:46 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA01298; Tue, 31 Mar 92 17:59:04 EST Received: from WILMA.CS.UTK.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA01284; Tue, 31 Mar 92 17:58:55 EST Received: from LOCALHOST by wilma.cs.utk.edu with SMTP (5.65/2.7c-UTK) id AA23960; Tue, 31 Mar 92 17:58:38 -0500 Message-Id: <9203312258.AA23960@wilma.cs.utk.edu> From: Keith Moore To: Walt Daniels , Greg Vaudreil Cc: ietf-822@dimacs.rutgers.edu, moore@cs.utk.edu Subject: Re: Working Group Last Call: Mnemonic to Proposed Standard In-Reply-To: Your message of "31 Mar 92 16:14:36 EST." <033192.161436.dan@watson.ibm.com> Date: Tue, 31 Mar 92 17:58:38 EST Sender: moore@cs.utk.edu > Date: 31 Mar 1992 16:14:36 EST > From: dan@watson.ibm.com (Walt Daniels) > Phone: 914-784/863-6736 > To: ietf-822@dimacs.rutgers.edu > Subject: Working Group Last Call: Mnemonic to Proposed Standard > > Advancement of Mnemonic to any form of standard is a "showstopper" > to me! > > It only really solves a Eurocentric problem. > For the same reasons, I suppose you would prefer that we stop using 8859/* and even ASCII, until we get a worldwide character set? I didn't understand from Greg's announcement whether the Mnemonic I-Ds are being submitted as informational RFCs or as proposed standard RFCs or as one of each. At any rate, I support promotion of Mnemonic to be an official character set within MIME. Keith   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02938; 31 Mar 92 19:22 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa29653; 31 Mar 92 19:24 EST Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa29630; 31 Mar 92 19:24 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA03427; Tue, 31 Mar 92 18:47:07 EST Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA03423; Tue, 31 Mar 92 18:47:05 EST Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0) id AA07264; Tue, 31 Mar 92 15:46:59 PDT Message-Id: <9203312346.AA07264@Mordor.Stanford.EDU> To: Greg Vaudreuil Cc: ietf-822@dimacs.rutgers.edu Subject: Re: Working Group Last Call: Mnemonic to Proposed Standard Org: The Branch Office Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Tue, 31 Mar 92 14:12:15 -0500. <9203311412.aa02283@ietf.NRI.Reston.VA.US> Date: Tue, 31 Mar 92 15:46:57 -0800 From: Dave Crocker Greg, et al, The international community has been haggling about common character sets for quite awhile. I hear various degrees of hopefulness that ISO 10646 will be "the" answer. Given that, I am having difficulty understanding whether MNemonic is solving a different problem or whether it is directly competitive. If it is competitive, then it is essential that we, the Internet, be clear about our reasons for going down a different path. I also do not understand why an electronic mail working group would be attempting to establish such a general character set standard. My fear is that there are others in the Internet, with additional knowledge, who could contribute to the character set discussion, if only they new to look for it in an electronic mai working group. Thoughts? Dave   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02962; 31 Mar 92 19:46 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa00762; 31 Mar 92 19:49 EST Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa00738; 31 Mar 92 19:49 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA03101; Tue, 31 Mar 92 18:43:02 EST Received: from binky.arc.nasa.gov by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA03000; Tue, 31 Mar 92 18:42:11 EST Received: from localhost.arc.nasa.gov by binky.arc.nasa.gov (4.1/1.34) id AA07237; Tue, 31 Mar 92 15:38:44 PST Message-Id: <9203312338.AA07237@binky.arc.nasa.gov> To: Tim Kehres Cc: Ned Freed Postmaster , masinter@parc.xerox.com, ietf-822@dimacs.rutgers.edu Subject: Re: mime formats and versions in format specifications In-Reply-To: Your message of "Sat, 28 Mar 92 00:07:54 PST." <9203280807.AA12079@ima.com> Date: Tue, 31 Mar 92 15:38:43 PST From: jknowles@binky.arc.nasa.gov >TIFF is basically just a wrapper for various different types of image >representations. It contains a header, no that much unlike a mail header. >These fields are standardized, but since there are just so many different >possible combinations possible, there have been TIFF classes identified to >aid developers in producing output that can be used between applications. >This makes it possible for you to say that you can deal with a certain type >of TIFF class. The two that come to mind are class B and F. The later >class is the one that defines which combination of header fields are required >for dealing with FAX data. The class information is useful, especially since TIFF classes are actually supersets of their "parent" class. That is, TIFF-F adds functionality that does not exist in TIFF-B. So a TIFF-F reader must read any TIFF-B file, but a TIFF-B reader cannot be expected to read all TIFF-F. Unfortunately, I can't find any internal mechanism for specifying the class of the file. This would indicate that it might be a good idea to have a "Class=n" parameter. Alternatively, we can register TIFF-B, TIFF-F, and so on. This is in fact the approach taken by the Netfax group in labelling their file format TIFF-B-Netfax. If we go with a parameter, TIFF-B-Netfax should then be registered with Aldus as TIFF-?. >Just a quick point: there is no need to go and write a specification, a >formal industry recognized standard exists. In addition, several classes >exist that define different types of conformance with the standard. My >recollection is that the NETFAX group was using class F, an existing >standard. The Netfax file format, while based on TIFF-F, differs substantially, and is largely incompatible. It is actually a sub-class (superset) of TIFF-F. TIFF-F is a G3 file format; Netfax allows G3 (T.4 encoding) but strongly recommends G4 (T.6 encoding). These extensions are the major source of incompatibility. >My personal feeling is that it would be nice to have some kind of mechanism >where not only TIFF but the conformance class could be indicated in MIME. >If however it would at all slow down the progress of MIME at this point, it >is not worth it - I assume it can be added at a later data through the IANA. Actually, it will have to be added through IANA since the MIME spec doesn't discuss TIFF at all. I would guess that many of the versioning arguments apply to the "Class=n" parameter as well. I'm not sure we can reach consensus, but some kind of MIME-group guidelines regarding when to create a new label vs. a new parameter would certainly add consistency to the coming proliferation of sub-types. Jim   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03065; 31 Mar 92 20:17 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa01645; 31 Mar 92 20:19 EST Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa01628; 31 Mar 92 20:19 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA05642; Tue, 31 Mar 92 19:37:08 EST Received: from CBROWN.CLAREMONT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA05635; Tue, 31 Mar 92 19:37:04 EST Received: from HMCVAX.CLAREMONT.EDU by HMCVAX.CLAREMONT.EDU (PMDF #11000) id <01GIAUEQS37K96VO5F@HMCVAX.CLAREMONT.EDU>; Tue, 31 Mar 1992 16:36 PST Date: Tue, 31 Mar 1992 16:36 PST From: "Ned Freed, Postmaster" Subject: Re: Last Call: Multipurpose Mail Extensions to Proposed Standard To: david@twg.com Cc: ietf-822@dimacs.rutgers.edu Message-Id: <01GIAUEQS37K96VO5F@HMCVAX.CLAREMONT.EDU> X-Vms-To: IN%"david@twg.com" X-Vms-Cc: IN%"ietf-822@dimacs.rutgers.edu" > I know this is an awfully late time to bring this up. Why was the > "cleartext" feature of PEM's Base64 removed from MIME's Base64. It > seems, now, this is a gratuitious incompatibility which may make us > non-interoperable with PEM's Base64. Having a cleartext capability > may, in fact, be useful. Are the PEM people going to adopt MIME's > modification of Base64, which would make the point moot? What should a > Base64 decoder do when it see's a `*'? Jim Galvin already pointed out that this discrepancy is no longer an issue; the latest PEM drafts have removed this clear text option as well. However, I think you might be interested in why this option was removed. The answer is easy to arrive at once you try to answer a different question: If there's clear text in the middle of a base64 encoded object, what exactly does that text MEAN? Is the text part of the object that just didn't need encoding? Is it out-of-band information that should be processed separately? What octets are implied by end of line sequences in the clear text? And what should be done about the very real possibility of character corruption in the case where base64 is being used to get through gateways with restricted character availability (this is one very important reason to use base64 in the first place)? PEM only deals with encoding. It says nothing about what the content of the encoded document means -- it does not have to because its beyond the purview of PEM. But MIME deals intimately with what the content of something means. When I tried to reconcile the usage of embedded clear text in PEM with MIME usage of base64, I ran into real trouble. There simply was no way to define it that was clear, consistent, and didn't introduce problems somewhere. I don't recall if all this was ever discussed on the mailing list; it may have been taken care of entirely in conversations between Nathaniel and myself. So the net result was that the clear text embedding was left out. I think it was a very wise choice, and I'm glad PEM has gone this way as well. Ned   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03116; 31 Mar 92 20:47 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa02536; 31 Mar 92 20:49 EST Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa02519; 31 Mar 92 20:49 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA07443; Tue, 31 Mar 92 20:34:29 EST Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA07439; Tue, 31 Mar 92 20:34:27 EST Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0) id AA00810; Tue, 31 Mar 92 17:34:04 PDT Message-Id: <9204010134.AA00810@Mordor.Stanford.EDU> To: Keld J|rn Simonsen Cc: dan@watson.ibm.com, ietf-822@dimacs.rutgers.edu Subject: Re: Working Group Last Call: Mnemonic to Proposed Standard Org: The Branch Office Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Wed, 01 Apr 92 01:02:43 +0200. <9203312302.AA27348@dkuug.dk> Date: Tue, 31 Mar 92 17:34:03 -0800 From: Dave Crocker Keld, You raise an interesting question, by referencing other efforts to support Asian languages: I would appreciate your offering a concise statement concerning the scope of use for MNemonic. What problem(s) does it solve and which ones does it not solve? I also continue to be confused about its relationship to the emerging ISO work, namely ISO 10646. (This may well be due to my not having done enough homework, but I keep thinking that I am not the only 822ext working group member with an inadequate understanding of MNemonics uses and limitations. Dave   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03186; 31 Mar 92 21:13 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa03423; 31 Mar 92 21:16 EST Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa03406; 31 Mar 92 21:16 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA07614; Tue, 31 Mar 92 20:38:50 EST Received: from dkuug.dk by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA07525; Tue, 31 Mar 92 20:37:56 EST Received: by dkuug.dk (5.64+/8+bit/IDA-1.2.8) id AA00419; Wed, 1 Apr 92 03:36:02 +0200 Date: Wed, 1 Apr 92 03:36:02 +0200 From: Keld J|rn Simonsen Message-Id: <9204010136.AA00419@dkuug.dk> To: atkinson@sundance.itd.nrl.navy.mil, ietf-822@dimacs.rutgers.edu Subject: Re: What to do with the charset and mnemonic documents X-Charset: ASCII X-Char-Esc: 29 > As I have said for some time now and backed myself up in fairly > clear technical terms, the document "draft-ietf-822ext-mnemonics.txt" > has significant technical flaws that make its use outside of European > alphabetic languages inappropriate in its present form. well, we had some conversation on this some time ago, but I did not get any response to my comments then. Maybe some mail was lost? If you have time we could discuss it offline, if you feel it mostly like a repetition. > Even alphabetic Asian languages, such as Vietnamese, are not well > served or equitably treated by this document and its author Keld > Simonsen has explicitly rejected my specific proposals to change it so > that it would treat at least all alphabetic languages on equal terms. Vietnamese is a language well known for its many accents. I might be able to make a scheme which can accomodate vietnamese as well as other languages based on the latin script. I have tried before to do Vietnamese support, but evidently not to the satisfaction of those people in need for it. I do not remember any specific proposals from you on Vietnamese, Ran. Please forward them to me if you have some. The last part of our conversation that I remember was that I doubted if the current Vietnamese trend of very specific post-accents and usage of variant characters could be merged, thus challenging you to come forward with such a proposal. > I think that it would be fine as an experimental protocol or as an > informational document, possibly with a registered type with the IANA. > I strongly oppose any and all attempts to put it on the standards > track until the author makes the changes that I and others have > outlined that are necessary to treat all alphabetic languages on an > even basis and to permit multiple character set profiles to work using > the same mechanism. One design goal has actually been to treat every *character set* and not language, equally. That is, all 7- or 8-bit character sets in the ECMA registry can actually be written with two-char mnemonics. There are of cause some languages that get preferential treatment, such as American, English, Dutch, Swahili and Hawaian, but this has historic origins. Actually, if you use a character set which supports your native language, you will get support for that with the specifications, be it either Japanese, Danish or Vietnamese. You only need mnemonic support for characters that are not in the character set you use. As said above I miss specific proposals on how to make it better. I think I have missed completely your points on the multiple character set profiles. I would like to hear more about that. > I think that the document "draft-ietf-822ext-charsets-*.txt" would > be very useful as an informational document and ery much hope that it > will be published informationally. It does not contain standards > track material and is not suitable for the standards track, and I > oppose any effort that might be made to put it on the standards track. Thanks for your support! Keld   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03216; 31 Mar 92 21:45 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa04252; 31 Mar 92 21:48 EST Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa04234; 31 Mar 92 21:48 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA10147; Tue, 31 Mar 92 21:12:10 EST Received: from dkuug.dk by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA10143; Tue, 31 Mar 92 21:12:05 EST Received: by dkuug.dk (5.64+/8+bit/IDA-1.2.8) id AA01286; Wed, 1 Apr 92 04:10:49 +0200 Date: Wed, 1 Apr 92 04:10:49 +0200 From: Keld J|rn Simonsen Message-Id: <9204010210.AA01286@dkuug.dk> To: dcrocker@mordor.stanford.edu Subject: Re: Working Group Last Call: Mnemonic to Proposed Standard Cc: dan@watson.ibm.com, ietf-822@dimacs.rutgers.edu X-Charset: ASCII X-Char-Esc: 29 > I would appreciate your offering a concise statement concerning the > scope of use for MNemonic. What problem(s) does it solve and which ones > does it not solve? My 2 cents: It solves the interoperability problems within EUnet. More generally: It solves the interoperability of character sets. You will always be able to unambigeously represent a message with your equipment. It provides a fallback method, so eg a Japanese would be able to use his own equipment and character sets and still be able to represent eg. the letter | in my middle name, which is not normally accessible to him. It somewhat solves readability in the fallback, but this fallback is more adequate for some languages than other. Eg. the Japanese find the fallbachk for ideographic characters totally unaccepatble. I think Danes can tolerate it. The Vietnamese have a better method for their language. It is always a pain in the neck not to have your own character set readily available on your equipment. > I also continue to be confused about its relationship to the emerging > ISO work, namely ISO 10646. (This may well be due to my not having done > enough homework, but I keep thinking that I am not the only 822ext working > group member with an inadequate understanding of MNemonics uses and > limitations. Mnemonics are closely aligned with 10646. Actually the I-D contains the best public electronic data available of 10646, that I know of. The data available in the I-D has been crosscheked electronically with the 10646 2DIS source. I am a member (newcomer) of SC2/WG2, who has produced 10646 (well some may say it was the Unicode consortium...) Mnemonics have been addressed in SC2/WG2 and the WG was positive about it, but said that it should rather be another WG who should work on it. The work is now being undertaken by SC22/WG20. I see mnemonic as the bridge between the new world, 10646 and the old world with it myriads of character sets. And email is probably the single application where interoperability of character sets are mostly needed, this is why we see the requrements and the solutions here first. > Dave Keld   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03258; 31 Mar 92 22:17 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa05244; 31 Mar 92 22:20 EST Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa05225; 31 Mar 92 22:20 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA10913; Tue, 31 Mar 92 21:46:47 EST Received: from itd.nrl.navy.mil by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA10909; Tue, 31 Mar 92 21:46:44 EST Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA20951; Tue, 31 Mar 92 21:45:57 EST Date: Tue, 31 Mar 92 21:45:57 EST From: Randall Atkinson Message-Id: <9204010245.AA20951@itd.nrl.navy.mil> To: ietf-822@dimacs.rutgers.edu Subject: archives Keld, My statements are presumably archived along with everything else. Before you make any further fallacious claims or implications about what I did or didn't say, please look in those archives. I don't have time to play your games. I will attempt to ignore further ad hominem or political remarks along the lines of the posting I just read from Denmark in the interest of other subscribers on this list. I am happy to have TECHNICAL discussions with anyone however. Ran   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03264; 31 Mar 92 22:36 EST Received: from venera.isi.edu by NRI.Reston.VA.US id aa05730; 31 Mar 92 22:39 EST Received: by venera.isi.edu (5.65c/5.65+local-4) id ; Tue, 31 Mar 1992 07:36:14 -0800 Received: from NRI.RESTON.VA.US by venera.isi.edu (5.65c/5.65+local-4) id ; Tue, 31 Mar 1992 07:36:12 -0800 Received: from ietf.NRI.Reston.Va.US by NRI.Reston.VA.US id aa10771; 31 Mar 92 10:26 EST Received: from [127.0.0.1] by ietf.NRI.Reston.VA.US id ab01076; 31 Mar 92 10:23 EST To: IESG Secretary Cc: IETF , IESG@nri.reston.va.us Cc: ietf-822@dimacs.rutgers.edu Subject: Re: Last Call: Multipurpose Mail Extensions to Proposed Standard In-Reply-To: Your message of "Tue, 31 Mar 92 10:11:50 EST." <9203311011.aa00998@ietf.NRI.Reston.VA.US> Date: Tue, 31 Mar 92 10:23:46 -0500 From: Greg Vaudreuil Message-Id: <9203311023.ab01076@ietf.NRI.Reston.VA.US> Please note that the latest version of the Internet Draft "MIME (Multipurpose Internet Mail Extensions)" is version 5, not 4 as indicated in the just posted last call announcement. Greg Vaudreuil IESG Secretary   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03452; 1 Apr 92 0:12 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa07766; 1 Apr 92 0:15 EST Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa07722; 1 Apr 92 0:14 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA15300; Tue, 31 Mar 92 23:46:13 EST Received: from dkuug.dk by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA15291; Tue, 31 Mar 92 23:46:09 EST Received: by dkuug.dk (5.64+/8+bit/IDA-1.2.8) id AA05473; Wed, 1 Apr 92 06:45:45 +0200 Date: Wed, 1 Apr 92 06:45:45 +0200 From: Keld J|rn Simonsen Message-Id: <9204010445.AA05473@dkuug.dk> To: atkinson@itd.nrl.navy.mil, ietf-822@dimacs.rutgers.edu Subject: Re: archives X-Charset: ASCII X-Char-Esc: 29 OK, Ran, some thechnical questions: How do you think we can merge mnemonic and the Vietnamese proposal? What did you mean with charater set profiles? regards keld   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03484; 1 Apr 92 0:43 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa09203; 1 Apr 92 0:45 EST Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa09158; 1 Apr 92 0:45 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA15478; Tue, 31 Mar 92 23:55:21 EST Received: from srawgw.sra.co.jp by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA15472; Tue, 31 Mar 92 23:55:14 EST Received: from sranhd.sra.co.jp by srawgw.sra.co.jp (5.67WH/1.5) id AA08729; Wed, 1 Apr 92 13:54:30 +0900 Received: from sran8.sra.co.jp by sranhd.sra.co.jp (5.67ew/6.4J.6-BX) id AA19674; Wed, 1 Apr 92 13:54:06 +0900 Received: from localhost by sran8.sra.co.jp (4.0/6.4J.6-SJX) id AA18643; Wed, 1 Apr 92 13:54:04 JST Return-Path: Message-Id: <9204010454.AA18643@sran8.sra.co.jp> Reply-To: erik@sra.co.jp From: "Erik M. van der Poel" To: Greg Vaudreuil Cc: ietf-822@dimacs.rutgers.edu Subject: Re: Working Group Last Call: Mnemonic to Proposed Standard Date: Wed, 01 Apr 92 13:54:02 +0900 Sender: erik@sran8.sra.co.jp > Specifically, this Working Group has been asked to recommend > > "Character Mnemonics & Character Sets" > as an informational document At first glance, this does not seem to be problematic. But what, exactly, does it mean for this 822ext WG to "recommend" this draft as an "informational document"? Does it mean that the WG says to IESG: "This WG has reached a consensus that the [draft] contains accurate information, and recommends that it be published as such." Or do we say that the author believes it to be accurate, and that the WG simply wants it published as a take-it-or-leave-it informational RFC that may or may not be accurate? > "Mnemonic Character Sets" > describes how to use the mnemonics and character sets tabled in the > above document as a character set. It is intended to register this > mechanism with IANA as a character set for use in MIME. In order to get the IESG to approve MIME, the WG had to delete references to documents that were incomplete or were not standards. Is there an analogous requirement for MIME charsets, where the IANA cannot register a charset if the document contains references to incomplete or non-standard documents? If so, wouldn't the reference to the above "charsets-04" document have to be deleted from the "mnemonics" document? Would we have to go through all of this hassle if Keld simply proposed the "mnemonics" document as an experimental protocol? Why don't we give it a name starting with "X-" and then get some people to use it for a while, iron out any remaining bugs in the specs, find out which particular characters are being used with the spec, and then moving parts of the specs to "standard" status when it seems appropriate? I.e. the Internet way? Erik   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03513; 1 Apr 92 1:42 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa10367; 1 Apr 92 1:45 EST Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa10329; 1 Apr 92 1:45 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA17842; Wed, 1 Apr 92 01:26:07 EST Received: from malmo.trab.se by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA17824; Wed, 1 Apr 92 01:25:58 EST Received: by malmo.trab.se (5.65+bind 1.7+ida 1.4.2/TRM-1-NS); Wed, 1 Apr 92 08:25:34 +0200 (MET) Date: Wed, 1 Apr 92 08:25:34 +0200 From: Dan Oscarsson Message-Id: <9204010625.AA08152@malmo.trab.se> To: dcrocker@mordor.stanford.edu Subject: Re: Working Group Last Call: Mnemonic to Proposed Standard Cc: ietf-822@dimacs.rutgers.edu > >The international community has been haggling about common character >sets for quite awhile. I hear various degrees of hopefulness that >ISO 10646 will be "the" answer. Given that, I am having difficulty >understanding whether MNemonic is solving a different problem or whether >it is directly competitive. If it is competitive, then it is essential >that we, the Internet, be clear about our reasons for going down a >different path. This is the reason that I would have liked MIME to only reference ASCII and ISO 8859-1 as the basic requirements, with the intention to use ISO 10646 when it becomes IS. Instead of allowing a lot of character sets that are not compatible with ISO 10646 and only gives me a lot of extra work to implement handling of them also. ISO 10646 is all we need and we should not put a lot of work using character sets that can be discarded when ISO 10646 becomes IS. Dan   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00496; 1 Apr 92 7:44 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa06460; 1 Apr 92 7:47 EST Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa06440; 1 Apr 92 7:47 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA23324; Wed, 1 Apr 92 07:40:25 EST Received: from itd.nrl.navy.mil by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA23319; Wed, 1 Apr 92 07:40:05 EST Received: from sundanceitd.nrl.navy.mil (sundance.itd.nrl.navy.mil) by itd.nrl.navy.mil (4.1/SMI-4.1) id AA05386; Wed, 1 Apr 92 07:39:10 EST Received: by sundanceitd.nrl.navy.mil (4.1/SMI-4.1) id AA07316; Wed, 1 Apr 92 07:40:37 EST Date: Wed, 1 Apr 92 07:40:37 EST From: Randall Atkinson Message-Id: <9204011240.AA07316@sundanceitd.nrl.navy.mil> To: ietf-822@dimacs.rutgers.edu Subject: Outline of changes needed for mnemonic In-Reply-To: Mail from 'keld@dkuug.dk Tue Mar 31 23:46:46 1992' dated Wed, 1 Apr 92 06:45:45 +0200 I made a specific proposal to generalise the mnemonic mechanism so that multiple profiles could use a single mechanism. That proposal is in the archives and was made within the past few months. A profile would mean a combination of a particular mnemonic character set to glyph mapping, the use of a single external mnemonic mechanism, and a specific identifier for that profile for use within MIME headers. I think that rfc-mnem represents a solid start towards the mechanism but needs to be completely generalised and in particular all of the Euro-centrisms need to be eliminated. The combination of a well-chosen subset of rfc-char that covers the European languages, some general mnemonic mechanism, and an IANA registered identifier might be a EUnet profile. I believe that this is what Erik van der Poel has previously suggested to this list and to the net-char list. The combination of the forthcoming informational RFC on existing Vietnamese mnemonic usages (being developed by the Vietnamese Standards Group, TriChlor, et. al.), the same general mnemonic mechanism, and a different IANA registered identifier might be a Vietnamese profile. In order for a unified profile that includes Vietnamese to be created, the characters used for Vietnamese glyphs must not be less readable than the current Viet Net menmonics are. This is a requirement for the simple reason that the thousands of users of the Viet Net mnemonics will not change if the result is less readable than their existing usage, especially since there is a lot of freely distributable X11 software that uses the Viet Net mnemonic encoding within files but displays the glyphs correctly on the X11 display. It is not clear to me (or a whole lot of other people) that it is useful or appropriate to have a mnemonic profile for ideogrammatic languages simply because there is no known way for an ideogrammatic language to be represented in a truly mnemonic manner. If a standards track profile were to desire to include ideogrammatic character mnemonics, a very strong case would have to be made that it is truly a mnemonic encoding. In particular, I share Dave Crocker's recently stated concerns that the current form of rfc-char is so broad as to be competing with 2nd DIS 10646 and I think that the Internet must be very careful not to have gratuitous competition with IEEE, IEC, ISO, or CCITT standards that exist or are likely to exist in the near term. Among the most objectionable parts of the current draft of rfc-mnem are the artificial distinctions between glyphs composed of a base roman character and one diacritical mark (covers most or all of the European languages) and glyphs composed of a base roman character and multiple marks (a very common case in Vietnamese). The effect of the current specification is clearly racist, though I hope that was not the intent. In general, all of the normative ("standards track") text needs to reside within the rfc-mnem document --- so rfc-mnem should not reference the existing rfc-char in a normative ("standards specifying") manner. The details of the changes needed in this regard were already spelled out in great detail in one of my earlier postings that should be in the archives. Ran atkinson@itd.nrl.navy.mil   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00520; 1 Apr 92 8:12 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa07317; 1 Apr 92 8:15 EST Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa07288; 1 Apr 92 8:15 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA23406; Wed, 1 Apr 92 07:47:35 EST Received: from [147.32.1.2] by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA23390; Wed, 1 Apr 92 07:47:09 EST Received: from sun.felk.cvut.cs by aci.cvut.cs (IBM VM SMTP V2R1) with TCP; Wed, 01 Apr 92 14:47:26 MET Received: from vrata.felk.cvut.cs by sun.felk.cvut.cs (4.1/SMI-4.1) id AA08213; Wed, 1 Apr 92 14:44:41 +0200 Received: From SERVER311/WORKQUEUE by vrata.felk.cvut.cs via Charon 3.4 with IPX id 100.920401144613.224; 01 Apr 92 14:47:14 +0100 Message-Id: To: Dan.Oscarsson@malmo.trab.se From: AXELSSON@cslab.felk.cvut.cs Date: 1 Apr 92 14:45:48 CET Subject: Re: Working Group Last Call: Mnemonic to Proposed Standard Cc: ietf-822@dimacs.rutgers.edu X-Mailer: Pegasus Mail v2.2 (R4). Well, I can think of several reasons why ASCII and -1 isn't such a neat idea. One of them is only a few kilometers south of you - Poland. Ingen tidligere \st-Europeiske land jeg kan komme p} unntatt Romania kan bruke ASCII p} samme m}te som Skandinavia (ved } bytte ut seks tegn i ASCII, og priviligert posisjon i -1). Den eneste grunnen til at Norden har f}tt med sine obskure tegn, og ikke si Tsjekkoslovakia, er at f|rstnevnte er medlem av COCOM og sistnevnte var medlem av COMECON. Og antallet brukere som trenger lang Y i dag er st|rre enn antallet som trenger Thorn, og snart st|rre enn de som trenger ]. Vennlig hilsen, Jonny -- Praha: axelsson@cslab.felk.cvut.cs Oslo:jonnya@ifi.uio.no   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa07027; 1 Apr 92 18:13 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa08553; 1 Apr 92 18:16 EST Received: from dimacs.RUTGERS.EDU by NRI.Reston.VA.US id aa08535; 1 Apr 92 18:16 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA24582; Wed, 1 Apr 92 17:52:05 EST Received: from ecovax.eco.twg.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA24532; Wed, 1 Apr 92 17:51:36 EST Message-Id: <9204012251.AA24532@dimacs.rutgers.edu> Received: from apache.twg.com by ECOVAX.ECO.TWG.COM via Pony Express SMTP with TCP (v8.1.1-dmr001); Tue, 31 Mar 92 16:19:14-EDT Date: Tue, 31 Mar 1992 13:16:15 -0800 From: david@twg.com To: galvin@tis.com, ietf-822@dimacs.rutgers.edu Subject: Re: Last Call: Multipurpose Mail Extensions to Proposed Standard Jim, In the MIME spec, in the introduction to Base64, it says it is the same as PEM's Base64 with one difference: base64 eliminates the "*" mechanism for embedded clear text. I don't know PEM terribly well, but this seems to mean the Base64 there allowed for some unencrypted text to be included if it was prefaced with "*" and ended somehow (another "*"?). I'm only up to date on what is in MIME ... Since you say the current draft of PEM also removes this capability then my objection is either modified or withdrawn. Modification: Add a sentence stating that later work on PEM will also be removing the "*" mechanism. David   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa25204; 1 Apr 92 22:43 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa16183; 1 Apr 92 22:46 EST Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa16164; 1 Apr 92 22:46 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA07759; Wed, 1 Apr 92 22:19:05 EST Received: from CBROWN.CLAREMONT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA07755; Wed, 1 Apr 92 22:19:02 EST Received: from HMCVAX.CLAREMONT.EDU by HMCVAX.CLAREMONT.EDU (PMDF #11000) id <01GICECM0HZQ96VOEJ@HMCVAX.CLAREMONT.EDU>; Wed, 1 Apr 1992 19:18 PST Date: Wed, 1 Apr 1992 19:18 PST From: "Ned Freed, Postmaster" Subject: Re: Last Call: Multipurpose Mail Extensions to Proposed Standard To: david@twg.com Cc: ietf-822@dimacs.rutgers.edu Message-Id: <01GICECM0HZQ96VOEJ@HMCVAX.CLAREMONT.EDU> X-Vms-To: IN%"david@twg.com" X-Vms-Cc: IN%"ietf-822@dimacs.rutgers.edu" This amounts to a reference to a draft document. These are not allowed. I'd be willing to press the point if there was something worth fighting for here, but I don't see this as being terribly interesting or important. Ned   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa25387; 2 Apr 92 0:45 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa19373; 2 Apr 92 0:48 EST Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa19354; 2 Apr 92 0:47 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA11303; Thu, 2 Apr 92 00:20:20 EST Received: from WILMA.CS.UTK.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA11298; Thu, 2 Apr 92 00:20:18 EST Received: from LOCALHOST by wilma.cs.utk.edu with SMTP (5.65/2.7c-UTK) id AA28955; Thu, 2 Apr 92 00:20:13 -0500 Message-Id: <9204020520.AA28955@wilma.cs.utk.edu> To: ietf-822@dimacs.rutgers.edu Subject: clarification re: mnemonic to proposed standard Cc: moore@cs.utk.edu From: Keith Moore Date: Thu, 02 Apr 92 00:20:12 EST Sender: moore@cs.utk.edu My recent message to this list regarding mnemonic may have been misunderstood, so I'd like to state my opinion more carefully. I believe Mnemonic to be valuable work, and a reasonable interim solution to the problem of representing text from many languages in electronic mail. I therefore support registering it as a MIME character set. However, I do not recommend promoting it to proposed standard status. My reason for this has nothing to do with the quality of the work, or that Mnemonic works better for some languages than for others. It is simply that a standard should be something that will be used for a long time, and this will not be the case for Mnemonic. Keith Moore   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00358; 2 Apr 92 4:13 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa02083; 2 Apr 92 4:15 EST Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa02066; 2 Apr 92 4:15 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA05139; Thu, 2 Apr 92 03:46:45 EST Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA05135; Thu, 2 Apr 92 03:46:42 EST Received: from INFOODS.MIT.EDU by INFOODS.MIT.EDU (PMDF #12913) id <01GICW33DXNK00023X@INFOODS.MIT.EDU>; Thu, 2 Apr 1992 03:46 EST Date: Thu, 2 Apr 1992 03:46:11 -0500 (EST) From: John C Klensin Subject: Re: mime formats and versions in format specifications In-Reply-To: <92Apr1.224728pst.101795@poplar.parc.xerox.com> To: masinter@parc.xerox.com Cc: jknowles@binky.arc.nasa.gov, ietf-822@dimacs.rutgers.edu Message-Id: <702204371.655857.KLENSIN@INFOODS.MIT.EDU> X-Envelope-To: ietf-822@dimacs.rutgers.edu Mail-System-Version: >What it seems is going on is that people disagree in this forum about >the proper role of versions and format management, Actually, I don't think very much, but it is possible... >but, in the >interest of getting something out the door, the disagreement is being >swept aside. Not my reading at all. >I guess that's OK with me too, as long as the issue is >actually resolved before this thing actually becomes an internet >standard -- resolved because the spec is ambiguous and the issue needs >to be addressed, independent of whether initial testers of the spec >think it is a problem. I think the disagreement, if there is one, is right here. Let me suggest that all complex specs are ambiguous (except those that are written in code s.t. the "spec" is "anything that works like this is correct"--those have other problems, but, if one believes that all side effects are intentional, ambiguity isn't one of them). The key question isn't "ambiguous" versus "not-ambiguous", it is whether the level of ambiguity is tolerable, e.g., whether multiple implementations to the same spec, written within the variance range permitted by the putative ambiguity will interoperate to a satisfactory degree. Now that sentence is filled with fuzzy language in its use of words like "tolerable" and "variance range" and "satisfactory". They can be pinned down only by experiment and operational experience: otherwise, we just have a hypothesis by one group (including you) that the answer is "not a chance without additional clarification", a hypothesis by another group (including Ned) that the answer is "within the bounds of what can practically be done either internal or external to Postscript, what is there will permit satisfactory interoperability", and an opportunity for a small-scale religious war and a lot of wasted bandwidth. So I think the issue isn't one of "sweeping aside the disagreement" as much as it is of trying to deploy some implementations to see where we get into trouble and have to narrow things down. Note that my "it would be a good idea to tighten the text up... later" hypothesis is mostly orthogonal to the above, since one can entertain that belief regardless of whether one things the present text is actually "ambiguous" or just a small trap for the unwary and/or future would-be extenders and/or IANA, etc. ---john   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00380; 2 Apr 92 4:42 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa02691; 2 Apr 92 4:45 EST Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa02674; 2 Apr 92 4:45 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA00705; Thu, 2 Apr 92 01:47:48 EST Received: from alpha.Xerox.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA00701; Thu, 2 Apr 92 01:47:44 EST Received: from poplar.parc.xerox.com ([13.2.16.165]) by alpha.xerox.com with SMTP id <11922>; Wed, 1 Apr 1992 22:47:36 PST Received: by poplar.parc.xerox.com id <101795>; Wed, 1 Apr 1992 22:47:28 -0800 To: jknowles@binky.arc.nasa.gov Cc: ietf-822@dimacs.rutgers.edu In-Reply-To: jknowles@binky.arc.nasa.gov's message of Tue, 31 Mar 1992 15:38:43 -0800 <9203312338.AA07237@binky.arc.nasa.gov> Subject: Re: mime formats and versions in format specifications From: Larry Masinter Sender: Larry Masinter Fake-Sender: masinter@parc.xerox.com Message-Id: <92Apr1.224728pst.101795@poplar.parc.xerox.com> Date: Wed, 1 Apr 1992 22:47:27 PST A TIFF reader that could read all possible forms of TIFF files seems easier than a Postscript reader that could read all possible forms of Postscript files. Just because Postscript doesn't define any subprofiles like TIFF-B or TIFF-F doesn't mean that the problems are analogous. Besides, you can tell looking at a TIFF file which tags it uses -- they are clearly identified in the body. If there aren't going to be separate versions of ps for different versions of postscript, and "ps" means basically "anything you think is ps as long as a reader might be expected to tell", then you might as well be consistent with "tiff" and "gif" and other things too, and not expect there to be different IANA-assigned types for those. While I'd much prefer specific registration of current versions of those as "ps1" and "tiff5.0B" and "gif89a", I'd also rather have consistentcy than to have some of the subtypes version controlled and others not. What it seems is going on is that people disagree in this forum about the proper role of versions and format management, but, in the interest of getting something out the door, the disagreement is being swept aside. I guess that's OK with me too, as long as the issue is actually resolved before this thing actually becomes an internet standard -- resolved because the spec is ambiguous and the issue needs to be addressed, independent of whether initial testers of the spec think it is a problem.   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00484; 2 Apr 92 8:14 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa06458; 2 Apr 92 8:17 EST Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa06441; 2 Apr 92 8:17 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA07644; Thu, 2 Apr 92 07:50:48 EST Received: from TIS.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA07636; Thu, 2 Apr 92 07:50:44 EST Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA25336; Thu, 2 Apr 92 07:50:04 EST Message-Id: <9204021250.AA25336@TIS.COM> Reply-To: James M Galvin To: david@twg.com Cc: ietf-822@dimacs.rutgers.edu Subject: Re: Last Call: Multipurpose Mail Extensions to Proposed Standard In-Reply-To: david@twg.com's message of Tue, 31 Mar 92 13:16:15 PST. <9204012251.AA24532@dimacs.rutgers.edu> Date: Thu, 02 Apr 92 07:50:01 -0500 From: James M Galvin Modification: Add a sentence stating that later work on PEM will also be removing the "*" mechanism. I have no position on this but it occurs to me that insofar as published works (ie RFCs) may not reference unpublished works (ie internet-drafts) and this sentence implicitly references unpublished works, ... . Jim   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa07584; 2 Apr 92 10:13 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa11398; 2 Apr 92 10:15 EST Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa11362; 2 Apr 92 10:15 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA15423; Thu, 2 Apr 92 10:07:29 EST Received: from CBROWN.CLAREMONT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA15419; Thu, 2 Apr 92 10:07:27 EST Received: from HMCVAX.CLAREMONT.EDU by HMCVAX.CLAREMONT.EDU (PMDF #11000) id <01GID33C9LF896VMIH@HMCVAX.CLAREMONT.EDU>; Thu, 2 Apr 1992 07:07 PST Date: Thu, 2 Apr 1992 07:07 PST From: "Ned Freed, Postmaster" Subject: Re: mime formats and versions in format specifications To: masinter@parc.xerox.com Cc: ietf-822@dimacs.rutgers.edu Message-Id: <01GID33C9LF896VMIH@HMCVAX.CLAREMONT.EDU> X-Vms-To: IN%"masinter@parc.xerox.com" X-Vms-Cc: IN%"ietf-822@dimacs.rutgers.edu" I disagree with your assertions, your assumptions, and your conclusions. Version management is important. It is especially important in PostScript. But duplication of an existing and comprehensive version management facility is not a good idea, especially when the proposed system is, to put it charitably, feeble. This is not an issue I believe is being left unresolved to get the standard out out the door. From my perspective the current mechanisms are more than adequate, the proposed additions wrong, and I will fight to keep these proposals from being placed in the document. You have yet to convince me of the incorrectness of this position. If it makes you or anyone else feel better to think this is being done in the interests of closure, I don't have any problems with it, I guess. But when you bring this up in six months my position will probably be the same. Ned   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa07683; 2 Apr 92 10:43 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa12673; 2 Apr 92 10:45 EST Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa12655; 2 Apr 92 10:45 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA15919; Thu, 2 Apr 92 10:16:52 EST Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA15915; Thu, 2 Apr 92 10:16:50 EST Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Thu, 2 Apr 92 10:16:49 EST Received: by greenbush.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Thu, 2 Apr 92 10:16:47 EST 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, 2 Apr 1992 10:16:45 -0500 (EST) Message-Id: Date: Thu, 2 Apr 1992 10:16:45 -0500 (EST) From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: erik@sra.co.jp Subject: Re: Working Group Last Call: Mnemonic to Proposed Standard Cc: ietf-822@dimacs.rutgers.edu In-Reply-To: <9204010454.AA18643@sran8.sra.co.jp> References: <9204010454.AA18643@sran8.sra.co.jp> Excerpts from internet.ietf-822: 1-Apr-92 Re: Working Group Last Call.. Erik M. van der Poel@sra (1821) > At first glance, this does not seem to be problematic. But what, > exactly, does it mean for this 822ext WG to "recommend" this draft as > an "informational document"? This is a really good question. My understanding was that informational documents did not need WG approval. If they do, I would like to request that the "Configuration" document that I've circulated several drafts of (about the mailcap file format) be recommended in the same way. My plan all along has been to publish this as an informational RFC at the same time that MIME comes out as an RFC, but I didn't think any WG action was necessary in order to do this. If it is, I would like to propose that the WG take such action. -- Nathaniel   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa07770; 2 Apr 92 11:13 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa14088; 2 Apr 92 11:16 EST Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa14066; 2 Apr 92 11:15 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA15389; Thu, 2 Apr 92 10:03:18 EST Received: from itd.nrl.navy.mil by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA15384; Thu, 2 Apr 92 10:03:13 EST Received: from madmaxx.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA02644; Thu, 2 Apr 92 10:02:12 EST Received: by madmaxx.itd.nrl.navy.mil (4.1/SMI-4.1) id AA01668; Thu, 2 Apr 92 10:01:21 EST Date: Thu, 2 Apr 92 10:01:21 EST From: Randall Atkinson Message-Id: <9204021501.AA01668@madmaxx.itd.nrl.navy.mil> To: ietf-822@dimacs.rutgers.edu Subject: FYI: more details on Vietnamese mnemonics Folks, It was suggested that I provide more details on the existing common Vietnamese mnemonic usage so that people on this list could get a better understanding of what the existing practice is and we could work from a specific example. Towards that end, I am appending (1) a posting from someone else to soc.culture.vietnamese that is a good real world example of the usage and (2) an excerpt from the Frequently Asked Questions posting to soc.culture.vietnamese that explains the usage in a bit more detail using the Vietnamese proper names for the tone marks and such. The letters "dd" (or "-d") are used to represent a roman base character consonant that is as far as I know unique to Vietnamese. It is similar to the Icelandic Eth, but not quite the same glyph. Also, the "+" represents a horn-shaped extension to the base letter in the upper right part of the base letter. (These glyph descriptions I'm doing are very rough -- it is hard to explain without writing them correctly). It is my belief that Keld's work could be adapted to support this kind of mnemonic either as a separate profile for Vietnamese using a common mechanism from a revised rfc-mnem or that the approach below could be extended to support all of the European language needs in the same manner. For example, o-umlaut might be encoded as "o:" or the more usual "oe" (this is just an example and I think the German speakers should be directly consulted on what they find readable :-). Ran atkinson@itd.nrl.navy.mil ---------------------------------------------------------------------- From: tcn1@cec1.wsutl.edu (tcn) Newsgroups: soc.culture.vietnamese Subject: [LIT] Mo^~i tua^`n mo^.t chuye^.n Message-ID: <1992Mar28.184447.12391@wuecl.wustl.edu> Date: 28 Mar 92 18:44:47 GMT Ra('n Vuo^ng Xu+a kia o+? mo^.t vu`ng no^ng tho^n he?o la'nh no., co' mo^.t thie^'u phu. goa' cho^`ng va` mo^.t ngu+o+`i con nho?. Ca?nh ddo+`i ddu+a dda^?y bie^'t bao la` no^?i kho^? dda~ dde^'n vo+'i ngu+o+`i me., nhu+ng ba` la.i ra^'t ye^u qui' ddu+'a con cu?a mi`nh. Ta^m nguye^.n cua? ngu+o+`i me. la` se~ ta?o ta^`n khuya so+'m dde^? nuo^i con mi`nh ddi ho.c, tha`nh ta`i dde^? ddo^. ta^'m tha^n. Nga`y nga`y ngu+o+`i me. ga'nh ha`ng ddi ba'n so+'m, ta?o ta^`n da`nh du.m chu't tie^`n va` ba?o ngu+o+`i con lu'c a^'y dda~ dde^'n tuo^?i ddi ho.c, mang tie^`n dde^'n nha` cu. ddo^` dda^`u la`ng ma` xin ho.c. Ngu+o+`i con da. va^ng, cu+' mo^~i sa'ng tinh su+o+ng ngu+o+`i me. ro+`i nha` kie^'m ke^' sinh nhai, ngu+o+`i con cu~ng ro+`i nha` ddi ho.c. Hai ngu+o+`i chi? ga(.p nhau mo^~i ddo^. chie^`u ta` sau mo^.t nga`y me^.t nho.c. Tho+`i gian tha('m thoa't tro^i, ngu+o+`i me. ra^'t la^'y la`m ha`i lo`ng vi` ngu+o+`i con hie^'u tha?o, bie^'t lo cho me. nhu+~ng bu+a co+m chie^`u va` ra^'t la` chu dda'o vo+'i vie^.c nha` cu+?a. Ro^`i mo^.t ho^m, muo^'n bie^'t con mi`nh a(n ho.c ra sao, ngu+o+`i me. mo+'i ho?i con ra(`ng: Vie^.c ho.c ba^'y la^u cu?a con ra sao ro^`i! Ho^m nay dda~ ho.c nhu+~ng gi`? Ngu+o+`i con im la(.ng trong gia^y la't va` thu+a: Thu+a me., ho^m nay con kho^ng co' ddi ho.c! Ra^'t la^'y la`m nga.c nhie^n, nhu+ng tin con, ngu+o+`i me. la.i ho?i ly' do vi` sao. Ngu+o+`i con mo+'i tra? lo+`i: Ho^m nay tre^n ddu+o+`ng ddi ho.c con ga(.p mo^.t con ra('n da`i cha(.n ngang, tha^n no' lo+'n chu+`ng mo^.t thu+o+'c ta^y va^.y ne^n con ho^ng the^? na`o bu+o+'c qua ddu+o+.c. Ngu+o+`i me. ra^'t la^'y la`m la. vi` tha^'y con mi`nh cha(?ng bao gio+` no'i chuye^.n nhu+ the^' bao gio+` ne^n ho?i tie^'p: The^' con ra('n ddo' da`i chu+`ng bao nhie^n va^.y ho+? con! Thu+a, chu+`ng na(m thu+o+'c ta^y ddo' me. a.! Ngu+o+`i con dda'p. Me. chu+a bao gio+` nghe no'i la`ng ta co' ra('n to nhu+ va^.y dda^u con, co' le~ con dda~ nhi`n la^`m ro^`i! Me. o^n to^`n ba?o. Va^ng, co' le~ chu+`ng ba thu+o+'c tho^i, me a.! The^' cu~ng co`n ra^'t la` da`i ddo' con! O^`, cha(?ng khoa?ng mo^.t thu+o+'c tho^i, con nho+' ra ro^`i! Ba^'y chu+` ngu+o+`i me. mo+'i ba?o ngu+o+`i con ra(`ng, "Con o+i, sao con la.i no+~ da^'u me. ddie^`u chi ddo'...tre^n ddo+`i na`y cha(?ng co' ra('n na`o la.i vuo^ng vu+'c ngang mo^.t thu+o+'c, da`i mo^.t thu+o+'c dda^u con!" Ngu+`o+`i con lu'c a^'y mo+'i oa` kho'c ma` ra(`ng: "Thu+.c ra con cha(?ng bao gio+` ddi dde^'n tha^`y ddo^` ma` ho.c ca?...." Sao ddo' ngu+o+`i con mo+'i no'i tha^.t cho me. ra(`ng trong suo^'t tho+`i gian qua, lu'c me. ddi la`m khuya so+'m, ngu+o+`i con cu~ng da`nh ca? tho+`i gio+` ddi que't do.n nha` ngu+o+`i, mong muo^'n da`nh du.m mo^.t so^' tie^`n cho me. mi`nh ta^.u mo^.t ma?nh dda^'t dde^? hai me. con chung so^'ng an vui. Ngu+o+`i me. hie^?u ta^m su+. ngu+o+`i con hie^'u tha?o ma` kho^ng sao ca^`m ddu+o+.c nu+o+'c ma('t. Ngu+o+`i con tha^'y me. ddau lo`ng nhu+ va^.y ne^n tu+. hu+'a ma~i ve^` sau se~ nghe lo+`i me. ba?o, cha(m lo ho.c ha`nh. Tha('m thoa't ma^'y xua^n qua, ngu+o+`i me. lao kho^? dda`nh ddu.m i't tie^`n nuo^i con a(n ho.c. Ngu+o+`i con vi` sie^ng na(ng ca^`n ma^~n ne^n ddo^~ dda.t ngay trong ky` thi dda^`u. Tu+` ddo', ngu+o+`i con he^'t lo`ng hie^'u tha?o, cha(m so'c me. gia` vo+'i ddo^`ng tie^`n ma` ngu+o+`i me. dda~ cho a(n ho.c. Tuy cha(?ng gia`u sang cho la('m, ma` me. con he^'t su+'c thu+o+ng ye^u nhau va^.y. Trong mo^.t lu'c nghi~ la.i, ngu+o+`i con he^'t su+'c nho+' o+n me. dda~ chi? da.y cho, va` tu+` ddo' cha(?ng bao gio+` da^'u me. ddie^`u chi ca?. Ti`nh thu+o+ng cao ca? bie^'t bao Xin ha~y no'i tha(?ng va` trao tha^.t lo`ng Ne^'u thu+o+ng a^'p u'ng lo`ng do`ng Ha.i ngu+o+`i ha.i ca? dda'm ddo^ng kho^ng chu+`ng! ---------------------------------------------------------------------- From: hho@usc.edu (Hung P. Ho) Newsgroups: soc.culture.vietnamese Subject: [ADMIN] Frequently Asked Question for SCV (revised) Message-ID: Date: 1 Apr 92 16:37:14 GMT [material deleted for brevity] 8) WHAT ARE THE STRANGE MARKS IN THE MESSAGE? Not everyone has workstation to display Vietnamese marks on top of the words. The following is a customary way of representing the marks in the text. Originated and evolved over the years on Viet-net, there is software available that will process these diacritical marks for printing on laser and dot matrix, or display on screen. sa('c: ' -+ la' single quote huye^`n: ` | ma` inverse of above ho?i: ? | tu? question mark nga~: ~ |--- na~ tilda na(.ng: . | da. period da^'u mu?: ^ -+ mo? da^'u a': a( a(n uo^'ng da^'u mo'c: u+ o+ tu+ tu+o+?ng dde^: dd dda? dda?o diacritical marks always follow the vowels immediately: ta' tu'c NOT t'a t'uc ta^'n to+'i NOT ta^n' to+i' so on ..... [rest deleted here for brevity] ----------------------------------------------------------------------   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa07907; 2 Apr 92 11:52 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa15829; 2 Apr 92 11:55 EST Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa15781; 2 Apr 92 11:55 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA17931; Thu, 2 Apr 92 11:20:47 EST Received: from NRI.RESTON.VA.US by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA17927; Thu, 2 Apr 92 11:20:45 EST Received: from ietf.NRI.Reston.Va.US by NRI.Reston.VA.US id aa13955; 2 Apr 92 11:14 EST Received: from [127.0.0.1] by ietf.NRI.Reston.VA.US id aa07745; 2 Apr 92 11:11 EST To: Nathaniel Borenstein Cc: erik@sra.co.jp, ietf-822@dimacs.rutgers.edu, gvaudre@nri.reston.va.us Subject: Q+A: Mnemonic to Proposed Standard In-Reply-To: Your message of "Thu, 02 Apr 92 10:16:45 EST." Date: Thu, 02 Apr 92 11:11:29 -0500 From: Greg Vaudreuil Message-Id: <9204021111.aa07745@ietf.NRI.Reston.VA.US> Several Issues have been raised in the past couple of days which I will try to answer here. 1) What exactly did I (The Chair) say in the last call. Well, The WG last call for MNEMONIC was to publish both the Character Mnemonics tables and the mnemonic charsets protocol together as a "set". The draft "Character Mnemonics & Character Sets" was recommended as an informational document and "Mnemonic Character Sets" was recommended as a proposed standard. As a set, these documents can reference each other and not cause problems. Many protocols, including most routing protocols are defined in multiple documents, which are editorially bundled to keep their references in sync. 2) What is a "recommendation" for an informational document. Anybody anytime can publish an informational RFC provided the RFC editor does not feel it is damaging or an end-run around the standards process. An IETF working group can be chartered to produce an Informational RFC, such as the mnemonic character set tables. In such a case, the working group asserts before publication that it represents a community effort, is believed to be accurate, and is useful. This is a "stamp of appoval" for the ideas expressed in the document. 3) Can an experimental document be referenced in MIME. The working group has not made a clear statement on this question, but it appears from a reading of MIME that so long as the character set is documented in a publicly available form, preferably an RFC, it can be registered. As such, and experimental RFC is an RFC for this purpose. An Informational RFC would also be acceptable. Now, it is worth mentioning that there has been quite a bit of confusion about exactly what an "experimental" protocol is. Fundamentally it documents the work of an ongoing experiment. It also has been the destination for protocols not yet ready for proposed standard. Because there are many protocols in use in a limited community, and as such do not have the community push for standardization, a new category of protocol is being proposed, called "Prototype". This would be a non-standards track protocol which is believed to be implementable and useful, although for a limited domain of use. Mnemonic #MAY# fall into the category for which this new protocol type is being proposed. If the WG is unwilling to standardize the protocol, and understands that this protocol is truely more than an experiment, we could try to recommend it for a new kind of state. 4) Will the IAB accept a non-ietf character set or protocol for reference in MIME. While there has not been a clear statement on this question, I think that the patern over the past few years indicates that stable, publically avaliable standards are acceptable to be referenced and used in Internet Standard Protocols provided the reference unambigously points to a specific version of a specific standard. The MNemonic documents #could# be published as Informational RFCs republishing and documenting for the Internet community a Danish National standard, or EUnet standard for instance. Once made available in this fashon, it could be registered for use in MIME. Note, this does NOT make the documents Internet Standards. An example of this is Sun Microsystems republication of their NFS Standard. (RFC 1094) Greg Vaudreuil Chair Internet Message Extensions Working Group.   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa08091; 2 Apr 92 13:13 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa18854; 2 Apr 92 13:15 EST Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa18830; 2 Apr 92 13:15 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA24302; Thu, 2 Apr 92 13:15:33 EST Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA24298; Thu, 2 Apr 92 13:15:31 EST Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0) id AA14657; Thu, 2 Apr 92 10:15:13 PDT Message-Id: <9204021815.AA14657@Mordor.Stanford.EDU> To: Nathaniel Borenstein Cc: erik@sra.co.jp, ietf-822@dimacs.rutgers.edu Subject: Re: Working Group Last Call: Mnemonic to Proposed Standard Org: The Branch Office Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Thu, 02 Apr 92 10:16:45 -0500. Date: Thu, 02 Apr 92 10:15:11 -0800 From: Dave Crocker (Wearing my Standards Monger hat) RFCs that are labeled Informational or Experimental are published by the RFC editor, primarily at his/her discretion but after coordination with the IESG. The coordination is to ensure that the document in question does not collide with IETF work-in-progress, or the like. I believe that the primary basis for having a WG recommend an Informational or Experimental status is to make an explicit statement that a spec is *not* intended for the standards track. Dave   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa08181; 2 Apr 92 13:43 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa19813; 2 Apr 92 13:46 EST Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa19795; 2 Apr 92 13:46 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA25426; Thu, 2 Apr 92 13:36:58 EST Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA25422; Thu, 2 Apr 92 13:36:55 EST Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0) id AA14871; Thu, 2 Apr 92 10:36:38 PDT Message-Id: <9204021836.AA14871@Mordor.Stanford.EDU> To: Greg Vaudreuil Cc: Nathaniel Borenstein , erik@sra.co.jp, ietf-822@dimacs.rutgers.edu Subject: Re: Q+A: Mnemonic to Proposed Standard Org: The Branch Office Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Thu, 02 Apr 92 11:11:29 -0500. <9204021111.aa07745@ietf.NRI.Reston.VA.US> Date: Thu, 02 Apr 92 10:36:37 -0800 From: Dave Crocker Greg, Point of clarification: A wide range of document types, including different status RFCs, may be registered with IANA, for use within the MIME context. The MIME document, however, should not cite an Experimental RFC, since MIME would be prevented from making progress along the standards track, by referencing a document of "lower" standards status. Informational status is an exception, since it is an explicit statement that the document being cited is under separate (i.e., non-IETF) control. (If the Informational document is on some other standards track, then IETF rules of maturity apply. For proprietary stuff, such as NFS, the rule does *not* apply. It is my impression that EUNet is not a standards-making body, but rather its comparison to UUnet suggests that it be viewed as a vendor.) But I do not understand the reason for pursuing this issue: There is no technical or operational requirement for having the MIME document cite MNemonic and there are a significant number of WG members that have voiced objection to having the citation or for having MNemonic entered into the standards track at this time. None of this (my statements or theirs) are intended to criticise MNemonic. Quite the opposite. There has been a very, very, (one more time) very strong and consistent set of statements that MNemonic appears to be a Good Thing, within its scope. But it needs to be introduced into the general Internet carefully. Have I missed something? Dave   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa08290; 2 Apr 92 14:13 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa20947; 2 Apr 92 14:16 EST Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa20925; 2 Apr 92 14:15 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA26408; Thu, 2 Apr 92 13:56:31 EST Received: from NRI.RESTON.VA.US by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA26404; Thu, 2 Apr 92 13:56:29 EST Received: from ietf.NRI.Reston.Va.US by NRI.Reston.VA.US id aa19603; 2 Apr 92 13:39 EST Received: from [127.0.0.1] by ietf.NRI.Reston.VA.US id aa08161; 2 Apr 92 13:37 EST To: Dave Crocker Cc: Greg Vaudreuil , Nathaniel Borenstein , ietf-822@dimacs.rutgers.edu Subject: Re: Q+A: Mnemonic to Proposed Standard In-Reply-To: Your message of "Thu, 02 Apr 92 10:36:37 PST." <9204021836.AA14871@Mordor.Stanford.EDU> Date: Thu, 02 Apr 92 13:37:18 -0500 From: Greg Vaudreuil Message-Id: <9204021337.aa08161@ietf.NRI.Reston.VA.US> > Have I missed something? I think so. I'm not talking about MIME at all. The current discussion and work on MNEMONIC is a separate work item from MIME. Greg V.   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa08338; 2 Apr 92 14:43 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa21983; 2 Apr 92 14:46 EST Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa21960; 2 Apr 92 14:46 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA26893; Thu, 2 Apr 92 14:05:57 EST Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA26889; Thu, 2 Apr 92 14:05:55 EST Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0) id AA15235; Thu, 2 Apr 92 11:05:49 PDT Message-Id: <9204021905.AA15235@Mordor.Stanford.EDU> To: Greg Vaudreuil Cc: Nathaniel Borenstein , ietf-822@dimacs.rutgers.edu Subject: Re: Q+A: Mnemonic to Proposed Standard Org: The Branch Office Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Thu, 02 Apr 92 13:37:18 -0500. <9204021337.aa08161@ietf.NRI.Reston.VA.US> Date: Thu, 02 Apr 92 11:05:48 -0800 From: Dave Crocker Greg, I'm confused, as usual. > Have I missed something? I think so. I'm not talking about MIME at all. The current discussion and work on MNEMONIC is a separate work item from MIME. I was referring to this line-item in your previous note: 3) Can an experimental document be referenced in MIME. Dave   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa08424; 2 Apr 92 15:13 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa23355; 2 Apr 92 15:15 EST Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa23334; 2 Apr 92 15:15 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA27685; Thu, 2 Apr 92 14:24:27 EST Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA27676; Thu, 2 Apr 92 14:24:23 EST Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0) id AA15435; Thu, 2 Apr 92 11:24:20 PDT Message-Id: <9204021924.AA15435@Mordor.Stanford.EDU> To: ietf-822@dimacs.rutgers.edu Subject: Re: Working Group Last Call: Mnemonic to Proposed Standard Org: The Branch Office Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Thu, 02 Apr 92 10:15:11 -0800. <9204021815.AA14657@Mordor.Stanford.EDU> Date: Thu, 02 Apr 92 11:24:19 -0800 From: Dave Crocker It has been pointed out me that I have just been royally careless in the wording of a previous note. Having potentially caused damage, let me try to undo it quickly: (Wearing my Standards Monger hat) RFCs that are labeled Informational or Experimental are published by the RFC editor, primarily at his/her discretion but after coordination with the IESG. The coordination is to ensure that the document in question does not collide with IETF work-in-progress, or the like. I believe that the primary basis for having a WG recommend an Informational or Experimental status is to make an explicit statement that a spec is *not* intended for the standards track, AT THIS TIME. (The last 3 words are added.) In other words, the wg statement is, in no way, making a statement about *future* comments or recommendations about a spec, only about the group's *current* assessment. Yours for Correct Language, Dave   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa09079; 2 Apr 92 17:06 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa28483; 2 Apr 92 17:09 EST Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa28459; 2 Apr 92 17:09 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA03113; Thu, 2 Apr 92 16:22:47 EST Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA03109; Thu, 2 Apr 92 16:22:44 EST Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0) id AA16395; Thu, 2 Apr 92 13:22:40 PDT Message-Id: <9204022122.AA16395@Mordor.Stanford.EDU> To: ietf-822@dimacs.rutgers.edu, iesg@nri.reston.va.us, iab@venera.isi.edu, interesting_people@dsl.cis.upenn.edu Cc: Jordan Brown Subject: Delayed in the mail Org: The Branch Office Phone: +1 408 246 8253; fax: +1 408 249 6205 Date: Thu, 02 Apr 92 13:22:38 -0800 From: Dave Crocker Folks, Given the sudden and extreme relevance of the topic, Jordan and I had hoped to get the enclosed published quickly, but it appears that some technical difficulties, particularly concerning the handling of IP addresses at two different levels, are causing delays. Further, there is some possibility that our use of software conforming to the enclosed spec may have delayed the spec "in the mail." We may need to follow-up with a specification for the MIB variables needed to diagnose such a problem. We are interested in getting widespread review of our proposal and encourage you to pass it on freely. Feedback is welcome. Dave Network Working Group J. Brown Request for Comments: ipovermts Quarterdeck Office Systems D. Crocker The Branch Office April 1, 1992 The Transmission of IP Datagrams over Message Transfer Service Status of this Memo This memo defines a protocol for the transmission of IP datagrams over a Message Transfer Service network, configured as a logical IP subnetwork. This RFC specifies an IAB Proposed Instantaneous Standard protocol for the Internet community. High demand for this feature precludes the normal period of open discussion and review. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This memo describes use of IP over the extended, asynchronous Internet messaging service environment, configured as a logical IP subnetwork. The encapsulation method used is described, as well as various service-specific issues and expected performance and operations issues. This document considers only directly connected IP end-stations or routers which are part of the Internet Message Transfer Service, in which the Message Transfer Service provides extended, high-latency sub-network functionality, for all sites using the Internet standard message object formats. Issues raised by MAC level bridging are beyond the scope of this paper. Acknowledgment This memo draws heavily in both concept and text from specifications for similar IP mappings, specifically [3], written by Dave Piscitello and Joseph Lawrence of Bell Communications Research, [4], written by Jon J Postel and Joyce K. Reynolds of ISI and [5], written by David Katz of Merit, Inc. The authors would also like to acknowledge the contributions of the staff of the Hilton Queen. Conventions The following language conventions are used in the items of specification in this document: o MUST, SHALL, or MANDATORY -- the item is an absolute requirement of the specification. Brown & Crocker [Page 1] RFC ipovermts IP over MTS April 1992 o SHOULD or RECOMMENDED -- the item should generally be followed for all but exceptional circumstances. o MAY or OPTIONAL -- the item is truly optional and may be followed or ignored according to the needs of the implementor. Introduction The goal of this specification is to allow compatible and interoperable implementations for transmitting IP datagrams, over an extended Internet, through the use of its existing MTS. The characteristics of the Internet Message Transfer Services are presented in [2], [6], and [7]. While use of the Internet MTS has been primarily limited to human-to-human communication, there is increasing interest in its natural extension, to be used for inter- process communication, often called "mail-enabled applications." This specification provides a well-defined mechanism for permitting such activity. Briefly, MTSs offer connectionless, public, datagram-switched service. The operation and features of these services are similar to those found in other, classic, packet-switched data networks of LANs and WANs: o They provide a datagram packet transfer, where each data unit is handled and switched separately without the prior establishment of a network connection. o They exhibit high delay and low throughput, and provide the transparent transport and delivery of up to 64K or more octets of user information in a single transmission, with only moderate reliability. o No explicit flow control mechanisms are provided, but substantial buffering is available in most MAC-level bridges, in this case appearing as Message Transfer Agents (MTAs), having extremely large amounts of under-utilized storage. o Both individually and group-addressed (multicast) packets can be transferred. o Internet MTS address syntax varies, but is represented by a variable-length "mailbox" field, a delimiting octet, and a variable-length "hostname" field. The mailbox and hostname fields may be composed of octets with values from 33 to 126; see [2] and [7] for the exact rules. The delimiting octet will generally have a value of 64, but 37 and 33 are also used. Interpretation of the hostname field is global and the mailbox string has private interpretation by the host referenced in the hostname. Brown & Crocker [Page 2] RFC ipovermts IP over MTS April 1992 Internet MTS implementations operate over a wide range of platforms and underlying protocols. The common, integrating layer of functionality is specified in [2], with underlying connectivity provided, for example, by systems utilizing [7] or [6]. As a consequence, this specification permits an immediate and very substantial increase in the "reach" of the Internet. Examples of the resulting stack of services are illustrated in Figure 1: +----------------------+ | IP | +----------------------+ | MIME | +----------------------+ | RFC-822 | +----------------------+ | Local Mail Service | +----------------------+ | UUX | SMTP | +-----------+----------| | UUCP | TCP/IP | +-----------+----------+ | RS-232 | Ether | +----------------------+ Figure 1. Protocol stack for IP over Message Transfer Service This memo describes use of IP over an extended Internet MTS environment configured as a logical IP subnetwork. Issues related to transparent data link layer interoperability of multi-stack MTSs such as [20] are beyond the scope of this specification. Advantages o As the logical network defined by an MTS is not bounded by physical IP network topologies, IP addresses may be assigned without regard for the actual real-time connectivity. This "hypernet" concept dramatically eases the current "address space crunch" - since the entire mail-connected Internet, with its thousands of component subnetworks can now be represented as a single IP subnet, a handfull of Class A network numbers would handle expected growth for several years. Note that unlike current "supernet" proposals, this mechanism does not require any changes in the Internet routing protocols. o Historically, electronic mail reliability has been fair to poor. IP over MTS resolves this concern. Electronic mail over TCP/IP over the MTS, means that a message is transmitted via SMTP and TCP. Since IP is typically over otherwise unreliable links, TCP retransmission and acknowledgement are automatically provided. Hence, this permits the use of email, to improve the reliability of email. o The multicast services provided are ideally suited for multimedia teleconferencing, though due to the transmission characteristics of the interface audio may be somewhat bursty. Brown & Crocker [Page 3] RFC ipovermts IP over MTS April 1992 o For sites not directly attached to the IP Internet, such as the vast array of uucp sites, multi-hop file transfer, via FTP or rcp, is made conveniently accessible. o This proposal suggests a natural resolution to the heated debate over remote procedure call, versus message-queueing inter-process, communication. This proposal specifies a synchronous -- i.e., RPC-oriented -- mechanism which operates over a fundamentally message-queuing service. Packet Format Service SHALL be encapsulated using the MIME message encapsulation described in [8]. This memo describes systems based on [2]. Considerably more extensive connectivity is possible, via gateway techniques, to the various commercial and LAN-based proprietary MTSs. Specification of MTS-level format-translation, serving the functional role of MAC-bridging, is beyond the scope of this document. Further, it seems feasible to contemplate interoperation with messaging based upon different hardware technologies, such as postal. However, the likelihood of excessive data corruption due to issues such as scanner error rates renders this capability a research topic for further study. The header mechanism described in [2] allows for a very rich set of routing and delivery options. The basic format allows for MAC-level route tracing and performance monitoring, uni- and multi-cast messages, unique packet identifiers, and fully extensible user-defined fields. Commonly available implementations [9] include extensions for MAC-level acknowledgments, packet prioritization, and error checking. However, such facilities are not yet standardized for the Internet. The following fields are required: To, From, and Date. To: From: Date: Content-type: Message/IP Content-transfer-encoding: hex64 [Hex-encoded MIME-based version of a single IP datagram] Figure 2. Data Link Encapsulation o The mailbox portion of the values of To and From in the Header are "IPoverMTSlink". Additional aggregate throughput may be achieved by the exercise of multiple paths, with different mailbox addresses. However, the specification in this document relies upon a single, standard mailbox reference, as is typical for other link-level Type protocol identifiers. Brown & Crocker [Page 4] RFC ipovermts IP over MTS April 1992 o The total length of the header is variable. The header is terminated by the first instance of the byte sequence 0D, 0A, 0D, 0A encountered in the packet, as discussed in [2]. o The choice of specific Content-Transfer-Encoding algorithm is at the option of the sender, within the limits of registered encoding types and the expected facilities of the recipients. However, the IP context generally is viewed as fully binary, so that Hex64 is the most natural choice. o The use of MIME message structuring suggests IP data aggregation through a Content-Type of Multi-part, thereby allowing datagram "bagging", but the use of such a capability is viewed as an enhancement beyond the scope of the current specification. A typical data link encapsulation for IP packets is shown in Figure 3. All values shown are in Internet NVT ASCII. Received: from localhost by qdeck.com; for ipovermtslink@mordor.stanford.edu; 01 April 1992 1200 +0800 To: ipovermtslink@mordor.stanford.edu From: ipovermtslink@qdeck.com Date: 01 April 1992 1200 +0800 Return-Receipt-To: ip-ack@qdeck.com Figure 3. IP Data Link Encapsulation and Values The Figure shows use of the popular, but non-standardized Return-Receipt-To feature available in some MTSs. This feature increases the reliability level of the MTS at the link-level, by making detection of delivery failure possible. This allows the option of re-transmission. It should be noted, however, that support for this capability is not universal, thereby suggesting that the safest operational model is of the MTS as an unreliable and unacknowledged datagram environment. Address Resolution The dynamic mapping of 32-bit Internet addresses to MTS addresses SHOULD be done via the reverse address mapping facility of the Domain Name System [10]. This IN-ADDR facility produces only a host reference; hence this specification has a single, fixed choice for the mailbox portion of a reference. Use of any other mailbox string would require prior arrangement among the participating hosts, as well as static address mapping tables. Each host implementation MUST know its own Internet address and MTS address. Brown & Crocker [Page 5] RFC ipovermts IP over MTS April 1992 IP Broadcast Address While the MTS environment supports explicit multicast, there is no facility for complete broadcast addressing. However, it is advised that there be exploration in the use of features in [18] and [19] to provide a relatively efficient broadcast mechanism. IP Multicast Support Source multicast - As the destination field is allowed to contain multiple addresses, the source may trivially send a single packet to numerous recipients. Group multicast - Depending upon the facilities of the underlying MTS, hosts may join logical "mailing lists" which provide a single MTS address which "explodes" to target numerous "real" MTS addresses, and this can be taken to any number of levels. The mapping of IP multicast addresses (Class D) to specific MTS mailing lists will initially require private lookup tables. Development of automated, distributed registration and lookup facilities is for further study. Trailer Formats Some versions of Unix 4.x BSD use a different encapsulation method in order to get better network performance with the VAX virtual memory architecture. Trailers SHALL not be used over the MTS. Byte Order As described in Appendix B of the Internet Protocol specification [1], the IP datagram is transmitted over the MT Service as a series of 8-bit bytes (octets). The network byte order of the IP datagram shall be mapped directly onto the native MT byte order. MAC Sublayer Details Packet Size [11] defines a a minimum maximum service data unit size of 65536 octets. This leaves about 65000 octets for user data after the RFC-822 and MIME headers are taken into account. Individual MTSes may define higher limits, and many do. Transmission of large IP datagrams may require use of IP fragmentation or MIME Multipart/partial. The choice between the use of these two options is at the option of the sender. It should be noted, however, that use of link-level fragmentation techniques, as long as they permit in-order reassembly of the data, have the benefit of increased efficiency, due to reduced memory and bandwidth requirements, since they do not result in the presence of the IP header in each fragment. Brown & Crocker [Page 6] RFC ipovermts IP over MTS April 1992 There is no minimum packet size restriction defined for the MTS. Performance It should be noted that proposed enhancements to TCP are designed to increase throughput over high-delay channels. It is expected the IP over MTS will provide a rich opportunity for use of these enhancements. Other MAC Sublayer Issues The MTS requires that the publicly administered host name plus mailbox name SHALL be used in both source and destination address fields of the RFC-822 header [2]. REFERENCES 1. Postel, J., "Internet Protocol", RFC 791, USC/Information Sciences Institute, September 1981. 2. Crocker, D. "ARPA Internet Text Messages", RFC 822, Univ of Delaware, August 1982. 3. Piscitello, D., and J. Lawrence, "The Transmission of IP Datagrams over the SMDS Service", RFC 1209, Bell Communications Research, March 1991. 4. Postel, J., and J. Reynolds, "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks", RFC 1042, USC/Information Sciences Institute, February 1988. 5. Katz, D., "A Proposed Standard for the Transmission of IP Datagrams over FDDI Networks", RFC 1188, Merit/NSFNET, October 1990. 6. Postel, Jonathan, "Simple Mail Transfer Protocol", RFC 821, USC/Information Sciences Institute, August 1982. 7. Horton, Mark, "UUCP Mail Interchange Format Standard", RFC 976, Bell Laboratories, February 1986. 8. Borenstein, N. and Freed, N., "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", Internet Draft, USC/Information Sciences Institute, February 1992. 9. Allman, Eric, "Mail Systems and Addressing in 4.2bsd", USENIX Proceedings, January 1983. 10. Mockapetris, P.V. "Domain names - implementation and specification", USC/Information Sciences Institute, November 1987. 11. Braden, R.T., "Requirements for Internet hosts - application and support", RFC 1123, USC/Information Sciences Institute, October 1989. Brown & Crocker [Page 7] RFC ipovermts IP over MTS April 1992 12. Reynolds, J.K. "Helminthiasis of the Internet", RFC 1135, USC/Information Sciences Institute, December 1989. 13. Linn, J. "Privacy enhancement for Internet electronic mail: Part III - algorithms, modes, and identifiers [Draft]", RFC 1115, August 1989. 14. Kent, S.T.; Linn, J. "Privacy enhancement for Internet electronic mail: Part II - certificate-based key management [Draft]", RFC 1114, August 1989. 15. Linn, J. "Privacy enhancement for Internet electronic mail: Part I - message encipherment and authentication procedures [Draft]", RFC 1113, August 1989. 16. This citation intentionally left blank. 17. This citation intentionally left blank. 18. Horton, M.R. and R. Adams, "Standard for interchange of USENET messages", RFC 1036, December 1987. 19. Kantor, B. and Lapsley, P. "Network News Transfer Protocol", RFC 977, February 1986. 20. Schicker, Pietro, "Message Handling Systems, X.400", Message Handling Systems and Distributed Applications, E. Stefferud, O-j. Jacobsen, and P. Schicker, eds., North-Holland, 1989, pp.3-41. Security Considerations As the insecurity of MTSes is well-known [12], this should be considered to be an insecure transport service. Additional layers [13,14,15] can be interposed, however, to substantially improve the situation. The details of such extensions are not discussed in this memo. Authors' Addresses Jordan Brown Quarterdeck Office Systems 150 Pico Blvd Santa Monica, CA 90405 Phone: +1 310 314 4260 EMail: jbrown@qdeck.com David H. Crocker The Branch Office 675 Spruce Dr. Sunnyvale, CA Phone: +1 408 246 8253 EMail: dcrocker@mordor.stanford.edu Brown & Crocker [Page 8]   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00347; 3 Apr 92 3:43 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa01485; 3 Apr 92 3:46 EST Received: from dimacs.RUTGERS.EDU by NRI.Reston.VA.US id aa01457; 3 Apr 92 3:45 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA25489; Fri, 3 Apr 92 03:24:47 EST Received: from srawgw.sra.co.jp by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA25485; Fri, 3 Apr 92 03:24:28 EST Received: from sranhd.sra.co.jp by srawgw.sra.co.jp (5.67WH/1.5) id AA22746; Fri, 3 Apr 92 17:23:31 +0900 Received: from sran8.sra.co.jp by sranhd.sra.co.jp (5.67ew/6.4J.6-BX) id AA15236; Fri, 3 Apr 92 17:23:03 +0900 Received: from localhost by sran8.sra.co.jp (4.0/6.4J.6-SJX) id AA22110; Fri, 3 Apr 92 17:23:00 JST Return-Path: Message-Id: <9204030823.AA22110@sran8.sra.co.jp> Reply-To: erik@sra.co.jp From: "Erik M. van der Poel" To: ietf-822@dimacs.rutgers.edu Subject: Re: Q+A: Mnemonic to Proposed Standard Date: Fri, 03 Apr 92 17:22:59 +0900 Sender: erik@sran8.sra.co.jp > (If the Informational document is on some other standards track, then > IETF rules of maturity apply. For proprietary stuff, such as NFS, > the rule does *not* apply. It is my impression that EUNet is not > a standards-making body, but rather its comparison to UUnet suggests > that it be viewed as a vendor.) 822ext people, I have no idea whether EUnet and UUnet can be meaningfully compared to each other, but, in my opinion, NFS and Keld's "charsets" document cannot be compared. NFS was simply a brand new protocol, and there were few items in the specs that could be challenged on accuracy grounds (though people may have had other reasons to complain -- that's a separate issue). [I'm not interested in replies to this paragraph.] What bothers me is that Keld's gigantic document contains many tables of existing character sets, many of which have already been officially registered with ECMA according to ISO procedures, and some of which are proprietary standards. Essentially, Keld's work is a duplication of the information already contained in other documents. My concern is whether this duplication is in fact faithful. I have no doubts about Keld's intentions (they're good), but work of this size is bound to have bugs in it. If the work simply involved copying each character's name from the official document to a table in Keld's document, there is some chance that it would be correct, but it would still have to be checked of course. But if I am not mistaken the work involves more than simply copying character names. For each character added to the tables, you need to check if that character has already been added to some other table, and give it the same name (i.e. the two-byte mnemonic). Now _that_ is where the problem comes in. How do you decide whether any particular pair of characters are the same? Are they the same if their names in their respective official documents are similar? Are they the same if they are graphically similar? What Keld has done is to unify the characters from the various character sets, very similar to Unicode's work. A heck of a lot of work. (Wow, Keld!) But now tell me -- is Keld's document the sort of document that the 822ext WG can put its stamp of approval on? I'd say "No". Many of the people in this WG are relatively clueless as far as character sets are concerned. (I am one of them.) This WG would be slapping the true experts in the face if it approves the document for publication as an informational RFC. It would be presumptuous to say the least. Erik PS I find it amazing that this situation can even arise in the IETF. Procedures are extremely loose. But that's why it's fun too! PPS If this WG "recommends" Keld's document, and the RFC editor publishes it as an informational RFC, you can bet on it that Keld will make that fact known to various other working groups, and use it as a lever to get his work approved elsewhere. PPPS If "informational RFCs" are really not such a big deal, and the RFC editor doesn't care about the accuracy of the information, and not many other people care either, then I take it all back, and you can ignore this message. (!)   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa15192; 3 Apr 92 11:43 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa00525; 3 Apr 92 11:46 EST Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa00502; 3 Apr 92 11:46 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA08059; Fri, 3 Apr 92 11:39:48 EST Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA08049; Fri, 3 Apr 92 11:39:43 EST Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Fri, 3 Apr 92 11:39:40 EST Received: by greenbush.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Fri, 3 Apr 92 11:39:17 EST 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, 3 Apr 1992 11:39:15 -0500 (EST) Message-Id: Date: Fri, 3 Apr 1992 11:39:15 -0500 (EST) From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: info-metamail@thumper.bellcore.com, ietf-822@dimacs.rutgers.edu Subject: Announcing a MIME mailserver References: I'm happy to announce an experimental MIME mailserver. To use the service, just send mail to "andrew@thumper.bellcore.com" with a subject line of autosend: keyword If your keyword is unrecognized (e.g. "help" or "list") it will send you back a list of the available information and the keywords to use. Currently, what's available is documents relating to the MIME standard and a few pictures & audio clips. What comes back to you will be MIME-compliant multimedia messages, usually in the form of several message/partial messages to avoid "mail too big" problems. Please let me know if you have any comments, problems, or suggestions regarding this service, which might be turned off without notice if it turns out to place too heavy a load on our facilities. -- Nathaniel   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa15459; 3 Apr 92 13:13 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa03536; 3 Apr 92 13:15 EST Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa03512; 3 Apr 92 13:15 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA13832; Fri, 3 Apr 92 13:12:36 EST Received: from othello.admin.kth.se by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA13828; Fri, 3 Apr 92 13:12:30 EST Received: from mercutio.admin.kth.se by othello.admin.kth.se (5.65+bind 1.7+ida 1.4.2/4.1) id AA23220; Fri, 3 Apr 92 19:29:16 +0200 From: Olle Jarnefors Received: by mercutio.admin.kth.se (5.65+bind 1.7+ida 1.4.2/4.0) id AA13325; Fri, 3 Apr 92 19:09:42 +0200 Date: Fri, 3 Apr 92 19:09:42 +0200 Message-Id: <9204031709.AA13325@mercutio.admin.kth.se> To: AXELSSON@cslab.felk.cvut.cs, Dan.Oscarsson@malmo.trab.se, ietf-822@dimacs.rutgers.edu, jonnya@ifi.uio.no, ojarnef@admin.kth.se Subject: Re: Working Group Last Call: Mnemonic to Proposed Standard Jonny Axelsson slipped into Norwegian in the middle of his recent message, cc-ed to the ietf-822 list. Here is (a Swede's) instant translation to English: > Well, I can think of several reasons why ASCII and -1 isn't such a > neat idea. One of them is only a few kilometers south of you - Poland. > > Ingen tidligere \st-Europeiske land jeg kan komme p} unntatt > Romania kan bruke ASCII p} samme m}te som Skandinavia (ved } bytte ut > seks tegn i ASCII, og priviligert posisjon i -1). * None of the East-European countries I can think of, except * Romania, can use ASCII in same way it is used in Scandinavia * (by replacing six characters in 7-bit ASCII, and having a * privileged position in [part] 1 [of ISO 8859]). > Den eneste grunnen til at Norden har f}tt med sine obskure tegn, og > ikke si Tsjekkoslovakia, er at f|rstnevnte er medlem av COCOM og > sistnevnte var medlem av COMECON. Og antallet brukere som trenger > lang Y i dag er st|rre enn antallet som trenger Thorn, og snart > st|rre enn de som trenger ]. * The sole reason for the inclusion of the obscure characters * from the Nordic countries, and the exclusion of * Czechoslovakian characters, are that the former are members of * COCOM and the latter country of COMECON. And the number of * users that need long Y [Y with acute accent] today is larger * than the number that need [Icelandic] Thorn, and soon also * larger than those needing [Scandinavian] A with ring. > Vennlig hilsen, > > Jonny * Yours sincerely, * * Jonny -- Olle Jarnefors, Royal Institute of Technology, Stockholm   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa15987; 3 Apr 92 19:13 EST Received: from nri.reston.va.us by NRI.Reston.VA.US id aa19669; 3 Apr 92 19:16 EST Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa19648; 3 Apr 92 19:16 EST Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA26472; Fri, 3 Apr 92 17:31:32 EST Received: from binky.arc.nasa.gov by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA26468; Fri, 3 Apr 92 17:31:27 EST Received: from localhost.arc.nasa.gov by binky.arc.nasa.gov (4.1/1.34) id AA18879; Fri, 3 Apr 92 14:30:54 PST Message-Id: <9204032230.AA18879@binky.arc.nasa.gov> To: erik@sra.co.jp Cc: ietf-822@dimacs.rutgers.edu Subject: Re: Q+A: Mnemonic to Proposed Standard In-Reply-To: Your message of "Fri, 03 Apr 92 17:22:59 +0900." <9204030823.AA22110@sran8.sra.co.jp> Date: Fri, 03 Apr 92 14:30:53 PST From: jknowles@binky.arc.nasa.gov >But now tell me -- is Keld's document the sort of document that the >822ext WG can put its stamp of approval on? > >I'd say "No". Many of the people in this WG are relatively clueless as >far as character sets are concerned. (I am one of them.) This WG would >be slapping the true experts in the face if it approves the document >for publication as an informational RFC. It would be presumptuous to >say the least. Well, I'm also in the clueless group and I'd love to hand this off to the experts. Where are they? Which working group would that be? Or should one be formed, quickly? If there's no place to punt to, I'd recommend trying to resolve the technical problems within this group as best we can. I don't think that slaps anybody's face, at least not intentionally. Besides, I've seen evidence that at least some of the wg members have enough experience to provide a useful evaluation of the proposal. The issues I see are, 1) accuracy of the information; 2) conflict with the co-existing Viet-net convention; 3) lower level of usefulness with non-alphabetic languages; 4) exactly what is the level of standardization we are recommending, and what does conformance to that standard mean (in and of itself, NOT in relationship to MIME)? No doubt there are others, but these have been consistently raised and I don't think we have reached consensus yet. Can we map out a plan to resolve these (and any additional) issues? As part of that plan, maybe we should define the end state for each. If we can agree on that (I remain hopeful), we should be able to figure out how to get there from here. 1) is kind of tied to 4). I'm assuming experimental status implies allowing a thorough test period to guarantee accuracy. Proposed seems to require a higher level of confidence going in. Informational, I'm not sure, but it would be a shame to have bad info in an Informational doc. Regarding 2): can Keld's mnemonic's be modified to accomodate the Viet-net convention as a profile? Should this be a requirement? If it is just technically impossible, this should be laid out plainly for the clueless. Then we can decide if two incompatible schemes can coexist. I'm not sure any mnemonic scheme can do much with 3). If that's true, and it's not a specific problem with Keld's proposal, we should decide quickly if we can accept any mnemonic proposal at all. 4) requires that we know what Informational, Experimental and Proposed mean. Pointers to the document specifying these would be very helpful. All this assumes that we're the right group to do this work. Any chance of consensus on at least this? Jim   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01464; 6 Apr 92 3:44 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa07699; 6 Apr 92 3:47 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa07676; 6 Apr 92 3:47 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA29609; Mon, 6 Apr 92 03:36:42 EDT Received: from bells.cs.ucl.ac.uk by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA29605; Mon, 6 Apr 92 03:36:36 EDT Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 6 Apr 1992 08:36:19 +0100 To: Bob Smart Cc: ietf-822@dimacs.rutgers.edu Subject: Re: Transport involvement in Delivery Acknowledgements Phone: +44-71-380-7294 In-Reply-To: Your message of Sat, 28 Mar 92 11:07:45 +1000. <9203280107.AA22911@manta.mel.dit.CSIRO.AU> Date: Mon, 06 Apr 92 08:35:30 +0100 Message-Id: <503.702545730@UK.AC.UCL.CS> From: Steve Hardcastle-Kille You write "In particular such optional Delivery Acks would not be useful to someone writing an X.400-smtp gateway. It would be nice if an expert like Ned Freed or Steve Kille would confirm my feeling on this matter." If you really want compatibility with X.400, there is little work to do on formats. 1148bis defines a representation of both Delivery Reports and Inter Personal Notifications. Extensiblity features in these PDUs could be used to add other features (if you really want this). IPNs (user level notifications) could be added in quite easily. I think that to do delivery notifications effectively, you have to change the MTS level (SMTP). Both services are needed, but the delivery ack is the more important - particularly because there are lots of reasons (not least privacy) why a higher level ack will never be implemented universally. Extending SMTP is fraught with problems, unlike the MIME 822 extensions, which are straightforward and excellent. I think that it would be better to switch to an X.400 transport. Perhaps it would be useful to define a way to carry MIME directly over X.400 MTS, so that there is no need for an intermediate P2 conversion. MIME/POP UAs can become cheap and widespread. These can be supported by X.400 and 1148ter capabale MTAs. A UA can request and receive delivery reports by 1148 and gets "nice" 822 addressing. Steve   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01499; 6 Apr 92 5:13 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa08309; 6 Apr 92 5:16 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa08292; 6 Apr 92 5:16 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA29682; Mon, 6 Apr 92 05:11:24 EDT Received: from garam.kreonet.re.kr by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA29678; Mon, 6 Apr 92 05:11:18 EDT Received: from bh.kpnu.ac.kr ([192.135.230.2]) by garam.kreonet.re.kr (4.1/GARAM-MX-1.0) id AA05077; Mon, 6 Apr 92 18:10:28 KST Received: by bh.kpnu.ac.kr (AIX 3.1/UCB 5.61/BH-1.0) id AA08993; Mon, 6 Apr 92 17:47:52 +0900 Date: Mon, 6 Apr 92 17:47:52 +0900 From: 5557 Message-Id: <9204060847.AA08993@bh.kpnu.ac.kr> To: S.Kille@cs.ucl.ac.uk, smart@mel.dit.csiro.au Subject: Re: Transport involvement in Delivery Acknowledgements Cc: ietf-822@dimacs.rutgers.edu Please remove me from the mailing list. Thanks. Kijun Han   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02571; 6 Apr 92 12:43 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa17903; 6 Apr 92 12:46 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa17885; 6 Apr 92 12:46 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA11490; Mon, 6 Apr 92 12:21:16 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA11485; Mon, 6 Apr 92 12:21:13 EDT Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Mon, 6 Apr 92 12:20:05 EDT Received: by greenbush.bellcore.com (4.1/4.7) id for lacroix@heron.bellcore.com; Mon, 6 Apr 92 12:19:46 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; Mon, 6 Apr 1992 12:19:44 -0400 (EDT) Message-Id: Date: Mon, 6 Apr 1992 12:19:44 -0400 (EDT) From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: metamail-announce@thumper.bellcore.com Subject: Metamail Version 2.2 Now available Cc: ietf-822@dimacs.rutgers.edu, Michel Lacroix , Dick Munroe , George Stratemeier , Rod Hart , Don Rolph I am very happy to announce the much-delayed second public release of the metamail software. (If you were a beta tester, please note that the new version is slightly improved, and you, too, should upgrade). This second release, metamail version 2.2, is available as a compressed tar file via the following various mechanisms, at least one of which should work for nearly everyone: 1. Anonymous ftp from thumper.bellcore.com, directory pub/nsb, file name "mm.tar.Z". 2. Send mail to "mailserver@thumper.bellcore.com" with a subject line of "metamail-sources". You will get back the sources in MIME format, which means you need to already have an older version of metamail or some other MIME reader in order for it to be useful. If you do, however, you should get the compressed tar file automatically extracted from the mail and stuck into a file with a funny name on /tmp. 3. Send mail to "mailserver@thumper.bellcore.com" with a subject line of "metamail-sources-uu". You will get back the sources as a UUENCODED compressed tar file, probably in several pieces. This is the most painful way, but probably the only option if you have neither ftp access nor a previous version of a MIME-compliant mail reader. The good news is that you'll be able to use method #2 for later upgrades. 4. The new version will probably appear on the funet archive before too long. (This message is notifying the funet administrators that a new version is available.) 5. If you can't retrieve the software using any of the above methods, send me mail. The new version has several major advantages over the old version, and I recommend that all metamail users upgrade. Aside from fixing one security hole (the postcheck program) and one core-dumping bug, the new release includes dozens of additional fixes and enhancements. In particular, it includes greatly enhanced portability (it now runs on almost every UNIX variant, plus MS-DOS), vastly improved documentation (man pages), additional mailcap entries, directions for patching several additional mail readers (MH-E, Mush, Batmail, UUPC), and a new program, "mailto", that makes it much easier for users to generate their own multimedia mail. There is also now a "contrib" directory that includes a couple of MIME-related tools for Emacs and a README.DOS file for DOS users. (DOS users should note that metamail has not been nearly as extensively tested yet on DOS as on UNIX, but it is reported to basically work.) Beyond simply replacing your old version of the software with the new version, you should also compare the new prototype mailcap file to your site's mailcap file, as there are several new entries you may want. Finally, several of the mailer patches have been improved, so if you have any complaints about your mailer's behavior with metamail, you may want to re-patch. (Users of some variants of Berkeley mail, in particular, may find the new patches essential in order to work with xmail or mailtool.) A more complete and detailed list of changes is in the file "2.2.CHANGES" in the pub/nsb directory on thumper. If you don't have ftp access, send mail to mailserver@thumper.bellcore.com with a subject line of "2.2.CHANGES". Note that I did not make this version available as a patch file, because there were so many changes that a patch file is actually BIGGER. I intend to provide patch files in future releases. Thanks are due to all the many people who helped with this release of metamail -- you are now acknowledged in a CREDITS file in the top-level directory. And thanks to all of you who have given me so much encouragement since the first public release of metamail. -- Nathaniel Borenstein   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00577; 7 Apr 92 9:44 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa09864; 7 Apr 92 9:47 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa09830; 7 Apr 92 9:47 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA25042; Tue, 7 Apr 92 09:28:32 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA25035; Tue, 7 Apr 92 09:28:29 EDT Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Tue, 7 Apr 92 09:28:13 EDT Received: by greenbush.bellcore.com (4.1/4.7) id for a722756@pan.mc.ti.com; Tue, 7 Apr 92 09:27:53 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; Tue, 7 Apr 1992 09:27:51 -0400 (EDT) Message-Id: <8dsOBLm0M2Yt0jUqJ1@thumper.bellcore.com> Date: Tue, 7 Apr 1992 09:27:51 -0400 (EDT) From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: metamail-announce@thumper.bellcore.com Subject: Anon ftp to thumper Cc: ietf-822@dimacs.rutgers.edu, Michel Lacroix , Dick Munroe , George Stratemeier , Rod Hart , Don Rolph In-Reply-To: References: Naturally, as soon as I told the whole world about the release of metamail 2.2, thumper had a crash and lost its anonymous ftp area. It is now restored, so if you were unable to pick up metamail 2.2 yesterday, it should work today. Mailserver access has been, I believe, unaffected by the problems. -- Nathaniel   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa07118; 7 Apr 92 18:14 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa01988; 7 Apr 92 18:17 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa01942; 7 Apr 92 18:16 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA20529; Tue, 7 Apr 92 18:13:28 EDT Received: from dkuug.dk by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA20525; Tue, 7 Apr 92 18:13:24 EDT Received: by dkuug.dk (5.64+/8+bit/IDA-1.2.8) id AA14583; Wed, 8 Apr 92 00:12:53 +0200 Date: Wed, 8 Apr 92 00:12:53 +0200 From: Keld J|rn Simonsen Message-Id: <9204072212.AA14583@dkuug.dk> To: erik@sra.co.jp, ietf-822@dimacs.rutgers.edu Subject: Re: Q+A: Mnemonic to Proposed Standard X-Charset: ASCII X-Char-Esc: 29 > Essentially, Keld's work is a duplication of the information already > contained in other documents. My concern is whether this duplication > is in fact faithful. I have no doubts about Keld's intentions (they're > good), but work of this size is bound to have bugs in it. Yes, I cannot guarantee that there are no bugs in it. There have been bugs found - in the order of 10 bugs in the last 6 months, plus some spelling errors. > If the work simply involved copying each character's name from the > official document to a table in Keld's document, there is some chance > that it would be correct, but it would still have to be checked of > course. > > But if I am not mistaken the work involves more than simply copying > character names. For each character added to the tables, you need to > check if that character has already been added to some other table, > and give it the same name (i.e. the two-byte mnemonic). That is true, some of the characters do not have the same names as in 10646, some even does not have names (some vendor sets). So I had to judge what it was. And that could be a source of errors. I have had the main tables checked by programs up against other collections of character sets (some errors were found in this process). The tables have been available for about a year, also in character set standards circles, so I think they are thoroughly tested. A good way to have them even better tested is to have them published as a RFC. > But now tell me -- is Keld's document the sort of document that the > 822ext WG can put its stamp of approval on? > > I'd say "No". Many of the people in this WG are relatively clueless as > far as character sets are concerned. (I am one of them.) This WG would > be slapping the true experts in the face if it approves the document > for publication as an informational RFC. It would be presumptuous to > say the least. The tables have also been available to other communities than IETF, including character set experts in ISO/IEC SC2/WG2, CEN IT/CSC, EWOS TLG/CS and UNICODE. They have not approved them, but if they found errors, they could easily report them. And some has done so. The tables are originally written for ISO standardisation. And they are also now being brought forward there, namely in SC22/WG20 and also CEN IT/CSC. > > PPS If this WG "recommends" Keld's document, and the RFC editor > publishes it as an informational RFC, you can bet on it that Keld will > make that fact known to various other working groups, and use it as a > lever to get his work approved elsewhere. Yes, I will tell people. Also those who paid me (Nordic Standards). But it may not be a great help, as some standardisation bodies are reluctant to standardise something which is already in use, and thus gives somebody an advantage. But I would regard publishing my I-D as an RFC as something I would be very proud of, I think many RFC authors would have this feeling. > PPPS If "informational RFCs" are really not such a big deal, and the > RFC editor doesn't care about the accuracy of the information, and not > many other people care either, then I take it all back, and you can > ignore this message. (!) > that was what I was about to say, we only intend it for informational RFC, and that has no great standing in the internet standards hierachy. Keld   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa07166; 7 Apr 92 19:43 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa04772; 7 Apr 92 19:46 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa04755; 7 Apr 92 19:46 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA24173; Tue, 7 Apr 92 19:31:24 EDT Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA24169; Tue, 7 Apr 92 19:31:22 EDT Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0) id AA17087; Tue, 7 Apr 92 16:31:04 PDT Message-Id: <9204072331.AA17087@Mordor.Stanford.EDU> To: Keld J|rn Simonsen Cc: erik@sra.co.jp, ietf-822@dimacs.rutgers.edu Subject: Re: Q+A: Mnemonic to Proposed Standard Org: The Branch Office Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Wed, 08 Apr 92 00:12:53 +0200. <9204072212.AA14583@dkuug.dk> Date: Tue, 07 Apr 92 16:31:03 -0700 From: Dave Crocker If you intend MNemonic to be an Informational RFC, you do not need working group review of it, other than to have any "relevant" working groups, via the Applications Area Director, agree that the spec is not in conflict with any on-going or planned IETF working group efforts. This is usually verified by the RFC Editor, after the document is submitted for publication, so it usually is quite automatic. Hence, it sounds as if you want to submit your documents to the RFC editor. Dave   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00360; 8 Apr 92 5:14 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa03752; 8 Apr 92 5:17 EDT Received: from dimacs.RUTGERS.EDU by NRI.Reston.VA.US id aa03735; 8 Apr 92 5:17 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA10858; Wed, 8 Apr 92 04:49:07 EDT Received: from srawgw.sra.co.jp by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA10854; Wed, 8 Apr 92 04:48:37 EDT Received: from sranhd.sra.co.jp by srawgw.sra.co.jp (5.67WH/1.5) id AA17399; Wed, 8 Apr 92 17:47:13 +0900 Received: from sran8.sra.co.jp by sranhd.sra.co.jp (5.67ew/6.4J.6-BX) id AA15321; Wed, 8 Apr 92 17:46:48 +0859 Received: from localhost by sran8.sra.co.jp (4.0/6.4J.6-SJX) id AA28261; Wed, 8 Apr 92 17:46:46 JST Return-Path: Message-Id: <9204080847.AA28261@sran8.sra.co.jp> Reply-To: erik@sra.co.jp From: "Erik M. van der Poel" To: Keld J|rn Simonsen Cc: ietf-822@dimacs.rutgers.edu Subject: Re: Q+A: Mnemonic to Proposed Standard Date: Wed, 08 Apr 92 17:46:44 +0900 Sender: erik@sran8.sra.co.jp > That is true, some of the characters do not have the same names > as in 10646, some even does not have names (some vendor sets). > So I had to judge what it was. And that could be a source of errors. Actually, in that case I wouldn't call it an "error", I would call it "your opinion". So people using your tables to convert between character sets would be basing their conversions on your opinion. The people who actually designed or actually use the character sets may have a different opinion. That is also one of my concerns. > I have had the main tables checked by programs up against other > collections of character sets (some errors were found in this process). Why don't you keep only the "main tables" in the document, then? > The tables have been available for about a year, also in character > set standards circles, so I think they are thoroughly tested. And why should I believe this statement? > A good way to have them even better tested is to have them published > as a RFC. For a standards-track RFC, the Internet Way is to make drafts available for some time and to have at least two independent implementations to try to assure that the specs ensure interoperability. So specs become RFCs after testing, not before. On the other hand, I believe Experimental RFCs are specifically meant to be published before testing. Why don't you ask for "Mnemonic" to be published as an Experimental RFC and simply make your "Charsets" document available through ftp and email? I assume Dave will correct me if I've made mistakes (and if so, I apologize). > Yes, I will tell people. Yes, but _what_ would you tell them? If your "charsets" document was published as an informational RFC, would you tell them that it has become an official RFC? Or would you tell them the whole truth, and say that it's an informational RFC? > But it may not be a great help, as some standardisation bodies > are reluctant to standardise something which is already in use, > and thus gives somebody an advantage. This is probably the most ridiculous thing I've heard this week (well, maybe today). If there are standards bodies that behave in this fashion, they deserve to... Erik   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00512; 8 Apr 92 8:14 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa07561; 8 Apr 92 8:17 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa07543; 8 Apr 92 8:17 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA13634; Wed, 8 Apr 92 08:04:47 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA13627; Wed, 8 Apr 92 08:04:44 EDT Received: from INFOODS.MIT.EDU by INFOODS.MIT.EDU (PMDF #12913) id <01GILIU5XW3K0003O4@INFOODS.MIT.EDU>; Wed, 8 Apr 1992 08:04 EDT Date: Wed, 8 Apr 1992 08:04:14 -0400 (EDT) From: John C Klensin Subject: Re: Q+A: Mnemonic to Proposed Standard In-Reply-To: <9204080847.AA28261@sran8.sra.co.jp> To: erik@sra.co.jp Cc: keld@dkuug.dk, ietf-822@dimacs.rutgers.edu Message-Id: <702734654.442231.KLENSIN@INFOODS.MIT.EDU> X-Envelope-To: ietf-822@dimacs.rutgers.edu Mail-System-Version: (1) Could we create a separate list for this, or take it offline? If the thing is going to be either "informational" or ""experimental", I don't see the WG having to take a position on anything but whether it ight interfere with anything else we are doing as a WG. The answer to that is pretty clearly "no". Two specific comments on the latest set of transactions... (2) The canonical behavior of other standardizers. >> That is true, some of the characters do not have the same names >> as in 10646, some even does not have names (some vendor sets). >> So I had to judge what it was. And that could be a source of errors. > >Actually, in that case I wouldn't call it an "error", I would call it >"your opinion". So people using your tables to convert between >character sets would be basing their conversions on your opinion. The >people who actually designed or actually use the character sets may >have a different opinion. That is also one of my concerns. On a DIS vote, ISO insists on near-unamimity, with a rule that two (!) unresolvable negative votes from P-members triggers a special problem resolution procedure involving the Secretary-General. So everyone gets to look at something like this, compare it to their own practice, and say "no" if anything is seriously wrong. And the voting procedure makes it hard for member bodies to sit one of these things out and then be surprised by it. On the other hand, this particular safety measure is one of the reasons "their" standards sometimes take such a horribly long time. (3) The misbehavior of standardizers. >> But it may not be a great help, as some standardisation bodies >> are reluctant to standardise something which is already in use, >> and thus gives somebody an advantage. > >This is probably the most ridiculous thing I've heard this week (well, >maybe today). If there are standards bodies that behave in this >fashion, they deserve to... I've never heard of this one being pulled in the character set area, but, indeed, in some others, saying "if we chose that solution, we would be giving manufacturer A an advantage in the marketplace, hence we have to choose something completely new which we will go invent" is the classic ISO model for saying "not invented here". It is also a behavior prohibited by the ISO Directives, at least as I read them: they contain words about standardizing the consensus of existing practice, not about inventing. But that piece of knowledge plus some small amount of an appropriate international currency will buy the proverbial cup of coffee. On the other hand, this is a non-issue wrt the proposal at hand, since the main claim used to push it forward in IETF has been that it is already in active use. --john   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01346; 8 Apr 92 11:48 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa15783; 8 Apr 92 11:51 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa15764; 8 Apr 92 11:51 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA25300; Wed, 8 Apr 92 11:36:19 EDT Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA25296; Wed, 8 Apr 92 11:36:16 EDT Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0) id AA21012; Wed, 8 Apr 92 08:35:59 PDT Message-Id: <9204081535.AA21012@Mordor.Stanford.EDU> To: erik@sra.co.jp Cc: Keld J|rn Simonsen , ietf-822@dimacs.rutgers.edu Subject: Re: Q+A: Mnemonic to Proposed Standard Org: The Branch Office Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Wed, 08 Apr 92 17:46:44 +0900. <9204080847.AA28261@sran8.sra.co.jp> Date: Wed, 08 Apr 92 08:35:58 -0700 From: Dave Crocker Erik, (Thanks for explicitly inviting my clarification about standard procedures...) A spec which goes to entry-level standards status (i.e., Proposed Standard) must be a stable spec, with no *known* omissions or errors. It is not required to have any implementation or operations experience, unless the spec has some flavor of "danger" associated with it (such as changing the Internet's routing protocol) or is viewed as having inherent technical obscurity which requires experimentation before there can be adequate understanding of the technology's "physics". In the case of Keld's document, I note that there have been strong expressions of concern about its complexity (which may well be necessary, but it impedes thorough understanding) and a lack of full understanding of its relationship to other standards efforts. Since the bulk of the work has been done outside of this wg and the spec's author is comfortable with having the spec published outside of the standards track, it would seem quite reasonable for the wg to support the document's publication as Informational. Dave   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03227; 8 Apr 92 22:47 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa09734; 8 Apr 92 22:50 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa09710; 8 Apr 92 22:50 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA01966; Wed, 8 Apr 92 22:44:20 EDT Received: from srawgw.sra.co.jp by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA01950; Wed, 8 Apr 92 22:44:12 EDT Received: from sranhd.sra.co.jp by srawgw.sra.co.jp (5.67WH/1.5) id AA22080; Thu, 9 Apr 92 11:43:41 +0900 Received: from sran8.sra.co.jp by sranhd.sra.co.jp (5.67ew/6.4J.6-BX) id AA02940; Thu, 9 Apr 92 11:43:17 +0900 Received: from localhost by sran8.sra.co.jp (4.0/6.4J.6-SJX) id AA29044; Thu, 9 Apr 92 11:43:14 JST Return-Path: Message-Id: <9204090243.AA29044@sran8.sra.co.jp> Reply-To: erik@sra.co.jp From: "Erik M. van der Poel" To: ietf-822@dimacs.rutgers.edu Subject: mnemonic and charsets Date: Thu, 09 Apr 92 11:43:12 +0900 Sender: erik@sran8.sra.co.jp Folks, The 822ext WG has been asked to consider 2 (two) documents written by Keld: (1) draft-ietf-822ext-mnemonics-03.txt ( 10263 bytes) (2) draft-ietf-822ext-charsets-04.txt (237830 bytes) I find these names rather long, so I have been referring to them as the "Mnemonic" document and the "charsets" document. The Chair (Greg Vaudreuil) asked the WG to consider these documents for the following "status": (1) draft-ietf-822ext-mnemonics-03.txt "proposed standard" (2) draft-ietf-822ext-charsets-04.txt "informational document" Now, as far as the "charsets" document is concerned, I have been questioning whether it is appropriate that this WG "recommend" it as an "informational document". I am concerned about the accuracy. And I am concerned about the particular unification that Keld has done, and whether it will be acceptable to other people. Dave, who is the "Director" for the "Area" "Standards Management", has said that "it would seem quite reasonable for the wg to support the document's publication as Informational". OK, if that's what Dave says, then so be it. I won't question it. However, I will assume that Dave was referring to the "charsets" document. So let us now turn our attention to the "Mnemonic" document, which is being considered for recommendation as a proposed standard. Perhaps "informational" documents may not be considered "such a big deal", but, as far as I know, "proposed standards" are taken very seriously by the IETF WGs. One issue that I raised before, and which I believe is being overlooked, is the fact that the "Mnemonics" document refers to the "charsets" document. As we all know, several references were deleted from MIME because a standards-track document may not refer to a document of lower standing. So I am wondering whether it should be considered legal to refer to the "charsets" document in the "Mnemonic" document. Having said all that, I am now totally "burned out" on the issues surrounding Keld's documents. And I hereby promise not to send any mail on this subject to the ietf-822 list for at least 6 months. Erik   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03408; 9 Apr 92 1:16 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa13686; 9 Apr 92 1:19 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa13661; 9 Apr 92 1:18 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA05925; Thu, 9 Apr 92 00:50:34 EDT Received: from cfaamp.harvard.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA05918; Thu, 9 Apr 92 00:50:31 EDT Received: from CFAAMP.HARVARD.EDU by CFAAMP.HARVARD.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 5660; Thu, 09 Apr 92 00:50:18 EST Date: Thu, 9 Apr 1992 00:40 EDT From: "John F. Chandler" To: Mail extensions Subject: Extension to MIME Message-Id: Hello, all. I'm new to this discussion. I've just obtained the MIME draft document and looked through it, and I have a few comments to offer. I am impressed with the robustness of the encoding schemes in MIME and gratified to see the emphasis on compatibility. However, I see one weak spot that, I think, could be filled quite easily. I imagine that quite a lot of MIME-compliant traffic will go as quoted-printable or 7-bit, rather than as base64, because of the ability of a non-MIME receiver to read "printable" text and because straight ASCII text can be transmitted faster without encoding. For that reason, among others, I am interested in increasing the robustness of quoted-printable and 7-bit text. In particular, I see a need for one small augmentation to the protocol to cover possible (and, in fact, likely) gateway translation problems. The note on page 15 of the (Postscript) draft points out that 14 specific characters are prone to garbling at certain gateways and observes that encoding those characters would improve the reliability of transfer. However, the readability (not to mention the speed of transmission) would suffer if lots of characters were encoded, and I think most people would simply not do that. It seems to me that the protocol can easily correct any garbling by including one extra header line that looks something like this: Content-key: !"#$@[\]^`{|}~ The sender inserts that line with the 14 "endangered" characters in that order, and the receiver can not only tell whether the message has been garbled, but also correct it (by translating all instances of any unexpected characters that arrive in that line into the expected ones). The latter step, of course, can be skipped unless garbling has actually occurred. One might argue that these 14 characters should be extended to 21 to include all characters not in the X.400 Printable String list, i.e., adding %&*;<>_ either tacked onto the end or interleaved. I've never run into a situation where any of those seven characters was messed up, so I can't tell if it would pay to include them. The 14 characters listed include all 12 characters alloted for national variants on ISO 646, and scrutiny of the IBM corporate standard character sets shows that those 14 characters are the only ones (of the 94 found in US-ASCII) that vary among the EBCDIC sets. Anyhow, that's a relatively minor detail, as is the decision of what to do if the header line comes through with too many or too few characters (or, perish the thought, duplicates) -- presumably, the MUA would have the option of sending an automatic error notice to the sender or simply informing the recipient that the message may be (but isn't necessarily) garbled. It's a fact of life that files can be messed up, whether by unfortunate translation at a gateway or by truncation or outright substitution, and I think every reasonable effort should be made to detect such problems where prevention cannot be ensured. Note that a non-MIME mail receiver on the wrong side of a translating gateway could benefit from this extension and be able to correct the garbled characters "by eye". I'm sure there are a number of other details that I haven't thought of, but the idea is basically very simple and easy to implement, and I think it would help to make MIME much more "bulletproof." John   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00405; 9 Apr 92 5:51 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa04047; 9 Apr 92 5:54 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa04030; 9 Apr 92 5:54 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA10968; Thu, 9 Apr 92 05:27:28 EDT Received: from mhs-relay.cs.wisc.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA10964; Thu, 9 Apr 92 05:27:23 EDT X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/; Relayed; Thu, 9 Apr 1992 04:27:06 +0000 X400-Received: by /PRMD=uninett/ADMD= /C=no/; Relayed; Thu, 9 Apr 1992 04:26:57 +0000 X400-Received: by /PRMD=uninett/ADMD=/C=no/; Relayed; Thu, 9 Apr 1992 04:26:42 +0000 Date: Thu, 9 Apr 1992 04:26:42 +0000 X400-Originator: Harald.T.Alvestrand@delab.sintef.no X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=uninett/ADMD=/C=no/;920409112642] X400-Content-Type: P2-1984 (2) Content-Identifier: 6563 From: Harald Tveit Alvestrand Message-Id: <6563*/G=harald/S=alvestrand/OU=delab/O=sintef/PRMD=uninett/C=no/@MHS> To: erik@sra.co.jp Cc: ietf-822@dimacs.rutgers.edu In-Reply-To: <9204090243.AA29044@sran8.sra.co.jp> Subject: mnemonic and charsets I will speak my personal opinion on these sets: (1) draft-ietf-822ext-mnemonics-03.txt "proposed standard" (2) draft-ietf-822ext-charsets-04.txt "informational document" There is also an implicit point (3) and (4) here: (3) allow registration of "mnemonic" as a charset with IANA (4) include "mnemonic" in the next MIME standard version As far as I can see, the reason for (1) being "proposed standards" is mainly to get to target (4). I certainly hope that the IANA (whoever he is) will not refuse to register anything that is not a "proposed standard RFC". In my other work (on MIME gateway to X.400 and charsets in X.400), I have found Keld's "charsets" document very useful. In fact, I need to quote it. So, I definitely think that (2) is a correct action. I see no big opposition to this, except for the question of whether Keld has typed everything correctly; I have not yet found any problem. I think that (4) (getting Mnemonic into the MIME document) is probably not possible to get consensus on. So what status we need for (1) is dependent on what we need to do to get a registered character set. When EUNET and NORDUNET can show heavy usage of it, in preference to ISO-8859-X, it becomes simple to ask for an Internet "standard" status for it, but I think that at the moment, it should be left as an "experimental standard", rather than wrangling for 6 months over whether it should be "proposed standard" or not. As with MIME, I think that it is more important to get it published, fixed and referencable, than it is to cross the last T and dot the last I. (Quick question, now: Does a small dotless I become identical to a large version of the dotted I, when both are converted to uppercase? :-) Harald Tveit Alvestrand The man with a thousand hats, but speaking for none of them   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00433; 9 Apr 92 7:13 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa05485; 9 Apr 92 7:16 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa05468; 9 Apr 92 7:16 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA14148; Thu, 9 Apr 92 07:06:16 EDT Received: from CBROWN.CLAREMONT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA14144; Thu, 9 Apr 92 07:06:12 EDT Received: from HMCVAX.CLAREMONT.EDU by HMCVAX.CLAREMONT.EDU (PMDF #11000) id <01GIMOSPC7J89BVD1S@HMCVAX.CLAREMONT.EDU>; Thu, 9 Apr 1992 04:05 PST Date: Thu, 9 Apr 1992 04:05 PST From: "Ned Freed, Postmaster" Subject: Re: Extension to MIME To: PEPMNT@cfaamp.harvard.edu Cc: ietf-822@dimacs.rutgers.edu Message-Id: <01GIMOSPC7J89BVD1S@HMCVAX.CLAREMONT.EDU> X-Vms-To: IN%"PEPMNT@cfaamp.harvard.edu" X-Vms-Cc: IN%"ietf-822@dimacs.rutgers.edu" > I am impressed with the robustness of the encoding schemes in MIME and > gratified to see the emphasis on compatibility. Thanks for the kind words. > However, I see one weak > spot that, I think, could be filled quite easily. I imagine that quite > a lot of MIME-compliant traffic will go as quoted-printable or 7-bit, > rather than as base64, because of the ability of a non-MIME receiver to > read "printable" text and because straight ASCII text can be transmitted > faster without encoding. For that reason, among others, I am interested > in increasing the robustness of quoted-printable and 7-bit text. In > particular, I see a need for one small augmentation to the protocol to > cover possible (and, in fact, likely) gateway translation problems. The > note on page 15 of the (Postscript) draft points out that 14 specific > characters are prone to garbling at certain gateways and observes that > encoding those characters would improve the reliability of transfer. > However, the readability (not to mention the speed of transmission) > would suffer if lots of characters were encoded, and I think most people > would simply not do that. It seems to me that the protocol can easily > correct any garbling by including one extra header line that looks > something like this: > Content-key: !"#$@[\]^`{|}~ > The sender inserts that line with the 14 "endangered" characters in > that order, and the receiver can not only tell whether the message > has been garbled, but also correct it (by translating all instances > of any unexpected characters that arrive in that line into the expected > ones). This an interesting idea; I don't recall anyone else suggesting it before. I agree that such a mechanism might help detect errors in the translation of quoted-printable. However, I don't see much hope for using it as a scheme for error correction. In my experience, when gateways decide to mess up character translation, they usually do it by mapping a group of characters into a single character. One favorite of mine is the group of gateways that map {|}~ into spaces. And when this happens, as it sometimes does, there is no way to correct it. The correction aspect of this scheme can only work when you're sure that none of the garbled characters have been mapped into something that clashes with existing content. And you can never be sure of this on the receiving end. For this reason I don't think the correction aspect of this scheme is very strong. But it definitely might help catch errors. On the other hand, other schemes, notably various sorts of message integrity checks, handle this case pretty well. The only reason that there's no MIC in MIME is that we could not reach closure on what MIC we wanted. > The latter step, of course, can be skipped unless garbling has > actually occurred. One might argue that these 14 characters should be > extended to 21 to include all characters not in the X.400 Printable > String list, i.e., adding %&*;<>_ either tacked onto the end or > interleaved. I've never run into a situation where any of those seven > > characters was messed up, so I can't tell if it would pay to include > them. The 14 characters listed include all 12 characters alloted for > national variants on ISO 646, and scrutiny of the IBM corporate > standard character sets shows that those 14 characters are the only > ones (of the 94 found in US-ASCII) that vary among the EBCDIC sets. Of the less problematic characters you list the _ is the only I've ever gotten into trouble with. > Anyhow, that's a relatively minor detail, as is the decision of what to > do if the header line comes through with too many or too few characters > (or, perish the thought, duplicates) -- presumably, the MUA would have > the option of sending an automatic error notice to the sender or simply > informing the recipient that the message may be (but isn't necessarily) > garbled. It's a fact of life that files can be messed up, whether by > unfortunate translation at a gateway or by truncation or outright > substitution, and I think every reasonable effort should be made to > detect such problems where prevention cannot be ensured. Note that a > non-MIME mail receiver on the wrong side of a translating gateway could > benefit from this extension and be able to correct the garbled > characters "by eye". Frankly, it is the "by eye" aspect of this scheme that I like. Unlike checksums it might actually be useful in an unextended mail reader environment. > I'm sure there are a number of other details that I haven't thought of, > but the idea is basically very simple and easy to implement, and I > think it would help to make MIME much more "bulletproof." I think this scheme needs to be considered along with other checksumming approaches when the time comes to put that in. Right now we're all too exhausted to do this work, I think! But keep in touch; this group will eventually have to deal with the shelved MIC issues. Ned   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00508; 10 Apr 92 7:50 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa06100; 10 Apr 92 7:53 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa06083; 10 Apr 92 7:53 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA04488; Fri, 10 Apr 92 07:42:44 EDT Received: from itd.nrl.navy.mil by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA04470; Fri, 10 Apr 92 07:42:33 EDT Received: from sundanceitd.nrl.navy.mil (sundance.itd.nrl.navy.mil) by itd.nrl.navy.mil (4.1/SMI-4.1) id AA24534; Fri, 10 Apr 92 07:42:04 EDT Received: by sundanceitd.nrl.navy.mil (4.1/SMI-4.1) id AA06376; Fri, 10 Apr 92 07:42:22 EDT Date: Fri, 10 Apr 92 07:42:22 EDT From: Randall Atkinson Message-Id: <9204101142.AA06376@sundanceitd.nrl.navy.mil> To: ietf-822@dimacs.rutgers.edu Subject: FYI: Vietnamese Document Draft Attached below is the document from the Vietnamese Standards Group that has been publically released describing current conventions for Vietnamese usage on the Internet/BITNET/USENET and other proposals or de facto standards for Vietnamese. It represents the consensus of the people who have been working on these issues for the past several years. Anh Nguye^~n Tha`nh has indicated that he intends to work on converting it into a format suitable for an RFC and publishing it on behalf of the Vietnamese Standards Group as an informational RFC documenting conventions and usages for the Vietnamese language. I'm not sure when that might be finished and submitted to the RFC Editor. If my understanding is correct, that informational RFC would not be focused on MIME in any way and would not be proposing registration of a token for Vietnamese for usage in MIME. The VSG would prefer to have at least a unified mechanism for mnemonic usages or possibly a single mnemonic convention, provided that such a single unified mnemonic convention's representation of Vietnamese glyphs were no less readable than the existing Vietnamese convention. I would also like to take this opportunity to disclaim the credit that the document gives to me. The vast majority of the work has been done by others in the working group and they deserve the lion's share of the credit for the document content. I am however quite pleased that we in the VSG working group have been able to produce such a document. Ran atkinson@itd.nrl.navy.mil ----cut here, omitting this line and above--- Vietnamese Mnemonic Notes: In the following ASCII text, Vietnamese letters with diacritics are represented as a vowel followed by the diacritics, with the following mappings: ( = breve, as in "a(n na(n" ^ = circumflex, as in "nha^n co^ng" + = horn, as in "tu+o+ng tu+" ' = acute, as in "choa'ng va'ng" ` = grave, as in "lu` khu`" ? = hook above, as in "ho?i tha(m" ~ = tilde, as in "ky~ ca`ng" . = dot below, as in "Tra.ng Nguye^n" dd = lower case d-bar, as in "dda ti`nh" DD = upper case D-bar, as in "DDo^ng So+n" The diacritics are interspersed freely in the text and should be clear from the context, for example, "The Vietnamese call themselves `Con Cha'u Hu`ng Vu+o+ng', or `Descendents of King Hu`ng'." However there are instances where it is necessary to differentiate between a single Vietnamese letter with diacritics and a sequence of characters, for example, "a^'". In such cases, when the single Vietnamese letter is meant, it is enclosed in angle brackets, e.g., ""; without the brackets the string "a^'" should be understood to be the sequence of characters "a", "^", and "'". It should be clear from context how the text should be read. The text was generated with "dvi2tty" and "nroff" with con- siderable hand-editing, but the formatting still leaves much to be desired. A much more readable version is available in PostScript form from various archive sites to be announced by the archivists themselves. If you have no means of retrieving or printing the PostScript file, you may obtain a printed copy by sending a self-address, stamped envelope to "Cuong T. Nguyen P. O. Box 9934, Stanford, CA 94309-1634". Please use two (2) 29-cent stamps and a letter-sized envelope. Please forward typos & comments to Viet-Std@Haydn.Stanford.EDU. Acknowledgments: ---------------- We acknowledge the direct authorship/contribution by the following people: Atkinson, Randall (atkinson@itd.nrl.navy.mil) Bu`i Cu+o+ng (bui@berlioz.nsc.com) Ho^` Khie^m (khiem@hpinddm.cup.hp.com) Lu+o+ng V. Tu+o+'c (tluong@borland.com) Ngo^ DDi`nh Ho.c (hoc%vri280@uunet.uu.net) Nguye^~n T. Cu+o+`ng (cuong@Haydn.Stanford.EDU) Nguye^~n Tha`nh (thanh@ipesun.e-technik.uni-stuttgart.de) To^n Khoa (khoa@hpda.hp.com) Tra^`n Nha^n (tran@peora.sdc.ccur.com) And the many, many insightful comments, arguments, and ideas contributed by the people on Viet-Std@Haydn.Stanford.EDU, too numerous to acknowledge properly but are nevertheless important, as well as the people of Viet-Net and Soc.Culture.Vietnamese, including those who proposed, discussed, and propagated the Viet-Net readable mnemonic convention. Viet-Std List ------------- Atkinson, Randall (atkinson@itd.nrl.navy.mil) BINGO@MTUS5.cts.mtu.edu Bu`i Cu+o+ng (bui@berlioz.nsc.com) DDa(.ng, Oliver (Oliver_Dang.Washington_CSD@Xerox.com) DDinh Hoa`n (hdinh@ihlpx.att.com) DDo^~, James (jDo@sjc.mentorg.com) Du+o+ng, Christie (chrisd@works.sun.com) Dung Trung (trung@CS.BU.EDU) Ho^.i Chuye^n Gia Vie^.t Nam (hcgvn@netcom.com) Ho^` Khie^m (khiem@hpinddm.hp.com) Ho^` Phi Hu`ng (hho%aludra.usc.edu, Archivist) JFT%NCCIBM1.BITNET@Forsythe.Stanford.EDU Le^ Quang (quangl@tabasco.sps.mot.com) Le^ Ti'n (tin@smsc.sony.com, Archivist) Lu+o+ng V. Tu+o+'c (tluong@borland.com) Ngo^ DDi`nh Ho.c (ngo@amelia.nas.nasa.gov) Ngo^ Quang (quang@csufres.csufresno.edu) Ngo^ Thanh Nha`n (nhan@LSP5.CS.NYU.EDU) Nguye^~n DDu+'c Long (long@ireq-num.hydro.qc.ca) Nguye^~n Du (nguyen@zariski.harvard.edu) Nguye^~n Gia Hoa` (nguyenh@eng.umd.edu) Nguye^~n Hoa`ng (Hoang_Nguyen.LAX1B@xerox.com) Nguye^~n Kinh (Kinh_Nguyen.ESXFC@Xerox.COM) Nguye^~n T. Cu+o+`ng (cuong@haydn.stanford.edu) Nguye^~n Tha`nh (thanh@ipesun.e-technik.uni-stuttgart.de) Nguye^~n Vu+o+ng (Vuong.Nguyen@szebra.saigon.com) Pha.m Tha.ch (thach.pham@Eng.Sun.COM) To^n Khoa (khoa@hpda.hp.com) Tra^`n Ha?i (htran@dash.mitre.org) Tra^`n Kha (KTRAN%APLVM.BITNET@Forsythe.Stanford.EDU) Tra^`n Nha^n (tran@peora.sdc.ccur.com) Vie^.t Anh (anh@media.mit.edu) Vu~ Tie^'n Giao (pyramid!infmx!grizzly!giao) ccicpg!al!ngo cdh1@homxc.att.com chi@markv.com ctt@alux2.att.com cvu@ic.sunysb.edu gregg@eoc.com hnguyen@sc9.intel.com k.ly@trl.OZ.AU kpv@ulysses.att.com lphung@ihbhk.att.com lphung@nike.calpoly.edu ltpham@netcom.com ndoduc@framentec.fr shg@rock.concert.net thanht@hls.com thu@friendship.sun.com trinh@paulus.enet.dec.com tuan@lgc.com v.mai@uow.edu.au vtpham@ap040.csc.ti.com vtt@turing.scs.uiuc.edu A UNIFIED FRAMEWORK FOR VIETNAMESE INFORMATION PROCESSING Vietnamese Standardization Working Group (Viet-Std@Haydn.Stanford.EDU) January 1992 ABSTRACT Increasing demand for Vietnamese electronic information pro- cessing has seen answer in a wide array of Vietnamese- capable applications. The inevitable need for integration of Vietnamese into existing environments and the exchange of data among them point to the necessity of standardization. This paper presents the strategic and pragmatic technical considerations that must go into such a standard, and re- views existing conventions/proposals in these important con- texts. A full description of the Viet-Std proposal is presented, including 1) an 8-bit, fully precomposed Viet- namese encoding table, 2) a 7-bit quoted-readable Vietnamese standard for data interchange over 7-bit channels, with a seamless interface to the 8-bit encoding, and 3) a keyboard user-interface specification that works transparently with both 1 and 2. Together, these provide vide a truly unified framework for a Vietnamese information processing environ- ment with simplicity, efficiency, and straightforward in- tegration. The real-world construction of this framework has proven quite successful in an array of compliant applica- tions from a number of group and individual developers across a number of platforms, including Unix and its vari- ants, the X window system, MS-DOS, Windows, and with ongoing work elsewhere. 1 INTRODUCTION With the growing Vietnamese population abroad and the proli- feration of computer usage within Viet Nam, the Vietnamese language has seen rapidly increasing representation in elec- tronic information processing. The concomitant growth in demand for Vietnamese-capable software has resulted in successful launches of myriad vendors in the U.S. and elsewhere, mainly in the area of Vietnamese word processing. In addition, individual and group efforts have also been productive in providing Vietnamese-language users with highquality public-domain appli- cations. In Viet Nam, centers such as the Institute of Infor- matics have reported impressive progress on many fronts, among which is the Vietnamization of standard software packages [1]. All of the above illustrate two important points: 1) There are growing market demands for Vietnamese-capable processing engines, and 2) There is no shortage of technical talent to fulfill those demands. Unfortunately, therein lies a large prob- lem: most existing Vietnamese applications have been designed to operate in the exclusive framework or environment of the developer, and all are incompatible with one another. As long as this trend continues, the application base for Vietnamese can never keep reasonable pace with demand. Users want to do more with Vietnamese than mere word processing, and to expect one sin- gle vendor to provide all potential applications across all plat- forms is to dream the impossible. Technicians providing these ap- plications are limited to the Vietnamese tools they must them- selves learn and develop from the ground up. Standardization is necessary. Anyone who has had to deal with the incompatibility between ASCII and EBCDIC can try to imagine a world where every machine is using a different character set, and appreciate how limited that world would be in its application base and how cumbersome in its data interchange. A uniform framework will greatly benefit both the user and the technician alike. The proposal for any Vietnamese data standardization must take several important points in the proper contexts. First and foremost, since this discussion is geared toward existing 7- and 8-bit environments, the prime goal is straightforward and direct integration onto current platforms. The standard must work here and now. This implies the use of precomposed Vietnamese characters, because the handling of floating diacritics will nev- er see full or simple support outside of specific contexts. The standard must be designed so as to take advantage of existing applications as much as possible. The familiar ``don't reinvent the wheel'' rule is not only an advantage---but a necessity- --if a meaningful application base is to be established in any reasonable length of time. Furthermore, it is known that overall efficiency both in time and space is greater in processing precomposed character units when compared with the floating- diacritic approach [2]. Floating diacritics therefore must be limited to only where they are necessary and inevitable, such as in keyboard entry or 7-bit data transmission. There is no reason to require that all applications must deal with the com- plexities and inefficiencies of floating diacritics, for exam- ple, in 8-bit data processing, storage, transmission, screen rendering, or printing. The second major context points to the pragmatic and vital consideration of existing precedents set in the Vietnamese software base. Standardization necessarily requires adaptation, but it makes little sense to propose to change the world so sig- nificantly that the inertia against large changes greatly delays adoption of the standard. Sixteenbit and wider data standards are just around the corner [3 , 4]; an 8-bit Vietnamese standard must not ignore existing software precedents if it is not to be useful only ``after its time,'' when it is no longer relevant. Thirdly, the standard must address the issue of user in- terface; if not defining it, then at least consider its possi- ble effects on the end-user. This relates primarily to the 7- bit keyboarding and representation of Vietnamese--in both in- stances diacritics are necessarily floating, and represented mnemonically by existing 7-bit characters with similar appear- ance. With keyboarding, one must preserve where possible exist- ing practices such as that defined for the Viet-Net mailing list and the Usenet newsgroup Soc.Culture.Vietnamese, both with members worldwide. For 7-bit readable representation, the key- word is ``readable.'' The goals here are to maintain a short learning time and to promote a uniform interface so that it is not necessary for a user to re-learn the particulars of every software installation before being able to use it effectively. Finally, to every extent possible, the standard must stay within the framework of international standards, e.g., ISO-8859/x [5], in order to ensure compatibility with existing environ- ments. For example, this goal means preservation of the ASCII encoding. It should extend also to the encoding into the same 8859/Latin-1 slots those Vietnamese characters that are already defined, thus ensuring that 8859/Latin-1 keyboards will work transparently for those Vietnamese characters. However, there are many standards requirements that are obsolete from a practical viewpoint. For example, in recent Unicode/ISO-10646 decisions, the prohibition from use of the available control character space--those with encodings between xx00h and xx1Fh, except for C0 itself---was discarded on the grounds that it was a waste of encoding space. As will be dis- cussed later, the encoding of Vietnamese into the existing 8- bit space presents some well-known trade-offs. Where trade-offs are made, they must be justified with good reason---pragmatic preferred over theoretical. These primary requirements are summarized as follows: R1. Straightforward and direct integration into ex- isting platforms. R2. Ease of adaptation for existing software. R3. User-friendly mnemonic encoding scheme and inter- face. R4. Adherence to international standards. R5. Trade-offs made only on practical usage consid- erations and with good reason. In the following section we present a brief review of the strengths and weaknesses of different approaches to Vietnamese encoding. Section 3 will describe the proposed 8bit encoding table in detail. A quoted-readable encoding scheme encompassing 7-bit data streams, including electronic mail and keyboard in- put, is presented in Section 4. Finally, Section 5 outlines the particular rules and conventions relevant in some application- specific contexts. 2 REVIEW OF CURRENT CONVENTIONS A review of current conventions used by software vendors reveals one distinct feature: virtually all realize the strengths of a precomposed encoding and adopt it as a primary requirement. The complications arise from a familiar fact: apart from the alpha- betics already available in the ASCII standard, Vietnamese re- quires an additional 134 unique characters. Of these, 128 can be coded in the C1 and G1 areas. The allocation of the remaining 6 characters in the lower C0 and G0 space is handled with differ- ing approaches: A1. Encode into 6 of the ``least-used'' G0 characters in the context of Vietnamese data processing. A2. Encode into 6 of the 12 National Replacement char- acters in G0. A3. Drop 6 of the ``least-used''(1) Vietnamese charac- ters, typically accented capitals such as A(?, A(~, A^~, Y?, Y~, and Y. . A4. Map accented ``y'' combinations into corresponding ``i'' combinations, e.g., ``ky~ su+'' is replaced with ``ki~ su+''. A5. Encode into the ASCII control space C0. Approaches A1 and A2 both satisfy the typical needs of the word processing environments in which rarely used ASCII charac- ters can be avoided, or employed by font shifting. However they both eliminate prospects for integration of Vietnamese into ex- isting ASCII environments where all graphic characters in G0 are needed. A character that already serves one purpose cannot be re-used for another. First, it makes rendering of the needed G0 character incorrect, as it would now look like a Vietnamese char- acter. The frequency of use of G0 characters in an integrated environment is far too high for this conflict to be tolerable. While font shifting may be employed to remedy this in some sit- uations, a more serious problem occurs when the Vietnamese char- acter is needed. The environment would typically have assigned some specific meaning to the G0 character, particularly with those in the National Replacement set. Consider, for example, using the backslash character ``\'' for a Vietnamese character under Unix. The backslash is used for many Unix escape mechanisms so that the Vietnamese character cannot simply be used but must be escaped in one way or another. This is more than an inconveni- ence; it means data interchange is now complicated by the fact that the escape mechanism will not be understood on another plat- form, and data integrity has thus not been preserved. A standard employing this approach fails at its basic mission: to provide cross-platform transparency. A similar case can be made for the other G0 characters. Both A3 and A4 propose to limit Vietnamese language data in one way or another. Most agree that elimination of some Viet- namese characters are simply unacceptable; indeed, this point is so fundamental that we have in the foregoing chosen to assume it as a technical requirement without elaboration. However, it must be said that A4 is not _________________________________________ (1) Least-used because they (a) rarely begin words and there- fore do not often get capitalized, and (b) appear in fewer words. a proposal without rationale. A school of thought exists that believes y's existing in words as a single vowel should be mapped to corresponding i's, as their pronunciations are indeed identi- cal. The concept dates as far back as 1948 [6 , 7]. However, it is not the function of an encoding standard to settle a linguistic issue, and hence A4 is also a bad choice. The immediate objection to A5 is primarily in data com- munication channels where many C0 characters are used as data control. In addition, it also presents problems for integration into environments where some C0 characters are used in the key- board interface and in data format controls, similar to the problem facing A1 and A2. However, as will be discussed further, judicious choice of the 6 C0 characters to be used has in prac- tice been shown successfully to avoid characters that are sig- nificant in data communication. Furthermore, most data channels provide for clean transfer of binary data, and there is no reason to worry that arbitrary data bits cannot be employed over these binary routes. With those particular cases where C0 is used in the key- board interface, judicious choice as well as remapping of keys can minimize conflict. Data format control is application- specific but is typically scattered in C0 and C1. It is therefore a universal problem for integration because C1 is necessarily densely encoded, but, again, conflict can be avoided by studying significant applications. Finally, the choice can be made for 6 least-used Vietnamese characters so that the probability of conflict is greatly reduced. It should be noted here that the foregoing discussion has subjected the alternatives to the requirements of integration into existing applications and platforms, as outlined in Sec- tion 1. The importance of this goal cannot be overstated, and it does present complications that result in the following Pragma- tism Principle: it is obviously impossible to define a standard that would operate seamlessly with all existing applications, therefore pragmatic considerations must be made to make a stan- dard workable in as many important applications and on as many platforms as possible, with emphasis on the word ``workable.'' 3 VISCII: 8-BIT ENCODING SPECIFICATION FOR VIETNAMESE 3.1 MOTIVATION The available body of evidence shows that alternative A5 described in the previous section, encoding into 6 of the C0 characters, has the greatest chance of success in fulfilling the requirements outlined in Section 1. The choice of the 6 C0 codes and the 6 least-used Vietnamese capital letters to encode, when made carefully, greatly reduces the probability of conflict for all practical purposes. Concerns regarding data communica- tions are well addressed by avoiding C0 codes that are in fact often used for data control. Indeed, data communication con- cerns are more applicable to C1 and G1 encoding; a prominent example is electronic mail transfer through 7-bit gateways and mail agents. Communication failure here has in most cases been due to the use of the eighth bit and not because of C0 encoding. In any event, the option exists for data to be sent in some ``binary'' mode, or to employ the Vietnamese Quoted-Readable for- mat to be described in Section 4. The overwhelming advantage of this approach is that it is readily and easily integrated into existing environments without many of the problems plaguing the other alternatives, if they can at all be integrated. As a testimony to the approach's suc- cessful application, this document itself was prepared using the TeX system under Unix. The text source was edited in an 8- bit X terminal window, using a minimally modified(2) version of Elvis, a public-domain 8bit version of Unix's Vi text editor. Both TeX (a document preparation system) and Dvi2ps (a PostScript generator) readily accepted and processed Vietnamese (8-bit) data transparently. Many other applications including a spreadsheet, various text viewers, PostScript and dot-matrix printing, DOS's WordPerfect, Word, PC Tools, etc., have been tested and seen to operate well with Vietnamese text. Modifica- tions if any, were primarily in making these applications accept 8-bit data. An educational teaching tool for Vietnamese has also been produced using the C programming language with 8-bit Vietnamese strings embedded in the source code. With in- creasing system internationalization, applications and tools are being made 8-bit ``clean,'' further facilitating integration of this Vietnamese encoding. _________________________________________ (2) The modifications provided the keyboard interface described in later sections. 3.2 ENCODING RATIONALE A basic requirement is to preserve the 7-bit ASCII graphic characters (G0) layout, since the emphasis is on integration. G0 was therefore left unchanged. For the 6 C0 characters, we first lay out the code space and consider typical usage, a sampler of which is in Table 1. The codes selected, STX (2), ENQ (5), ACK (6), DC4 (20), EM (25), and RS (30) present the least possible problems with data communication and significant ap- plications considered. The use of ACK, for example, is actually context-dependent. In those protocols we have reviewed, it is only considered a ``control'' character outside of a data frame; within a data frame it is transfered without special interpre- tation. To reduce the probability of conflict even further, the 6 least-often used Vietnamese capital letters, A(?, A(~, A^~, Y?, Y~, and Y., are encoded into these slots. The encoding of C1 is less troublesome, although in applicationspecific contexts it has been found that some C1 characters are employed with special meanings. A review of on- going work on 8-bit mail transport standardization indicates that C1 characters will be fully supported as graphic charac- ters without special interpretation. Nevertheless, it is pru- dent to encode only upper-case characters into the C1 space. For G1, the aim is to adhere to the 8859/Latin-1 mapping where Vietnamese-specific characters are already encoded. Table 2 lists the subset of 8859/Latin-1 characters in G1 that are also Vietnamese (3). The motivation behind this choice is the predominant and increasing availability of 8859/Latin-1 key- boards and font sets, e.g., Digital's VT-terminal series, Xterm keymaps, and Microsoft's Windows. It is natural and reasonable for a user in France to expect that the same keystrokes producing "e'" on the screen for French will do the same for Vietnamese. With the above guidelines, the task is then to lay out the remaining Vietnamese characters in some fashion, perhaps even arbitrary. This has been done in such a way so as to provide some degree of symmetry simply for aesthetics. Note that the Viet- namese collating order cannot in any case be preserved, but this is not a major issue since collation for non-ASCII characters is well accepted to be a table-lookup problem. _________________________________________ (3) Note that the ``dd'' in Table 2 is actually a similar-looking Icelandic ``edh'' in 8859/Latin-1; the Vietnamese rendering form is better reflected in 8859/Latin-2. Table 1: A sampler of possible C0 usage conflicts. Codes selected for this standard proposal are noted with a +. ----------------------------------------------------------------------------- | CODE COMM CTRL GENERAL PRINTER (PC) PC UNIX VI (Unix) | |===========================================================================| | 0 NUL @ C string strings | | 1 SOH A | | 2+ STX B back screen | | 3 ETX C INTR INTR INTR | | 4 EOT D EOF EOF back tab | | 5+ ENQ E | | 6+ ACK F forw.screen | | 7 BEL G BEL BEL BEL | | 8 BS H BS BS BS BS BS | | 9 HT I HT HT HT HT HT | | 10 LF J LF LF LF LF LF | | 11 VT K VT | | 12 FF L FF FF FF redraw | | 13 CR M CR CR CR CR CR | | 14 SO N wide on (IBM) | | 15 SI O comp.on (IBM) | | 16 DLE P Prt.on/off | | 17 DC1 Q XOFF XOFF XOFF XOFF | | 18 DC2 R comp.off(IBM) retype | | 19 DC3 S XON XON XON XON | | 20+ DC4 T wide off(IBM) forw. tab | | 21 NAK U clr. buf(IBM) kill kill | | 22 SYN V literal literal | | 23 ETB W werase werase | | 24 CAN X kill | | 25+ EM Y suspend | | 26 SUB Z EOF suspend | | 27 ESC [ ESC ESC sequence ESC ESC ESC | | 28 FS \ quit | | 29 GS ] Telnet ESC | | 30+ RS ^ | | 31 US _ Windows | ----------------------------------------------------------------------------- Table 2: Vietnamese-specific characters already present in 8859/Latin-1. ---------------------------------------------------------------------- | | 0 1 2 3 4 5 6 7 8 9 A B C D E F | |====|===============================================================| | Cx | A` A' A^ A~ E` E' E^ I` I' | ---------------------------------------------------------------------- | Dx | DD O` O' O^ O~ U` U' Y' | ---------------------------------------------------------------------- | Ex | a` a' a^ a~ e` e' e^ i` i' | ---------------------------------------------------------------------- | Fx | dd o` o' o^ o~ u` u' y' | ---------------------------------------------------------------------- Experience in development of this encoding on the MSDOS platform motivates the consideration of line-drawing glyphs in the PC character set (code page 850). Code positions occupied by singleand double-line drawing characters should be popu- lated with upper case letters. It is possible to do this without violating the major guidelines already established above. With this provision, the MSDOS user can be supplied with code pages containing either PC line-drawing or Vietnamese glyphs. For ex- isting applications, the user can choose the code page most appropriate for her purpose. Where the code page with line drawing characters must be used, the penalty from missing Viet- namese characters has been minimized by the choice of the infre- quently used ones. For new applications, code page switching can easily be done on the fly, if it is desired. The preceding guidelines have resulted in the VISCII 8- bit Vietnamese encoding proposal listed in Table 3. It is intend- ed to be a single table that applies to Vietnamese data handling including storage, processing, transmission, and font encoding. This greatly simplifies the integration, implementation, and usage processes and is indeed one of the major strengths of the proposal. 4 VIQR: MNEMONIC ENCODING SPECIFICATION FOR VIETNAMESE 4.1 MOTIVATION While the 8-bit specification attempts to standardize Viet- namese encoding in 8-bit environments, much remains to be ad- dressed in important 7-bit environments such as electronic mail transport and other 7-bit data lines, as well as in keyboard en- try applications where the interface for generating Vietnamese Table 3: VISCII 8-bit Encoding Standard Proposal for Vietnamese. ----------------------------------------------------------------------- | | 0 1 2 3 4 5 6 7 8 9 A B C D E F | |====|================================================================| | 0x | nul A(? stx etx eot A(~ A^~ bel bs ht lf vt ff cr so si | |----|----------------------------------------------------------------| | 1x | dle dc1 dc2 dc3 Y? nak syn etb can Y~ sub esc rs gs Y. us | |----|----------------------------------------------------------------| | 2x | ! " # $ % & ' ( ) * + , - . / | |----|----------------------------------------------------------------| | 3x | 0 1 2 3 4 5 6 7 8 9 : ; < = > ? | |----|----------------------------------------------------------------| | 4x | @ A B C D E F G H I J K L M N O | |----|----------------------------------------------------------------| | 5x | P Q R S T U V W X Y Z [ \ ] ^ _ | |----|----------------------------------------------------------------| | 6x | ` a b c d e f g h i j k l m n o | |----|----------------------------------------------------------------| | 7x | p q r s t u v w x y z { | } ~ del| |----|----------------------------------------------------------------| | 8x | A. A(' A(` A(. A^' A^` A^? A^. E~ E. E^' E^` E^? E^~ E^. O^'| |----|----------------------------------------------------------------| | 9x | O^` O^? O^~ O^. O+. O+' O+` O+? I. O? O. I? U? U~ U. Y` | |----|----------------------------------------------------------------| | Ax | a. a(' a(` a(. a^' a^` a^? a^. e~ e. e^' e^` e^? e^~ e^. o^'| |----|----------------------------------------------------------------| | Bx | o^` o^? o^~ O+~ O+ o^. o+` o+? i. U+. U+' U+` U+? o+ o+' U+ | |----|----------------------------------------------------------------| | Cx | A` A' A^ A A? A( a(? a(~ E` E' E^ E? I` I' I~ y` | |----|----------------------------------------------------------------| | Dx | DD u+' O` O' O^ O~ y? u+` u+? U` U' y~ y. Y' o+~ u+ | |----|----------------------------------------------------------------| | Ex | a` a' a^ a~ a? a( u+~ a^~ e` e' e^ e? i` i' i~ i? | |----|----------------------------------------------------------------| | Fx | dd u+. o` o' o^ o~ o? o. u. u` u' u~ u? y' o+. U+~| ----------------------------------------------------------------------- characters needs to be standardized. Transporting more than 128 unique symbols over 7-bit data channels is not a problem specific to the Vietnamese language. Since its proposal in 1982, the Internet Simple Mail Transfer Protocol (``SMTP'', [8]) has seen unrelenting efforts to ex- tend it to accommodate 8-bit and widerword data in European La- tin scripts and Oriental ideographic characters (see, e.g., [9]). While clean 8-bit transport is highly desirable, all mail gateways are not going to be converted overnight. For the fore- seeable future there is a need for unambiguous transport of Viet- namese text over existing 7-bit channels. Indeed there is an ad-hoc standard in use on the VietNet mailing list and the Usenet newsgroup Soc.Culture.Vietnamese, where mnemonic use of appropriate characters to follow a vowel proves to be quite readable; for example, ``Vit Nam'' would be written as ``Vie^.t Nam''. However, this is troubled by the am- biguity in the multiple roles played by the mnemonic diacritical marks; for example, does ``tha?'' mean ``tha?'' or ``th''? The Viet-Net convention is not far in concept from a quoted-readable format proposed by K. Simonsen [10 , 11]. which disambiguates such texts by specifying text states at both the character and character set levels. Unfortunately, in its at- tempt to provide a universal solution to mnemonic encoding, the proposal does not provide a good answer for Vietnamese text. First, it restricts the use of mnemonics to the 83 invariant ISO-646 [12] graphic characters, which is a good idea in prin- ciple, but sacrifices readability in the process. For example, the counter-intuitive mnemonics for hook-above (da^'u ho?i) and tilde (da^'u nga~) are ``2'' and ``?'', respectively, in order to avoid ``\'' itself, which is not an invariant. The wide availability of ASCII keyboards to the great majority of Vietnamese users makes this too unreasonable a limitation in the context of Vietnamese processing. It should be noted that we are in fact arguing in favor of ``readability for most'' against ``illegibility for all.'' Furthermore, with ongoing progress on keyboard and display internationalization, e.g., in graphical window environments where keyboard mapping and font switching are easily implemented, this availability is on the increase, further obsoleting the res- triction. The greater difficulty is that the two-character fixed- length encoding(4) cannot provide a readable or mnemonic rep- _________________________________________ (4) The convention is ``&xy'', where x is a literal character and y represents some combining form. resentation of all Vietnamese characters, in particular those with 2 diacritical marks. The variable-length mnemonics(5) have been extended to include all Vietnamese characters, but this scheme is so cluttered with announcers and delimiters that rea- dability and efficiency are near nil, keeping in mind that diacritics are heavily used in Vietnamese. While machine data translators will have little trouble with any ``mnemonic'' scheme, one that is directly accessible to human users, who are in many cases typing mail messages using 7-bit editors, needs to be more user-friendly. A Vietnamese user will not want to learn or remember among all possible combinations that, say, ``a5'' stands for "a('", nor will she like typing sequences as long as ``&_a('_'' for some letter in every word. To satisfy the readability and flexibility requirements, a separate specification is necessary. It is better to adopt an approach like code-page switching under ISO-2022 [13] to switch the text into ``Vietnamese'' mode and optimize encoding according to the language state. Recently, van der Poel put forth a mnemon- ic proposal [14] which emphasizes language-specific conven- tions for these reasons. This proposal provides a means to speci- fy the language state, each with its own (efficient) encoding method. Its strength lies in the flexible specification that con- formant implementations ``need not be able to display all of the character sets specified''; they have the option of stating messages such as ``undisplayable Greek appeared here'' for un- supported languages (for a more precise specification, see [14]). This allows networking communities to determine the best ap- proach for encoding their own languages. The VIQR convention is compatible with this approach and should easily be incorporated into this framework. The specification here encompasses all data streams in- cluding text transfer, file I/O, and keyboard entry. This princi- ple has been the major reason for success in operating systems such as Unix, in which device-specific details are hidden as much as possible from the applications programmer, leaving a uniform interface above which tools such as common library rou- tines can be shared. Indeed as the keyboard example above has im- plied, the characters actually typed by the user are often not different from the text data that is eventually stored or transmitted. It is therefore desirable to provide a common base on which to build data interpreters for all data streams, independent of the input source. In actual implementation, this _________________________________________ (5) The convention is ``&_xxxx_'' where xxxx can be an arbi- trary mnemonic sequence. has greatly facilitated development of the Vietnamese-capable software base. In addition, the user stands to benefit tremendously from standardization of keyboard entry. One does not need to learn a different keyboard entry technique for each different Viet- namese application. If one standard keyboard model is fully sup- ported by all Vietnamese software, a user familiar with the standard can sit down and start typing Vietnamese immediately. This standard defines the minimum expected behavior from com- pliant software; any additional input techniques can of course be incorporated as a superset of the standard behavior. This is discussed further in Section 5.2 on Vietnamese keyboarding. 4.2 QUOTED-READABLE SPECIFICATION (VIQR) The mnemonic model from Viet-Net is fully employed in the specif- ication. The Vietnamese QR comprises three major states: Literal, English, and Vietnamese. The Literal state is intended for completely transparent handling of literal data (except of course for the escape sequences into and out of Literal state). The English and Vietnamese states are designed for mixed use of English and Vietnamese, with each optimized in appearance as well as data size for texts containing mostly English and Vietnamese, respectively. In either state there exist methods for composing Vietnamesespecific characters, using a base vowel followed by one or two diacritics. We first introduce the concept of implicit and explicit composition, then discuss how they are used in each of the states. 4.2.1 Implicit Composition Implicit composition is useful for data containing a large per- centage of Vietnamese characters. With implicit composition, a sequence of a base vowel followed by one or two diacritical marks is combined into one Vietnamese letter as long as it is grammatically legal. This is best illustrated by examples: a^ --> o+? --> ? --> Vie^.t --> Vit Vi.t --> Vit la'^n --> l^n (not ln) l^n --> l^n (not ln) Note in the last two example that the sequence a^' is not grammatically equivalent to a'^ or ^. In general a modifier ("(", "^", "+") must immediately follow the appropriate vowel in order to be combined. The special sequence "dd" is composed into "
"; "DD", "dD", and "Dd" all represent "
". The base vowels are: a, a(, a^, e, e^, i, o, o^, o+, u, u+, y, and their corresponding capitals. The encoding values are those listed in Table 3, the 8-bit VISCII proposed standard. The diacritical marks are represented by ASCII charac- ters having correspondingly similar appearances. Table 4 lists the 7 ASCII characters used as mnemonic replacements for the Vietnamese diacritics: the first three are modifiers, and the remaining five are tone marks. Table 4: ASCII Mnemonics for Vietnamese Diacritics -------------------------------------------------------- | Diacritic | Char | ASCII Code | Da^'u | |============|========|==================|=============| | breve | ( | 0x28, left paren | tra(ng (() | | circumflex | ^ | 0x5E, caret | mu~ (^) | | horn | + | 0x2B, plus sign | mo'c (+) | |------------|--------|------------------|-------------| | acute | ' | 0x27, apostrophe | sa('c (') | | grave | ` | 0x60, backquote | huye^`n (`) | | hook above | ? | 0x3F, question | ho?i (?) | | tilde | ~ | 0x7E, tilde | nga~ (~) | | dot below | . | 0x2E, period | na(.ng (.) | -------------------------------------------------------- 4.2.2 Explicit Composition Explicit composition is associated with the concept of a leading character which explicitly announces the composition. The an- nouncer character is the backslash ("\", ASCII 0x5C), known here as . The subsequent combining characters are defined in the same way as those in implicit composition. Thus the ex- amples given above would appear in explicit composition mode as: \a^ --> \o+? --> Vi\e^.t --> Vit Explicit composition is useful for data containing main- ly English text, as well as for maintaining real-time compati- bility with keyboard character events, as will be discussed in Section 5.2 on Vietnamese keyboarding. With the composition methods described, we are now ready to discuss how they are em- ployed in each of the three states. The state of the data stream is specified by the two character sequence x, where x is specified below. 4.2.3 Literal State The appearance of L or l in the data stream initiates the Literal state. This state is intended for nearperfect tran- sparent literal data transfer. Neither implicit nor explicit composition is available here, nor is the character spe- cial, except when it is followed by one of the six characters l, L, v, V, m or M which initiates one of the three states (6). 4.2.4 English State The sequence M or m sets the data stream state to En- glish. In English state, only explicit composition is supported. This means that in order to generate a Vietnamese letter, the announcer character must be used. A ``composition'' se- quence not preceded by will be left uninterpreted. Exam- ples: \mD\u~ng, how are you? --> Dng, how are you? \mKho\e? kh\o^ng? --> Kho khng? As noted, the sequence "you?" above was not converted into "yo" because no composition was specified. 4.2.5 Vietnamese State The data stream state is set to Vietnamese when the sequence V or v is encountered. In Vietnamese mode, both _________________________________________ (6) To effect L, M, and V themselves, it is necessary to switch to either English or Vietnamese state and use the Character Literal feature available there. explicit and implicit compositions are in effect. The following examples assume that the data stream is initially in English state: \vCh\u+~ Vi\e^.t --> Ch Vit \vChu+~ Vie^.t --> Ch Vit Chu+~ \vVie^.t --> Chu+~ Vit The availability of implicit composition in Vietnamese state ensures that the text is not cluttered with unnecessary s, as would be the case in Vietnamese text using explicit composition. Explicit composition is included to maintain com- patibility with the English state so that there is no need to de- fine additional meanings for the sequences. Also, the real-time keyboard compatibility mentioned previously is also available in Vietnamese state through explicit composition. 4.2.6 Character Literals in English and Vietnamese States Consider the following example: \vDu~ng, how are you? --> Dng, how are yo In this example, the sequence "you?" was interpreted as "yo" because the data stream was still in Vietnamese state. Thus it is sometimes desirable to suppress composition altogether without having to switch states. The literal property of the character conveniently accomplishes this. In either Viet- namese or English state, whenever is followed by a non- combining character c the result is the literal character c it- self. The is discarded from the data stream. To get the character literally, use . Consider the following examples: \vddi dda^u? -->
i
\vddi dda^u\? -->
i
u? \vddi v\o^? -->
i v \vddi v\o^\? -->
i v? \h\e\l\l\o --> hello \\ --> \ \\V --> \V \\M --> \M \\L --> \L 4.2.7 Closure The data stream supports another special character used to gen- erate explicit closure. The closure character is CTRL-A (ASCII 0x01), known here as . When is encountered in the data stream, it immediately terminates any ongoing composition sequence. The itself is always discarded, unless it ap- pears in the literal sequence \. Explicit closure is useful in real-time character appli- cations such as keyboard entry, when it is necessary to specify that a composition sequence has in fact ended and the input en- gine should not stay hanging and wait for more data. 5 SPECIFIC APPLICATIONS This section outlines application-specific guidelines and conven- tions that have evolved in the software development community. It is intended to be a live and growing documentation of such discussions as more experience is gathered. Readers are welcome to participate in these discussions and contribute to the development of these guidelines in particular, and to the stan- dards in general. 5.1 ELECTRONIC MAIL OVER 7-BIT CHANNELS Many of the available channels for electronic mail currently still enforce the 7-bit limitation. The 8-bit character set de- fined in Section 3 cannot be transported verbatim over these channels. VIQR plays an important role here, as it provides for 7-bit transport of Vietnamese text without the ambiguity prob- lem of deciding what to do with the double usage of a diacritical/punctuation mark, e.g., the hook-above or question mark, "?". Because of the 7-bit nature of these communications channels, mail agents will typically not encounter those Vietnamese-specific base vowels that are encoded in the G1 area, namely: a(, A(, a^, A^, e^, E^, o^, O^, o+, O+, u+, and U+. However, mail agents designed to work with 8-bit channels are still expected to handle the occurrence of these characters according to the complete VIQR, namely to combine base vowels and diacritical marks as appropriate. In order to be correctly interpreted, electronic mail mes- sages must explicitly set the language state either in the headers or text body. One cannot assume what state the receiving input engine is in at the start of the message, since messages are not always read in message units, e.g., when a file contain- ing multiple mail messages is scanned. Furthermore, if a language state specification (\L, \V or \M) is present in a mail message, it is highly recommended that the message end in the Literal state. This helps applications reading multiple mail messages in one data stream, such as a terminal application. It is useful because mail headers do not adhere to the VIQR, and they are more adversely affected when in- terpreted in non-Literal states. 5.2 VIETNAMESE KEYBOARDING Keyboards are becoming increasingly internationalized. As men- tioned in the 8-bit specification, this is the major reason for using the same code positions for those Vietnamese characters al- ready present in ISO 8859/Latin-1. A Vietnamese keyboard driver designed to work in the 7-bit-only environment can assume that it will not encounter Vietnamese base vowels residing in G1. Keyboard drivers for the 8-bit environments, like 8-bit electron- ic mail agents (Section 5.1), must be prepared to accept any base vowel, including those encoded in G1. The real-time echoing behavior of keyboard input during composition requires further specification. The options are to report the character only after the composition sequence has finished, or to report all intermediate forms and backspacing over them. Each has its own useful context as described below. 5.2.1 Immediate Echo for Implicit Composition Implicit composition is designed to be convenient for a user processing data that is mostly Vietnamese. As such it is desir- able for the keyboarding user to get immediate feedback on typed keys. With implicit composition, the keyboard works in immediate-echo mode. Keypresses immediately generate key events. If a character is subsequently composed with a diacrit- ical mark, a backspace (typically BS, ASCII 0x08) is sent fol- lowed by the new composed character. This cycle continues as long as composition is possible. The sequence of events for the key sequence "a^'n" under immediate echo is: 1. user types a, a is sent to the application 2. user types ^, BS and are sent 3. user types ', BS and are sent 4. user types n, the single key n is sent The actual backspace character code may vary depending on the system, application, and user settings. The keyboard in- ter- face should use the appropriate code, and/or allow the user to specify the preferred backspace character. 5.2.2 Delayed Echo for Explicit Composition When a composition sequence is started, the keyboard interface must not send any key events to the application expecting key- board input until the sequence is terminated. Composition may end either naturally when the interface receives a character that cannot be composed into the sequence, or when the closure character is received. A single key event for the com- posed character is then sent to the application above. Subsequent processing can proceed naturally. Consider what happens when the user types the sequence "\a^'n" under delayed echo: 1. user types \, no key is sent to the application 2. user types a, no key is sent 3. user types ^, no key is sent 4. user types ', the single key is sent 5. user types n, the single key n is sent Or an example involving closure, "t\o+": 1. user types t, the key t is sent 2. user types \, no key is sent 3. user types o, no key is sent 4. user types +, no key is sent 5. user types CTRL-A, the single key is sent Note that without the closure key the keyboard interface would still be left hanging after the "+" key has been pressed, because the user can still enter a tone mark as part of the com- position sequence. This delayed-echo behavior for explicit composition is designed to ensure compatibility with applications expecting single key events for each character, particularly in the English state where only explicit composition is available. While it is certainly possible to have immediate-echo in explicit composi- tion or delayed-echo in implicit composition, these options are not useful and serve only to confuse the user learning how to use a Vietnamese keyboard. It is therefore simplest to associate delayed-echo with expli- cit composition, and immediate-echo with implicit composition. These options make natural sense. This standard defines the minimal ``look-and-feel'' be- havior a user can expect from a compliant Vietnamese software package. A standardized interface decreases the required learn- ing time for each new application. This standard does not pre- clude other input mechanisms to improve user-friendliness, e.g., intelligent menu-driven diacritics, or to assist in speed typ- ing, e.g., through the use of CONTROL or FUNCTION keys. Any enhancement in compliant applications is a bonus for the user, so long as such enhancements do not adversely conflict with the minimum expected behavior described here. 5.3 ADAPTING EXISTING VIETNAMESE APPLICATIONS A realistic approach to standardization provides for the inertia against change in existing software applications. While it is desirable that the standard 8-bit encoding described here be fully supported, an alternative exists which is more amenable to rapid adoption. All applications should provide a means for im- porting and exporting data encoded using the VISCII 8-bit encod- ing table. At the same time, the VIQR keyboard interface should be implemented, at least as an optional entry method. Such moves are highly desirable both for the user and the vendor alike. The user will be able to use the software immediately because of the uniform keyboard interface, as well as process the same da- ta in different applications and on different platforms, with in- creased productivity and interactivity among users. This ease of use means greater acceptance and a correspondingly larger customer base for the vendor. 6 SUMMARY & CONCLUSIONS This paper has presented a proposal for standardization of Viet- namese information processing. A case has been made for the necessity of standardization; we hope to have encouraged ven- dors and users of Vietnamese alike to work together toward this goal to benefit everyone involved. Various encoding approaches were discussed, leading to the choice of the VISCII 8-bit encod- ing proposal. A single encoding table was presented that has been shown in actual practice to work well for Vietnamese including editing, processing, storage, transfer, font encoding, and print- ing. Where 8bit data handling was not available or reliable, e.g., elec- tronic mail transport, the Vietnamese Quote-Readable specifica- tion (VIQR) was introduced to provide a seamless filtering gateway. VIQR was defined to be input-source-independent and hence has been designed to be applicable to Vietnamese keyboard input as well as machine data filters. All of this was shown to have been integrated into existing environments facilitating the use of existing tools and applications--a major strength of the encoding. Finally, these specifications have been linked together seamlessly to include every point in the input- process/transfer-output cycle of data handling and provide for a truly unified framework for Vietnamese information processing. References [1] Ba.ch Hu+ng Khang. ``Institute of Informatics,''. Ha` No^.i, Vie^.t Nam, February 1991. [2] B. Jerman-Blazic, ``Will the Multi-octet Standard Character Set Code Solve the World Coding Problems for Information Interchange?,'' Computer Standards & Interfaces, vol. 8, pages 127--136, 1988. [3] The Unicode Consortium. The Unicode Standard: Worldwide Character Encoding Version 1.0. Addison- Wesley, Reading, MA, first edition, October 1991. [4] ISO Technical Committee, ``Universal Multiple-Octet Coded Character Set (UCS), ISO/IEC DIS 10646-1.2,'' Draft standard, International Organization for Standardization, 1992. [5] International Organization for Stan- dardization. ISO 8859/x: 8-bit International Code Sets. ISO, 1977. [6] Famjxuaen Thais. Vie^.t Ngu+~ Ca?i Ca'ch. Tu+' Ha?i, Ha` No^.i, Vie^.t Nam, March 1948. [7] Pha.m Xua^n Tha'i. Chu+~ Vie^.t Ho+.p Li'. Ti'n DDu+'c Thu+ Xa~ Vie^.t Nam, April 1958. [8] J. Postel, ``Simple Mail Transfer Protocol,'' RFC 822, USC Information Sciences Institute, August 1982. [9] J. C. Klensin et al., ``SMTP Extensions for Transport of Text-Based Messages Containing 8-bit Characters,'' Internet draft, Massachusetts Institute of Technology, July 1991. [10] K. Simonsen, ``Character Mnemonics & Character Sets,'' Internet draft, Danish Unix Users Group, January 1992. [11] K. Simonsen, ``Mnemonic Text Format,'' Internet draft, Danish Unix Users Group, August 1991. [12] International Organization for Standardization. ISO 646: 7-bit Cod- ed Character Set for Information Interchange. ISO, third edition, 1991. [13] International Organization for Standardization. ISO 2022: 7-bit and 8-bit Coded Character Sets---Code Extension Techniques. ISO, third edition, 1986. [14] E. M. van der Poel, ``Multilingual Character Encoding for Internet Messages,'' Internet draft, Software Research Associates, Japan, January 1992. [15] IBM. System/370 Reference Summary--GX20-1850-5, sixth edition, 1984. [16] C.E. Mackenzie. Coded-Character Sets: History and Development. Addison-Wesley, Reading, MA, 1980. [17] D.E. Knuth. The TeXbook. Addison-Wesley, Reading, MA, 1984. Glossary of Terms Announcer: A character or sequence of characters appearing in the data that signifies the start of some special sequence. In this text, it announces a Vietnamese composition sequence. ASCII: American Standard Code for Information Interchange, a 128-character code used almost universally by computers for representing and transmitting characters data, in which each character corresponds to a decimal number between 0 and 127. Eightor nine-bit codes of which the first 128 characters correspond to ASCII are called Extended ASCII; the additional characters are used to provide graphic characters for roman al- phabets with diacritics, non-roman alphabets, special screen ef- fects, etc. Base Vowel: In this text, the unaccented Vietnamese vowels: a a( a^ e e^ i o o^ o+ u u+ y (and their capitals). Contrast this with Vowel. C0 Space: ``Control characters'' at code positions with hex values 00 through 1F. C1 Space: ``Control characters'' at code positions with hex values 80 through 9F. Code: In data communication, the numeric or internal represen- tation for a character, e.g., in ASCII. Code Page: Name used to denote glyph sets on the IBM PC. Abbre- viated as CP. CP 850 is the multilingual code page, CP860 is for Portugal, CP863 is for French Canada, CP865 is for Norway. Control Character: An ASCII character in the range 0 to 31, plus ASCII character 127, contrasted with the printable, or graphic, characters in the range 32 to 126. It is produced on an ASCII terminal by holding down the CTRL key and typing the desired character. EBCDIC: Extended Binary Coded Decimal Interchange Code. The char- acter code used on IBM mainframes. Not covered by any formal standards but described definitively in [15] and discussed at length in [16]. Floating Diacritics: A multiple-unit encoding approach for Viet- namese that treats the vowel and its diacritics as separate un- its. The diacritics may either precede or follow the vowel, or even the word. Contrast this with Precomposed Character. Glyph: The physical appearance of a character as displayed on the screen or printed on paper. G0 Space: ``Graphic characters'' at code positions with hex values 20 through 7F. G1 Space: ``Graphic characters'' at code positions with hex values A0 through FF. ISO: International Organization for Standardization. A volun- tary international group of national standards organizations that issues standards in all areas, including computers, infor- mation processing, and character sets. ISO 646: The standard 7-bit code set, equivalent to ASCII [12]. ISO Standard 8859: An ISO standard specifying a series of 8-bit computer character sets that include characters from many languages. These include ISO Latin Alphabets 1-9, which cover most of the written languages based on Roman letters, plus spe- cial character sets for Cyrillic, Greek, Arabic, and Hebrew [5]. ISO 8859/1: ISO Standard 8859 Latin Alphabet Number 1. Supports at least the following languages: Latin, Danish, Dutch, English, Faeroese, Finnish, French, German, Icelandic, Irish, Italian, Norwegian, Portuguese, Spanish, and Swedish [5]. ISO 2022 and ISO 4873: ISO standards for switching code pages [13]. ISO DIS 10646: The prospective 16and 32-bit Universal Coded Set, (Draft International Standard) [4]. Latin: Referring to the Latin, or Roman, alphabet, comprised of the letters A through Z, or to any alphabet based upon it. MS-DOS: Microsoft's Disk Operating System for microcomputers based on the Intel 80x86 family of CPU chips. Modifier: A phonetic diacritical mark. The Vietnamese modif- iers, are: breve (tra(ng, (), circumflex (mu~, ^), horn (mo'c, +). PC: Personal Computer. In this text, the term PC refers to the entire IBM PC and PS/2 families and compatibles, which includes the AT, 286, 386, and 486 PC's. PostScript: A page description language with graphics capabili- ties designed for electronic printing. The description is high-level and device-independent. PostScript is a trademark of Adobe Systems Incorporated. Precomposed Characters: An encoding approach for Vietnamese that treats all vowel combinations as single units. Contrast this with Floating Diacritics. TeX: A computerized typesetting system developed by Donald Knuth [17], providing nearly everything needed for high-quality typesetting of mathematical notations as well as of ordinary text. TeX is a trademark of the American Mathematical Society. Tone Mark: A tonal diacritical mark that indicates the tone/accent. The Vietnamese tone marks are: acute (sa('c), grave (huye^`n), hook above (ho?i), tilde (nga~), dot below (na(.ng). Unicode: A 16-bit multilingual character code proposed by the Un- icode Consortium [3]. Unix: A popular operating system developed at AT&T Bell Labora- tories and noted for its portability. Usenet: A worldwide network available to users for sending mes- sages (or ``news articles'') that can be read and responded to by other users. Participating in Usenet is like subscribing to a collection of electronic magazines. These ``magazines,'' called newsgroups, are devoted to particular topics. The ``Soc.Culture.Vietnamese'' newsgroup is very popular among both Vietnamese and non-Vietnamese worldwide. Viet-Std: A non-profit group of overseas Vietnamese profession- als working on software & hardware standards for the Vietnamese language. Members of the group exchange ideas via electronic mail and meetings. Vowel: In this text, a generic term applying to all Vietnamese vowels and their various combining forms, e.g., a, a(, and a('. See Base Vowel.   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01000; 12 Apr 92 12:52 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa05820; 12 Apr 92 12:55 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa05803; 12 Apr 92 12:55 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA00590; Sun, 12 Apr 92 12:31:02 EDT Received: from heifetz.msen.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA00586; Sun, 12 Apr 92 12:30:58 EDT Received: by heifetz.msen.com (/\==/\ Smail3.1.22.1 #22.11) id ; Sun, 12 Apr 92 12:28 EDT Message-Id: To: ietf-822-post@msen.com Subject: [soc.culture.korean] Announcing SSHR - Read/Write Hangul even on Dumb Terminals (forwarded) Date: Sun, 12 Apr 92 12:28:04 -0400 From: Edward Vielmetti ------- Forwarded Message Path: heifetz!spool.mu.edu!agate!pollux.usc.edu!dkyoon From: dkyoon@pollux.usc.edu (Dae-kyun Yoon) Newsgroups: comp.archives Subject: [soc.culture.korean] Announcing SSHR - Read/Write Hangul even on Dumb Terminals Message-ID: Date: 9 Apr 92 01:39:35 GMT Article-I.D.: agate.s078nINNp8u References: Followup-To: soc.culture.korean Organization: University of Southern California, Los Angeles, CA Lines: 25 Approved: adam@soda.berkeley.edu NNTP-Posting-Host: soda.berkeley.edu X-Original-Newsgroups: soc.culture.korean X-Original-Date: 8 Apr 1992 11:04:21 -0700 Archive-name: auto/soc.culture.korean/Announcing-SSHR-Read-Write-Hangul-even-on-Dumb-Terminals If you really like to communicate in hangul but have given up the use of hangul because you don't have a hangul terminal, you might want to try this: romanized hangul. If you think you can read/write something like "an.nyeong.ha.se.yo? BanGabSeubNiDa.", the chance is that you can communicate with other hangul-users in hangul even on dumb terminals. We have defined a hangul romanization scheme called SSHR, and made a few code converters for KS5601: - ks2sshr (and readks) to generate romanized hangul from KS5601 - sshr2ks to convert romanized hangul to KS5601 They are are compiled and run in Unix systems. When coupled with other "ks-wares" such as iso2ks and msy2ksc, ks2sshr/sshr2ks can be used for those 7-bit encoding schemes The document and programs for sshr is available through anonymous ftp to cair.kaist.ac.kr, in directory pub/hangul/codeconv, file name ks2sshr.tar.Z (should be transferred in binary mode). Please send any comments/questions to either dkyoon@usc.edu or sung@ibm.com. -- Thanks. - -- Dae-kyun Yoon dkyoon@usc.edu, ..!uunet!usc!dkyoon ------- End of Forwarded Message   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03801; 13 Apr 92 14:30 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa12695; 13 Apr 92 14:33 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa12672; 13 Apr 92 14:33 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA20266; Mon, 13 Apr 92 14:02:02 EDT Received: from att-out.att.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA20261; Mon, 13 Apr 92 14:01:59 EDT Message-Id: <9204131801.AA20261@dimacs.rutgers.edu> From: "t.l.hansen" To: ietf-822@dimacs.rutgers.edu Date: 11 Apr 1992 12:15 EDT Subject: Network World Would anyone care to comment on this report, in particular, the last statement about hampering X.400? < Network World reports that the Internet Activities Board (IAB) is < developing a standard called the Multipurpose Internet Mail Extensions < (MIME) that will enhance mail exchange functions on the Internet computer < network, and is expected to further hamper the widespread acceptance of < the X.400 standard. Tony Hansen hansen@pegasus.att.com, tony@attmail.com att!pegasus!hansen, attmail!tony   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa04403; 13 Apr 92 16:52 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa18802; 13 Apr 92 16:55 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa18783; 13 Apr 92 16:55 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA29606; Mon, 13 Apr 92 16:51:31 EDT Received: from WILMA.CS.UTK.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA29602; Mon, 13 Apr 92 16:51:26 EDT Received: from LOCALHOST by wilma.cs.utk.edu with SMTP (5.65/2.7c-UTK) id AA23845; Mon, 13 Apr 92 16:51:00 -0400 Message-Id: <9204132051.AA23845@wilma.cs.utk.edu> From: Keith Moore To: "t.l.hansen" Cc: ietf-822@dimacs.rutgers.edu, moore@cs.utk.edu Subject: Re: Network World In-Reply-To: Your message of "11 Apr 92 12:15:00 EDT." <9204131801.AA20261@dimacs.rutgers.edu> Date: Mon, 13 Apr 92 16:50:59 EDT Sender: moore@cs.utk.edu > From: hansen@pegasus.att.com (t.l.hansen) > To: ietf-822@dimacs.rutgers.edu > Date: 11 Apr 1992 12:15 EDT > Subject: Network World > > Would anyone care to comment on this report, in particular, the last > statement about hampering X.400? > > < Network World reports that the Internet Activities Board (IAB) is > < developing a standard called the Multipurpose Internet Mail Extensions > < (MIME) that will enhance mail exchange functions on the Internet computer > < network, and is expected to further hamper the widespread acceptance of > < the X.400 standard. Another way to look at this is that the Internet is moving closer to *compatibility* with X.400. The introduction of MIME to the Internet community will allow X.400 users to take advantage of the "extra" features of X.400 that will soon be available in MIME also. This increases the usability (and the widespread acceptance) of BOTH 822 and X.400, because it increases the number of users you can exchange "enhanced" mail with, regardless of which protocol you use. Keith Moore   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa05223; 13 Apr 92 18:52 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa23618; 13 Apr 92 18:55 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa23600; 13 Apr 92 18:55 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA05124; Mon, 13 Apr 92 18:41:28 EDT Received: from ics.uci.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA05118; Mon, 13 Apr 92 18:41:26 EDT Received: from ics.uci.edu by q2.ics.uci.edu id aa09096; 13 Apr 92 13:04 PDT To: "t.l.hansen" Cc: ietf-822@dimacs.rutgers.edu Subject: Re: Network World In-Reply-To: 11 Apr 92 12:15:00 EDT. <9204131801.AA20261@dimacs.rutgers.edu> Cc: stef@nma.com From: Einar Stefferud Reply-To: stef@nma.com Date: Mon, 13 Apr 92 13:04:04 -0700 Message-Id: <9092.703195444@ics.uci.edu> Sender: stef@ics.uci.edu It is my claim that MIME will help spread X.400 by making it easier for Internet and X.400 mail systems to interwork, thus blurring, rather than enhancing the boundaries between them. It has become my firm belief that much of the problem faced by X.400 deployment is besed in the way X.400 is "Installed Base Hostile" in that it offers little (if anyting) to help interwork with any installed base, particularly internet mail. MIME corrects this, though there is more work to be done in terms of mapping MIME body parts to X.400 body parts. This work is being led by Marshall Rose and Harald Alverstrom. We also have some difficult work to do to interwork the delivery and receipt notifications issues. This work is being discussed in the ietf-ack list. I do not see any easy way to map between the two without some serious changes to SMTP, which I do not believe can be made into deployable implementations. But, Network World is simply wrong headed in their point of view, shich suggests that anything helpgful to any installed base system is harmful to X.400. They need to learn that networtking is not a Zero-Sum Game! Every interesting connection or message tranfer (according to Communications 101) has two ends! Improving things at one end should not harm the things at the other end, in terms of getting useful work done at both ends. The great (rude) question to ask is: "Do you want to get some work done, or do you just want to make a statement?" Cheers...\Stef   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa05241; 13 Apr 92 19:22 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa24477; 13 Apr 92 19:25 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa24459; 13 Apr 92 19:25 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA05273; Mon, 13 Apr 92 19:04:11 EDT Received: from sayshell.umd.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA05269; Mon, 13 Apr 92 19:04:09 EDT Received: by sayshell.umd.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0) id AA17363; Mon, 13 Apr 92 19:04:01 EDT Message-Id: <9204132304.AA17363@sayshell.umd.edu> To: Keith Moore Cc: "t.l.hansen" , ietf-822@dimacs.rutgers.edu Reply-To: "Louis A. Mamakos" Subject: Re: Network World In-Reply-To: Your message of "Mon, 13 Apr 92 16:50:59 EDT." <9204132051.AA23845@wilma.cs.utk.edu> Date: Mon, 13 Apr 92 19:04:00 -0400 From: "Louis A. Mamakos" Gee, I look at MIME as a reason to NOT move to X.400. Now I can give my users many of the same capabilities of X.400 (like the important things to them: attaching their WordPerfect files), plus they get to use an already installed and working mature network infrastructure (the Internet). louie   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00910; 14 Apr 92 9:35 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa07880; 14 Apr 92 9:38 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa07858; 14 Apr 92 9:38 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA01971; Tue, 14 Apr 92 09:24:24 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA01967; Tue, 14 Apr 92 09:24:22 EDT Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Tue, 14 Apr 92 09:24:15 EDT Received: by greenbush.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Tue, 14 Apr 92 09:24:13 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; Tue, 14 Apr 1992 09:24:10 -0400 (EDT) Message-Id: Date: Tue, 14 Apr 1992 09:24:10 -0400 (EDT) From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: Keith Moore Subject: Re: Network World Cc: "t.l.hansen" , ietf-822@dimacs.rutgers.edu In-Reply-To: <9204132304.AA17363@sayshell.umd.edu> References: <9204132304.AA17363@sayshell.umd.edu> Sigh. I HATE talking to reporters. I hate it, I hate it, I hate it. They always manage to get something terribly wrong, either accidentally or maliciously. The first published article about metamail actually "quoted" me as saying that Bellcore gave metamail away "because we didn't think anyone would pay for it." Needless to say, those were not my words at all. In the case of the Network World article, I thought I made it quite clear that MIME represented a remarkable coalition between X.400-lovers and X.400-haters, who had a large area of common interest that led both groups to work together to create MIME. Apparently, that message did not get through clearly enough, and I apologize for any role I may have played in giving the article an anti-X.400 slant. Personally, as many of you know, I've always been skeptical about the claim that MIME will help X.400 -- I'm more or less on Louie Mamakos' side of the argument -- but I have tried very hard to make it clear to reporters that MIME represents a joint effort of the people who feel as I do and the people who feel it will help X.400. (I would think that the experience and affiliations of Ned & myself would make that pretty clear, too!) Alas, I guess that a story about reasonable people agreeing to disagree and still work together constructively just doesn't make good copy. -- Nathaniel   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01186; 14 Apr 92 10:35 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa09858; 14 Apr 92 10:38 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa09837; 14 Apr 92 10:38 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA02346; Tue, 14 Apr 92 10:36:22 EDT Received: from qualcom.qualcomm.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA02342; Tue, 14 Apr 92 10:36:20 EDT Received: from middleearth.qualcomm.com by Qualcomm.COM; id AA27091 sendmail 5.65/QC-2.0 via SMTP Tue, 14 Apr 92 07:35:29 -0700 for ietf-822@dimacs.rutgers.edu Message-Id: <9204141435.AA27091@Qualcomm.COM> Date: Tue, 14 Apr 1992 07:35:56 -0800 To: "Louis A. Mamakos" , Keith Moore From: John Noerenberg Subject: Re: Network World Cc: "t.l.hansen" , ietf-822@dimacs.rutgers.edu >Gee, I look at MIME as a reason to NOT move to X.400. Now I can give >my users many of the same capabilities of X.400 (like the important >things to them: attaching their WordPerfect files), plus they get to >use an already installed and working mature network infrastructure >(the Internet). > >louie The emphasis should be on diversity. We recognized early on that X.400 has it's adherents. As Stef said yesterday, promoting greater interoperation offers both systems greater opportunities for growth and acceptance. We should always remember we're developing systems for people. And different people have different needs. Being close-minded serves no one. -jwn2 jwn2@qualcomm.com noerenberg.j (Applelink) =============================================================== Speak of the world's own change. Though we cannot conceive Of an undreamt thing, we know to our cost How the dreamt cloud crumbles... -Richard Wilbur, Advice to a Prophet [1959] ===============================================================   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01323; 14 Apr 92 11:05 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa10889; 14 Apr 92 11:08 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa10864; 14 Apr 92 11:08 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA02397; Tue, 14 Apr 92 10:44:10 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA02393; Tue, 14 Apr 92 10:44:07 EDT Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Tue, 14 Apr 92 10:44:00 EDT Received: by greenbush.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Tue, 14 Apr 92 10:43:58 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; Tue, 14 Apr 1992 10:43:56 -0400 (EDT) Message-Id: Date: Tue, 14 Apr 1992 10:43:56 -0400 (EDT) From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ietf-822@dimacs.rutgers.edu Subject: New mailcap document I've got an updated version of my "Configuration" document, which describes the mailcap file format, which I intend to publish as an informational RFC when MIME comes out. The new version is mostly the same as the last one, with a few clarifications suggested by various readers, plus a new optional field, "x11-bitmap". The latest version is available via anonymous ftp on thumper.bellcore.com, where you can find it as "Configuration.ps" and "Configuration.txt" in the directory pub/nsb. As always, comments are welcome. -- Nathaniel   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01537; 14 Apr 92 12:10 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa13547; 14 Apr 92 12:14 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa13508; 14 Apr 92 12:13 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA02871; Tue, 14 Apr 92 11:41:23 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA02867; Tue, 14 Apr 92 11:41:20 EDT Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Tue, 14 Apr 92 11:41:18 EDT Received: by greenbush.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Tue, 14 Apr 92 11:41:14 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; Tue, 14 Apr 1992 11:41:08 -0400 (EDT) Message-Id: <0dujoI_0M2YtQ27nkp@thumper.bellcore.com> Date: Tue, 14 Apr 1992 11:41:08 -0400 (EDT) From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ietf-822@dimacs.rutgers.edu Subject: Implications of MIME for Transport I've been thinking, off and on, about MIME and MTA's. We've been very careful not to do anything in MIME that will REQUIRE changes in MTA's, but we also all know that there are things in MIME that will be of interest to those who maintain MTA's. I've therefore taken a first cut at an INFORMATIONAL document that will try to explain to MTA implementors how they can benefit from MIME facilities. A draft of this document follows below. I'd be grateful for any comments or suggestions that this group might have. Thanks. -- Nathaniel Network Working Group Internet Draft Nathaniel S. Borenstein Bellcore April, 1992 Implications of MIME for Message Transport Abstract The recent development of MIME (Multipurpose Internet Mail Extensions) offers a wide range of new opportunities for electronic mail system software. Most of these opportunites are relevant only to user agents, the programs that interact with human users when tthey send and receive mail. However, some opportunities are also opened up for mail transport software. While MIME was carefully designed so that it does not require any changes to message transport facilities, there are several ways in which message transport software may want to take advantage of MIME. These opportunities are the subject of this memo. Status of This Memo This is an informational memo for the Internet community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard. Distribution of this memo is unlimited. Background -- The MIME Format Recently, a new standardized format has been defined for enhanced electronic mail messages on the Internet. This format, known as MIME, permits messages to include, in a standardized manner, non-ASCII text, images, audio, and a variety of other kinds of interesting data. The MIME effort was explicitly focused on requiring absolutely no changes at the message transport level. Because of this fact, MIME-format mail runs transparently on all known Internet or Internet-style mail systems. This means that those concerned solely with the maintenance and development of message transport software can safely ignore MIME completely, if they so choose. However, the fact that MIME can be ignored, for the purpose of message transport, does not necessarily mean that it should be ignored. In particular, MIME offers several features that should be of interest to those responsible for message transport software. By exploiting these features, transport software can provide certain kinds of service that are currently unavailable, and can alleviate a few existing problems. The remainder of this document is an attempt to briefly point out and summarize some important ways in which MIME may be of use for message transport software. This document makes no attempt to present a complete technical description of MIME, however. For that, the reader is refered to the MIME document itself [MIME]. Rejected Messages An unfortunately frequent duty of message transport software is the rejection of mail to the sender. This may happen because the mail was undeliverable, or because it did not conform to the requirements of a gateway (e.g. it was too large). There has never been a standard format for rejected messages in the past. This has been an annoyance, but not a major problem for text messages. For non-text messages, however, the lack of a standard rejection format is more crucial, because rejected messages typically appear to be text, and the user who is forced to view images or audio as text is rarely happy with the result. MIME makes it very easy to encapsulate messages in such a way that their semantics are completely preserved. The simplest way to do this is to make each rejection notice a MIME "multipart/mixed" message. That multipart message would contain two parts, a text part explaining the reason for the rejection, and an encapsulated message part that contained the rejected message itself. It should be stressed that the transport software does not need to understand the structure of the rejected message at all. It merely needs to encapsulate it properly. The following, for example, shows how any MIME message may be encapsulated in a rejection message in such a way that all information will be immediately visible in the correct form if the recipient reads it with a MIME-conformant mail reader: From: Mailer-Daemon Subject: Rejected Message Content-type: multipart/mixed; boundary=unique-boundary --unique-boundary Content-type: text/plain; charset=us-ascii Your message to "bush@whitehouse.gov" was rejected for the following reason: >>> No mail from libertarians is accepted. <<< The original message follows below. --unique-boundary Content-type: message/rfc822 The ENTIRE REJECTED MESSAGE, starting with the headers, goes here. --unique-boundary-- In the above example, the ONLY thing that is not 'boilerplate" is the choice of boundary string. The phrase "unique-boundary" should be replaced by a string that does not appear (prefixed by CRLF and two hyphens) in any of the body parts. Encapsulating a message in this manner is very easily done, and will constitute a significant service that message transport software can perform for MIME users. Fragmenting and Reassembling Large Messages One problem that occurs with increasing frequency in Internet mail is the rejection of messages because of size limitations. This problem can be expected to grow substantially more severe with the acceptance of MIME, as MIME invites the use of very large objects such as images and audio clips. Fortunately, MIME also provides mechanisms that can help alleviate the problem. One particularly relevant MIME type is "message/partial", which can be used for the automatic fragmentation and reassembly of large mail messages. The message/partial type can be handled entirely at the user agent level, but message transport software can also make use of this type to provide more intelligent behavior at gateways. In particular, when gatewaying mail to or from a system or network known to enforce size limitations that are more or less stringent than are enforced locally, message transport software might choose either to break a large message into fragments, or (perhaps less likely) to reassemble fragments into a larger message. The combination of these two behaviors can make the overall Internet mail environment appear more complete and seamless than it actually is. Details on the message/partial format may be found in the MIME document. What follows is an example of how a simple short message might be broken into two message/partial messages. In practice, of course, the message/partial facility would only be likely to be used for much longer messages. The following initial message: From: Nathaniel Borenstein To: Ned Free: Subject: a test message Content-type: image/gif Content-Transfer-Encoding: base64 R0lGODdhQAGMAbMAAAAAAP/u7swzIu6ZiLsiEd1EM+5VRGaI3WYAAO67qkRV uwARd6q7/ywAAAAAQAGMAUME/hDISau9OOvNu/9gKI6kRJwoUa5s675wLM90l XW5YKxqPyKRygxv2dr4czwlMCZrQLFTYHBJ2hlyQYFiaz+i0WWBou7fOq1x8vXWfU qU1fJ2qEhYaHGjhZQmJ2QT1xBW1ak1xUdV0/VjtsbpUEDaEJCQOIpqeoNV+LXo5W fVN3dZKceAQPvgyhwQ2lqcXGxx5wja59eJIGUNCszF90sYp50CoqFZ4DoqMMo6M can be transformed, invertibly, into the following two message/partial messages: From: Nathaniel Borenstein To: Ned Freed Subject: a test message Content-type: message/partial; id="xyx@host.com"; number=1; total=2 Content-type: image/gif Content-Transfer-Encoding: base64 R0lGODdhQAGMAbMAAAAAAP/u7swzIu6ZiLsiEd1EM+5VRGaI3WYAAO67qkRV and From: Nathaniel Borenstein To: Ned Freed Subject: a test message Content-type: message/partial; id="xyx@host.com"; number=2; total=2 uwARd6q7/ywAAAAAQAGMAUME/hDISau9OOvNu/9gKI6kRJwoUa5s675wLM90l XW5YKxqPyKRygxv2dr4czwlMCZrQLFTYHBJ2hlyQYFiaz+i0WWBou7fOq1x8vXWfU qU1fJ2qEhYaHGjhZQmJ2QT1xBW1ak1xUdV0/VjtsbpUEDaEJCQOIpqeoNV+LXo5W fVN3dZKceAQPvgyhwQ2lqcXGxx5wja59eJIGUNCszF90sYp50CoqFZ4DoqMMo6M Fragmenting such messages rather than rejecting them might be a reasonable option for some gateway software, at least for a certain size range of messages. Using or Removing External-Body Pointers Another MIME type oriented to extremely large messages is the "message/external-body" type. In this type of message, the body data is not included in the actual message itself. Instead, the Content-Type header field includes information that tells how the body data can be retrieved -- either via a file system, via anonymous ftp, or via other mechanisms. The message/external-body type provides a new option for mail transport software that wishes to optimize the way bandwidth resources are used in a given environment. For example, the basic use of message/external-body is to reduce bandwidth in email traffic. However, when email crosses a slow and expensive boundary -- e.g. a satellite link across the Pacific -- it might make sense to retreive the data itself and transform the external-body reference into the actual data. Alternately, it might make sense to copy the data itself to a new location, closer to the message recipients, and change the location pointed to in the message. Because the external-body specification can include an expiration date, message transport software can trade off storage and bandwidth capabilities to try to optimize the overall use of resources for very large messages. For example, the following message includes PostScript data by external reference: From: Nathaniel Borenstein To: Ned Freed Subject: The latest MIME draft Content-Type: message/external-body; name="BodyFormats.ps"; site="thumper.bellcore.com"; access-type=ANON-FTP; directory="pub"; mode="image"; expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" Content-type: application/postscript A gateway to Australia might choose to copy the file to an Australian FTP archive, changing the relevant parameters on the Content-type header field. Alternately, it might choose simply to transform the message into one in which all the data were included: From: Nathaniel Borenstein To: Ned Freed Subject: The latest MIME draft Content-type: application/postscript %!PS-Adobe-1.0 %%Creator: greenbush:nsb (Nathaniel Borenstein,MRE 2A-274,4270,9938586,21462) etc... Image Format Conversions MIME currently defines two image formats, image/gif and image/jpeg. The former is much more convenient for many users, and can be displayed more quickly on many systems. The latter is a much more compact representation, and therfore places less stress on mail transport facilities. Message transport software can optimize both transport bandwidth and user convenience by intelligent translation between these formats (and other formats that might be added later). When a message of type image/gif is submitted for long-haul delivery, it might reasonably be translated to image/jpeg. Conversely, when image/jpeg data is received for final delivery on a system with adequate storage resources, it might be translated to image/gif for the convenience of the recipient. Software to perform these translations is widely available. Although MIME currently only defines one audio format, more are likely to be defined and registered with IANA in the future. In that case, similar format conversion facilities might be appropriate for audio. References [MIME] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", Internet Draft draft-ietf822-bodyformats-05", March, 1992.   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01868; 14 Apr 92 13:04 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa15845; 14 Apr 92 13:08 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa15828; 14 Apr 92 13:08 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA04328; Tue, 14 Apr 92 13:03:11 EDT Received: from venera.isi.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA04324; Tue, 14 Apr 92 13:03:09 EDT Received: from braden.isi.edu by venera.isi.edu (5.65c/5.65+local-4) id ; Tue, 14 Apr 1992 09:41:58 -0700 Date: Tue, 14 Apr 92 10:02:54 PDT From: braden@isi.edu Posted-Date: Tue, 14 Apr 92 10:02:54 PDT Message-Id: <9204141702.AA00816@braden.isi.edu> Received: by braden.isi.edu (4.1/4.0.3-4) id ; Tue, 14 Apr 92 10:02:54 PDT To: hansen@pegasus.att.com, stef@nma.com Subject: Re: Network World Cc: ietf-822@dimacs.rutgers.edu But, Network World is simply wrong headed in their point of view, shich suggests that anything helpgful to any installed base system is harmful to X.400. They need to learn that networtking is not a Zero-Sum Game! Every interesting connection or message tranfer (according to Communications 101) has two ends! Improving things at one end should not harm the things at the other end, in terms of getting useful work done at both ends. The great (rude) question to ask is: "Do you want to get some work done, or do you just want to make a statement?" Cheers...\Stef Stef, You have it totally right. Bob Braden   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02089; 14 Apr 92 13:34 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa17038; 14 Apr 92 13:38 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa17018; 14 Apr 92 13:38 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA03207; Tue, 14 Apr 92 12:52:05 EDT Received: from transarc.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA03203; Tue, 14 Apr 92 12:52:02 EDT Received: by transarc.com (5.54/3.15) id for ietf-822@dimacs.rutgers.edu; Tue, 14 Apr 92 12:51:54 EDT Received: via switchmail; Tue, 14 Apr 1992 12:51:52 -0400 (EDT) Received: from apollo.transarc.com via qmail ID ; Tue, 14 Apr 1992 12:51:15 -0400 (EDT) Received: from apollo.transarc.com via qmail ID ; Tue, 14 Apr 1992 12:51:04 -0400 (EDT) Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.apollo.transarc.com.pmax.3 via MS.5.6.apollo.transarc.com.pmax_3; Tue, 14 Apr 1992 12:50:58 -0400 (EDT) Message-Id: <4dukpmf0BwwO4ZU0dC@transarc.com> Date: Tue, 14 Apr 1992 12:50:58 -0400 (EDT) From: Craig_Everhart@transarc.com To: ietf-822@dimacs.rutgers.edu, Nathaniel Borenstein Subject: Re: Implications of MIME for Transport In-Reply-To: <0dujoI_0M2YtQ27nkp@thumper.bellcore.com> References: <0dujoI_0M2YtQ27nkp@thumper.bellcore.com> Just a few notes as I go. First, the whole ack/nak stuff seems to be under discussion in the ietf-ack list and I'd hate to preempt it. I hate also to rely on communal wisdom rather than looking something up, but I will since this issue will be resolvable immediately by somebody. I recall that Mark Crispin had a major objection to some kinds of recursive embeddings. Would Nathaniel's proposed format for a message rejection create exactly that kind of recursive embedding? Nit: > In the above example, the ONLY thing that is not 'boilerplate" is the > choice of boundary string. The phrase "unique-boundary" should be > replaced by a string that does not appear (prefixed by CRLF and two > hyphens) in any of the body parts. Nope: the string may not appear ANYWHERE in any of the body parts. It is insufficient that it not appear prefixed by CRLF and two hyphens. Craig   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02363; 14 Apr 92 14:05 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa18457; 14 Apr 92 14:09 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa18424; 14 Apr 92 14:09 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA04530; Tue, 14 Apr 92 13:31:43 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA04526; Tue, 14 Apr 92 13:31:41 EDT Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Tue, 14 Apr 92 13:31:35 EDT Received: by greenbush.bellcore.com (4.1/4.7) id for Craig_Everhart@transarc.com; Tue, 14 Apr 92 13:31:33 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; Tue, 14 Apr 1992 13:31:30 -0400 (EDT) Message-Id: Date: Tue, 14 Apr 1992 13:31:30 -0400 (EDT) From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ietf-822@dimacs.rutgers.edu, Craig_Everhart@transarc.com Subject: Re: Implications of MIME for Transport In-Reply-To: <4dukpmf0BwwO4ZU0dC@transarc.com> References: <0dujoI_0M2YtQ27nkp@thumper.bellcore.com> <4dukpmf0BwwO4ZU0dC@transarc.com> Excerpts from mail: 14-Apr-92 Re: Implications of MIME fo.. Craig_Everhart@transarc. (884) > I recall that Mark > Crispin had a major objection to some kinds of recursive embeddings. > Would Nathaniel's proposed format for a message rejection create exactly > that kind of recursive embedding? No, because Mark's objections had to do with applying content-transfer-encodings recursively. In my model , there's no recursive encodings, and Mark objected to recursive encodings, not recursive embeddings, I believe. > Nit: > > In the above example, the ONLY thing that is not 'boilerplate" is the > > choice of boundary string. The phrase "unique-boundary" should be > > replaced by a string that does not appear (prefixed by CRLF and two > > hyphens) in any of the body parts. > Nope: the string may not appear ANYWHERE in any of the body parts. It > is insufficient that it not appear prefixed by CRLF and two hyphens. I don't understand why you think this is the case. I believe you're wrong here. What's the problem if the boundary appears without the leading "--"?   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02672; 14 Apr 92 14:35 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa19829; 14 Apr 92 14:38 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa19790; 14 Apr 92 14:38 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA04783; Tue, 14 Apr 92 14:10:39 EDT Received: from transarc.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA04779; Tue, 14 Apr 92 14:10:36 EDT Received: by transarc.com (5.54/3.15) id for ietf-822@dimacs.rutgers.edu; Tue, 14 Apr 92 14:10:24 EDT Received: via switchmail; Tue, 14 Apr 1992 14:10:23 -0400 (EDT) Received: from apollo.transarc.com via qmail ID ; Tue, 14 Apr 1992 14:10:08 -0400 (EDT) Received: from apollo.transarc.com via qmail ID ; Tue, 14 Apr 1992 14:09:55 -0400 (EDT) Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.apollo.transarc.com.pmax.3 via MS.5.6.apollo.transarc.com.pmax_3; Tue, 14 Apr 1992 14:09:49 -0400 (EDT) Message-Id: Date: Tue, 14 Apr 1992 14:09:50 -0400 (EDT) From: Craig_Everhart@transarc.com To: ietf-822@dimacs.rutgers.edu, Nathaniel Borenstein Subject: Re: Implications of MIME for Transport In-Reply-To: References: <0dujoI_0M2YtQ27nkp@thumper.bellcore.com> <4dukpmf0BwwO4ZU0dC@transarc.com> Thanks for the clarification on encodings vs. embeddings. Glad there's no problem. Excerpts from mail: 14-Apr-92 Re: Implications of MIME fo.. Nathaniel Borenstein@thu (1080*) > > Nit: > > > In the above example, the ONLY thing that is not 'boilerplate" is the > > > choice of boundary string. The phrase "unique-boundary" should be > > > replaced by a string that does not appear (prefixed by CRLF and two > > > hyphens) in any of the body parts. > > Nope: the string may not appear ANYWHERE in any of the body parts. It > > is insufficient that it not appear prefixed by CRLF and two hyphens. > I don't understand why you think this is the case. I believe you're > wrong here. What's the problem if the boundary appears without the > leading "--"? OK, sorry, I'm wrong; no problem if the boundary appears without the leading ``--''. But there's a problem even if it appears not prefixed by CRLF and ``--''. That is, the string, with its ``--'' prefix, may not appear anywhere in any of the body parts, irrespective of whether it appears after a CRLF. Craig   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02898; 14 Apr 92 15:04 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa21150; 14 Apr 92 15:08 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa21133; 14 Apr 92 15:08 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA05038; Tue, 14 Apr 92 14:58:48 EDT Received: from akbar.cac.washington.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA05034; Tue, 14 Apr 92 14:58:46 EDT Received: from tomobiki-cho.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.25 ) id AA15479; Tue, 14 Apr 92 11:58:36 -0700 Date: Tue, 14 Apr 1992 11:56:15 -0700 (PDT) From: Mark Crispin Subject: Re: Implications of MIME for Transport To: Craig_Everhart@transarc.com Cc: ietf-822@dimacs.rutgers.edu, Nathaniel Borenstein In-Reply-To: <4dukpmf0BwwO4ZU0dC@transarc.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Craig - My objection to recursive embeddings was an objection to recursive encoding; that is, encoding contents of type MESSAGE or MULTIPART instead of leap contents. The problem was that a program could not determine the message structure without a decoding step otherwise. I have no particular objection to encapsulation of messages in bounce messages, as long as the encapsulation does not use an encoding. -- Mark --   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa05235; 14 Apr 92 18:34 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa28104; 14 Apr 92 18:38 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa28087; 14 Apr 92 18:38 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA06207; Tue, 14 Apr 92 18:11:46 EDT Received: from ics.uci.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA06203; Tue, 14 Apr 92 18:11:43 EDT Received: from ics.uci.edu by q2.ics.uci.edu id aa02836; 14 Apr 92 11:57 PDT To: Craig_Everhart@transarc.com Cc: ietf-822@dimacs.rutgers.edu, Nathaniel Borenstein Subject: Re: Implications of MIME for Transport In-Reply-To: Tue, 14 Apr 92 12:50:58 EDT. <4dukpmf0BwwO4ZU0dC@transarc.com> Cc: stef@nma.com From: Einar Stefferud Reply-To: stef@nma.com Date: Tue, 14 Apr 92 11:57:50 -0700 Message-Id: <2833.703277870@ics.uci.edu> Sender: stef@ics.uci.edu Hello Craig -- I endorse your concern about preepting the ACK disucssion and work from ietf-ack. The issue is very complex and must be dealt with very carefully. There are very serious problems with the need for per recipient requests for ACKs of verious kinds, which appear to need carriage in what is now called the SMTP RCPT addresses. This is very difficult to do without changing someting in SMTP, or requiring modifications in fielded implementations of SMTP. We need to think about all this very carefully for a while. Haste is our enemy on this one. Best...\Stef   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa05507; 14 Apr 92 22:04 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa03285; 14 Apr 92 22:08 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa03268; 14 Apr 92 22:08 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA08598; Tue, 14 Apr 92 22:02:03 EDT Received: from ecovax.eco.twg.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA08594; Tue, 14 Apr 92 22:01:55 EDT Message-Id: <9204150201.AA08594@dimacs.rutgers.edu> Received: from apache.twg.com by ECOVAX.ECO.TWG.COM via Pony Express SMTP with TCP (v8.1.1-dmr001); Tue, 14 Apr 92 21:59:58-EDT Date: Tue, 14 Apr 1992 18:59:56 -0700 From: david@twg.com To: ietf-822@dimacs.rutgers.edu, ietf-ack@ics.uci.edu Subject: Re: Implications of MIME for Transport [IETF-ACK readers who do not read IETF-822, Nathaniel Borenstein posted a draft of an ``Executive Summary'' type document estolling the virtues of MIME. He asked for comments so I'm providing a few. They happen to overlap considerably with the IETF-ACK charter, sooo... -- David] ... > Rejected Messages > >An unfortunately frequent duty of message transport software is the >rejection of mail to the sender. This may happen because the mail was >undeliverable, or because it did not conform to the requirements of a >gateway (e.g. it was too large). > >There has never been a standard format for rejected messages in the >past. ... Weeelll... strictly speaking there *is* already a standard format for rejected messages. It is the "Delivery Report" format defined over in the X.400 series. Which, of course, means that the TCP/IP crowd is going to reject it out of hand because it's big, ugly, and from the (*&(* phone companies ;-) ;-) ;-). > It should be stressed that the transport software does not need to > understand the structure of the rejected message at all. It merely > needs to encapsulate it properly. Again, strictly speaking you are correct. We can continue on with the current situation of cryptic error messages coming back to users which require experts to decode them. If, instead, we define a standard format for delivery reports (which include negative delivery reports as a subset of the functionality) the users UA (if it's smart enough) can decode the information and present it nicely. There are other added side benefits like being able to tunnel IP packets ;-). Of course few people will tunnel IP packets with e-mail, but that indicates we can do other interesting applications -- IF delivery reports are in a standard parsable format. As a start I propose adopting the capabilities and features of the P1 and P2 delivery reports into RFC-land documents. We can represent those things using the format defined in RFC-1148, something which is already parsable &c. If there are capabilities we want to add beyond that.. fine, wonderful, fantastic. But use this already existing stuff as the basis, please. > Fragmenting and Reassembling Large Messages > > One problem that occurs with increasing frequency in Internet mail is > the rejection of messages because of size limitations. This problem can > be expected to grow substantially more severe with the acceptance of > MIME, as MIME invites the use of very large objects such as images and > audio clips. Fortunately, MIME also provides mechanisms that can help > alleviate the problem. ... > In particular, when gatewaying mail to or from a system or network known > to enforce size limitations that are more or less stringent than are > enforced locally, message transport software might choose either to > break a large message into fragments, or (perhaps less likely) to > reassemble fragments into a larger message. Yes automagic fragmentation and reassembly will be neato and keano. I would be surprised if a sending MTA were to be able to magically know that a destination MTA would have strict size limits. I believe that the only (or `best') way this information can travel from destination to sending MTA is as part of the protocol between the two MTA's. I believe the IETF-SMTP group is talking about adding a SIZE verb to SMTP, which would serve this purpose. The point is your words imply that the size limit is known ahead of time. David   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa05779; 15 Apr 92 1:35 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa07870; 15 Apr 92 1:38 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa07853; 15 Apr 92 1:38 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA09556; Wed, 15 Apr 92 01:35:33 EDT Received: from ppp.dbc.mtview.ca.us by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA09552; Wed, 15 Apr 92 01:35:28 EDT Received: from localhost (localhost.ARPA) by dbc.mtview.ca.us (4.1/3.1.090690) id AA29269; Tue, 14 Apr 92 22:34:33 PDT To: david@twg.com Cc: ietf-822@dimacs.rutgers.edu, ietf-ack@ics.uci.edu Reply-To: ietf-822@dimacs.rutgers.edu Subject: Re: Implications of MIME for Transport In-Reply-To: Your message of "Tue, 14 Apr 1992 18:59:56 PDT." <9204150201.AA08594@dimacs.rutgers.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 14 Apr 1992 22:34:31 -0700 Message-Id: <29268.703316071@dbc.mtview.ca.us> From: Marshall Rose Before we all go charging down the "let's steal from X.400" path, let's have a reality check. The most cryptic gibberish I've ever seen in an error report has come from mail that tried to get somewhere in an MHS network. Rather than taking the X.400 stuff and adding on to it, why don't we figure out what exactly works (not much), why it doesn't work (lotsa reasons), and then how we should do it right. My guess is that one can derive an acceptable minimal error report format that bears little relationship to the features you find in X.400 and yet will still have an order of magnitude more real usefullness. /mtr   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00443; 15 Apr 92 5:14 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa03810; 15 Apr 92 5:18 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa03590; 15 Apr 92 5:08 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA10849; Wed, 15 Apr 92 04:59:16 EDT Received: from bells.cs.ucl.ac.uk by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA10845; Wed, 15 Apr 92 04:59:12 EDT Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 15 Apr 1992 09:58:51 +0100 To: ietf-822@dimacs.rutgers.edu Cc: ietf-ack@ics.uci.edu Subject: Re: Implications of MIME for Transport Phone: +44-71-380-7294 In-Reply-To: Your message of Tue, 14 Apr 92 22:34:31 -0800. <29268.703316071@dbc.mtview.ca.us> Date: Wed, 15 Apr 92 09:57:45 +0100 Message-Id: <725.703328265@UK.AC.UCL.CS> From: Steve Hardcastle-Kille Marshall, Learning from history, good and bad, is clearly desirable. At this stage, reviewing X.400 approach is important. It is also important to carefully review requirements. Only when this analysis is done can an sensible choice be made. Almost any protocol in existence could be improved. Stability is desirable, and so changes are made as part of an overall balance of considerations (smetimes good decisions are made, and sometimes bad). Compatibility with X.400 is desirable. An incompatible solution should not be chosen for the sake of it. Neither is compatabiltiy an overriding consideration. I think that an analysis should be done, and then we should try to decide. My sense is that an X.400 compatible solution is appropriate and sensible. I'd be happy to work on 1148 to facilitate this. I think that X.400 holds (or can hold) the needed information. A lot of the 1148 cruft is there to prevent information being discarded. When used in conjunction with a sensible parser, the right information can easily be extracted and presented. Steve   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00957; 15 Apr 92 8:34 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa07431; 15 Apr 92 8:38 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa07412; 15 Apr 92 8:38 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA11353; Wed, 15 Apr 92 08:25:10 EDT Received: from charon.cwi.nl by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA11349; Wed, 15 Apr 92 08:25:00 EDT Received: from voorn.cwi.nl by charon.cwi.nl with SMTP id AA03166 (5.65b/2.10/CWI-Amsterdam); Wed, 15 Apr 1992 14:23:53 +0200 Received: by voorn.cwi.nl with SMTP; Wed, 15 Apr 1992 12:23:52 GMT Message-Id: <9204151223.AA25164@voorn.cwi.nl> To: ietf-822@dimacs.rutgers.edu Subject: Re: Implications of MIME for Transport In-Reply-To: Your message of "Tue, 14 Apr 1992 11:41:08 MDT." <0dujoI_0M2YtQ27nkp@thumper.bellcore.com> From: Guido van Rossum X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands X-Phone: +31 20 5924127 (work), +31 20 6225521 (home), +31 20 5924199 (fax) Date: Wed, 15 Apr 1992 14:23:50 +0200 Sender: Guido.van.Rossum@cwi.nl Nathaniel writes a sensible piece on what MTA's can do with the new MIME features, but then makes a big mistake: >When a message of type >image/gif is submitted for long-haul delivery, it might reasonably be >translated to image/jpeg. Conversely, when image/jpeg data is received >for final delivery on a system with adequate storage resources, it might >be translated to image/gif for the convenience of the recipient. >Software to perform these translations is widely available. WHAAAAAAT? JPEG is a "lossy" image format. I don't know what you usually do with images, maybe you just look at them for a second or two, but for some applications I would be very angry if the mail transport decided to turn a GIF image into JPEG, thereby dropping subtleties in the image that may be needed by my image processing software. >Although MIME currently only defines one audio format, more are likely >to be defined and registered with IANA in the future. In that case, >similar format conversion facilities might be appropriate for audio. Again, I'd be more than disappointed if a piece of CD quality audio that a friend prepared for me were turned into U-LAW by an MTA that had nothing better to do. Summary: CONVERSIONS THAT LOSE INFORMATION ARE A NO-NO FOR MTAS! --Guido van Rossum, CWI, Amsterdam "Oh Bevis! And I thought you were so rugged!"   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02392; 15 Apr 92 10:05 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa10153; 15 Apr 92 10:08 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa10133; 15 Apr 92 10:08 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA11640; Wed, 15 Apr 92 09:46:42 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA11636; Wed, 15 Apr 92 09:46:39 EDT Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Wed, 15 Apr 92 09:46:19 EDT Received: by greenbush.bellcore.com (4.1/4.7) id for Craig_Everhart@transarc.com; Wed, 15 Apr 92 09:46:18 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; Wed, 15 Apr 1992 09:46:13 -0400 (EDT) Message-Id: Date: Wed, 15 Apr 1992 09:46:13 -0400 (EDT) From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ietf-822@dimacs.rutgers.edu, Craig_Everhart@transarc.com Subject: Re: Implications of MIME for Transport In-Reply-To: References: <0dujoI_0M2YtQ27nkp@thumper.bellcore.com> <4dukpmf0BwwO4ZU0dC@transarc.com> Excerpts from mail: 14-Apr-92 Re: Implications of MIME fo.. Craig_Everhart@transarc. (1077) > OK, sorry, I'm wrong; no problem if the boundary appears without the > leading ``--''. But there's a problem even if it appears not prefixed > by CRLF and ``--''. That is, the string, with its ``--'' prefix, may > not appear anywhere in any of the body parts, irrespective of whether it > appears after a CRLF. Well, this is progress. As I read the grammar, however, the CRLF is also essential -- it is PART of the boundary, in the latest draft. Thus I believe that it would actually be OK (though not smart) to have the boundary appear somewhere not after a CRLF. (The only danger I can think of is if the line gets wrapped later -- is that what you were thinking of?)   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02838; 15 Apr 92 11:04 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa12830; 15 Apr 92 11:08 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa12792; 15 Apr 92 11:08 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA11930; Wed, 15 Apr 92 10:47:22 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA11926; Wed, 15 Apr 92 10:47:20 EDT Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Wed, 15 Apr 92 10:47:19 EDT Received: by greenbush.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Wed, 15 Apr 92 10:47:18 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; Wed, 15 Apr 1992 10:47:15 -0400 (EDT) Message-Id: Date: Wed, 15 Apr 1992 10:47:15 -0400 (EDT) From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ietf-822@dimacs.rutgers.edu Subject: Re: Implications of MIME for Transport In-Reply-To: <9204151223.AA25164@voorn.cwi.nl> References: <9204151223.AA25164@voorn.cwi.nl> Excerpts from internet.ietf-822: 15-Apr-92 Re: Implications of MIME fo.. Guido van Rossum@cwi.nl (1368) > Summary: CONVERSIONS THAT LOSE INFORMATION ARE A NO-NO FOR MTAS! Guido is right on the general principles here, but I think the specifics are more complicated. For example, JPEG encodings can tradeoff picture quality vs. bandwidth in a way that makes it at least plausible to think about reducing the size of gif images without enough loss of picture quality to bother most users. Moreover, we already know that it is within the bounds of reasonableness for MTAs to reject mail based on size. Now, if someone sends me a GIF image, and the MTA says its too big, I'd much rather get it as a lower-quality JPEG image than not get it at all, at least in most cases. So I think the bottom line is that this is not nearly as cut and dried as you imply. While I'd rather never lose information, I'd often rather lose a little information than all of it!   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02949; 15 Apr 92 11:34 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa13960; 15 Apr 92 11:38 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa13918; 15 Apr 92 11:38 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA12144; Wed, 15 Apr 92 11:10:43 EDT Received: from ppp.dbc.mtview.ca.us by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA12140; Wed, 15 Apr 92 11:10:38 EDT Received: from localhost (localhost.ARPA) by dbc.mtview.ca.us (4.1/3.1.090690) id AA03223; Wed, 15 Apr 92 08:10:01 PDT To: Steve Hardcastle-Kille Reply-To: ietf-822@dimacs.rutgers.edu Cc: ietf-822@dimacs.rutgers.edu, ietf-ack@ics.uci.edu Subject: Re: Implications of MIME for Transport In-Reply-To: Your message of "Wed, 15 Apr 1992 09:57:45 BST." <725.703328265@UK.AC.UCL.CS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 Apr 1992 08:09:59 -0700 Message-Id: <3222.703350599@dbc.mtview.ca.us> From: Marshall Rose I don't see why there is an apriori requirement to be compatible with X.400 error reports. A *lot* more people out there run Novell MHS. Perhaps we should be compatible with what they do as well. Heck, a lot of folks run ccmail, etc., etc. Perhaps we should be compatible with all of them... The best solution is to determine what approach satisifies the minimal set of requirements and is the least invasive. Compatibility with other systems is nice, but hardly a requirement for a successful solution. /mtr   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03317; 15 Apr 92 12:05 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa15143; 15 Apr 92 12:08 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa15124; 15 Apr 92 12:08 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA12150; Wed, 15 Apr 92 11:10:56 EDT Received: from transarc.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA12146; Wed, 15 Apr 92 11:10:53 EDT Received: by transarc.com (5.54/3.15) id for ietf-822@dimacs.rutgers.edu; Wed, 15 Apr 92 11:10:40 EDT Received: via switchmail; Wed, 15 Apr 1992 11:10:38 -0400 (EDT) Received: from apollo.transarc.com via qmail ID ; Wed, 15 Apr 1992 11:08:34 -0400 (EDT) Received: from apollo.transarc.com via qmail ID ; Wed, 15 Apr 1992 11:08:26 -0400 (EDT) Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.apollo.transarc.com.pmax.3 via MS.5.6.apollo.transarc.com.pmax_3; Wed, 15 Apr 1992 11:08:22 -0400 (EDT) Message-Id: Date: Wed, 15 Apr 1992 11:08:22 -0400 (EDT) From: Craig_Everhart@transarc.com To: ietf-822@dimacs.rutgers.edu, Nathaniel Borenstein Subject: Re: Implications of MIME for Transport In-Reply-To: References: <0dujoI_0M2YtQ27nkp@thumper.bellcore.com> <4dukpmf0BwwO4ZU0dC@transarc.com> Excerpts from mail: 15-Apr-92 Re: Implications of MIME fo.. Nathaniel Borenstein@thu (771*) > Well, this is progress. As I read the grammar, however, the CRLF is > also essential -- it is PART of the boundary, in the latest draft. Thus > I believe that it would actually be OK (though not smart) to have the > boundary appear somewhere not after a CRLF. (The only danger I can > think of is if the line gets wrapped later -- is that what you were > thinking of?) Yes, that's what I was thinking of. You've rediscovered the danger that we discussed a year ago or more--that MTA-induced line wraps can make text appear at the beginning of the line to the recipient where it wasn't at the beginning of the line to the sender. Thus, the string that must not appear anywhere is ``--newBoundaryText'', not ``--newBoundaryText''. Craig   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03448; 15 Apr 92 12:34 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa16127; 15 Apr 92 12:38 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa16104; 15 Apr 92 12:38 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA12382; Wed, 15 Apr 92 12:04:31 EDT Received: from charon.cwi.nl by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA12378; Wed, 15 Apr 92 12:04:28 EDT Received: from voorn.cwi.nl by charon.cwi.nl with SMTP id AA08428 (5.65b/2.10/CWI-Amsterdam); Wed, 15 Apr 1992 18:04:26 +0200 Received: by voorn.cwi.nl with SMTP; Wed, 15 Apr 1992 16:04:26 GMT Message-Id: <9204151604.AA25885@voorn.cwi.nl> To: Nathaniel Borenstein Cc: ietf-822@dimacs.rutgers.edu Subject: Re: Implications of MIME for Transport In-Reply-To: Your message of "Wed, 15 Apr 1992 10:47:15 MDT." From: Guido van Rossum X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands X-Phone: +31 20 5924127 (work), +31 20 6225521 (home), +31 20 5924199 (fax) Date: Wed, 15 Apr 1992 18:04:24 +0200 Sender: Guido.van.Rossum@cwi.nl I wrote: >> Summary: CONVERSIONS THAT LOSE INFORMATION ARE A NO-NO FOR MTAS! Nathaniel writes: >Moreover, we already know that it is within the bounds of reasonableness >for MTAs to reject mail based on size. Now, if someone sends me a GIF >image, and the MTA says its too big, I'd much rather get it as a >lower-quality JPEG image than not get it at all, at least in most cases. Suppose that in a particular case, any loss of information is absolutely intolerable. How do I know that an image I'm receiving hasn't secretly been converted to JPEG and back to GIF by conspiring MTAs? Is there a way for the sender to specify that this is not an acceptable step (e.g. to say that he'd much rather fragment the data himself if the MTA won't do that)? BTW, I think that the issue of convenience of GIF vs. JPEG for users is a red herring -- soon enough, JPEG will be as widely supported as GIF (it sells itself quite well through its lesser disk space requirements). E.g., there is already a version of "xv" that understands JPEG. --Guido van Rossum, CWI, Amsterdam "Exploding is a perfectly normal medical phenomenon."   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03564; 15 Apr 92 13:04 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa17046; 15 Apr 92 13:08 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa17029; 15 Apr 92 13:08 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA12464; Wed, 15 Apr 92 12:24:12 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA12460; Wed, 15 Apr 92 12:24:10 EDT Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Wed, 15 Apr 92 12:24:09 EDT Received: by greenbush.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Wed, 15 Apr 92 12:24:09 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; Wed, 15 Apr 1992 12:24:06 -0400 (EDT) Message-Id: <0dv5WaK0M2YtF4Phxh@thumper.bellcore.com> Date: Wed, 15 Apr 1992 12:24:06 -0400 (EDT) From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: Guido van Rossum Subject: Re: Implications of MIME for Transport Cc: ietf-822@dimacs.rutgers.edu In-Reply-To: <9204151604.AA25885@voorn.cwi.nl> References: <9204151604.AA25885@voorn.cwi.nl> Excerpts from mail: 15-Apr-92 Re: Implications of MIME fo.. Guido van Rossum@cwi.nl (1140) > Suppose that in a particular case, any loss of information is > absolutely intolerable. How do I know that an image I'm receiving > hasn't secretly been converted to JPEG and back to GIF by conspiring > MTAs? Is there a way for the sender to specify that this is not an > acceptable step (e.g. to say that he'd much rather fragment the data > himself if the MTA won't do that)? This would suggest that, at a minimum, some sort of trace headers should be included, no? > BTW, I think that the issue of convenience of GIF vs. JPEG for users > is a red herring -- soon enough, JPEG will be as widely supported as > GIF (it sells itself quite well through its lesser disk space > requirements). E.g., there is already a version of "xv" that > understands JPEG. Well, JPEG really does have a lot more computational requirements -- xv displays a GIF image an order of magnitude faster than a JPEG one, for example. And your own point about the often-superior quality of GIF images is well taken. I'm not convinced that GIF will go away completely any time soon. But that's just one opinion... -- Nathaniel   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03780; 15 Apr 92 13:34 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa18144; 15 Apr 92 13:38 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa18123; 15 Apr 92 13:38 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA13793; Wed, 15 Apr 92 13:04:42 EDT Received: from bells.cs.ucl.ac.uk by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA13789; Wed, 15 Apr 92 13:04:38 EDT Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 15 Apr 1992 18:04:27 +0100 To: ietf-822@dimacs.rutgers.edu Cc: ietf-ack@ics.uci.edu Subject: Re: Implications of MIME for Transport Phone: +44-71-380-7294 In-Reply-To: Your message of Wed, 15 Apr 92 08:09:59 -0800. <3222.703350599@dbc.mtview.ca.us> Date: Wed, 15 Apr 92 18:03:20 +0100 Message-Id: <1621.703357400@UK.AC.UCL.CS> From: Steve Hardcastle-Kille I did NOT say that there was a requirement. I clearly said the opposite. I did say that it was desirable. Compatibility with existing things usually has some meausre of desirability. How desirable depends on your perspective. Steve   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa04029; 15 Apr 92 14:05 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa19159; 15 Apr 92 14:08 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa19140; 15 Apr 92 14:08 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA13856; Wed, 15 Apr 92 13:24:13 EDT Received: from eco.twg.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA13852; Wed, 15 Apr 92 13:24:09 EDT Received: from LOCAL.eco.twg.com by eco.twg.com (5.65/ECO.m-$Revision: 2.15 $) id AA12248; Wed, 15 Apr 92 13:24:03 -0400 Message-Id: <9204151724.AA12248@eco.twg.com> Organization: The Wollongong Group, Inc., East Coast Operations Address: 2010 Corporate Ridge Drive, Suite 550, McLean, VA 22102 Phone: 703-847-4500 (Voice); 703-847-4520 (Fax) Date: Wed, 15 Apr 1992 10:24:00 -0700 From: david@twg.com To: ietf-822@dimacs.rutgers.edu, ietf-ack@ics.uci.edu Subject: Re: Implications of MIME for Transport > I don't see why there is an apriori requirement to be compatible with > X.400 error reports. A *lot* more people out there run Novell MHS. ... > The best solution is to determine what approach satisifies the minimal > set of requirements and is the least invasive. Compatibility with other > systems is nice, but hardly a requirement for a successful solution. Well, OK. Perhaps so. The reason I brought up the existing definitions in 1148 is because they *exist* now. That is, there's already a wheel shaped object (it might, however, be a bit oblong... which is the nature of the OSI beast) so why work on reinventing one? The simplest path, IMO, is to adopt the existing stuff. I haven't studied what the requirements are and whether this path is terribly invasive, etc etc etc. You might well be right, or you might be overreacting. Either way it is worth some study. Which, of course, the IETF-ACK group has done ... David   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa04373; 15 Apr 92 14:34 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa20240; 15 Apr 92 14:38 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa20219; 15 Apr 92 14:38 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA13832; Wed, 15 Apr 92 13:15:04 EDT Received: from eco.twg.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA13826; Wed, 15 Apr 92 13:14:59 EDT Received: from LOCAL.eco.twg.com by eco.twg.com (5.65/ECO.m-$Revision: 2.15 $) id AA12164; Wed, 15 Apr 92 13:14:50 -0400 Message-Id: <9204151714.AA12164@eco.twg.com> Organization: The Wollongong Group, Inc., East Coast Operations Address: 2010 Corporate Ridge Drive, Suite 550, McLean, VA 22102 Phone: 703-847-4500 (Voice); 703-847-4520 (Fax) Date: Wed, 15 Apr 1992 10:14:28 -0700 From: david@twg.com To: ietf-822@dimacs.rutgers.edu Subject: Re: Implications of MIME for Transport [Since the focus of ietf-822 is on UA-UA issues perhaps there should be another group formed on MTA-MTA issues? ;-) ;-)] > Excerpts from internet.ietf-822: 15-Apr-92 Re: Implications of MIME fo.. > Guido van Rossum@cwi.nl (1368) > > > Summary: CONVERSIONS THAT LOSE INFORMATION ARE A NO-NO FOR MTAS! ... > Moreover, we already know that it is within the bounds of reasonableness > for MTAs to reject mail based on size. Now, if someone sends me a GIF > image, and the MTA says its too big, I'd much rather get it as a > lower-quality JPEG image than not get it at all, at least in most cases. > So I think the bottom line is that this is not nearly as cut and dried > as you imply. While I'd rather never lose information, I'd often rather > lose a little information than all of it! Both Nathaniel's and Guido's statements are reasonable points of view. There are times when loss is acceptible and times when it isn't. I doubt that Guido uses FAX machines for transporting pictures needing image analysis. On the other hand the people who avidly collect alt.sex.pictures GIF's probably wouldn't care if it became a bit fuzzier. So, how to serve both parties? If you take Guido's stance then bandwidth will be wasted, but every last pixel of the sex scene will make it through unmolested. If you take Nathaniel's stance then the NASA people (and others) who need to find volcano's on jupiter will be unable to do so. There certainly isn't any automagic way to determine the senders desire with facilities we have at hand. You couldn't, for instance, look at the contents or at the source & destination addresses to determine what purpose the bits will be put to. So you give the user a way to declare their desire. For instance the X.400 protocol contains three flags in P1 named IMPLICIT-CONVERSION-PROHIBITED EXPLICIT-CONVERSION-PROHIBITED CONVERSION-WITH-LOSS-PROHIBITED This by itself satisfies most or all the concerns above. It might be nice to have a flag which allows differing levels of loss on a conversion. But how to describe that, etc? We can leave that for `later' .. Where to carry this flag and what to do with it at gateways and such? But the discussion starts to get out of my depth and into issues of `style' as applies to protocol specification. I'll just note that 1148 specifies carrying these particular while X.400/P1 specifies carrying them in an envelope which is somewhat equivalent to the data carried in the SMTP conversation. It'd be nice to expand the amount of information which SMTP carries, but that's a job for the other WG. There is potential for abuse with this. That is, the alt.sex.pictures people might learn to always set the LOSS-PROHIBITED flag and the researchers might forget to set it. But at least control is in the hands of the sender ... David   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa04681; 15 Apr 92 15:05 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa21363; 15 Apr 92 15:09 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa21339; 15 Apr 92 15:08 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA13995; Wed, 15 Apr 92 13:45:33 EDT Received: from binky.arc.nasa.gov by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA13991; Wed, 15 Apr 92 13:45:30 EDT Received: from localhost.arc.nasa.gov by binky.arc.nasa.gov (4.1/1.34) id AA28416; Wed, 15 Apr 92 10:45:07 PDT Message-Id: <9204151745.AA28416@binky.arc.nasa.gov> To: Nathaniel Borenstein Cc: ietf-822@dimacs.rutgers.edu Subject: Re: Implications of MIME for Transport In-Reply-To: Your message of "Wed, 15 Apr 92 10:47:15 EDT." Date: Wed, 15 Apr 92 10:45:07 MDT From: jknowles@binky.arc.nasa.gov > Excerpts from internet.ietf-822: 15-Apr-92 Re: Implications of MIME fo.. > Guido van Rossum@cwi.nl (1368) > > > Summary: CONVERSIONS THAT LOSE INFORMATION ARE A NO-NO FOR MTAS! > > Guido is right on the general principles here, but I think the specifics > are more complicated. For example, JPEG encodings can tradeoff picture > quality vs. bandwidth in a way that makes it at least plausible to think > about reducing the size of gif images without enough loss of picture > quality to bother most users. I would really rather not have any MTA making this decision, especially since we are talking about intangibles such as "enough..quality to bother most". This is a UA level decision, IMHO. > Moreover, we already know that it is within the bounds of reasonableness > for MTAs to reject mail based on size. Now, if someone sends me a GIF > image, and the MTA says its too big, I'd much rather get it as a > lower-quality JPEG image than not get it at all, at least in most cases. > So I think the bottom line is that this is not nearly as cut and dried > as you imply. While I'd rather never lose information, I'd often rather > lose a little information than all of it! > You and I may agree that a JPEG (with appropriate parameters) version of the original is appropriate. We can negotiate and resend, etc. I don't see this sort of interaction with the MTA. If specific agreements between UA's and MTA's exist, I suppose that's alright. But I think the authority must not reside at the MTA level. The solution I'd prefer is to use message/partial and keep all the information intact. Although this has a drawback if the receiving side isn't MIME aware, this still seems to me to be a more reasonable attempt at delivery than a possibly unauthorized conversion. Jim   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa05119; 15 Apr 92 15:35 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa22850; 15 Apr 92 15:38 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa22813; 15 Apr 92 15:38 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA14185; Wed, 15 Apr 92 14:21:11 EDT Received: from ics.uci.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA14181; Wed, 15 Apr 92 14:21:09 EDT Received: from ics.uci.edu by q2.ics.uci.edu id aa29018; 15 Apr 92 10:56 PDT To: david@twg.com Cc: ietf-822@dimacs.rutgers.edu, ietf-ack@ics.uci.edu Subject: Re: Implications of MIME for Transport In-Reply-To: Wed, 15 Apr 92 10:24:00 PDT. <9204151724.AA12248@eco.twg.com> Cc: stef@nma.com From: Einar Stefferud Reply-To: stef@nma.com Date: Wed, 15 Apr 92 10:55:58 -0700 Message-Id: <29009.703360558@ics.uci.edu> Sender: stef@ics.uci.edu We are faced with the great question of whether the IETF-ACK work should be moved back into IETF-822, or left where it is, with those who want to work on it moving (or just staying) there. I suspect that a lot of ietf-822 folks are really not much interrested, but I will not try to judge this. I just think we should decide and stop using two lists for the disucssion. One question: Are we discussing just ACK, or something larger? This is a factor in deciding what to do. From the meta-level view, I must say that we are still badly bogged down in confusion about the MUA/MTA relationship. Thsi whole idea of arbitrary MTA conversion between GIF and JPEG because of some decision logic imbedded in some random RELAY-MTA just boggles my mind. Suppose the US Postal Service (or The Royal Mail) descided that the bulk of paper was too great in some random package, and converted it to microfiche for its own convenience! And suppose it was the Dead Sea Scolls! Waht rubbish is this iead that any MTA might be intelligent enough to make any such decision with out MUA autority! HOGWASH! We need to get it straight once and for all in this discussion as to waht is legit for an Abstract MTA to do, and what is not. Then we can argue about the rules. Until we do this, we are just churning butter. Cheers...\Stef   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa05276; 15 Apr 92 15:44 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa23204; 15 Apr 92 15:48 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa23186; 15 Apr 92 15:48 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA14142; Wed, 15 Apr 92 14:10:18 EDT Received: from ics.uci.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA14138; Wed, 15 Apr 92 14:10:15 EDT Received: from ics.uci.edu by q2.ics.uci.edu id aa28000; 15 Apr 92 10:41 PDT To: ietf-822@dimacs.rutgers.edu, ietf-ack@ics.uci.edu Subject: Re: Implications of MIME for Transport In-Reply-To: Wed, 15 Apr 92 18:03:20 BST. <1621.703357400@UK.AC.UCL.CS> Cc: stef@nma.com From: Einar Stefferud Reply-To: stef@nma.com Date: Wed, 15 Apr 92 10:41:45 -0700 Message-Id: <27997.703359705@ics.uci.edu> Sender: stef@ics.uci.edu Steve, Marshall, et al -- It should be clear to us all that choosing something this is arbitrarily incompatible is stupid! This goes for INTERNET vs {X.400, MSMAIL, cc:MAIL, Novell MHS, DaVinci, etc, ad nauseum}. Our analysis has to look at what all installed base systems do in order to see what we can do to match up with them to some desired degree of interworkability. In doing this, we need to also decide some things about exactly what semantics we assign to things like "delivery" and "receipt" so that our notifications will be consistently meaningful in all cases. I suggest that we start with the discussion of what we want these things to mean, regardless of how some existing implementation might happen to define them now. In this regard, it is my opinion that X.400 has correctly defined the semantics of these terms. This opinion has nothing to do with what X.400 has done with its notification PDU definitions, or what RFC1148ter has done with the mapping from X.400 Notification specifications to RFC822 body text. Whatever RFC1148ter did, it was dealing with the total lack of any defined notification format or semantics on the RFC822 side. We are now approaching an effort to define the RFC822 side, so we need to rethink the whole RFC1148ter specification of this stuff. But first, we have the task of discovering what the existing installed base does and then deciding what semantics we wish to standardize, and then decide how to represent the chosen semantics in RFC821/822 syntax. In doing this, we must develop an INTERNET abstract model of the MUA/MTA relationship and functionality, or we will find ourselves engaged in endless arguments about this whole thing. Perhaps this is a first prerequisite while we are doing the investigation of how the installed base does what it does. I am very much concerned here that we (in the INTERNET) not adopt the OSI attitude toward the installed base. It is in our own best interests to find ways to maximize interworking with the installed base (including that which is not inside our current IP INTERNET). As I have said with some frequency, every interesting connection has two ends, and it does not matter where they are. What we are trying to do is to maximize the number of interesting potential connections. Cheers...\Stef   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa05785; 15 Apr 92 16:50 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa25387; 15 Apr 92 16:54 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa25352; 15 Apr 92 16:53 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA14620; Wed, 15 Apr 92 15:11:36 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA14616; Wed, 15 Apr 92 15:11:34 EDT Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Wed, 15 Apr 92 15:11:29 EDT Received: by greenbush.bellcore.com (4.1/4.7) id for ietf-ack@ics.uci.edu; Wed, 15 Apr 92 15:11:28 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; Wed, 15 Apr 1992 15:11:25 -0400 (EDT) Message-Id: Date: Wed, 15 Apr 1992 15:11:25 -0400 (EDT) From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: david@twg.com Subject: Re: Implications of MIME for Transport Cc: ietf-822@dimacs.rutgers.edu, ietf-ack@ics.uci.edu In-Reply-To: <29009.703360558@ics.uci.edu> References: <29009.703360558@ics.uci.edu> Excerpts from internet.ietf-822: 15-Apr-92 Re: Implications of MIME fo.. Einar Stefferud@nma.com (1338) > Suppose the US Postal Service (or The Royal Mail) descided that > the bulk of paper was too great in some random package, and converted it > to microfiche for its own convenience! And suppose it was the Dead Sea Scolls! Again, this is a phony argument in the absence of an alternative. What if the previous behavior of the postal service was to throw away such large packages? That means that the new behavior is an improvement -- in the old behavior, you threw the Dead Sea Scrolls into a landfill. In the new behavior, you at least copy them to microfiche before composting them. Personally, I think that's an improvement, however distasteful. Jim Morris offers some real words of wisdom for times like these: "The Best is the Enemy of the Good." It would be a real shame to shoot down a scheme that is a substantial improvement on today's reality in the name of something that's even better, but might not really get implemented in the sites that need it most. -- Nathaniel   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa05920; 15 Apr 92 17:37 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa27179; 15 Apr 92 17:40 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa27161; 15 Apr 92 17:40 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA15077; Wed, 15 Apr 92 16:23:13 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA15073; Wed, 15 Apr 92 16:23:11 EDT Received: from INFOODS.MIT.EDU by INFOODS.MIT.EDU (PMDF #12913) id <01GIVSAMT1QO0005LG@INFOODS.MIT.EDU>; Wed, 15 Apr 1992 16:22 EDT Date: Wed, 15 Apr 1992 16:22:45 -0400 (EDT) From: John C Klensin Subject: Transport and MIME, MIME and transport To: ietf-822@dimacs.rutgers.edu Message-Id: <703369365.575231.KLENSIN@INFOODS.MIT.EDU> X-Envelope-To: ietf-822@dimacs.rutgers.edu Mail-System-Version: I've been trying to ignore this discussion for a while. I hope to return to that stance soon, but a few observations: (1) As David has pointed out, there is a MTA-MTA WG. I don't especially want to see this discussion there, but, as soon as things turn to "if only MTAs did things differently, I'd suggest that the charter of this WG is being pushed very hard in the direction of that one. (2) There are installations who are getting very concerned about the maximum cumulative amount of message someone can receive in a given amount of time. For some parts of the extended mail internet, huge logical messages provide avenues for denial-of-service attacks as well as for forcing receivers to pay for being sent trash (sort of the equivalent of junk fax, given the cost of keeping most fax machines in paper). Now the opportunity for this sort of thing has alwyas been there, but MIME creates a much greater opportunity to have it happen by accident. Curiously, if large messages are sent as a single chunk, servers have ways to defend themselves by rejecting such tings. The proposed SIZE verb may make the rejection process more efficient, but doesn't change the possbility. But there is no defense that I'm aware of, at least in transport, against being flooded by huge objects that are automatically disassembled into message/partial by a sending system. Please think about this folks: not everyone has fixed cost, large-fraction-of-a-megabaud-of-better connections to machines with lots of free disk space. (3) The SMTP-EX group spent a lot of time worrying about the issue of conversion and who/what gets to authorize it. I'd encourage people to go back and look at that stuff, since the same ground seems to be able to be traversed again. --john   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa06163; 15 Apr 92 18:04 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa27936; 15 Apr 92 18:08 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa27919; 15 Apr 92 18:08 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA15099; Wed, 15 Apr 92 16:26:56 EDT Received: from relay1.UU.NET by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA15095; Wed, 15 Apr 92 16:26:54 EDT Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA00157; Wed, 15 Apr 92 16:26:49 -0400 Received: from slcpi.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 162442.12196; Wed, 15 Apr 1992 16:24:42 EDT Received: from tardis.shearson.com by shearson.com (4.1/LB-0.3) id AA09992; Wed, 15 Apr 92 15:06:28 EDT Received: from lorax.shearson.com by tardis.shearson.com (4.0/SMI-4.1) id AA15527; Wed, 15 Apr 92 15:06:27 EDT Date: Wed, 15 Apr 92 15:06:27 EDT From: Rens Troost Message-Id: <9204151906.AA15527@tardis.shearson.com> Received: by lorax.shearson.com (4.1/SMI-4.1) id AA04910; Wed, 15 Apr 92 15:06:25 EDT To: nsb@thumper.bellcore.com Cc: ietf-822@dimacs.rutgers.edu Subject: Re: Implications of MIME for Transport References: <9204151223.AA25164@voorn.cwi.nl> Hi- In your message, you said: > Guido is right on the general principles here, but I think the specifics > are more complicated. For example, JPEG encodings can tradeoff picture > quality vs. bandwidth in a way that makes it at least plausible to think > about reducing the size of gif images without enough loss of picture > quality to bother most users. Perhaps, but certainly there should be way to override this behavior. Since we are talking about gateway mechanisms, you must be careful that you don't impose on ALL users what might be acceptable to most users! > Moreover, we already know that it is within the bounds of reasonableness > for MTAs to reject mail based on size. Now, if someone sends me a GIF > image, and the MTA says its too big, I'd much rather get it as a > lower-quality JPEG image than not get it at all, at least in most cases. > So I think the bottom line is that this is not nearly as cut and dried > as you imply. While I'd rather never lose information, I'd often rather > lose a little information than all of it! Perhaps <> header "Content-Dont-Munge:" :) -Rens -- ,__________________________________________________________. |\/////////| |//////////| |\\////////| Rens Troost |/////////\| |\\\///////| Lehman Brothers Technical Services |////////\\| |\\\\//////| 388 Greenwich Street, 11th Floor |///////\\\| |\\\\\/////| New York, New York 10013 |//////\\\\| |\\\\\\////| VOICE: (212) 464-3705 |/////\\\\\| |\\\\\\\///| FAX: (212) 464-3776 |////\\\\\\| |\\\\\\\\//| ARPA: rens@shearson.com |///\\\\\\\| |\\\\\\\\\/| UUCP: uunet!shearson.com!rens |//\\\\\\\\| |\\\\\\\\\\| |/\\\\\\\\\| `----------------------------------------------------------'   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa06382; 15 Apr 92 18:34 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa28927; 15 Apr 92 18:38 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa28905; 15 Apr 92 18:38 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA15397; Wed, 15 Apr 92 17:11:13 EDT Received: from mp.cs.niu.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA15393; Wed, 15 Apr 92 17:11:10 EDT Received: by mp.cs.niu.edu with SMTP id AA32025 (5.65c/IDA-1.5 for ); Wed, 15 Apr 1992 16:11:07 -0500 To: ietf-822@dimacs.rutgers.edu Subject: Acknowledgements. (was Implications of MIME for Transport) Newsgroups: info.ietf.smtp References: <3222.703350599@dbc.mtview.ca.us> <27997.703359705@ics.uci.edu> Organization: Northern Illinois University Date: Wed, 15 Apr 92 16:11:06 -0500 Message-Id: <19731.703372266@mp.cs.niu.edu> From: Neil W Rickert In article <27997.703359705@ics.uci.edu> stef@nma.com (Einar Stefferud) writes: > >In doing this, we need to also decide some things about exactly what >semantics we assign to things like "delivery" and "receipt" so that our >notifications will be consistently meaningful in all cases. > >I suggest that we start with the discussion of what we want these things >to mean, regardless of how some existing implementation might happen to >define them now. You can spend as much time as you like arguing about the semantics of "delivery" and "receipt". But, no matter how much time you spend, you will never escape from the problem that one person's "delivery" is another person's "transport". Nor will you ever escape from the problem that, as soon as you think you are approaching the "truth" the technology will make a sudden change and everything will need reinterpretation. Forget about all the semantic and definitional nonsense, and just do something that is reasonably easy to implement and is somewhat useful. (I think this means I am supporting Marshall Rose's comments). -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa06409; 15 Apr 92 18:38 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa29064; 15 Apr 92 18:42 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa29047; 15 Apr 92 18:42 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA14556; Wed, 15 Apr 92 15:05:23 EDT Received: from eitech.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA14552; Wed, 15 Apr 92 15:05:21 EDT Received: from hewey.eitech.com.eitech.com by eitech.com (4.1/SMI-4.1) id AA05788; Wed, 15 Apr 92 11:59:41 PDT Date: Wed, 15 Apr 92 11:59:41 PDT From: "Jay C. Weber" Message-Id: <9204151859.AA05788@eitech.com> Received: by hewey.eitech.com.eitech.com (4.1/SMI-4.1) id AA29132; Wed, 15 Apr 92 12:00:45 PDT Mime-Version: 1.0 To: ietf-822@dimacs.rutgers.edu Subject: multipart partial messages Content-Type: text/richtext Content-Transfer-Encoding: quoted-printable Here's a question that came up while hacking a MIME reader: what is the semantics of a message/partial embedded in a multipart? It doesn't appear to be prohibited, but since message assembly is supposed to be transparent, does it make any sense? Jay Weber Enterprise Integration Technologies   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa06425; 15 Apr 92 18:39 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa29101; 15 Apr 92 18:43 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa29084; 15 Apr 92 18:43 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA15546; Wed, 15 Apr 92 17:37:36 EDT Received: from CBROWN.CLAREMONT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA15542; Wed, 15 Apr 92 17:37:34 EDT Received: from HMCVAX.CLAREMONT.EDU by HMCVAX.CLAREMONT.EDU (PMDF #11000) id <01GIVOLTWFHU9BVCNP@HMCVAX.CLAREMONT.EDU>; Wed, 15 Apr 1992 14:37 PST Date: Wed, 15 Apr 1992 14:37 PST From: "Ned Freed, Postmaster" Subject: Re: multipart partial messages To: weber@eitech.com Cc: ietf-822@dimacs.rutgers.edu Message-Id: <01GIVOLTWFHU9BVCNP@HMCVAX.CLAREMONT.EDU> X-Vms-To: IN%"weber@eitech.com" X-Vms-Cc: IN%"ietf-822@dimacs.rutgers.edu" I don't think an embedded message/partial has any special semantics at all. I can see one way that they could arise very easily -- an automatic digestifier, when fed an incomplete series of message/partial message, might well produce such a thing. The whole idea of message/partial is that the pieces are tagged in a globally unique way. This means that they should reassemble regardless of where they appear in a hierarchy. However, I suspect that most reassembly agents won't bother to deal with imbedded message/partial objects. I know my code sure doesn't; you'd have to explode and redeliver the parts to get the thing to reassemble. Ned   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa06708; 15 Apr 92 19:05 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa29919; 15 Apr 92 19:08 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa29902; 15 Apr 92 19:08 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA15581; Wed, 15 Apr 92 17:43:50 EDT Received: from alpha.Xerox.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA15577; Wed, 15 Apr 92 17:43:49 EDT Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11868>; Wed, 15 Apr 1992 14:43:31 PDT Received: by holmes.parc.xerox.com id <25544>; Wed, 15 Apr 1992 14:43:29 -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; Wed, 15 Apr 1992 14:43:14 -0700 (PDT) Message-Id: Date: Wed, 15 Apr 1992 14:43:14 PDT Sender: Bill Janssen From: Bill Janssen To: ietf-822@dimacs.rutgers.edu Subject: Allowable-Degradation-Percentage header In-Reply-To: References: <9204151223.AA25164@voorn.cwi.nl> Excerpts from ext.ietf-822: 15-Apr-92 Re: Implications of MIME fo.. Nathaniel Borenstein@thu (961*) > Excerpts from internet.ietf-822: 15-Apr-92 Re: Implications of MIME fo.. > Guido van Rossum@cwi.nl (1368) > > Summary: CONVERSIONS THAT LOSE INFORMATION ARE A NO-NO FOR MTAS! > Guido is right on the general principles here, but I think the specifics > are more complicated. [...] > Moreover, we already know that it is within the bounds of reasonableness > for MTAs to reject mail based on size. Now, if someone sends me a GIF > image, and the MTA says its too big, I'd much rather get it as a > lower-quality JPEG image than not get it at all, at least in most cases. This goes back to a discussion we had a year ago: What is the sender's intent? Why is an image being sent? Nathaniel is distinguishing between two cases, one in which we want to transmit the general form of the image (every pixel is not significant), and one in which we need the exact image. Similar cases can be imagined in the transmission of formatted text documents; there are clearly cases in which every comma and linebreak is important, and other cases in which they are not. Clearly (:-) a new header is needed: "Allowable-Degradation-Percentage", that will enable the MTA to make decisions about whether to attempt format conversion. Bill   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa06819; 15 Apr 92 19:34 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa00705; 15 Apr 92 19:38 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa00683; 15 Apr 92 19:37 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA15034; Wed, 15 Apr 92 16:09:55 EDT Received: from ics.uci.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA15030; Wed, 15 Apr 92 16:09:53 EDT Received: from ics.uci.edu by q2.ics.uci.edu id aa10095; 15 Apr 92 12:51 PDT To: ietf-822@dimacs.rutgers.edu, ietf-ack@ics.uci.edu Subject: Re: Implications of MIME for Transport In-Reply-To: Wed, 15 Apr 92 15:11:25 EDT. Cc: stef@nma.com From: Einar Stefferud Reply-To: stef@nma./com Date: Wed, 15 Apr 92 12:51:29 -0700 Message-Id: <10090.703367489@ics.uci.edu> Sender: stef@ics.uci.edu There is a great danger in setting up to honor the good, art the expense of the best in certain very interesting cases. As always, one cannot apply such sikple rules as "Avoid the best in the interests of the good!" Take for Special Delivery as it once existed in the US Postal Service. It turns out that suddenly on e year (about 1975) the USPS would no longer leave a special Delivery envelope at a residence if there was no one there to personally take possession of it. Special Delivery had signature required" rule, and no accounting for receipt, but suddenly, if I was not home to receive it, the envelope was taken back to the post office and I was left a notice to go there to pick it up. Worse yet, since it was Special Delivery, it was not my local office, but one much farther away, because they used special post office stations to handle all Special Delivery mail. When I enquired about s degradation in service, I was told that the problem was with many illegal aliens using special delivery in place of registered mail, so they were now treating Special Delivery as though it was Registered Mail, and would no longer leave it in a residential mailbox. The problem is that quality of certainty of delivery went up, but the variance on time of delivery went to hell. The USPS apparently was not aware that the special value of Special Delivery was "FAST DELIVERY". Special Delivery service was thus destroyed, and it is now useless, and not used. By analogy, it is my position that if we allow any random MTA to decide to "downgrade" the quality of the content of a message without explicit permission from the SENDER's or the RECIPIENT~s UA Authority, then we have created a monster and will destroy the value of sending anything of value via netmail, precisely because we will not guarantee anything about the possibility of conversion and potential destruction of the value of the content. In short, it is not better to get a FICHE of the Dead Sea Scrolls (with the originals destroyed) if you posted them with the expectation that they would either be delivered as posted, or returned as posted, without destruction. It is not always better to get something more than nothing!!!! We are dangerously close to changing mail to be unreliable by design, like an ETHERNET. It is fine for an ETHERNET where we all understand that the design calls for loss of stuff, so we all deal with it in those terms. But, we do cannot design Netmail to have this property of loss. Cheers...\Stef   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa07075; 15 Apr 92 20:34 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa02121; 15 Apr 92 20:38 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa02104; 15 Apr 92 20:38 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA16164; Wed, 15 Apr 92 20:10:35 EDT Received: from ics.uci.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA16160; Wed, 15 Apr 92 20:10:33 EDT Received: from ics.uci.edu by q2.ics.uci.edu id aa02142; 15 Apr 92 16:57 PDT To: "Ned Freed, Postmaster" Cc: weber@eitech.com, ietf-822@dimacs.rutgers.edu Subject: Re: multipart partial messages In-Reply-To: Wed, 15 Apr 92 14:37:00 PST. <01GIVOLTWFHU9BVCNP@HMCVAX.CLAREMONT.EDU> From: Einar Stefferud Reply-To: stef@nma.com Date: Wed, 15 Apr 92 16:57:11 -0700 Message-Id: <2139.703382231@ics.uci.edu> Sender: stef@ics.uci.edu Obviously there is need for a way to assemmble a set of messages conatining partial messages and tehn ask your UA to reassemble them. Forcing them back through the MTA delivery process is pretty grotesque;-) Best...\Stef   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa07545; 16 Apr 92 1:04 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa08357; 16 Apr 92 1:08 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa08340; 16 Apr 92 1:08 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA18425; Thu, 16 Apr 92 00:52:33 EDT Received: from Kona.CS.UCLA.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA18421; Thu, 16 Apr 92 00:52:31 EDT Received: from twinsun.UUCP by kona.cs.ucla.edu (Sendmail 5.61b+YP/3.17) id AA06575; Wed, 15 Apr 92 14:07:47 -0700 Received: from set by twinsun.com (4.1/SMI-4.1) id AA23535; Wed, 15 Apr 92 13:49:13 PDT Message-Id: <9204152049.AA23535@twinsun.com> Date: Wed, 15 Apr 1992 13:49:12 -0700 (PDT) From: Makr Keasling Subject: Re: Implications of MIME for Transport To: ietf-822@dimacs.rutgers.edu In-Reply-To: <29009.703360558@ics.uci.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > From: Einar Stefferud > Date: Wed, 15 Apr 92 10:55:58 -0700 > [stuff deleted] > Thsi whole idea of arbitrary MTA conversion between GIF and JPEG because > of some decision logic imbedded in some random RELAY-MTA just boggles my > mind. Suppose the US Postal Service (or The Royal Mail) descided that > the bulk of paper was too great in some random package, and converted it > to microfiche for its own convenience! And suppose it was the Dead Sea > Scolls! Waht rubbish is this iead that any MTA might be intelligent > enough to make any such decision with out MUA autority! HOGWASH! > [more stuff deleted] > > Cheers...\Stef I agree with Stef. I dislike idea that an MTA can arbitrarily convert data between different data formats that it thinks are equivalent. Converting GIF to JPEG is like converting PostScript to RichText.:) YUCK. When I mail something I expect it to arrive in the manner that I sent it. I don't want MTA's mucking around with my messages any more than they have to. For me modification of the contents is unacceptable; but, breaking a large message into pieces is fine. Mark   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00374; 16 Apr 92 3:34 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa02080; 16 Apr 92 3:38 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa02057; 16 Apr 92 3:38 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA19143; Thu, 16 Apr 92 02:22:52 EDT Received: from garam.kreonet.re.kr by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA19139; Thu, 16 Apr 92 02:22:46 EDT Received: from bh.kpnu.ac.kr ([192.135.230.2]) by garam.kreonet.re.kr (4.1/GARAM-MX-1.0) id AA28444; Thu, 16 Apr 92 15:21:31 KST Received: by bh.kpnu.ac.kr (AIX 3.1/UCB 5.61/BH-1.0) id AA05128; Thu, 16 Apr 92 14:59:10 +0900 Date: Thu, 16 Apr 92 14:59:10 +0900 From: 5557 Message-Id: <9204160559.AA05128@bh.kpnu.ac.kr> To: ietf-822@dimacs.rutgers.edu Please remove me from your mailing list. Thanks. Ki-jun Han   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00399; 16 Apr 92 4:04 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa02664; 16 Apr 92 4:08 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa02645; 16 Apr 92 4:08 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA19909; Thu, 16 Apr 92 03:58:52 EDT Received: from charon.cwi.nl by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA19905; Thu, 16 Apr 92 03:58:49 EDT Received: from voorn.cwi.nl by charon.cwi.nl with SMTP id AA03310 (5.65b/2.10/CWI-Amsterdam); Thu, 16 Apr 1992 09:58:45 +0200 Received: by voorn.cwi.nl with SMTP; Thu, 16 Apr 1992 07:58:44 GMT Message-Id: <9204160758.AA26599@voorn.cwi.nl> To: Nathaniel Borenstein Cc: ietf-822@dimacs.rutgers.edu Subject: Re: Implications of MIME for Transport In-Reply-To: Your message of "Wed, 15 Apr 1992 12:24:06 MDT." <0dv5WaK0M2YtF4Phxh@thumper.bellcore.com> From: Guido van Rossum X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands X-Phone: +31 20 5924127 (work), +31 20 6225521 (home), +31 20 5924199 (fax) Date: Thu, 16 Apr 1992 09:58:43 +0200 Sender: Guido.van.Rossum@cwi.nl Me: >> [...] Is there a way for the sender to specify that this is not an >> acceptable step (e.g. to say that he'd much rather fragment the data >> himself if the MTA won't do that)? Nathaniel: >This would suggest that, at a minimum, some sort of trace headers should >be included, no? This doesn't address my (second) point: how to *prevent* unacceptable conversions. Maybe more general: MIME needs a definition of what conversions are acceptable. --Guido van Rossum, CWI, Amsterdam "Are all your pets called Eric?"   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03106; 16 Apr 92 14:05 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa18245; 16 Apr 92 14:09 EDT Received: from dimacs.RUTGERS.EDU by NRI.Reston.VA.US id aa18226; 16 Apr 92 14:09 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA23299; Thu, 16 Apr 92 13:53:59 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA23295; Thu, 16 Apr 92 13:53:57 EDT Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Thu, 16 Apr 92 13:53:56 EDT Received: by greenbush.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Thu, 16 Apr 92 13:53:55 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, 16 Apr 1992 13:53:52 -0400 (EDT) Message-Id: Date: Thu, 16 Apr 1992 13:53:52 -0400 (EDT) From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: weber@eitech.com Subject: Re: multipart partial messages Cc: ietf-822@dimacs.rutgers.edu In-Reply-To: <01GIVOLTWFHU9BVCNP@HMCVAX.CLAREMONT.EDU> References: <01GIVOLTWFHU9BVCNP@HMCVAX.CLAREMONT.EDU> Excerpts from internet.ietf-822: 15-Apr-92 Re: multipart partial messages Ned Freed@hmcvax.claremo (651) > However, I suspect that most reassembly agents won't > bother to deal with imbedded message/partial objects. I know my code sure > doesn't; you'd have to explode and redeliver the parts to get the thing to reassemble. Actually, this is one of the few advantages to the generally-stupid way that metamail implements message/partial -- it will work just as well even if the parts are embedded in a multipart.   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00710; 18 Apr 92 22:48 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa09063; 18 Apr 92 22:52 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa09046; 18 Apr 92 22:52 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA16981; Sat, 18 Apr 92 22:09:31 EDT Received: from CBROWN.CLAREMONT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA16977; Sat, 18 Apr 92 22:09:28 EDT Received: from HMCVAX.CLAREMONT.EDU by HMCVAX.CLAREMONT.EDU (PMDF #11000) id <01GJ04Z2B0H49BVF0K@HMCVAX.CLAREMONT.EDU>; Sat, 18 Apr 1992 19:09 PST Date: Sat, 18 Apr 1992 19:09 PST From: "Ned Freed, Postmaster" Subject: Re: Network World To: ietf-822@dimacs.rutgers.edu Message-Id: <01GJ04Z2B0H49BVF0K@HMCVAX.CLAREMONT.EDU> X-Vms-To: IN%"ietf-822@dimacs.rutgers.edu" If X.400 needs anything at all it is the boost it is going to get from MIME. I think that without MIME the fate of X.400 is quite certain -- it will go the way of dinosaurs eventually. But with MIME it is possible for the first time to deploy X.400 locally and actually get some benefit out of it. Currently all you get when you deploy X.400 on a local network is a headache. None of the advantages it offers are useful because they do not interoperate across most WANs, and the Internet in particular. So all you get is the tremendous headache that comes when you install any piece of sophisticated networking software. No matter how well an implementation is designed there's just no way to make complex software trivial to deal with. (And this supposes that most X.400 implementations are clean and sweet. My experience says that this is far from true -- most of them are pitiful.) The result is sites are staying away from X.400 in droves. I deal with dozens, even hundreds, of sites that do use X.400, and almost without exception their reasons for using it have nothing to do with any actual benefit it gives. (This is the "age of reason", after all: (1) because it is mandated by GOSIP, (2) because upper level management went to some conference and heard about it, (3) because some contract requires it, or (4) because someone else installed it and wants someone, anyone, to talk to. The age of reason indeed ;-) And keep in mind that these sites are a small minority. Most of them look and never consider X.400 again. But MIME changes all this. For the first time you can install X.400 locally and hope to get some actual tangible benefit out of it because there's some chance that you'll be able to interoperate over a WAN with some of your new-found features. I realize that this turns the usual model for these things on its head. The usual idea is to use X.400 globally and something else locally. But I don't see any way to get to this without finding some way to bootstrap it off the existing infrastructure. In other words, MIME. I quite frankly don't know if MIME is enough to save X.400. What I do know is that without MIME X.400 will remain in the doldrums where it has been all along. It is possible that some radical rethink of X.400 would also suffice to change the way the world sees it. But it would have to be radical, and I don't see much likelihood of that happening now. I'm sorry if this sounds like a very negative review of X.400 overall. I actually like quite a bit of X.400, and I see great promise in parts of it. But most of what I've said here is not based on my personal feeling for or against X.400, it is instead based on what I hear on the phone and via e-mail talking to customers every day. And when you consider that these are customers who have access to a readily available commercial X.400 implementation that has been around for a while, is considered to be reasonably bug free if not exactly spectacular, and is fairly reasonably priced (no, I had nothing to do with the writing of all this), you might just have to admit this view is somewhat optimistic. Ned   Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00330; 22 Apr 92 3:04 EDT Received: from nri.reston.va.us by NRI.Reston.VA.US id aa01632; 22 Apr 92 3:08 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa01606; 22 Apr 92 3:08 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA15411; Wed, 22 Apr 92 03:01:35 EDT Received: from jarvis.csri.toronto.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA15407; Wed, 22 Apr 92 03:01:31 EDT Received: by jarvis.csri.toronto.edu id <6844>; Wed, 22 Apr 1992 03:00:55 -0400 To: ietf-822@dimacs.rutgers.edu, ietf-ack@ics.uci.edu From: Rayan Zachariassen Subject: Re: Implications of MIME for Transport Organization: Department of Computer Science, University of Toronto References: <10090.703367489@ics.uci.edu> Distribution: list Date: Wed, 22 Apr 1992 03:00:19 -0400 Message-Id: <92Apr22.030055edt.6844@jarvis.csri.toronto.edu> Although I'm pretty much in the MTA == Postoffice functions camp, the argument Nat makes about the value of change can't be dismissed trivially. So, let me take a stab at defining our abstract MTA and see where it leads. The function of an (E-)mail system is to carry messages from one entity to another. Therefore the sending entity must minimally provide message data, and addressing information for the receiving entity. The sending entity may not know anything about the environment of the receiving entity, including a direct way to it. Therefore we need a mail system infrastructure. We choose to impose the following requirements: 1. The sending entity may transmit the message to multiple independent recipients as a single action. 2. The recipient should have some idea of where the message came from and how it got to the recipient. Either of these imply that each message must carry state information with it as it traverses the mail system infrastructure. We now have message chunks that satisfy the sender (the message data, and some specification of the desired action), the recipient (trace information), and whatever is between them (the mail system infrastructure). Therefore a message has exactly three basic parts: 1. Body, the message data the sender entity wanted to transmit to the recipient. 2. Header, the other information supplied by the sender entity. 3. Envelope, the mail system (state) information carried with the message. Note: These terms do not necessarily correspond to common casual usage specific to any particular protocol. While traversing the mail system infrastructure, the message Envelope may change at any time. The Header will not change on a mail "relay" (by definition), and may change on a mail "gateway" (by definition). The Body will not change on a mail relay, but may it change on a mail gateway? (see below) For a message to be transmitted from a sender [entity] to a recipient [], the following are requirements: 1. The sender must generate a message. 2. The sender must specify the recipient(s). 3. The sender must demark that the should be sent. 4. Something must decide what to do with the . 5. Something must do the appropriate thing with the . 6. If necessary the message traverses the mail system infrastructure i.e., go to 4, otherwise continue. 7. The message is made available to the recipient at a demarkation point. 8. The recipient takes delivery of the message. The lines of communication in the above sequence are very fluid. However the sequence is clear. We should now be able to discuss the characteristics of any mail system model in terms of how its components map to this sequence, what is communicated between the sequence points, and how what is communicated is acted upon. Start of Very Subjective Opinion: To me, the Internet E-mail nomenclature maps to the above as follows: The User Agent is responsible for pts. 1,2,3,8. The Message Transfer Agent is responsible for pts. 4,5,6,7. The message Body corresponds to the RFC822 body, as well as any RFC822 header fields with null semantics (i.e. that communicate data unchanged from sender to recipient, like the Subject: line et al). The message Header corresponds to the static RFC822 header fields with defined non-null semantics supplied at time of entry into the mail system (between Point 3 and 4). The message Envelope corresponds to the dynamic information maintained about the message, including RFC821 sender and recipient route-addrs and associated information, RFC822 Received: header fields, etc. End of Very Subjective Opinion. The way RFC821 and RFC822 and X.400 have defined things are just a few possible instantiations of the general model. Hopefully this model will be a useful reference in clarifying what people are actually thinking and talking about. Point 5 is where message Body translation might happen. Point 4 is where something decides that it should happen. The separation and sequence of these is occasionally ignored by some of the comments on features people want added to Point 5. What such comments are really asking is that 4 and 5 and 6 be mandated to be a single very tightly integrated step that hides the underlying structure. We can now get back to the lossy message conversion issue. The only thing in the general model that bears on this issue is that the sender's purpose was to transmit the original "message Body" to the recipient. If the mail system infrastructure, which is the only thing between the sender and recipient (and in my opinion the area that delineates MTAs), cannot ensure that the recipient will get what the sender wanted, it should give up. It can't do its job. Now the original message may be protected, hidden, sent by another subsystem or whatever, but the obligation on the mail system is clear: the sender at a demarkation point asked for a specific message to be sent, and that is what should be (isomorphically) received at a demarkation point. In practical terms, if you want something to do lossy conversion of a message, that something should be on the non-mail system side of a demarkation point (before pt. 3 or after pt. 7). It may be done at the end-recipient or may be an intermediate protocol converter, but in any case its action (if remote from the sender) must be implicitly requested by the sender's recipient specification. Note that this argument is independent of where you draw the UA/MTA boundary, though it happens to coincide nicely with what I think it should be :-) "The message Body may change isomorphically on a mail gateway."   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa00713; 8 Sep 92 6:02 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa00707; 8 Sep 92 6:02 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa03592; 8 Sep 92 6:04 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA13091; Tue, 8 Sep 92 04:42:53 EDT Received: from relay1.UU.NET by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA13086; Tue, 8 Sep 92 04:42:51 EDT Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA17634; Tue, 8 Sep 92 04:42:46 -0400 Received: from kddlab.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 044131.12470; Tue, 8 Sep 1992 04:41:31 EDT Received: from kddfuji by kddlab.kddlabs.co.jp (5.61/6.2Junet) id AA19963; Tue, 8 Sep 92 17:07:18 +0900 Received: from ccut.cc.u-tokyo.ac.jp by kddfuji.kddlabs.co.jp (5.65+1.6W/KDD-1.02MX) id AA07186; Tue, 8 Sep 92 17:07:05 JST Received: by ccut.cc.u-tokyo.ac.jp (5.67+1.6W/6.4J.6-ut3.146) id AA19833; Tue, 8 Sep 92 17:06:58 JST Received: by juicegw.juice.or.jp (4.0/6.4J.6-juice01) id AA23015; Tue, 8 Sep 92 16:25:29 JST Received: by green.lime.juice.or.jp (4.1/6.4J.6-juice01) id AA08124; Tue, 8 Sep 92 15:44:50 JST Received: from localhost by samrat.poel.juice.or.jp (4.0/6.4J.6-juice01) id AA05389; Tue, 8 Sep 92 15:07:03 JST Return-Path: Message-Id: <9209080607.AA05389@samrat.poel.juice.or.jp> Reply-To: erik@poel.juice.or.jp From: "Erik M. van der Poel" To: ietf-822@dimacs.rutgers.edu Subject: Re: iso-2022-jp Date: Tue, 08 Sep 92 15:07:02 +0900 Sender: erik@samrat.poel.juice.or.jp Olle, Thank you for the comments, and sorry about the delay in replying. > : This document describes the encoding used in plain text electronic > : mail and network news in several Japanese networks. > > This should be "... used in the plain text parts of electronic > mail and network news messages in several ...". Hmm. I can see what you're getting at, but if I use your wording, people might get the impression that iso-2022-jp is currently also used in the plain text parts of message headers, but it isn't. So perhaps I should change it to read "... used in the bodies of electronic mail and network news messsages in several ...". > Is the > intention that JUNET encoding shall be allowed there too, in > accordance with the rules of RFC 1342? Either way, it may be > useful to include some text about the use or non-use of JUNET > encoding in message headers. Very true. Currently MIME and RFC 1342 are intended to proceed together along the standards track, so the iso-2022-jp document should probably also mention its relationship to RFC 1342. > : Formal Description > : > : This section provides a formal description of the JUNET encoding. In > : the event that this description is not consistent with the above > : informal description, this formal description shall take precedence. > > The formal description is not as complete as the informal > description: It only specifies the syntax - > > which octet sequences are allowed > > not the semantics - > > which character set shall be used to interpret a certain > (or * outside s) > > The semantics is only specified in the informal specification. True, but I don't feel that it is worth it to make the "Formal Description" complete. I think I'll change the wording to make the two sections complementary rather than alternate. > : CHAR = ; ( 0-177, 0.-127.) > : > : text = : CR & bare LF, but NOT > : including CRLF> > > I see two problems with the definition of , one formal and > one substantial. > > Formal problem: as defined is one single character. How > can the definition then say that is "any CHAR ... but not > including CRLF"? is a _sequence_ of two characters. I took that part straight from RFC 822. If it's good enough for RFC 822, it's good enough for the iso-2022-jp doc. I appreciate your concern, but I really don't want to bog down this doc with incomprehensible gobbledeegook. :-) > Substantial problem: Is allowed as ? The present > definition implies that, but obviously at least can't be > allowed in the context > > ESC "(" ( "B" / "J" ) > / ESC "$" ( "@" / "B" ) > > And I guess other similar escape sequences, that would indicate > a switch to other character sets according to ISO 2022 are > disallowed too. Maybe should be excluded from ? OK, I'll exclude ESC from "text". > : Additional restrictions that are difficult to describe in the above > ^^^^^^^^^^^^ > : are as follows. > : > : Adjacent segments should have different escape sequences. For > ^^^^^^ > : example, the following is not recommended: > : > : ESC $ B .... ESC $ B .... > > The use of "should" indicates that this rule isn't a > "restriction" but rather a recommendation. Actually, someone else pointed out that this part really isn't necessary, so it'll be removed. Regards, Erik   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa07126; 10 Sep 92 13:10 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa07120; 10 Sep 92 13:10 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa03644; 10 Sep 92 13:13 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA03228; Thu, 10 Sep 92 12:38:15 EDT Received: from relay1.UU.NET by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA03206; Thu, 10 Sep 92 12:36:23 EDT Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA17771; Thu, 10 Sep 92 12:34:39 -0400 Received: from kddlab.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 122221.17002; Thu, 10 Sep 1992 12:22:21 EDT Received: from kddfuji by kddlab.kddlabs.co.jp (5.61/6.2Junet) id AA12571; Fri, 11 Sep 92 00:37:34 +0900 Received: from ccut.cc.u-tokyo.ac.jp by kddfuji.kddlabs.co.jp (5.65+1.6W/KDD-1.02MX) id AA22774; Fri, 11 Sep 92 00:37:25 JST Received: by ccut.cc.u-tokyo.ac.jp (5.67+1.6W/6.4J.6-ut3.146) id AA00492; Fri, 11 Sep 92 00:37:14 JST Received: by juicegw.juice.or.jp (4.0/6.4J.6-juice01) id AA08590; Fri, 11 Sep 92 00:27:39 JST Received: by green.lime.juice.or.jp (4.1/6.4J.6-juice01) id AA01500; Thu, 10 Sep 92 23:45:49 JST Received: from localhost by samrat.poel.juice.or.jp (4.0/6.4J.6-juice01) id AA11832; Thu, 10 Sep 92 22:33:46 JST Return-Path: Message-Id: <9209101334.AA11832@samrat.poel.juice.or.jp> Reply-To: erik@poel.juice.or.jp From: "Erik M. van der Poel" To: ietf-822@dimacs.rutgers.edu Subject: Re: iso-2022-jp Date: Thu, 10 Sep 92 22:33:45 +0900 Sender: erik@samrat.poel.juice.or.jp Folks, A new draft of the iso-2022-jp document has been prepared and is included below. I have added "diff marks" on the right to indicate changes since the previous draft: "!" means modification, "+" means addition, and "-" means deletion. The review period is another two weeks (also on the Japanese newsgroup fj.kanji). Regards, Erik Network Working Group Jun Murai Internet Draft Mark Crispin Erik van der Poel 10th September 1992 Japanese 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 I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. This draft document will be submitted to the RFC editor as an informational document. This document will expire before 10th March 1993. Distribution of this memo is unlimited. Please send comments to ietf-822@dimacs.rutgers.edu. Introduction This document describes the encoding used in the bodies of electronic ! mail and network news 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. This document provides a name for the encoding which is intended to be used in the "charset" parameter field of MIME [MIME] messages and ! RFC 1342 [RFC1342] headers. ! This document only describes the encoding of plain text. The encoding of other subtypes of text, such as rich text, is not discussed here. Murai et al Expires 10th March 1993 [Page 1] Internet Draft Updated 10th September 1992 Description ! The message body starts in ASCII, and switches to Japanese characters through an escape sequence. For example, the escape sequence ESC $ B (three bytes, hexadecimal values: 1B 24 42) indicates that the bytes ! following this escape sequence are Japanese characters, which are encoded in two bytes each. To switch back to ASCII, the escape sequence ESC ( B is used. The following table gives the escape sequences and the character sets used in JUNET messages. ESC ( B ASCII ESC ( J JIS X 0201-1976 ("Roman" set) ! ESC $ @ JIS X 0208-1978 ESC $ B JIS X 0208-1983 The "Roman" character set of JIS X 0201-1976 is identical to ASCII ! except for backslash (\) and tilde (~). The backslash is replaced by the Yen sign, and the tilde is replaced by macron (overline). This set is Japan's national variant of ISO 646. The JIS X 0208 character sets consist of Kanji, Hiragana, Katakana and some other symbols and characters. Each character takes up two bytes. For further details about the JIS Japanese national character set standards, refer to the JIS standards themselves. For further information about the escape sequences, see ISO 2022 [ISO2022]. If there are JIS X 0208 characters on a line, there must be a switch to ASCII or to the "Roman" set of JIS X 0201 before the end of the ! line (i.e. before the CRLF). This means that the next line starts in the character set that was switched to before the end of the previous line. Other restrictions are given in the Formal Syntax below. ! Formal Syntax ! - The notational conventions used here are identical to those used in RFC 822 [RFC822]. The * (asterisk) convention is as follows: l*m something meaning at least l and at most m somethings, with l and m taking default values of 0 and infinity, respectively. Murai et al Expires 10th March 1993 [Page 2] Internet Draft Updated 10th September 1992 line = *text *1( *segment single-byte-seq *text ) CRLF segment = single-byte-segment / double-byte-segment single-byte-segment = single-byte-seq 1*text double-byte-segment = double-byte-seq 1*( one-of-94 one-of-94 ) single-byte-seq = ESC "(" ( "B" / "J" ) double-byte-seq = ESC "$" ( "@" / "B" ) ; ( Octal, Decimal.) ESC = ; ( 33, 27.) SI = ; ( 17, 15.) + SO = ; ( 16, 14.) + one-of-94 = ; (41-176, 33.-126.) CHAR = ; ( 0-177, 0.-127.) text = ! - MIME and RFC 1342 Considerations ! The name given to the JUNET character encoding is "ISO-2022-JP". This name is intended to be used in MIME messages as follows: Content-Type: text/plain; charset=iso-2022-jp The JUNET encoding is already in 7-bit form, so it is not necessary to use a Content-Transfer-Encoding header. It should be noted that applying the Base64 or Quoted-Printable encoding will render the message unreadable in current JUNET software. The name ISO-2022-JP may also be used in RFC 1342 headers, though in + this case, the text should be encoded using either the "B" or "Q" + encoding, to avoid getting damaged by header-processing software. As + ISO-2022-JP text often contains many bytes that have a special + meaning in headers, it is probably easier to use the "B" encoding, + rather than trying to determine which particular byte values need "Q" + encoding. + Murai et al Expires 10th March 1993 [Page 3] Internet Draft Updated 10th September 1992 Background Information The JUNET encoding was described in the JUNET User's Guide [JUNET] (JUNET Riyou No Tebiki Dai Ippan). The encoding is based on the particular usage of ISO 2022 announced ! by 4/1 (see [ISO2022] for details). However, the escape sequence ! normally used for this announcement is not included in JUNET messages. The so-called half-width (hankaku) Katakana, that is, the Kana set of + JIS X 0201-1976, are not used in JUNET messages. + In the past, some systems erroneously used the escape sequence ESC ( + H in JUNET messages. This escape sequence is officially registered + for a Swedish character set, and should not be used in JUNET + messages. + Some systems do not distinguish between ESC ( B and ESC ( J or + between ESC $ @ and ESC $ B for display. However, when relaying a + message to another system, the escape sequences must not be altered + in any way. + The human user (not implementor) should try to keep lines within 80 + display columns, or, preferably, within 75 (or so) columns, to allow + insertion of ">" at the beginning of each line in excerpts. Each JIS + X 0208 character takes up two columns, and the escape sequences do + not take up any columns. The implementor is reminded that JIS X 0208 + characters take up two bytes and should not be split in the middle to + break lines for displaying, etc. + The JIS X 0208 standard was revised in 1990, to add two characters at + the end of the table. Although ISO 2022 specifies special additional + escape sequences to indicate the use of revised character sets, it is + suggested here not to make use of this special escape sequence in + ISO-2022-JP text, even if the two characters added to JIS X 0208 in + 1990 are used. + References [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) [JUNET] JUNET Riyou No Tebiki Sakusei Iin Kai (JUNET User's Guide Drafting Committee), "JUNET Riyou No Tebiki (Dai Ippan)" ("JUNET Murai et al Expires 10th March 1993 [Page 4] Internet Draft Updated 10th September 1992 User's Guide (First Edition)"), February 1988 [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 [RFC822] David H. Crocker, "Standard for the Format of ARPA Internet Text Messages", Internet standard, August 1982, rfc822 [RFC1342] Keith Moore, "Representation of Non-ASCII Text in Internet + Message Headers", Proposed (Internet) standard, June 1992, rfc1342 + Security Considerations Security considerations are not discussed in this memo. Acknowledgements Many people assisted in drafting this document. The authors wish to thank in particular Akira Kato, Masahiro Sekiguchi and Ken'ichi Handa. Authors' Addresses Jun Murai Keio University 5322 Endo, Fujisawa Kanagawa 252 Japan ! Fax: +81 (466) 49-1101 EMail: jun@wide.ad.jp Mark Crispin Panda Programming 6158 Lariat Loop NE Bainbridge Island, WA 98110-2098 USA Phone: +1 (206) 842-2385 EMail: MRC@PANDA.COM Murai et al Expires 10th March 1993 [Page 5] Internet Draft Updated 10th September 1992 Erik M. van der Poel A-105 Park Avenue 4-4-10 Ohta, Kisarazu Chiba 292 Japan Phone: +81 (438) 22-5836 Fax: +81 (438) 22-5837 EMail: erik@poel.juice.or.jp Murai et al Expires 10th March 1993 [Page 6]   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa08799; 10 Sep 92 14:59 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa08792; 10 Sep 92 14:59 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa10753; 10 Sep 92 15:02 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA04433; Thu, 10 Sep 92 13:35:36 EDT Received: from itd.nrl.navy.mil by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA04429; Thu, 10 Sep 92 13:35:35 EDT Received: from mason.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA23081; Thu, 10 Sep 92 13:35:23 EDT Return-Path: Received: by mason.itd.nrl.navy.mil; Thu, 10 Sep 92 13:35:16 EDT Date: Thu, 10 Sep 92 13:35:16 EDT From: atkinson@itd.nrl.navy.mil Message-Id: <9209101735.AA09424@mason.itd.nrl.navy.mil> To: ietf-822@dimacs.rutgers.edu Subject: ISO-2022-JP draft I'd like to see the document either explicitly state that by "ASCII" we mean ANSI X3.4-1986 OR state that it means ISO-whatever OR that it means any 7-bit character set. I'd really prefer to add a reference to ANSI X3.4 to the end and require that it shift back to US ASCII, but perhaps there are reasons that isn't a good idea (if such reasons exist, I'd appreciate being enlightened on what they are). Otherwise, looks fine to me... ran atkinson@itd.nrl.navy.mil   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa12996; 10 Sep 92 18:24 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa12990; 10 Sep 92 18:24 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa17530; 10 Sep 92 18:27 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA06398; Thu, 10 Sep 92 17:30:21 EDT Received: from inet-gw-1.pa.dec.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA06393; Thu, 10 Sep 92 17:30:15 EDT Received: by inet-gw-1.pa.dec.com; id AA11167; Thu, 10 Sep 92 14:29:31 -0700 Received: from garfield.jrd.dec.com by jrdmax.jrd.dec.com (5.65/J-ULTRIX4.2A)id AA07248; Fri, 11 Sep 92 06:29:16 +0900 Received: from localhost by garfield.jrd.dec.com (5.65/JULT-4.X)id AA20768; Fri, 11 Sep 1992 06:29:36 +0900 Message-Id: <9209102129.AA20768@garfield.jrd.dec.com> To: ietf-822@dimacs.rutgers.edu Subject: Re: iso-2022-jp In-Reply-To: Your message of "Thu, 10 Sep 92 22:33:45 +0900." <9209101334.AA11832@samrat.poel.juice.or.jp> From: Hitoshi Doi =?ISO-2022-JP?B?GyRCRVowZj9OO1YbKEI=?= X-Phone-Reply-To: 045-336-5358 (work)/045-320-0492 (home) [in Japan] Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-2022-JP Date: Fri, 11 Sep 92 06:29:36 +0900 Sender: doi@jrd.dec.com X-Mts: smtp # The name ISO-2022-JP may also be used in RFC 1342 headers, though in + # this case, the text should be encoded using either the "B" or "Q" + # encoding, to avoid getting damaged by header-processing software. As + # ISO-2022-JP text often contains many bytes that have a special + # meaning in headers, it is probably easier to use the "B" encoding, + # rather than trying to determine which particular byte values need "Q" + # encoding. + Since this is not being used very widely yet, can't we just say that the "B" encoding must be used? We have pretty much agreed on the Japanese mime mailing list that we just use the "B" encoding. -- Hitoshi Doi, International Open Systems Engineering doi@jrd.dec.com Japan Research and Development Center decwrl!jrd.dec.com!doi Digital Equipment Corporation Japan doi@decvax.dec.com   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa13259; 10 Sep 92 19:32 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa13253; 10 Sep 92 19:32 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa18845; 10 Sep 92 19:35 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA06551; Thu, 10 Sep 92 18:05:27 EDT Received: from dkuug.dk by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA06546; Thu, 10 Sep 92 18:05:18 EDT Received: by dkuug.dk (5.64+/8+bit/IDA-1.2.8) id AA12856; Fri, 11 Sep 92 00:04:47 +0200 Date: Fri, 11 Sep 92 00:04:47 +0200 From: Keld J|rn Simonsen Message-Id: <9209102204.AA12856@dkuug.dk> To: erik@poel.juice.or.jp, ietf-822@dimacs.rutgers.edu Subject: Re: iso-2022-jp X-Charset: ASCII X-Char-Esc: 29 For a reference to JIS X0201 and X0208 you could also reference RFC1345. Keld   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa14106; 10 Sep 92 22:03 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa14099; 10 Sep 92 22:03 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa21091; 10 Sep 92 22:06 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA08442; Thu, 10 Sep 92 21:34:33 EDT Received: from etlpost.etl.go.jp by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA08438; Thu, 10 Sep 92 21:34:28 EDT Received: from etlpom.etl.go.jp by etlpost.etl.go.jp (5.67+1.6W/2.7W) id AA02345; Fri, 11 Sep 92 10:34:38 JST Received: by etlpom.etl.go.jp (4.1/6.4J.6-ETLpom.MASTER) id AA09723; Fri, 11 Sep 92 10:35:22 JST Received: by etlibs.etl.go.jp (4.1/6.4J.6-ETL.SLAVE) id AA09720; Fri, 11 Sep 92 10:35:18 JST Date: Fri, 11 Sep 92 10:35:18 JST Return-Path: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP To: ietf-822@dimacs.rutgers.edu Subject: Re: iso-2022-jp From: Yutaka Sato =?ISO-2022-JP?B?GyRAOjRGI0stGyhK?= Organization: Electrotechnical Laboratory, Tsukuba Science City Message-Id: References: <9209101334.AA11832@samrat.poel.juice.or.jp> <9209102129.AA20768@garfield.jrd.dec.com> <9209102204.AA12856@dkuug.dk> <1678@~/Mail/drafts> In message <9209102129.AA20768@garfield.jrd.dec.com> on 09/11/92(06:29:36) you Hitoshi Doi 土井仁志 wrote: |# The name ISO-2022-JP may also be used in RFC 1342 headers, though in + |# this case, the text should be encoded using either the "B" or "Q" + |# encoding, to avoid getting damaged by header-processing software. As + |# ISO-2022-JP text often contains many bytes that have a special + |# meaning in headers, it is probably easier to use the "B" encoding, + |# rather than trying to determine which particular byte values need "Q" + |# encoding. + | |Since this is not being used very widely yet, |can't we just say that the "B" encoding must be used? |We have pretty much agreed on the Japanese mime mailing list |that we just use the "B" encoding. | |-- |Hitoshi Doi, International Open Systems Engineering doi@jrd.dec.com I agree with you. The quoted printable is desirable when the result is somewhat human READABLE, but the ISO-2022-JP become totally unreadable when it is encoded anyway. The "B" is preferable to the "Q" because, as Erik says, we don't need any discussion about what byte values should be encoded. The more important thing we should determine is whether or not each encoded-word should be ended in the ISO-2022 sequence to switch ASCII, especially when a long ISO-2022-JP string is separated into multiple encode- words. We have discussed about it in the mime@etl.go.jp mailing list, and I think we will reach our conclusion soon. -- Yutaka Sato Information Base Section ELECTROTECHNICAL LABORATORY 1-1-4 Umezono, Tsukuba, Ibaraki, 305 Japan   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa04327; 11 Sep 92 10:01 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04321; 11 Sep 92 10:01 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa08010; 11 Sep 92 10:04 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA12014; Fri, 11 Sep 92 09:33:10 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA12010; Fri, 11 Sep 92 09:33:08 EDT Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Fri, 11 Sep 92 09:33:06 EDT Received: by greenbush.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Fri, 11 Sep 92 09:33:05 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, 11 Sep 1992 09:33:02 -0400 (EDT) Message-Id: Date: Fri, 11 Sep 1992 09:33:02 -0400 (EDT) From: Nathaniel Borenstein X-Andrew-Message-Size: 1279+1 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="Interpart.Boundary.Ieg:0BK0M2YtM1Y7pC" To: Hitoshi Doi =?ISO-2022-JP?B?GyRCRVowZj9OO1YbKEI=?= Subject: Re: iso-2022-jp Cc: ietf-822@dimacs.rutgers.edu In-Reply-To: <9209102129.AA20768@garfield.jrd.dec.com> References: <9209102129.AA20768@garfield.jrd.dec.com> > 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.Ieg:0BK0M2YtM1Y7pC Content-type: text/plain; charset=US-ASCII Hitoshi -- Your mail came through with a content-type header of: Content-type: text/plain; charset=iso-2022-jp Yet in fact it contained only ASCII. I don't know what software you're using, but if it isn't yours please point out to the author that RFC 1341 specifies that in such cases (when your text can legitimately be called either ASCII or a superset) it should be labelled as ASCII to promote interoperability. To give you an idea of why this is important: I read your mail with a mail reader that displays ASCII and a few other character sets in its main window. When it gets iso-2022-jp, it starts a kterm window in which to display it. This is only mildly annoying when I get to see real Japanese characters (it makes the wait worthwhile!) but in the case of your message, all that popped up was ASCII, which was kind of annoying. I'm glad to see you using the features, I just thought whoever wrote the software should know about this minor error. -- Nathaniel PS -- This is unrelated to the use of iso-2022-jp in your From field, to give your correct name. That, by the way, looked fine for me in a kterm window -- I reproduce them here as an image for the benefit of list readers who have MIME support for image/gif but not for Kanji data in the headers: [An Andrew ToolKit view (mailobjv) was included here, but could not be displayed.] --Interpart.Boundary.Ieg:0BK0M2YtM1Y7pC Content-Type: multipart/mixed; boundary="Alternative.Boundary.Ieg:0BK0M2YtI1Y7k=" --Alternative.Boundary.Ieg:0BK0M2YtI1Y7k= Content-type: text/richtext; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hitoshi -- Your mail came through with a content-type header of: Content-type: text/plain; charset=3Diso-2022-jp Yet in fact it contained only ASCII. I don't know what software you're using,= but if it isn't yours please point out to the author that RFC 1341 specifies = that in such cases (when your text can legitimately be called either ASCII or = a superset) it should be labelled as ASCII to promote interoperability. To give you an idea of why this is important: I read your mail with a mail re= ader that displays ASCII and a few other character sets in its main window. W= hen it gets iso-2022-jp, it starts a kterm window in which to display it. Thi= s is only mildly annoying when I get to see real Japanese characters (it makes= the wait worthwhile!) but in the case of your message, all that popped up was= ASCII, which was kind of annoying. I'm glad to see you using the features, I just thought whoever wrote the softw= are should know about this minor error. -- Nathaniel PS -- This is unrelated to the use of iso-2022-jp in your From field, to give = your correct name. That, by the way, looked fine for me in a kterm window -- = I reproduce them here as an image for the benefit of list readers who have MIM= E support for image/gif but not for Kanji data in the headers: --Alternative.Boundary.Ieg:0BK0M2YtI1Y7k= Content-type: image/gif Content-Description: Your headers as they looked to me Content-Transfer-Encoding: base64 R0lGODdh9gE7APEAAAAAAP7+/v7+3wAA/iwAAAAA9gE7AAAC/gSEqcvteJ6ctNo2Lhtc +w+G4kiW5omm6moZ7AvH8kzX9o3nOuju/g8MCofEorEVOSqXzKbzCa31EJyqreOwUrEC bZebyESZ4rH5jH5Nw6QyZiF2s6lddjlzh893cnM/DRgoSLFGJ/F3IYdoWJfnuMcItPg0 OWh5iVZYF8blteGmVZX3MArZuLWF1YnHebeKiBdn50Wr+tVK2nmbmuvaUYoZLNykWQr8 xijbGifKq6BIx2pst0kdbYp6aghq3Sh7nPz1jV3Neh05nK4eVLxX+bysTO5u+mheTs38 +0mqtw0frVkfMHAEDlwk6p7CdQwb6mgXzgI4aP3+AQwYEZ+0/m7+NnSUp7GjyIvZPCKj B86hypUpIOJDZ/KlskmPSFbLaC/kuZc3N9nyaaUmPZy7hvJcyIyl0qUmXIrDleXVs5RT 9f1qJs6qs1FYa/mCua/knFCfvjrr+fSs16TvmLp9q0AThbZL6Z60G1MEXrh8+06Q6xeH p8CECzsBbDix4sVuETN+DDnyJceSK1u+vKTQ4HkwsOrwBEoq5tGkZaxJCSuRBqoV9l4c pxOtzdK0a0s4PcF1XphGd6cQipSz7eHEHeB+nXUq1LSeN0f0mqvq8n7HKGLQWjz7aM0/ td2UtxAtQrIZs6CcBbo8xYQAWWt/bxhw8EhW7wn36IvgIeXl/j/2lu2Pe/AN2Jd8sXHT 00CrWeSBgjyJxNVI5j1IYIWBHadNWN+FEyGFyE2zH4fkKAgSgCZ5ZmGKBSahljTkmZVW Sc7JJNp1MM7IXjIGOTeTij5eyOIHJTbYxhg9/ojkW5TNpRtfuiQJpVJLRkllEJVQhVeT j01ZZZef5TZPlvBx6WWZNVwZZlY4jslijioIKFGDM7amXyI1zpnedGWRBF0vybV2xJwo oMnblQkdSpOEUblGqAx2YfgCiLxVpOhYlJ5UD5giFmopeOJ1uqmJPt036QjvWEdqCbAg mqdqcVZ61Gy+wfomErIKSWlqri4oaojXbIRQppzuNN+H3YQ3/iGcvYKQKLAbrsDqZhPt RdcfbSl7a6ontAWpN1BpuOY2+S1H1ioh6sOJr2quO2GC9yFb6rEjJerhVkWVe6MqOO4I hpa7tgvNtaxe+mctY7mCUSqr6gvjnlvZt+xpocB2CrwF0cKnvN3Riyy95NYJCXne5AlM fgiWHCCK2MUUCzotexeeoQ0vq6qmslE7l3+SbnQwsXcd+HNOqDbQrXXO5qwecvf+F2Cs l7Ln5qwWK12vf/2dGq+74mqYrsJDVnVVq53ZGC22o5qIIMznnWy1zgLZLKJ97xSts3e+ otybp/FS7B43zgaLX5pDYT04rZaqC7SuDpr3d7aD2mwtoHr//uwzh+u1bazjWldc9QJ0 Gzu1UWwD53SypWPqMuTy+mbO0J+WSOjXmatttEyluu7vq+3eLDnq7a1eNeyiazy8zzzT 9bl0NOoKVGgf673vnSDHKKT0Cz+57kEYe80uP1kzdzDXLTofgqDbqht5tAyenezE+YY1 ZFevoDv+86ESEqQJuZvpY9nbj6g6benve5pDmmnyx78ECmFxBQTb/lbzwCOQSYEUrCAQ JmjBDGqQBhjcoAc/iAKJTa8NKCqS48x3iBphCk8qdOBZqOdCGMJNbDQDIWE0Myl/XQuC /KEckSoXuHqRbj8d6lXo3gC92NgQMjgEEOF8VyShzIpXamMZ7+9CNRGwME12bSvWEZdY mCbSrzktzJS5qHg7h5XwP5HbiZ6q2KrF0a8/ACMeEMG4GDE2rXhky4bZUucnoPVRcCNL mzv+xxzQINJ914tZUICHR8XosWAxhNsV/0WzWDwya6wZIhTRlEUickZSxhNgJJeixyLW UFiG280Oa3euuwVvd0jEBihHyUZBnjIxqTxcxwjWxq7REnC0C5fdGEcUQJYuZnz8oh6S KMVdhrFNaxFmn1zpsNvxa2HfYlJ9niaaHF3zmjEa5wjzQsMISlMYHTTgAK/wJTSWb50Z bCdD1EnPfD4Egfrs5ynt6c+A8q8AADs= --Alternative.Boundary.Ieg:0BK0M2YtI1Y7k= Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable --Alternative.Boundary.Ieg:0BK0M2YtI1Y7k=-- --Interpart.Boundary.Ieg:0BK0M2YtM1Y7pC--   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa03650; 22 Sep 92 11:00 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03639; 22 Sep 92 11:00 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa07653; 22 Sep 92 11:04 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA14167; Tue, 22 Sep 92 10:43:54 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA14163; Tue, 22 Sep 92 10:43:52 EDT Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Tue, 22 Sep 92 10:43:50 EDT Received: by greenbush.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Tue, 22 Sep 92 10:43: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; Tue, 22 Sep 1992 10:43:47 -0400 (EDT) Message-Id: Date: Tue, 22 Sep 1992 10:43:47 -0400 (EDT) Sender:ietf-archive-request@IETF.NRI.Reston.VA.US From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ietf-822@dimacs.rutgers.edu Subject: New Email/MIME book by MTR Readers of this list will be interested in checking out Marshall Rose's latest tome: "The Internet Message: Closing the Book with Electronic Mail" published by Prentice-Hall (ISBN 0-13-092941-7) It's fun, informative, and opinionated, just as you'd expect from Marshall, and it has 60 or so pages on MIME, including a monochrome version of the Telephone Chords picture I sent to this mailing list as a MIME message last spring. Since that makes it the only published book in the universe, to my knowledge, with a picture of me singing, it is clear that everyone needs to buy a copy!   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa06072; 22 Sep 92 13:29 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa06064; 22 Sep 92 13:29 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa11692; 22 Sep 92 13:33 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA17524; Tue, 22 Sep 92 13:15:13 EDT Received: from mx1.cac.washington.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA17516; Tue, 22 Sep 92 13:15:10 EDT Received: from Ikkoku-Kan.Panda.COM by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA13381; Tue, 22 Sep 92 10:14:59 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NeXT-1.0 (From Sendmail 5.52)/UW-NDC/Panda Revision: 2.27.MRC ) id AA02951; Tue, 22 Sep 92 10:14:54 PDT Date: Tue, 22 Sep 1992 09:56:15 -0700 (PDT) Sender:ietf-archive-request@IETF.NRI.Reston.VA.US From: Mark Crispin X-Orig-Sender: Mark Crispin Subject: tspecials again To: IETF Mail Extensions WG Cc: davecb@nexus.yorku.ca Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Well, I just got finished with dealing with ANOTHER interoperability problem caused by an implementor who innocently forgot to quote parameter strings with an embedded period in it. Once again, the string in question was a filename, the usual name=foo.bar Need I say that the poor fellow was even more confused by the fact that most MIME implementations happily swallow this in spite of the syntax violation, simply because it's so common? I am appalled that this glaring bug in MIME has not been fixed yet. The objections to fixing it from certain individuals are that it's a `trivial' matter. Well, this `trivial' matter has managed to waste amazing amounts of time. Perhaps not to the extent of a Bernstein, but enough to be annoying anyway.   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa08871; 22 Sep 92 14:29 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa08863; 22 Sep 92 14:29 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa13569; 22 Sep 92 14:33 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA18276; Tue, 22 Sep 92 14:06:32 EDT Received: from ppp.dbc.mtview.ca.us by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA18272; Tue, 22 Sep 92 14:06:27 EDT Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA18825; Tue, 22 Sep 92 10:58:57 -0700 To: Mark Crispin Reply-To: IETF Mail Extensions WG Cc: IETF Mail Extensions WG , davecb@nexus.yorku.ca Subject: Re: tspecials again In-Reply-To: Your message of "Tue, 22 Sep 1992 09:56:15 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 22 Sep 1992 10:58:41 -0700 Message-Id: <18823.717184721@dbc.mtview.ca.us> Sender:ietf-archive-request@IETF.NRI.Reston.VA.US From: Marshall Rose Mark - in my implementation, I relaxed the tspecial checking. The reason was simple: I anticipated losing this battle when the MIME spec comes up for revision. Basically, I figured it would be easier to just concede rather than listen to a lot of whining. As such, some might consider it bad taste on your part to complain. (-: However, the fact remain that, outside of a typo in one example, the MIME spec is very clear on the use of tspecials. One can view the typo as a bug, but one can not view the rules as a bug. Nonetheless, I'm sure we'll end up changing them. /mtr   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa10536; 22 Sep 92 15:29 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa10528; 22 Sep 92 15:29 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa17669; 22 Sep 92 15:33 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA19288; Tue, 22 Sep 92 15:08:14 EDT Received: from mx1.cac.washington.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA19283; Tue, 22 Sep 92 15:08:11 EDT Received: from Ikkoku-Kan.Panda.COM by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA14715; Tue, 22 Sep 92 12:08:06 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NeXT-1.0 (From Sendmail 5.52)/UW-NDC/Panda Revision: 2.27.MRC ) id AA03029; Tue, 22 Sep 92 12:08:01 PDT Date: Tue, 22 Sep 1992 11:55:02 -0700 (PDT) Sender:ietf-archive-request@IETF.NRI.Reston.VA.US From: Mark Crispin X-Orig-Sender: Mark Crispin Subject: Re: tspecials again To: IETF Mail Extensions WG In-Reply-To: <18823.717184721@dbc.mtview.ca.us> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Marshall - I relaxed the rule too. That has led me into more problems. Now, some instances of my software in the field have the relaxed rule, and some have the strict rule. I have no way of exterminating the old software except hope for the passage of time. And, of course, the old software is `right' and the new software is `wrong'. This all could have been fixed a long time ago with much less hassle. I don't know who was responsible for adding dot to tspecials. I know it was not there once upon a time. I know because I invented tspecials; expressly to exclude dot (which appeared in RFC-822 specials) from token delimiters. I'm sorry that I get very frustrated when I end up wasting huge amounts of time dealing with interoperability problems that could have been prevented if people who should know better weren't unreasonably stubborn. Perhaps I should see having to solve the same problems over and over again as a form of job security. -- Mark --   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa12911; 22 Sep 92 17:44 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa12903; 22 Sep 92 17:44 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa22422; 22 Sep 92 17:48 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA20291; Tue, 22 Sep 92 16:35:20 EDT Received: from nexus.yorku.ca by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA20287; Tue, 22 Sep 92 16:35:15 EDT Received: from localhost ([127.0.0.1]) by nexus.yorku.ca with SMTP id <9221>; Tue, 22 Sep 1992 16:35:05 -0400 To: IETF Mail Extensions WG Cc: Dave Collier-Brown Subject: Re: tspecials again Date: Tue, 22 Sep 1992 16:34:56 -0400 Sender:ietf-archive-request@IETF.NRI.Reston.VA.US From: davecb@nexus.yorku.ca Message-Id: <92Sep22.163505edt.9221@nexus.yorku.ca> In Mark Crispin writes: | Well, I just got finished with dealing with ANOTHER interoperability problem | caused by an implementor who innocently forgot to quote parameter strings with | an embedded period in it. Once again, the string in question was a filename, | the usual | name=foo.bar And I'm the implementer in question. While my program is intended as a throw-away translator for a format that I expect to be replaced (NeXT mail), I had read the specification with some care and did not really expect to be caught by this. I'd thought we'd learned parsimony from the experience of parsing multiple comment/quoting formats in RFC-822 mail (:-)). I respectfully request you consider changes to give you a grammar which is both unambigous and minimal. I submit that simplicity is a quality-of-specification issue that directly affects the quality of implementation and therefor the acceptance of those implementations. --dave   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa03509; 24 Sep 92 9:34 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03503; 24 Sep 92 9:34 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa07578; 24 Sep 92 9:38 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA01010; Thu, 24 Sep 92 09:17:37 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA01006; Thu, 24 Sep 92 09:17:35 EDT Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Thu, 24 Sep 92 09:17:34 EDT Received: by greenbush.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Thu, 24 Sep 92 09:17:32 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, 24 Sep 1992 09:17:29 -0400 (EDT) Message-Id: Date: Thu, 24 Sep 1992 09:17:29 -0400 (EDT) Sender:ietf-archive-request@IETF.NRI.Reston.VA.US From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: IETF Mail Extensions WG Subject: Re: tspecials again In-Reply-To: <92Sep22.163505edt.9221@nexus.yorku.ca> References: <92Sep22.163505edt.9221@nexus.yorku.ca> Is there ANYONE out there who thinks there is a good reason to keep tspecials the way they are? If so, you should speak soon or forever hold your peace, in my opinion. -- Nathaniel   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa16752; 25 Sep 92 0:31 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa16746; 25 Sep 92 0:30 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa00111; 25 Sep 92 0:35 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA11049; Fri, 25 Sep 92 00:13:07 EDT Received: from umail.umd.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA11045; Fri, 25 Sep 92 00:13:05 EDT Received: by umail.UMD.EDU (5.57/Ultrix3.0-C) id AA12067; Fri, 25 Sep 92 00:12:57 -0400 Date: Fri, 25 September 1992 00:13:06 -0500 Sender:ietf-archive-request@IETF.NRI.Reston.VA.US From: Dana S Emery To: IETF Mail Extensions WG Subject: Re: tspecials again Message-Id: In-Reply-To: Your message of Thu, 24 Sep 1992 09:17:29 -0400 (EDT) Content-Type: TEXT/plain; charset=US-ASCII > Is there ANYONE out there who thinks there is a good > reason to keep tspecials the way they are? > > If so, you should speak soon or forever hold your peace, > in my opinion. Im not sure what you imply by this, but my vote is with the changes proposed by MRC. ---- Dana S Emery