From owner-ietf-822@dimacs.rutgers.edu Sat Apr 6 14:57:48 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA13224; Sat, 6 Apr 91 14:12:51 EST Received: from porthos.rutgers.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA13220; Sat, 6 Apr 91 14:12:46 EST Received: by porthos.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA27039; Sat, 6 Apr 91 14:12:41 EST Date: Sat, 6 Apr 91 14:12:38 EST From: David Paul Zimmerman To: ietf-smtp@dimacs.rutgers.edu, ietf-822@dimacs.rutgers.edu Reply-To: "Reply to ietf-smtp-request or ietf-822-request -- not dpz"@cs.rutgers.edu Subject: new 822 list is alive! Message-Id: The IETF SMTP list's address is ietf-smtp@dimacs.rutgers.edu. The list's maintainer is ietf-smtp-request@dimacs.rutgers.edu. An archive of the mailing list is available via anonymous FTP from dimacs.rutgers.edu in pub/ietf-smtp-archive. The IETF 822 list's address is ietf-822@dimacs.rutgers.edu. The list's maintainer is ietf-822-request@dimacs.rutgers.edu. An archive of the mailing list is available via anonymous FTP from dimacs.rutgers.edu in pub/ietf-822-archive. Except for two specific requests (Mark Needleman and Don Jackson), everyone (including the redists) is currently on both of these lists. David From owner-ietf-822@dimacs.rutgers.edu Mon Apr 8 10:51:51 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA03480; Mon, 8 Apr 91 10:38:46 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA03476; Mon, 8 Apr 91 10:38:44 EDT Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Mon, 8 Apr 91 10:38:42 EDT Received: by greenbush.bellcore.com (4.12/4.7) id for ietf-822@dimacs.rutgers.edu; Mon, 8 Apr 91 10:41:58 edt Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.greenbush.mouseclub.sun4.40 via MS.5.6.greenbush.mouseclub.sun4_40; Mon, 8 Apr 1991 10:41:51 -0400 (EDT) Message-Id: Date: Mon, 8 Apr 1991 10:41:51 -0400 (EDT) From: Nathaniel Borenstein To: ietf-822@dimacs.rutgers.edu Subject: text --> IA5 ? I've started working on yet another draft RFC-XXXX, which I hope will, as a result of our latest discussions, bring us much closer to a consensus. One of the things I'd like to do is get rid of "Content-type: text" which, as Stef, has pointed out, is kind of ambiguous. Neither Stef nor I, however, are sure what the right replacement would be. Here are some possibilities: Content-type: IA5 Content-type: USASCII Content-type: NVT-ASCII Does anyone have a strong feeling about the "right" name for this content-type, which is to be used as the formal designator for "the established default"? At this point, anyone with a strong opinion has a very good chance of winning by default.... -- Nathaniel From owner-ietf-822@dimacs.rutgers.edu Mon Apr 8 11:58:18 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA04283; Mon, 8 Apr 91 11:17:33 EDT Received: from qualcom.qualcomm.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA04279; Mon, 8 Apr 91 11:17:29 EDT Received: from [129.46.4.152] with SMTP by QUALCOMM.COM (5.64+/QUALCOMM/V1.0) id AA20373 for ietf-822@dimacs.rutgers.edu; Mon, 8 Apr 91 08:17:23 -0700 Date: Mon, 8 Apr 91 08:17:23 -0700 Message-Id: <9104081517.AA20373@QUALCOMM.COM> To: ietf-822@dimacs.rutgers.edu, Nathaniel Borenstein From: jwn2@qualcom.qualcomm.com Subject: Re: text --> IA5 ? > >Content-type: IA5 Too cryptic. >Content-type: USASCII Non-Americans will complain we're being chauvinistic :-) >Content-type: NVT-ASCII Too long. If we're voting, I vote for USASCII. Actually, the US is redundant...but then we still have to distinguish 7-bit ASCII from 8-bit, eh? (No offense intended to citizens of other "American" states...) -jwn2 From owner-ietf-822@dimacs.rutgers.edu Mon Apr 8 12:21:53 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA04371; Mon, 8 Apr 91 11:38:58 EDT Received: from [129.34.139.4] by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA04367; Mon, 8 Apr 91 11:38:55 EDT Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R1) with BSMTP id 4164; Mon, 08 Apr 91 11:38:50 EDT Date: 08 Apr 1991 11:37:51 EDT From: dan@watson.ibm.com (Walt Daniels) Phone: 914-784/863-6736 To: ietf-822@dimacs.rutgers.edu Message-Id: <040891.113751.dan@watson.ibm.com> Subject: text --> IA5 ? >Content-type: IA5 >Content-type: USASCII >Content-type: NVT-ASCII IA5 is a character set. USASCII is a codeset. I don't know what NVT-ASCII is. I would prefer if it refered to an ISO standard. I think IA5 is ISO 6429. In any case I think we are trying to specify the character set not the codeset. This mail is being sent from an EBCDIC system and is in IA5 but not in USACII (at least until it leaves here :-). From owner-ietf-822@dimacs.rutgers.edu Mon Apr 8 12:51:51 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA05032; Mon, 8 Apr 91 11:51:48 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA05028; Mon, 8 Apr 91 11:51:46 EDT Date: Mon 8 Apr 91 11:51:32-EDT From: John C Klensin Subject: Re: Inline excerpts (was: Re: Another look at 8 bit transport for...) To: kankkune@cs.helsinki.fi Cc: ietf-822@dimacs.rutgers.edu Message-Id: <671125892.390521.KLENSIN@INFOODS.MIT.EDU> In-Reply-To: <9104081458.AA10916@hydra.Helsinki.FI> Mail-System-Version: >However, would it be reasonable to have inline parts as >part of multipart messages? You could use some flag to indicate that the >part should be positioned right after the previous EOL, not starting a >new line. I suppose that if one wanted to do something with "content order" (I'm not sure what happened with that thread) it would be quite natural to attach this sort of thing to it, along with very precise language about where the embedded part actually stopped and ended, possibly by adding some special bracketing characters that would not be EOL sensitive. E.g., Content-order: 3,delimiter=/ Content-type: ASCII /The ancient symbol / Content-order: 4, delimiter=/ Content-type= GIF Content-encoding: HEX /010.../ Whether it is worth the trouble and complexity is another question. Clearly a lot of overhead to put in a single "character". john ------- From owner-ietf-822@dimacs.rutgers.edu Mon Apr 8 15:21:52 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA11828; Mon, 8 Apr 91 14:55:09 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA11824; Mon, 8 Apr 91 14:55:07 EDT Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Mon, 8 Apr 91 14:55:03 EDT Received: by greenbush.bellcore.com (4.12/4.7) id for ietf-822@dimacs.rutgers.edu; Mon, 8 Apr 91 14:58:20 edt Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.greenbush.mouseclub.sun4.40 via MS.5.6.greenbush.mouseclub.sun4_40; Mon, 8 Apr 1991 14:58:16 -0400 (EDT) Message-Id: Date: Mon, 8 Apr 1991 14:58:16 -0400 (EDT) From: Nathaniel Borenstein To: ietf-822@dimacs.rutgers.edu Subject: Re: text --> IA5 ? In-Reply-To: <9104081517.AA20373@QUALCOMM.COM> References: <9104081517.AA20373@QUALCOMM.COM> Between the answers posted to this list and the answers sent to me as mail, it's obvious that none of my suggested alternatives was good enough. The real problem, I think, is that the current default content-type for mail has never been well-enough defined for any of the more specific terms to properly apply. Thus, for example, calling it "NVT-ASCII" or "IA5" might actually be strengthening the constraints on it. While that might be desirable, it opens a major can of worms, and was not the intent. What I'm seeking is just a descriptive term for "what mail bodies are now assumed to be." How about simply Content-type: US-7-bit which is, at least, a non-technical term that somewhat describes the status quo.... From owner-ietf-822@dimacs.rutgers.edu Mon Apr 8 17:22:01 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA14517; Mon, 8 Apr 91 16:22:08 EDT Received: from Sun.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA14510; Mon, 8 Apr 91 16:22:01 EDT Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA25266; Mon, 8 Apr 91 13:21:58 PDT Received: from vision.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA09515; Mon, 8 Apr 91 13:21:57 PDT Received: by vision.Eng.Sun.COM (4.1/SMI-4.1) id AA11991; Mon, 8 Apr 91 13:22:40 PDT Date: Mon, 8 Apr 91 13:22:40 PDT From: lau@eng.sun.com (Vincent Lau) Message-Id: <9104082022.AA11991@vision.Eng.Sun.COM> To: ietf-822@dimacs.rutgers.edu Subject: Re: text --> IA5 ? > One of the things I'd like to do is get rid of > "Content-type: text" which, as Stef, has pointed out, is kind of > ambiguous. Neither Stef nor I, however, are sure what the right > replacement would be. Here are some possibilities: > Although "text" may sound ambiguous, the contents should be human readable. I would like to suggest a slightly different approach. Warning: it may be controversial. That is to create a new header (e.g. Codeset: ) to identify the codeset being used in the contents. Why? I have an NROFF document which uses tbl and mm macros, but it contains ISO-8859-1 characters. According to RFC 1148, the content-type becomes: Content-Type: nroff; null; tbl, ms There is no place to identify the character set/codeset. If a new header is created, I can specify it as: Content-Type: nroff; null; tbl, ms Codeset: ISO-8859-1 (or whatever the convention we define) Note, it is merely a suggestion. It is controversial because some mailers don't care if nroff document contains non-7-bit-ASCII as long as Content-Encoding does the right thing. If you feel that it is too controversial, I will not mention it again. Some people may feel that Content-Type should contain the semantic meaning, but not the actual implementation. I am not saying that it is a right way, but it brings up an interesting question. Should we recommend the type names format: should it be in hierarchy format (such as "company"-"type") or just a flat type space? For example, in flat type space, if company A has implemented voice data-type and registered it as "voice". When company B has implemented its own voice data-type, it must register the type as anything other than "voice". In hierachy format, the name will be "A-voice" and "B-voice". In a drastic approach, there will be only *one* type "voice" registered and it uses different field to identify the implementation. Any comment on this? -Vincent From owner-ietf-822@dimacs.rutgers.edu Mon Apr 8 18:22:03 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA17384; Mon, 8 Apr 91 17:39:17 EDT Received: from RUTGERS.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA17379; Mon, 8 Apr 91 17:39:13 EDT Received: from nrtc.northrop.com by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA02030; Mon, 8 Apr 91 17:39:00 EDT Received: from nma.com by nrtc.nrtc.northrop.com id ab02524; 8 Apr 91 13:34 PST Received: from odin.nma.com by nma.com id aa02594; 8 Apr 91 12:11 PDT To: Nathaniel Borenstein Cc: ietf-822@dimacs.rutgers.edu Subject: Re: text --> IA5 ? In-Reply-To: Your message of Mon, 08 Apr 91 10:41:51 -0500. Reply-To: Stef@ics.uci.edu From: Einar Stefferud Date: Mon, 08 Apr 91 13:09:54 MDT Message-Id: <9318.671141394@nma.com> Sender: stef@nma.com I would hope that the winner (see below) would be someone with a strong logical case for the choice, like "Here is the formal, unique, adopted International Standard, designation for exactly what RFC822 intended all along!" Best...\Stef > Here are some possibilities: > Content-type: IA5 > Content-type: USASCII > Content-type: NVT-ASCII > Does anyone have a strong feeling about the "right" name for this > acontent-type, which is to be used as the formal designator for "the > established default"? At this point, anyone with a strong opinion has a > very good chance of winning by default.... -- Nathaniel From owner-ietf-822@dimacs.rutgers.edu Mon Apr 8 20:22:02 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA20510; Mon, 8 Apr 91 19:57:02 EDT Received: from RUTGERS.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA20506; Mon, 8 Apr 91 19:57:00 EDT Received: from nrtc.northrop.com by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA10211; Mon, 8 Apr 91 19:56:57 EDT Received: from nma.com by nrtc.nrtc.northrop.com id ac03614; 8 Apr 91 15:56 PST Received: from odin.nma.com by nma.com id aa00187; 8 Apr 91 15:16 PDT To: Nathaniel Borenstein Cc: ietf-822@dimacs.rutgers.edu Subject: Re: text --> IA5 ? In-Reply-To: Your message of Mon, 08 Apr 91 14:58:16 -0500. Reply-To: Stef@ics.uci.edu From: Einar Stefferud Date: Mon, 08 Apr 91 16:15:20 MDT Message-Id: <9445.671152520@nma.com> Sender: stef@nma.com Well;-) I guess I now feel that my instincts were right on the mark. We don't know for sure what "text" means, do we! Best...\Stef From owner-ietf-822@dimacs.rutgers.edu Mon Apr 8 20:52:03 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA20519; Mon, 8 Apr 91 19:57:55 EDT Received: from RUTGERS.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA20514; Mon, 8 Apr 91 19:57:52 EDT Received: from nrtc.northrop.com by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA10251; Mon, 8 Apr 91 19:57:47 EDT Received: from nma.com by nrtc.nrtc.northrop.com id ad03614; 8 Apr 91 15:56 PST Received: from odin.nma.com by nma.com id aa00201; 8 Apr 91 15:23 PDT To: John C Klensin Cc: kankkune@cs.helsinki.fi, ietf-822@dimacs.rutgers.edu Subject: Re: Inline excerpts (was: Re: Another look at 8 bit transport for...) In-Reply-To: Your message of Mon, 08 Apr 91 11:51:32 -0500. <671125892.390521.KLENSIN@INFOODS.MIT.EDU> Reply-To: Stef@ics.uci.edu From: Einar Stefferud Date: Mon, 08 Apr 91 16:22:14 MDT Message-Id: <9454.671152934@nma.com> Sender: stef@nma.com I am bothered by the comments shown below (with > prefixes). It seems to me that multi-part adn multi-media parts are very different beasts, whcih we should understand. We sho9uld avoid mixing them to gether too much. I don't see any point in trying to make out multi-part mechainsm into ODA where I can mix all sortsof theings to gether in a single body part. What I want is to be able to carry an ODA body part when I need such a thing, and to carry other body-parts when they suit my needs, but I do not want to convert all of RFC822bis into a new form of ODA, or even a partial form of ODA. A half baked RFC822oda is not of much value as I see it. Lets abandon trying to too far beyond hierarchical multi-part structures. Best...\Stef >>However, would it be reasonable to have inline parts as >>part of multipart messages? You could use some flag to indicate that the >>part should be positioned right after the previous EOL, not starting a >>new line. > >I suppose that if one wanted to do something with "content order" (I'm >not sure what happened with that thread) it would be quite natural to >attach this sort of thing to it, along with very precise language about >where the embedded part actually stopped and ended, possibly by adding >some special bracketing characters that would not be EOL sensitive. >E.g., >a Content-order: 3,delimiter=/ > Content-type: ASCII > /The ancient symbol / > > Content-order: 4, delimiter=/ > Content-type= GIF > Content-encoding: HEX > > /010.../ > >Whether it is worth the trouble and complexity is another question. >Clearly a lot of overhead to put in a single "character". > john From owner-ietf-822@dimacs.rutgers.edu Mon Apr 8 21:22:03 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA22893; Mon, 8 Apr 91 21:16:45 EDT Received: from RUTGERS.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA22889; Mon, 8 Apr 91 21:16:42 EDT Received: from nrtc.northrop.com by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA15012; Mon, 8 Apr 91 21:16:32 EDT Received: from nma.com by nrtc.nrtc.northrop.com id ab03955; 8 Apr 91 17:15 PST Received: from odin.nma.com by nma.com id aa00341; 8 Apr 91 16:41 PDT To: jwn2@qualcom.qualcomm.com Cc: ietf-822@dimacs.rutgers.edu, Nathaniel Borenstein Subject: Re: text --> IA5 ? In-Reply-To: Your message of Mon, 08 Apr 91 08:17:23 -0800. <9104081517.AA20373@QUALCOMM.COM> Reply-To: Stef@ics.uci.edu From: Einar Stefferud Date: Mon, 08 Apr 91 17:40:33 MDT Message-Id: <9567.671157633@nma.com> Sender: stef@nma.com I note that you did not suggest that IA5 is too unambiguous! >>Content-type: IA5 >Too cryptic. >>Content-type: USASCII >Non-Americans will complain we're being chauvinistic :-) >>Content-type: NVT-ASCII >Too long. > >If we're voting, I vote for USASCII. Actually, the US is redundant...but >then we still have to distinguish 7-bit ASCII from 8-bit, eh? (No offense >intended to citizens of other "American" states...) -jwn2 How is it that something can be redundant, and its absence can then cause a failure to distinguish. )-:-) I vote for the one that is most unambiguous, believing that accepting ambiguity in the interests of avoiding things like "too cryptic" "chauvanistic" is just not useful in terms of our objectives. I am becoming very baffled by this discussion. Is this a standards meeting, or am I really at the IMPROV in Hollywood? I always did want to be a stand-up comic, but I never thought to do it here. Best...\Stef From owner-ietf-822@dimacs.rutgers.edu Tue Apr 9 03:50:35 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA07630; Tue, 9 Apr 91 03:33:22 EDT Received: from citi.umich.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA07625; Tue, 9 Apr 91 03:33:16 EDT Message-Id: <9104090733.AA07625@dimacs.rutgers.edu> From: Bruce Howard To: jwn2@qualcom.qualcomm.com, Stef@ics.uci.edu Cc: nsb@thumper.bellcore.com, ietf-822@dimacs.rutgers.edu Date: Tue, 9 Apr 91 03:32 EDT Subject: Re: text --> IA5 ? From: Einar Stefferud To: jwn2@qualcom.qualcomm.com Cc: ietf-822@dimacs.rutgers.edu, Nathaniel Borenstein Subject: Re: text --> IA5 ? I note that you did not suggest that IA5 is too unambiguous! >>Content-type: IA5 >Too cryptic. >>Content-type: USASCII >Non-Americans will complain we're being chauvinistic :-) [ rest deleted ] hmm. does spanish have any funky characters? i seem to remember reading that puerto rico voted spanish the "state" language recently...perhaps united states americans will complain as well...or not if there are no special characters. unfortunately, ignorance leaves me uncertain on this point... bruce From owner-ietf-822@dimacs.rutgers.edu Tue Apr 9 10:19:09 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA16803; Tue, 9 Apr 91 10:17:46 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA16799; Tue, 9 Apr 91 10:17:44 EDT Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Tue, 9 Apr 91 10:17:40 EDT Received: by greenbush.bellcore.com (4.12/4.7) id for ietf-822@dimacs.rutgers.edu; Tue, 9 Apr 91 10:21:01 edt Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.greenbush.mouseclub.sun4.40 via MS.5.6.greenbush.mouseclub.sun4_40; Tue, 9 Apr 1991 10:20:56 -0400 (EDT) Message-Id: Date: Tue, 9 Apr 1991 10:20:56 -0400 (EDT) From: Nathaniel Borenstein To: ietf-822@dimacs.rutgers.edu Subject: Re: text --> IA5 ? In-Reply-To: <9104082022.AA11991@vision.Eng.Sun.COM> References: <9104082022.AA11991@vision.Eng.Sun.COM> Vincent's latest message was, as usual, thoughtful and reasonable. It also worries me. The problem appears to be what I would characterize as the attempt to *combine* two different content-types. In this case, we have the apparently reasonable request for nroff source with an international character set. This seems to violate a very fundamental assumption that we've been making all along, which is that mail messages (or parts of messages) are uniquely typed. Here we have a sort of "multiple inheritance" problem, and at least two radical solutions might spring to mind: -- make character sets & content types independent (Vincent mentioned this one, as did Timo earlier) -- allow somehow for general-case multiple or cascaded content-types I'm very reluctant to go down either of these paths, because I think that there is a LOT of potential complexity here to support what I really think are likely to be "pathological" cases. In this particular example, nroff is an ancient and poorly-defined "rich text" representation. Unlike most such representations, it doesn't really explicitly address character set issues, and so it is almost necessary to think of nroff and character sets as independent. However, this is NOT the case for most modern text representations. For example, when Andrew (which is by no means state-of-the-art in its dealing with multiple charactersets) sends messages in non-standard character sets, it uses a representation for them that means that the whole overall message is in US ASCII. In almost all other cases that I know of, rich text formats explicitly deal with character set issues, as well they should. That is, there is a standard file format, for each of these representations, that encodes character sets among other things. This is NOT the case for nroff, of course, for which charsets are "out-of-band" information. The question that remains, I think, is a simple one: how many troublesome cases like Vincent's example will there really be, and how important are they? Without much evidence to support it, I have a gut feeling that the answer is "not too many and not too important." If this is the case, we can handle them much more simply with a small proliferation of content-types, e.g.: Content-Type: nroff/iso-8859-1; null; tbl, ms In other words, if there aren't too many such cases, we can handle them by defining different content-types to handle the charset-variations within a type such as nroff. Anyway, the argument above is my gut response, which is strongly motivated by a desire not to open new cans of worms at this stage. I fully realize that there are some cans that just have to be opened, and I suppose I might yet be convinced that this is one of them, but I'm not convinced just yet... -- Nathaniel From owner-ietf-822@dimacs.rutgers.edu Tue Apr 9 11:19:10 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA18323; Tue, 9 Apr 91 11:07:43 EDT Received: from NRI.RESTON.VA.US by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA18319; Tue, 9 Apr 91 11:07:38 EDT Received: from NRI by NRI.NRI.Reston.VA.US id aa18412; 9 Apr 91 10:58 EDT To: Nathaniel Borenstein Cc: ietf-822@dimacs.rutgers.edu, gvaudre@nri.reston.va.us Subject: Compression, and nested encodings In-Reply-To: Your message of "Tue, 09 Apr 91 10:20:56 EDT." Date: Tue, 09 Apr 91 10:58:50 -0400 From: Greg Vaudreuil Message-Id: <9104091058.aa18412@NRI.NRI.Reston.VA.US> > The question that remains, I think, is a simple one: how many > troublesome cases like Vincent's example will there really be, and how > important are they? There is one more significant case we decided not to look at at St. Louis for fear of getting a migraine. Many people believe that compression should be included in the message format. I'm not sure where the best place to put it is but both of the current headers are good ideas. Compression can be viewed as another level of encoding, which is independent of the base encoding of a part. This is a tar|compress|uuencode case. These are all ways of altering the data representation and are not mutually exclusive. I have heard people suggest that this concept of nested encodings is a good thing. Another way to view compression is as a separate data type. This is: type: fax|compressed encoding: uuencode This argues for nested content-type fields. This idea stems from Nathaniels question about other strange encoding cases. I'm not sure the need for nested content-types is justified by the compression case, but is another possibility for such a facility. In the case of 8 bit nroff, or LaTeX or any of our favorite mark-up, document enhancement languages, we should not try to identify what is contained in the part. What is a LaTeX document with boxes and charts called? Text? Think of this as a parallel of ODA. We just name it and send it. If the application cannot differentiate the data, it is not up to the mail message format protocols to define it for the application. Think of Word Perfect. It can represent many foreign characters, but I do not think that we need to declare in the content-type header what characters are used in the document. Mail is just providing transport to these applications. If the nroff has a 8 bit character in it, then it obviously needs to be encoded, so specify that. This is wierd in that nroff may or may not need encoding, but I do not think we need to define a character set for it. We may have to be explicit in the definition of the Type: nroff whether it needs to be encoded or not when sending over a normal 7 bit datapath, and that will largely determined by whether or not the program itself is capabile of dealing with 8 bit characters. If it is.... it must be encoded! Quoted Printable was defined for just such cases. Thoughts? Greg V. From owner-ietf-822@dimacs.rutgers.edu Tue Apr 9 11:52:56 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA19008; Tue, 9 Apr 91 11:30:08 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA18999; Tue, 9 Apr 91 11:30:05 EDT Date: Tue 9 Apr 91 11:29:58-EDT From: John C Klensin Subject: Re: text --> IA5 ? To: nsb@thumper.bellcore.com, ietf-822@dimacs.rutgers.edu Message-Id: <671210998.413521.KLENSIN@INFOODS.MIT.EDU> In-Reply-To: Mail-System-Version: Nathaniel writes... >Vincent's latest message was, as usual, thoughtful and reasonable. It >also worries me. Me, too. >The question that remains, I think, is a simple one: how many >troublesome cases like Vincent's example will there really be, and how >important are they? Without much evidence to support it, I have a gut >feeling that the answer is "not too many and not too important." My gut feeling is that, if this is carried to its logical extreme, the answer would be "perhaps very important, and a great many". Consider the multipliers involved: if you accept "nroff" as motivating a content type, recall that nroff is the product of one operating system and a relatively small number of things that have cloned its (nroff's) code. But fairly low-level formatting languages exist at roughly a one-one ratio to operating systems, plus or minus a few, so... Content-type: dsr/... Content-type: script/... Content-type: scribe/... Content-type: compose/... and so one and so forth. This makes a very good place to consider how far one wants to go, and I'd refer people back to Stef's recent message for what I consider a persuasive case. There is a critter called ODA. It is designed for the handling and representation of structured, rich text format, documents that contain combinations of variant character sets and/or, e.g., special format codings. IETF management, in its infinite wisdom, has created a WG on ODA over Internet mail. I would suggest that this is a reasonable place to draw the line and that, if the ODA types are not rich enough to handle nroff and 8859-1, we send people off to the ISO WGs and make that happen. In other words, for both this case, and for other cases where carefully- structured text is needed (maybe imbedded in-line funny glyphs, per Risto's example, maybe even ordered content sections), we introduce one additional content type, ODA, and then let those folks do their thing. The question shouldn't be whether we can diddle Content-type to handle every imaginable case (we are collectively certainly smart enough to do that), but how to figure out where to stop. I think Vincent's example should be used to open debate on the question. Stef thinks Risto's example (and my comments on it) should be used to open debate on the question. We are probably both right, not necessarily about the conclusion, but that a little meta-level consideration of whether it is desirable and necessary to make this sort of thing work as part of Content-type is in order before working on the engineering details of how to do it. Curiously, being able to say "that is an ODA problem", when appropriate, meets Nathaniel's criterion about not opening cans of worms: it involves taking the closed can, worms and all, and passing it to someone else with instructions that it is their problem. If ODA is adequate today (it may not be), "they" will have very docile worms when they do open the can. ---john ------- From owner-ietf-822@dimacs.rutgers.edu Tue Apr 9 13:19:12 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA23068; Tue, 9 Apr 91 13:00:20 EDT Received: from relay.cdnnet.ca by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA23064; Tue, 9 Apr 91 13:00:13 EDT Received: by relay.CDNnet.CA (4.1/1.14) id AA08437; Tue, 9 Apr 91 09:59:51 PDT Date: 9 Apr 91 9:58 -0700 From: Brian Wideen To: John C Klensin Cc: nsb@thumper.bellcore.com, ietf-822@dimacs.rutgers.edu In-Reply-To: <671210998.413521.KLENSIN@INFOODS.MIT.EDU> Message-Id: <9104092791*Brian.Wideen@Vancouver.osiware.bc.ca> Subject: Re: text --> IA5 ? John argues that ODA is the answer that meets key requirements regarding flexibility (to carry documents from a variety of sources) and simplicity (in terms of content-type handling). Further, details regarding format can be punted to the IETF & ISO WGs responsible. I like this general solution to a general problem, being superior to the specific solutions outlined so far. To mandate nroff is too limiting and too parochial (Unix-oriented). It does not facilitate general exchange, only allowing some members of the Unix-community to exchange documents. From owner-ietf-822@dimacs.rutgers.edu Tue Apr 9 14:19:10 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA26083; Tue, 9 Apr 91 14:16:44 EDT Received: from RUTGERS.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA26076; Tue, 9 Apr 91 14:16:37 EDT Received: from nrtc.northrop.com by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA00602; Tue, 9 Apr 91 14:16:17 EDT Received: from nma.com by nrtc.nrtc.northrop.com id aa06980; 9 Apr 91 10:15 PST Received: from odin.nma.com by nma.com id aa01352; 9 Apr 91 10:02 PDT To: Brian Wideen Cc: John C Klensin , nsb@thumper.bellcore.com, ietf-822@dimacs.rutgers.edu Subject: Re: text --> IA5 ? In-Reply-To: Your message of 09 Apr 91 09:58:00 -0800. <9104092791*Brian.Wideen@Vancouver.osiware.bc.ca> Reply-To: Stef@ics.uci.edu From: Einar Stefferud Date: Tue, 09 Apr 91 11:00:51 MDT Message-Id: <9995.671220051@nma.com> Sender: stef@nma.com Hello Brian -- I believe we agree. Just want to be sure. I am not advocating ODA per se, but noting that where users want to include different fonts and different character sets in single body parts, they should do so with tools designed for that purpose, rather then imposing a general requirement on our RFC822bis design to be all things to all poeple, and in essence reinvent a combination of ODA/et-al. Best...\Stef From owner-ietf-822@dimacs.rutgers.edu Tue Apr 9 14:50:31 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA26911; Tue, 9 Apr 91 14:41:09 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA26906; Tue, 9 Apr 91 14:41:06 EDT Date: Tue 9 Apr 91 14:40:55-EDT From: John C Klensin Subject: Re: text --> IA5 ? To: Stef@ics.uci.edu Cc: ietf-822@dimacs.rutgers.edu Message-Id: <671222455.282521.KLENSIN@INFOODS.MIT.EDU> In-Reply-To: <9995.671220051@nma.com> Mail-System-Version: Stef writes... >I am not advocating ODA per se, but noting that where users want to >include different fonts and different character sets in single body >parts, they should do so with tools designed for that purpose, rather >then imposing a general requirement on our RFC822bis design to be all >things to all poeple, and in essence reinvent a combination of >ODA/et-al. Best...\Stef Me neither. ODA --probably in some combination with SGML-- just seems to be an appropriate framework for doing this sort of thing right and, perhaps more important, *once*. It is really Brian's comment that would characterize my hope: that passing this problem off to someone else who is at an appropriate stage in *their* development to do something with it, and then "encourage" them to make sure that cases relevant to us are covered will result in better solutions in their area, a better RFC822 extension, and complete compatibility between X.400 and SMTP/RFC822bis for the most complex documents around. One could ask for little more; the only question is just where to draw the lines. john ------- From owner-ietf-822@dimacs.rutgers.edu Tue Apr 9 15:19:10 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA27835; Tue, 9 Apr 91 14:58:39 EDT Received: from RUTGERS.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA27828; Tue, 9 Apr 91 14:58:32 EDT Received: from nrtc.northrop.com by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA03344; Tue, 9 Apr 91 14:58:14 EDT Received: from nma.com by nrtc.nrtc.northrop.com id ad07181; 9 Apr 91 10:56 PST Received: from odin.nma.com by nma.com id aa01418; 9 Apr 91 10:53 PDT To: Bruce Howard Cc: jwn2@qualcom.qualcomm.com, nsb@thumper.bellcore.com, ietf-822@dimacs.rutgers.edu Subject: Re: text --> IA5 ? In-Reply-To: Your message of Tue, 09 Apr 91 03:32:00 -0500. <9104090733.AA07625@dimacs.rutgers.edu> Reply-To: Stef@ics.uci.edu From: Einar Stefferud Date: Tue, 09 Apr 91 11:52:01 MDT Message-Id: <10091.671223121@nma.com> Sender: stef@nma.com Oh, come off it! What is all this Americans baiting about? I am only talking about putting an unabiguous label on whatever it is that RFC822 defined to be the character set/encoding for RFC822 mail. This has nothing whatever to with why it was chosen or whether it is good, or bad, or whatever. Whatever it is, it is! Quite frankly, I am not even a little bit amused by these no-sequitors! Over and out...\Stef > hmm. does spanish have any funky characters? i seem to remember > reading that puerto rico voted spanish the "state" language > recently...perhaps united states americans will complain as well...or > not if there are no special characters. unfortunately, ignorance > leaves me uncertain on this point...bruce From owner-ietf-822@dimacs.rutgers.edu Tue Apr 9 15:49:10 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA28935; Tue, 9 Apr 91 15:26:24 EDT Received: from relay.cdnnet.ca by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA28931; Tue, 9 Apr 91 15:26:10 EDT Received: by relay.CDNnet.CA (4.1/1.14) id AA11394; Tue, 9 Apr 91 12:25:30 PDT Date: 9 Apr 91 12:24 -0700 From: Einar Stefferud Sender: Brian Wideen To: Brian Wideen Cc: John C Klensin , nsb@thumper.bellcore.com, ietf-822@dimacs.rutgers.edu Reply-To: Stef@ics.uci.edu In-Reply-To: Message-Id: <9104092798*Brian.Wideen@Vancouver.osiware.bc.ca> Subject: Re: text --> IA5 ? Hello Brian -- I believe we agree. Just want to be sure. I am not advocating ODA per se, but noting that where users want to include different fonts and different character sets in single body parts, they should do so with tools designed for that purpose, rather then imposing a general requirement on our RFC822bis design to be all things to all poeple, and in essence reinvent a combination of ODA/et-al. Best...\Stef From owner-ietf-822@dimacs.rutgers.edu Tue Apr 9 16:19:10 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA29413; Tue, 9 Apr 91 15:36:41 EDT Received: from RUTGERS.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA29404; Tue, 9 Apr 91 15:36:35 EDT Received: from nrtc.northrop.com by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA05667; Tue, 9 Apr 91 15:36:11 EDT Date: Tue, 9 Apr 91 15:36:11 EDT From: @odin.nma.com:stef@nma.com Message-Id: <9104091936.AA05667@rutgers.edu> Received: from nma.com by nrtc.nrtc.northrop.com id ab07370; 9 Apr 91 11:34 PST Received: from odin.nma.com by nma.com id aa01483; 9 Apr 91 11:35 PDT To: John C Klensin Cc: ietf-822@dimacs.rutgers.edu ietf-822@dimacs.rutgers.EDU Subject: Re: text --> IA5 ? In-reply-to: Your message of Tue, 09 Apr 91 14: 40:55 -0500. <671222455.282521.KLENSIN@INFOODS.MIT.EDU> Reply-to: Stef@ics.uci.edu From: Einar Stefferud Date: Tue, 09 Apr 91 12:33:44 MDT Message-ID: <10179.671225624@nma.com> Sender: stef@nma.com Thanks John -- I think the right place to draw the line is at the concept of identifiable whole body parts, with perhaps a little extension to indicate the existance of some potential concurrency among some body-parts, but no requirement that the indication of concurency must result in concrrent action on the part of any UA. (Per some comments from Nathaniel a while back.) I expect that we should not exceed the capabilities of X.400 in this regard, for any linkage among the body-parts carried in an IPM envelope. Lets not exceed X.400 in this reard. I believe that anything more complext than this should be part of a separate standard for structured multi-media objects that are entirely independent of mail, so they may be transported in any way that is interesting and available. FTP, TAPE, DISKETTES, BAR-CODES, whatever.. To me, multi-media mail is just a tool for carrying multiple objects of arbitrary kinds. I do not want to limit the kinds in any way, though I understand fully that we need standards so that composers can expect recipients to be able to understand what composers compose. So, I want to shunt this complecity to the multi-media object developemnt track. Best...\Stef From owner-ietf-822@dimacs.rutgers.edu Tue Apr 9 17:19:13 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA03406; Tue, 9 Apr 91 16:59:23 EDT Received: from Sun.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA03400; Tue, 9 Apr 91 16:59:17 EDT Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA19233; Tue, 9 Apr 91 13:59:14 PDT Received: from skylark.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA15605; Tue, 9 Apr 91 13:59:12 PDT Received: by skylark.Eng.Sun.COM (4.1/SMI-4.1) id AA06062; Tue, 9 Apr 91 13:53:46 PDT Date: Tue, 9 Apr 91 13:53:46 PDT From: katin@eng.sun.com (Neil Katin) Message-Id: <9104092053.AA06062@skylark.Eng.Sun.COM> To: ietf-822@dimacs.rutgers.edu Subject: Re: text --> IA5 ? Wait. I think some people have missed Vincent's point, and have gotten too wrapped up in the particular example. The example of nroff was *not* proposing nroff as the "net standard formatting language". It was only trying to be an example of an older program which does not internally identify the character set that it uses; therefore the character set needs to be represented on the outside of the body part. There have been two proposed solutions: concatenate the character set identifier along with the type name, or represent the character set in a separate header field of its own. These solutions are clearly equivalent in the information transmission sense -- anything that one can represent the other can too. The choice between them will be made because of differences in style and religion rather than because "something couldn't be done" one way or the other. With that said, I'ld like to state my opinion: I think that the "character set encoding" information should be split to a different field. Why? I have a model where there are pieces of information that the "mail system" wants to understand, independent of the data type -- things like encoding method(s), compression method(s), character encodings, etc. This is all information on the body part "envelope"; things that are carried around in addition to the actual data. Just today we've already heard two different positional combinations of the type field: type/character_set and type/compression. One can easily believe that new things will need to be standardized. The easiest way to do this is to give these attributes their own header field in the body part, rather than trying to positionally represent them in the type field. About Nathaniel's point with respect to nroff being "old technology" that doesn't internally identify a character set (whereas things like postscript, Andrew, etc, internally represent the character set) -- like it or not these things abound in today's world, and we should make sure that we pass enough information to properly display the document on the user's screen. Neil From owner-ietf-822@dimacs.rutgers.edu Tue Apr 9 18:11:00 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA04975; Tue, 9 Apr 91 17:48:28 EDT Received: from qualcom.qualcomm.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA04969; Tue, 9 Apr 91 17:48:19 EDT Received: by QUALCOMM.COM (5.64+/QUALCOMM/V1.0) id AA06091 for ietf-822@dimacs.rutgers.edu; Tue, 9 Apr 91 14:48:07 -0700 Date: Tue, 9 Apr 91 14:48:07 -0700 From: jwn2@qualcomm.com (John Noerenberg) Message-Id: <9104092148.AA06091@QUALCOMM.COM> To: ietf-822@dimacs.rutgers.edu, nsb@thumper.bellcore.com Subject: Re: text --> IA5 ? > The question that remains, I think, is a simple one: how many > troublesome cases like Vincent's example will there really be, and how > important are they? Without much evidence to support it, I have a gut > feeling that the answer is "not too many and not too important." If > this is the case, we can handle them much more simply with a small > proliferation of content-types, e.g.: > > Content-Type: nroff/iso-8859-1; null; tbl, ms > > In other words, if there aren't too many such cases, we can handle them > by defining different content-types to handle the charset-variations > within a type such as nroff. > I disagree, Nathaniel. Vincent's example demonstrates that the central question remains "What is meant by content-type?". Is a content-type a symbol-mapping, or is it a language-mapping? Your original choices -- IA5, USASCII, or NVT-ASCII specify a symbol map. But Vincent suggests the latter. It seems to me that part of what you are trying to do is specify the lingua franca of messages, besides provide a method to negotiate some other encoding. I believe this is the proper thing to do. But trying to enumerate the universe of language maps is probably a fruitless task. Any enumeration will restrict the set of content-types, which is definitely the wrong thing. Let us specify that the symbol set for describing message parts shall be USASCII. Further, I suggest that the interpretation of the content-type argument be left to the UAs. In the absence of any content-type specifi- cation, the bytes of data should be interpreted as USASCII symbols. This provides a framework for communication, and provides a means to negotiate more complex encodings without restricting the set of content- types available. (It also avoids having to decide if content-type is a symbol map or a language :-) But I believe this _should_ be left to the discretion of the UAs.) I think it would be wise to provide a list of well-known content types, and the rules for their interpretation as examples. But I don't believe (nor do I think it is your intent that) the RFC should restrict the range of content-types included in messages. -jwn2 From owner-ietf-822@dimacs.rutgers.edu Tue Apr 9 20:49:12 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA09767; Tue, 9 Apr 91 20:16:37 EDT Received: from RUTGERS.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA09761; Tue, 9 Apr 91 20:16:33 EDT Received: from nrtc.northrop.com by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA22014; Tue, 9 Apr 91 20:16:16 EDT Received: from nma.com by nrtc.nrtc.northrop.com id aa08827; 9 Apr 91 16:15 PST Received: from odin.nma.com by nma.com id aa01829; 9 Apr 91 16:08 PDT To: John Noerenberg Cc: ietf-822@dimacs.rutgers.edu, nsb@thumper.bellcore.com Subject: Re: text --> IA5 ? In-Reply-To: Your message of Tue, 09 Apr 91 14:48:07 -0800. <9104092148.AA06091@QUALCOMM.COM> Reply-To: Stef@ics.uci.edu From: Einar Stefferud Date: Tue, 09 Apr 91 17:06:07 MDT Message-Id: <10507.671241967@nma.com> Sender: stef@nma.com I am becoming more and more confused. I thought we were (at this point0 only rtrying to decide exactly how to identify (what label to use to identify) the character set that is (was) specified in the original RFC822. Howabout calling it "822ASCII" since that is exactly what we mean. Now, did RFC822 really nail down what character set it meant to be used? I have heard of something called "NVT-ASCII" whatever that is. I am beginning to wonder how we have managed for all these years to not get messed up on this question of what the original character set was (is)! Beyond this, I do agree that we should decide what is the exact character set to be allowed in the body-part headers, but that was not the original question. Fine by me if it is chosen to be "822ASCII". Best...\Stef From owner-ietf-822@dimacs.rutgers.edu Tue Apr 9 21:50:13 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA11830; Tue, 9 Apr 91 21:18:49 EDT Received: from qualcom.qualcomm.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA11826; Tue, 9 Apr 91 21:18:44 EDT Received: by QUALCOMM.COM (5.64+/QUALCOMM/V1.0) id AA21210 for ietf-822@dimacs.rutgers.edu; Tue, 9 Apr 91 18:18:33 -0700 Date: Tue, 9 Apr 91 18:18:33 -0700 From: jwn2@qualcomm.com (John Noerenberg) Message-Id: <9104100118.AA21210@QUALCOMM.COM> To: Stef@ics.uci.edu, jwn2@qualcomm.com Subject: Re: text --> IA5 ? Cc: ietf-822@dimacs.rutgers.edu, nsb@thumper.bellcore.com > I am becoming more and more confused. I thought we were (at this > point0 only rtrying to decide exactly how to identify (what label to > use to identify) the character set that is (was) specified in the > original RFC822. OK, we kinda got off on the content-type tangent. > > Howabout calling it "822ASCII" since that is exactly what we mean. > > Now, did RFC822 really nail down what character set it meant to be > used? I have heard of something called "NVT-ASCII" whatever that is. Yes it did! Here's the relevant rules: CHAR = ; ( 0-177, 0.-127.) text = atoms, specials, CR & bare LF, but NOT ; comments and including CRLF> ; quoted-strings are ; NOT recognized. message = fields *( CRLF *text ) ; Everything after > > I am beginning to wonder how we have managed for all these > years to not get messed up on this question of what the original > character set was (is)! Also from RFC822, this is Crocker, et al.'s reference for ASCII. ANSI. "USA Standard Code for Information Interchange," X3.4. American National Standards Institute: New York (1968). Also in: Feinler, E. and J. Postel, eds., "ARPANET Protocol Hand- book", NIC 7104. When I say "ASCII", this is the ASCII I mean. But, I'm with Stef. This discussion is getting silly. I really don't care what the label is. Nathaniel, this is your RFC, you name the label, just pick something! :-) I promise not to say another word...at least for a while :-) -jwn2 From owner-ietf-822@dimacs.rutgers.edu Wed Apr 10 02:19:12 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA20371; Wed, 10 Apr 91 01:55:24 EDT Received: from RUTGERS.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA20367; Wed, 10 Apr 91 01:55:21 EDT Received: from nrtc.northrop.com by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA15514; Wed, 10 Apr 91 01:55:01 EDT Received: from nma.com by nrtc.nrtc.northrop.com id aa09697; 9 Apr 91 21:54 PST Received: from odin.nma.com by nma.com id aa02124; 9 Apr 91 21:29 PDT To: ietf-822@dimacs.rutgers.edu, nsb@thumper.bellcore.com Cc: John Noerenberg Subject: Re: text --> IA5 ? In-Reply-To: Noerenberg message of Tue, 09 Apr 91 18:18:33 -0800. <9104100118.AA21210@QUALCOMM.COM> Reply-To: Stef@ics.uci.edu From: Einar Stefferud Date: Tue, 09 Apr 91 22:26:41 MDT Message-Id: <10784.671261201@nma.com> Sender: stef@nma.com OK -- From the last few messages, plus some off-list messages, we can see that the original definition was indeed ANSI X3.4, per the excerpt from RFC822. ANSI. "USA Standard Code for Information Interchange," X3.4. American National Standards Institute: New York (1968). Also in: Feinler, E. and J. Postel, eds., "ARPANET Protocol Hand- book", NIC 7104. Now then, RFC822 will never be changed from what it says, so we could easily refer to 822ascii and be entirely precise in RFC822bis by reference to this excerpted section of RFC822. It is also easy to see how it got the informal code of USascii. So, I will vote for either USascii or 822ascii, in the interests of being totally precise about what we mean. We should also cite it the same way in RFC822bis as in RFC822. That should not leave any wiggle room for anyone to miss what is intended. I will object to just using "ascii" because there seems to be a tendency for "ascii" to take on various shades of informal meaning among the populace. e.g., "8-bit ascii" has been mentioned here, along with other sorts of ascii in Europe, etc. Are there other versions of "ascii" in fact, or are these all just some sort of techno-mythology? I expect USascii to win the clarity of expression award. Fine by me...\Stef From owner-ietf-822@dimacs.rutgers.edu Wed Apr 10 11:49:14 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA03193; Wed, 10 Apr 91 11:35:12 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA03188; Wed, 10 Apr 91 11:35:09 EDT Date: Wed 10 Apr 91 11:34:54-EDT From: John C Klensin Subject: Re: text --> IA5 ? To: Stef@ics.uci.edu Cc: ietf-822@dimacs.rutgers.edu, nsb@thumper.bellcore.com, jwn2@qualcomm.com Message-Id: <671297694.734521.KLENSIN@INFOODS.MIT.EDU> In-Reply-To: <10784.671261201@nma.com> Mail-System-Version: >Now then, RFC822 will never be changed from what it says, so we could >easily refer to 822ascii and be entirely precise in RFC822bis by >reference to this excerpted section of RFC822. Welcome to the world of ANSI and ISO standards :-( The document referenced by RFC822, more correctly and completely cited as X3.4-1968, is no longer available. It has been been superceded by later editions, and ANSI does not stock obsolete versions of Standards, nor do most libraries. I say "ANSI *and ISO*" here, because ISO behaves the same way, and one needs to be very careful about what one is referencing. I assume that most ISO Member Bodies do too, but there are probably exceptions. >It is also easy to see how it got the informal code of USascii. The organization that is now called ANSI went through an identity crises a number of years ago in which it had trouble standardizing its own name. It started that period as "ASA" (the "American Standards Association"), went through "USASA" or something quite similar, and finally ended up as "ANSI", with maybe an addition version in between. This was over a period of two or three years (aside to anyone who happens to be involved in advising registration authorities: reminding them about this period is probably not considered funny by senior ANSI staff, but should be considered if rules are proposed that would constrain name bindings for all time :-) ). Anyway, these name changes caused the parallel designations of national standards to go from "American Standard..." to "United States of America Standard..." to "American National Standard..." One could have redesignated the acronyms along the way, but many (probably most) weren't, so while ASA->USASA->...->ANSI occurred, "ASCII" (which started under the original regime and name) stayed "ASCII". But *that* is how the "informal code of USascii" happened. "ASCII" as actually part of the title. Then, with the most recent revision, someone, in my opinion, screwed up and changed the name of the standard without changing the numeric designation. This was done to make symmetry with "8-bit ASCII", a separate standard which corresponds to ISO8859-1 (X3.134.1 sticks in my mind, but that might easily be wrong). That the name has been changed is not debatable; current ANSI catalogue lists it as "7-bit ASCII". >We should also cite it the >same way in RFC822bis as in RFC822. That should not leave any wiggle >room for anyone to miss what is intended. If you really want to do this -- there are a few characteristics of the 1968 version that don't precisely correspond to today's common usage, then it might be best for someone to go check the Protocol Handbook and be sure that it contains text identical to X3.4-1968, then cite that, forget about citing "X3.4" and use "822ASCII" or, better yet, "822CII" as the code. If I were IAB or the RFC editor, I might take exception to citing the old Protocol Handbook as the reference source for some important characteristic of a proposed new standard in 1991. But I'm not, obviously. Someone might ask for an advisory opinion on that, however. I recommend against USASCII--other than looking strange, it has all of the disadvantages attributed to "ASCII", plus just being wrong. >Are there other versions of "ascii" in fact, or >are these all just some sort of techno-mythology? Mythology and informal shorthand ways of expressing the same sorts of concepts as might have been expressed as ASCIIbis (ISO Latin-1 ?) in another community. ISCII (ISO Code...) has been used, but no one seems to know whether it refers to 646, 10646, 8859-1, 8859-2,..., or a variety of others. And then one hears about things like UK-ASCII, an oxymoron if there ever was one. --john ------- From owner-ietf-822@dimacs.rutgers.edu Wed Apr 10 19:19:17 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA20424; Wed, 10 Apr 91 19:02:40 EDT Received: from RUTGERS.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA20420; Wed, 10 Apr 91 19:02:31 EDT Received: from nrtc.northrop.com by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA22820; Wed, 10 Apr 91 19:02:20 EDT Received: from nma.com by nrtc.nrtc.northrop.com id ab13443; 10 Apr 91 15:01 PST Received: from odin.nma.com by nma.com id aa02674; 10 Apr 91 10:27 PDT To: John C Klensin Cc: ietf-822@dimacs.rutgers.edu, nsb@thumper.bellcore.com, jwn2@qualcomm.com Subject: SIGH! Re: text --> IA5 ? In-Reply-To: Your message of Wed, 10 Apr 91 11:34:54 -0500. <671297694.734521.KLENSIN@INFOODS.MIT.EDU> Reply-To: Stef@ics.uci.edu From: Einar Stefferud Date: Wed, 10 Apr 91 11:25:32 MDT Message-Id: <11384.671307932@nma.com> Sender: stef@nma.com OK John -- So USascii is not a good label. What are the differences between X3.4-1968 and x3.4-? Are they worth worrying about, iin the case where we might cite X3.4- instead of RFC822 (or citing what RFC82 cited). I am begining to favor asking the IAB, or the IETF/IESG, but first, lets ask Dave Crocker who represents them to us for this kind of question. Dave! Please come over here and put us out of our misery! Best...\Stef From owner-ietf-822@dimacs.rutgers.edu Wed Apr 10 23:19:19 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA26135; Wed, 10 Apr 91 22:21:00 EDT Received: from RUTGERS.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA26131; Wed, 10 Apr 91 22:20:57 EDT Received: from Relay.Prime.COM by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA04058; Wed, 10 Apr 91 22:20:45 EDT Message-Id: <9104110220.AA04058@rutgers.edu> Received: (from user DRB) by Relay.Prime.COM; 10 Apr 91 22:20:23 EDT To: IETF SMTP list , IETF RFC-822 list From: David Robinson Organization: Prime Computer, Inc. Systems Integration Subject: Why We Disagree So Much... A Thought Date: 10 Apr 91 22:20:24 EDT I think a source of much disagreement on these list has to do with the differences in assumptions about the lifetime of SMTP- and 822-based mail. If you think that SMTP and 822 are short-lived, then only minor adjustments, if any, are going to be practical. Furthermore, it will be impractical to hunt down and get fixed all the implementations that are misimplementing the protocol, to say nothing of getting any enhancements (no matter how slight) implemented on all the mail relays. On the other hand, if you think that SMTP and 822 may be slightly longer lived, then both extensions to SMTP and 822 as well as hunting down and fixing mailers which are unenhanced or misimplemented is just part of network normal operation. -David From owner-ietf-822@dimacs.rutgers.edu Wed Apr 10 23:49:18 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA27615; Wed, 10 Apr 91 23:13:28 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA27611; Wed, 10 Apr 91 23:13:25 EDT Date: Wed 10 Apr 91 23:13:10-EDT From: John C Klensin Subject: Re: SIGH! Re: text --> IA5 ? To: Stef@ics.uci.edu Cc: ietf-822@dimacs.rutgers.edu, nsb@thumper.bellcore.com, jwn2@qualcomm.com Message-Id: <671339591.4521.KLENSIN@INFOODS.MIT.EDU> In-Reply-To: <11384.671307932@nma.com> Mail-System-Version: >What are the differences between X3.4-1968 and x3.4-? I've probably got a copy of the '68 version around somewhere, but it could take a year to find it. So this is from memory (and my memory is not good about these things). Let me try a little history.... There is a tension in the char set standards as to whether a code sequence is mapped onto a concept or onto a specific glyph or symbol and, if the latter, how specific? It explodes into debates about whether the EBCDIC "solid vertical line" is a different concrete character from ASCII 7/12, |, which is usually stylized as "broken vertical line". Before anyone says "who cares", recall that there is an abstraction called "or-symbol" in several programming languages and that ISO WGs and then-TC92/SC6 decided in several cases to map it onto ASCII (and ISO646) 2/1, !, on the theory that ! looked more like or-symbol (solid vertical bar) than | did. Anyone reading this on a European national 646-variant terminal will immediately see the other reason behind the SC6 reasoning :-). The earliest character standards and, specifically, the earliest versions of ASCII, were very much in the "map to concept" camp, and filled with weasel words and "alternate stylizations". So, for example, if you received 5/14, ^, you could display it as "hat" or "carat", or as "up arrow". The newest character standards, e.g., the ISO8859-n set, 10646, and UNICODE, have tended to map codes onto glyphs or onto abstractions that are sufficiently precise as to not make much difference. The trend in the control characters is precisely the opposite of this trend in the graphics. The earliest standards were quite precise about what the controls were expected to do, the recent ones tend to leave those specifications for separate standards that don't contain code-> graphic bindings at all. There were also a few other things. For example, in the first version of ASCII (I think the '68 version was the second, but it might have been the first, and I don't recall when this disappeared), the preferred interpretation of 0/10 was "NL" (first character on next line") not "LF" (same character position on next line), a similar "first character on applicable line" interpretation was applied to 0/11 (VT) and 0/12 (NP or FF), and there was very clear language about what 0/13 (CR) meant. >Are they worth worrying about, iin the case where we might cite >X3.4- instead of RFC822 (or citing what RFC82 cited). In my personal opinion, they are not worth worrying about. With the exception of the vertical carriage motion controls (which RFC821/822 specify themselves anyway--the elegance of requiring CR-LF combinations is that they work equally well in "old" LF==NL systems, where the CR is just noise and "new" LF==vertical_index systems, where both are needed), anything that conforms to "today" also conforms to "1968" and should produce the same page. This does impose a slight incompatability in the other direction, but I think it is insignificant and, morever, people have had years to get used to it. In the original ASCII, someone could print solid-vertical- bar in response to receipt of 7/12. If one had an ASCII OCR device, both solid-vertical-bar and broken-vertical-bar would produce 7/12. Today, if one took that text and applied, say, an ISO8859-1 OCR device, they would produce two distinct codes and, if an ASCII OCR device where used, ???. I don't consider that a big deal and strongly prefer reference to current versions of Standards when possible. But the history is above, and people should make their own decisions about how sensitive they feel. --john ------- From owner-ietf-822@dimacs.rutgers.edu Thu Apr 11 00:19:18 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA29337; Thu, 11 Apr 91 00:12:09 EDT Received: from ics.uci.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA29333; Thu, 11 Apr 91 00:12:03 EDT Received: from ics.uci.edu by ICS.UCI.EDU id ab24293; 10 Apr 91 21:10 PDT To: John C Klensin Cc: ietf-822@dimacs.rutgers.edu, nsb@thumper.bellcore.com, jwn2@qualcomm.com Subject: Re: SIGH! Re: text --> IA5 ? In-Reply-To: Wed, 10 Apr 91 23:13:10 EDT. <671339591.4521.KLENSIN@INFOODS.MIT.EDU> Cc: Einar Stefferud Date: Wed, 10 Apr 91 21:10:55 -0700 Message-Id: <24290.671343055@ics.uci.edu> From: Einar Stefferud I fear that this insignificant little question is going to take more of Nathaniels time than we deserve to request. Lets see if we can set up tactics and strategies for getting around it all. Lets cite the new stnadard (someone needs to get a copy for Nathaniel, and for NIC.DDN.MIL or for Jon Postel's files), and also be explicit about the business to be sure we do not confuse anyone. What else should we note in RFC822bis to avoid connfusions, or trouble? Best...\Stef From owner-ietf-822@dimacs.rutgers.edu Thu Apr 11 00:49:19 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA00263; Thu, 11 Apr 91 00:33:46 EDT Received: from enet-gw.pa.dec.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA00244; Thu, 11 Apr 91 00:33:35 EDT Received: by enet-gw.pa.dec.com; id AA29478; Wed, 10 Apr 91 21:32:18 -0700 Received: by palo-alto.pa.dec.com; id AA05217; Wed, 10 Apr 91 21:32:08 PDT Message-Id: <9104110432.AA05217@palo-alto.pa.dec.com> To: jwn2@qualcomm.com (John Noerenberg) Cc: ietf-822@dimacs.rutgers.edu, nsb@thumper.bellcore.com Subject: Re: text --> IA5 ? In-Reply-To: Your message of Tue, 09 Apr 91 14:48:07 -0700. <9104092148.AA06091@QUALCOMM.COM> Date: Wed, 10 Apr 91 21:32:06 PDT From: Dave Crocker Let's try this on for size (pun?): A body part has several levels of context, or interpretation. In theory, the number of levels might get quite large, and our attempting to handle the theoretical maximum, or the possibility of infinite nesting, will bog us down. But just for the heck of it, let's try the following: 1. How I, the sender, want it interpreted; e.g., run the BP through a program that is located in file foo/bar 2. BP consists of data generically characterized in a standard category, and precisely defined by a simple citation 3. Data are being sent according to a cited encoding standard. Hence, there is the sender's view, the 'byte' (or thereabouts) view of the interpretable data, and finally the transmission convention. So, I might have 1. nroff 2. USASCII 3. Quoted Text Thoughts? Dave From owner-ietf-822@dimacs.rutgers.edu Thu Apr 11 01:19:19 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA00502; Thu, 11 Apr 91 00:41:24 EDT Received: from enet-gw.pa.dec.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA00492; Thu, 11 Apr 91 00:40:48 EDT Received: by enet-gw.pa.dec.com; id AA29775; Wed, 10 Apr 91 21:38:04 -0700 Received: by palo-alto.pa.dec.com; id AA05266; Wed, 10 Apr 91 21:37:54 PDT Message-Id: <9104110437.AA05266@palo-alto.pa.dec.com> To: Stef@ics.uci.edu Cc: John C Klensin , ietf-822@dimacs.rutgers.edu, nsb@thumper.bellcore.com, jwn2@qualcomm.com Subject: Re: SIGH! Re: text --> IA5 ? In-Reply-To: Your message of Wed, 10 Apr 91 11:25:32 -0600. <11384.671307932@nma.com> Date: Wed, 10 Apr 91 21:37:51 PDT From: Dave Crocker This is great. I get to watch a long series of infinitely detailed messages, debating the number of ASCII's on the head of a byte and then Stef calls for me to dig you guys out. Well, precise citations and compare/contrast exercises between two international standards is not exactly my forte. Sorry. Besides, I can't believe that this is the right discussion to be having, at this stage. Yesssss, there will need to be a precise and agreed-upon citation in the final spec, but until you've got a document that is converging on finality, it probably isn't the issue to consume ourselves with. Dave From owner-ietf-822@dimacs.rutgers.edu Thu Apr 11 02:32:28 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA01584; Thu, 11 Apr 91 01:33:02 EDT Received: from ics.uci.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA01580; Thu, 11 Apr 91 01:32:57 EDT Received: from ics.uci.edu by ICS.UCI.EDU id aa29999; 10 Apr 91 22:04 PDT Date: Wed, 10 Apr 91 22:04:25 -0700 Message-Id: <29993.671346265@ics.uci.edu> From: Einar Stefferud Subject: Re: Why We Disagree So Much... A Thought Apparently-To: ietf-822-list ------- Blind-Carbon-Copy To: David Robinson cc: IETF SMTP list Subject: Re: Why We Disagree So Much... A Thought In-reply-to: 10 Apr 91 22:20:24 EDT. <9104110220.AA04058@rutgers.edu> Cc: "Einar Stefferud" Date: Wed, 10 Apr 91 22:04:25 -0700 Message-ID: <29993.671346265@ics.uci.edu> From: "Einar Stefferud" I am only sending this to the ietf-smtp list, because us ietf-822 people do not want to be bothered any more by this damn argument! I suggest that you keep your arguement about it to your own side of the house! We don't want to hear about it! Until now, life was actully becoming sort of pleasant on the ietf-822 side of the house! Mr Chairman, will you please rule this discussion out of order on the ietf-822 side ot the house! Best...\Stef ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ David -- NO! I think the cause is orthogonal to your continuum. It is precisely because of the large immobile installed base that is perceived as very likely to never be upgraded under any conditions, that causes me, and I belive many others to want to do nothing to SMTP (RFC821) that will break old systems. The whole idea of just declaring older installed systems broken in the effort to move forward is just a very very bad idea, and we should put it away forever in the context of SMTP(RFC821). You can carry 8-bit stuff in 7-bit SMTP if you want to, so you are only making a very small gain in badwidth efficiency anyway. (But we have been over this endlessly, so I will not repeat any more of it.) If you want to go ahead anyway, then declare that you are going to define a new internet mail standard (to do what X.400 does, and more if you can) and run it as a 3rd alternative MTA system, with gateways between it and RFC821/822 systems to protect RFC821/822 systems from any and all ill effects. All you need to do is define gateways between your RFC-newmta systems and RFC821/822 systems and X.400 MTA systems. Lets get the real issue out on the table here. I always say that it is much easier to hold an autopsy if you have a corpse on the table! Some want a new INTERNET RFC STANDARD blessed MTA system to do 8-bit mail (at minimum), and they don't want to use X.400 to do it, so they want to convert an existing installed base (7bit RFC821) into something new. They don't mind that it breaks lots of mail systems that lots of people are using in production mode, with no desire to fix it, cause it ain't broke. They just want to blatantly declare all old stuff "broken, when it is not" and go their merry way. Well, I wonder how they would react if we were on opposite sides of this same question about just declaring my tools broken when they are not. My response, and yours to this challenge is "Just Say NO!". I don't know why they (the "we want a new MTA Protocol" people) don't want to just do something entirely new that only works among consenting parties that implement their "something new", with firewalls around it to protect the non-users. For myself, having already seen what happens when we have gateways among three mail system realms (RFC822/X.400/PROFS), I don't want to promote this "3 body problem" as a solution, but I will not stand in the way of folk who are really convinced that they have a valuable idea for how to really do mail right (e.g., do the MTA protocol right, for the last time, of course). I just don't want to contribute to it, and I don't want it to damage my currently working installed base. And I don't want it to get in the way of the other work that we need to get done. This is what the problem is all about! Best...\Stef ------- End of Blind-Carbon-Copy From owner-ietf-822@dimacs.rutgers.edu Thu Apr 11 02:19:24 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA01641; Thu, 11 Apr 91 01:37:30 EDT Received: from CBROWN.CLAREMONT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA01637; Thu, 11 Apr 91 01:37:26 EDT Date: Wed, 10 Apr 1991 22:37 PDT From: "Ned Freed, Postmaster" Subject: Re: Why We Disagree So Much... A Thought To: DRB@relay.prime.com Cc: ietf-822@dimacs.rutgers.edu Message-Id: <0D05B4437E60092A@HMCVAX.CLAREMONT.EDU> X-Envelope-To: ietf-822@dimacs.rutgers.edu X-Vms-To: IN%"DRB@relay.prime.com" X-Vms-Cc: IN%"ietf-822@dimacs.rutgers.edu" Well, it is an interesting idea, but speaking for myself, I don't think I fit the categories you present. (1) I believe that RFC 821 and RFC 822 will be around for a very, very, very long time. (2) I believe that enhancements at both levels are warranted. Just because I'm against most of the SMTP enhancements proposed thus far doesn't mean there aren't enhancements to be made to SMTP. I haven't bothered to present what I think SMTP needs since it is unrelated to the issues we're debating at present. (3) I believe that if we come up with sound enhancements, they will be widely deployed and used. (4) I believe that just because we come up with enhancements, and they may see wide use, that many MTAs and UAs will be extremely slow to upgrade. Some will never upgrade, for all practical purposes. This necessitates backwards compatibility in order to insure operational integrity. (5) I also believe that X.400 will see increasing use, but it will be a long time before it overtakes 821 and 822 use. Given the fact that the most explosive e-mail growth today is in PC e-mail, and these systems are for the most part 822-derived, it may be that X.400 will _never_ overtake 822, certainly not within the useful life of what we're working on here. My opinions only. I offer them simply to show how they fit, or don't fit, your analysis. Ned From owner-ietf-822@dimacs.rutgers.edu Thu Apr 11 10:06:59 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA09306; Thu, 11 Apr 91 08:53:08 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA09302; Thu, 11 Apr 91 08:53:07 EDT Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.EDU; Thu, 11 Apr 91 08:52:08 EDT Received: by greenbush.bellcore.com (4.12/4.7) id for David_Crocker@Pa.dec.com; Thu, 11 Apr 91 08:55:27 edt Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.greenbush.mouseclub.sun4.40 via MS.5.6.greenbush.mouseclub.sun4_40; Thu, 11 Apr 1991 08:55:22 -0400 (EDT) Message-Id: Date: Thu, 11 Apr 1991 08:55:22 -0400 (EDT) From: Nathaniel Borenstein To: John C Klensin , Einar Stefferud Subject: Re: SIGH! Re: text --> IA5 ? Cc: ietf-822@dimacs.rutgers.edu, jwn2@qualcomm.com, Dave Crocker In-Reply-To: <24290.671343055@ics.uci.edu> References: <24290.671343055@ics.uci.edu> Personally, I think we ARE converging on finality, but then I'm always an optimist. I'm nearly done with another pass through the draft RFC. This draft, as it turns out, is the first one that is "complete-looking" -- that is, if everyone agreed, it would need virtually no further work before publication. That doesn't, of course, mean that everyone will agree, but from where I sit it feels like enormous progress -- at least, for the first time, I'm happy with it, and it helps to have a document that the author is happy with. And, to answer the burning question you're all surely asking right now: the draft document calls the default content-type -- ta-ta -- "822ASCII". It strikes me as the label that best summarizes what we're trying to capture, i.e. "ASCII as specified by RFC 822." -- Nathaniel From owner-ietf-822@dimacs.rutgers.edu Thu Apr 11 10:33:37 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA09316; Thu, 11 Apr 91 08:56:38 EDT Received: from hydra.Helsinki.FI by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA09312; Thu, 11 Apr 91 08:56:18 EDT Received: from poros (poros.Helsinki.FI) by hydra.Helsinki.FI (4.1/SMI-4.1/32) id AA01559; Thu, 11 Apr 91 15:55:56 +0300 Date: Thu, 11 Apr 91 15:55:56 +0300 From: kankkune@cs.helsinki.fi (Risto Kankkunen) Message-Id: <9104111255.AA01559@hydra.Helsinki.FI> In-Reply-To: Dave Crocker's message as of Apr 10, 21:32 X-Mailer: Mail User's Shell (7.2.0 10/31/90) To: ietf-822@dimacs.rutgers.edu Subject: Re: text --> IA5 ? > Hence, there is the sender's view, the 'byte' (or thereabouts) view of > the interpretable data, and finally the transmission convention. > > So, I might have > > 1. nroff > 2. USASCII > 3. Quoted Text One thing that should be considered, is the functionality of these headers. With the content-type/content-encoding pair the matter is quite simple: first the UA unpacks the body by feeding it through all the decoders mentioned in the content-encoding header. Then it chooses the right viewer for this part according to the content-type header. How does a content-charset or something like that fit into this? Is the charset passed as a parameter to the viewer? Maybe it would then be better to place the charset indicator as a parameter to the content type. Or maybe there is a different viewer for each pair, that pair could be used as the content-type name, like X-nroff-USASCII. There is probably some lookup table for the different contents and their viewers. Even if there is a single viewer for the different character sets, that could be handled with this table, if this latter style is used: X-nroff /usr/bin/nroff -c ascii X-nroff-USASCII /usr/bin/nroff -c ascii X-nroff-Latin1 /usr/bin/nroff -c ISO-8859-1 Also, a separate character set header would be needed only for these kind of special cases. Most text formats handle the charset issue themselves (like WP documents) and graphics or voice parts don't have this at all. So, I'd prefer a more general method instead of a specific header. I think we could manage with using X-nroff-USASCII style content names, or we could use the resource-ref part for this (e.g. Content- type: X-nroff;;me,Latin1). I don't know, if the RFC822bis should decide this in general. Btw. RFC1049 allows one to leave out the ver-num part, if there are no resource-refs, but requires it when they are present. Is there a reason for this? -- Risto Kankkunen kankkune@cs.Helsinki.FI (Internet) Department of Computer Science kankkunen@finuh (Bitnet) University of Helsinki, Finland ..!mcsun!uhecs!kankkune (UUCP) From owner-ietf-822@dimacs.rutgers.edu Thu Apr 11 10:41:08 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA09705; Thu, 11 Apr 91 09:10:48 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA09684; Thu, 11 Apr 91 09:10:28 EDT Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7) id for IETF-SMTP@dimacs.rutgers.edu; Thu, 11 Apr 91 09:10:26 EDT Received: by greenbush.bellcore.com (4.12/4.7) id for IETF-822@dimacs.rutgers.edu; Thu, 11 Apr 91 09:13:44 edt Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.greenbush.mouseclub.sun4.40 via MS.5.6.greenbush.mouseclub.sun4_40; Thu, 11 Apr 1991 09:13:38 -0400 (EDT) Message-Id: Date: Thu, 11 Apr 1991 09:13:38 -0400 (EDT) From: Nathaniel Borenstein To: IETF SMTP list , IETF RFC-822 list Subject: Re: Why We Disagree So Much... A Thought In-Reply-To: <9104110220.AA04058@rutgers.edu> References: <9104110220.AA04058@rutgers.edu> Actually, David, it's too bad you weren't in St. Louis. My observation there is that the difference is not between people who expect 822/SMTP to be transient and those who expect it to last a long time. Rather, I was amused to discover, the difference seems to be between two groups that disagree about the right way to prolong and promote the longevity of 822/SMTP: -- The "conservative" camp believes that simplicity and stability is one of 822/SMTP's biggest advantages over X.400. If 822/SMTP were to become as complex as X.400, for example, it would lose most of its staying power. -- The "liberal" camp believes that upgrading 822/SMTP is the best way to stave off future desertions from the 822/SMTP camp. In other words, I think that many people on both sides of this debate hope & expect that 822/SMTP will be long-lived, and that the disagreements center on the right way to promote and guide that long life. -- Nathaniel From owner-ietf-822@dimacs.rutgers.edu Thu Apr 11 11:10:15 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA09422; Thu, 11 Apr 91 09:04:14 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA09414; Thu, 11 Apr 91 09:04:07 EDT Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Thu, 11 Apr 91 09:04:05 EDT Received: by greenbush.bellcore.com (4.12/4.7) id for ietf-822@dimacs.rutgers.edu; Thu, 11 Apr 91 09:07:24 edt Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.greenbush.mouseclub.sun4.40 via MS.5.6.greenbush.mouseclub.sun4_40; Thu, 11 Apr 1991 09:07:20 -0400 (EDT) Message-Id: Date: Thu, 11 Apr 1991 09:07:20 -0400 (EDT) From: Nathaniel Borenstein To: jwn2@qualcomm.com (John Noerenberg), Dave Crocker Subject: Re: text --> IA5 ? Cc: ietf-822@dimacs.rutgers.edu In-Reply-To: <9104110432.AA05217@palo-alto.pa.dec.com> References: <9104110432.AA05217@palo-alto.pa.dec.com> Excerpts from mail: 10-Apr-91 Re: text --> IA5 ? Dave Crocker@Pa.dec.com (828) > A body part has several levels of context, or interpretation. In > theory, the number of levels might get quite large, and our attempting > to handle the theoretical maximum, or the possibility of infinite > nesting, will bog us down. But just for the heck of it, let's try the > following: I've tried it on, and I don't think it fits. > 1. How I, the sender, want it interpreted; e.g., run the BP through a > program that is located in file foo/bar Like, maybe, a program that just knows how to display 8 bit text? 7 bit? > 2. BP consists of data generically characterized in a standard > category, and precisely defined by a simple citation Like, maybe, nroff or TeX sources, as cited by RFC 1049? > 3. Data are being sent according to a cited encoding standard. Like, maybe, "some kind of data" encoded in hex? The line betwee #1 and #2 is totally fuzzy. #3 is clearly a different concept, but doesn't stand alone -- you have to know what, precisely, you have encoded. #1 and #2 are both the kinds of things that Content-type, as defined by RFC 1049, was designed to handle. An important point: THAT MECHANISM WORKS VERY WELL. There are lots of different people using the Content-type header, and have been for several years now, and the ONLY problems people have had with it, to my knowledge, are the lack of a standard mechanism for multipart bodies and the lack of a standard for your case #3, encoding data that can't be passed in 7 bit mail bodies. These problems were, indisputably, the motivation for the current effort. The basic notion of "Content-type" is, however, not broken, so I don't think we should fix it. It seems to me that we're solving enough issues in this RFC without trying to change something that works fine as it is. I would strongly urge us not to tamper with the basic notion of Content-type, which is the direction I think I sense Dave heading. -- Nathaniel From owner-ietf-822@dimacs.rutgers.edu Thu Apr 11 11:26:53 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA10900; Thu, 11 Apr 91 09:41:57 EDT Received: from NRI.RESTON.VA.US by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA10892; Thu, 11 Apr 91 09:41:53 EDT Received: from NRI by NRI.NRI.Reston.VA.US id aa08850; 11 Apr 91 9:35 EDT Org: Corp. for National Research Initiatives Phone: (703) 620-8990 ; Fax: (703) 620-0913 To: ietf-822@dimacs.rutgers.edu Cc: gvaudre@nri.reston.va.us Subject: ietf-822 charter Date: Thu, 11 Apr 91 09:35:55 -0400 From: Greg Vaudreuil Message-Id: <9104110935.aa08850@NRI.NRI.Reston.VA.US> Internet Message Extentions (822ext) Charter Chair(s): Gregory Vaudreuil, gvaudre@nri.reston.va.us Mailing Lists: General Discussion: ietf-822@dimacs.rutgers.edu To Subscribe: ietf-822-request@dimacs.rutgers.edu Description of Working Group: This working group is chartered to extend the RFC 822 Message format to facilitate multi-media mail and alternate character sets. The group is expected to formulate a standard message format, roughly based on either RFC1154 or RFC 1049. The immediate goals of this group are to define a mechanism for the standard interchange and interoperation of international character sets. Goals and Milestones: Mar 1991 Review the charter, and refine the groups focus. Decide whether this is a worthwhile effort. Mar 1991 Discuss, debate, and choose a framework for the solution. Assign writing assignments, and identify issues to be resolved. Jul 1991 Review exiting writing, resolve outstanding issues, identify new work, and work toward a complete document Nov 1991 Post a first Internet Draft. Dec 1991 Review and finalize the draft document. Jan 1991 Submit the document as a Proposed Standard. From owner-ietf-822@dimacs.rutgers.edu Thu Apr 11 12:23:43 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA14891; Thu, 11 Apr 91 11:52:33 EDT Received: from enet-gw.pa.dec.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA14867; Thu, 11 Apr 91 11:52:15 EDT Received: by enet-gw.pa.dec.com; id AA12644; Thu, 11 Apr 91 08:50:38 -0700 Received: by palo-alto.pa.dec.com; id AA14461; Thu, 11 Apr 91 08:50:21 PDT Message-Id: <9104111550.AA14461@palo-alto.pa.dec.com> To: Greg Vaudreuil Cc: ietf-822@dimacs.rutgers.edu Subject: Re: ietf-822 charter In-Reply-To: Your message of Thu, 11 Apr 91 09:35:55 -0400. <9104110935.aa08850@NRI.NRI.Reston.VA.US> Date: Thu, 11 Apr 91 08:50:18 PDT From: Dave Crocker Just a thought: What about shooting for an ID by July and attempting Proposed by September? Dave From owner-ietf-822@dimacs.rutgers.edu Thu Apr 11 13:19:22 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA17990; Thu, 11 Apr 91 13:15:31 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA17986; Thu, 11 Apr 91 13:15:27 EDT Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Thu, 11 Apr 91 13:15:23 EDT Received: by greenbush.bellcore.com (4.12/4.7) id for ietf-822@dimacs.rutgers.edu; Thu, 11 Apr 91 13:18:42 edt Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.greenbush.mouseclub.sun4.40 via MS.5.6.greenbush.mouseclub.sun4_40; Thu, 11 Apr 1991 13:18:38 -0400 (EDT) Message-Id: Date: Thu, 11 Apr 1991 13:18:38 -0400 (EDT) From: Nathaniel Borenstein To: ietf-822@dimacs.rutgers.edu Subject: Re: text --> IA5 ? In-Reply-To: <9104111255.AA01559@hydra.Helsinki.FI> References: <9104111255.AA01559@hydra.Helsinki.FI> Excerpts from internet.ietf-822: 11-Apr-91 Re: text --> IA5 ? Risto Kankkunen@cs.helsi (2135) > Btw. RFC1049 allows one to leave out the ver-num part, if there are no > resource-refs, but requires it when they are present. Is there a reason > for this? I think that's just a syntactic oddity. I've seen people use "null", which is legal, or just leave the version number blank, which is not really legal since it has to be a local-part, which (by my reading) requires at least non-whitespace character. I suppose we could consider changing the definition to allow it to be blank, e.g. local-part / "" Is there a strong reason for wanting to make this change? From owner-ietf-822@dimacs.rutgers.edu Thu Apr 11 14:49:24 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA20754; Thu, 11 Apr 91 14:42:09 EDT Received: from ics.uci.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA20750; Thu, 11 Apr 91 14:42:03 EDT Received: from ics.uci.edu by ICS.UCI.EDU id aa01753; 11 Apr 91 7:58 PDT To: Nathaniel Borenstein Cc: John C Klensin , ietf-822@dimacs.rutgers.edu, jwn2@qualcomm.com, Dave Crocker Subject: Re: SIGH! Re: text --> IA5 ? In-Reply-To: Thu, 11 Apr 91 08:55:22 EDT. Cc: Einar Stefferud Date: Thu, 11 Apr 91 07:58:27 -0700 Message-Id: <1751.671381907@ics.uci.edu> From: Einar Stefferud I expect that we might want to change that to be RFC822bisASCII, when we know what the new RFC number is. Question: Do we or do we not want to cite a 1968 obsolete SI X3.4 standard in a 1991 RFC? Best...\Stef From owner-ietf-822@dimacs.rutgers.edu Thu Apr 11 15:28:13 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA21644; Thu, 11 Apr 91 15:19:02 EDT Received: from qualcom.qualcomm.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA21640; Thu, 11 Apr 91 15:18:57 EDT Received: from [129.46.4.152] with SMTP by QUALCOMM.COM (5.64+/QUALCOMM/V1.0) id AA09217 for ietf-822@dimacs.rutgers.EDU; Thu, 11 Apr 91 12:18:30 -0700 Date: Thu, 11 Apr 91 12:18:30 -0700 Message-Id: <9104111918.AA09217@QUALCOMM.COM> To: Nathaniel Borenstein , Einar Stefferud From: jwn2@qualcom.qualcomm.com Subject: Re: SIGH! Re: text --> IA5 ? Cc: John C Klensin , ietf-822@dimacs.rutgers.edu, jwn2@qualcomm.com, Dave Crocker Question: Do we or do we not want to >cite a 1968 obsolete SI X3.4 standard in a 1991 RFC? > I thought about that. If the symbol map for the left half of the table (the first 128 codes) match between the 68 revision and the current revision, then the current revision is probably the right one to cite. I'm still trying to scare up a copy of the current revision. Btw, yesterday while pondering this whole business, I went looking for all the different ascii charts I could find. To my horror, I discovered that Microsoft had inserted some glyph of their own choosing in the DEL position (7/f), explaining that DEL and BS are the same under DOS. Now that I think about it, Microsoft invented glyphs for all of the (traditionally) non-printable codes for DOS. All this proves, of course, is setting a standard is one thing. _Adhering_ to it is quite another. I think there's a lesson here... From owner-ietf-822@dimacs.rutgers.edu Thu Apr 11 15:49:22 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA21695; Thu, 11 Apr 91 15:20:34 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA21689; Thu, 11 Apr 91 15:20:32 EDT Date: Thu 11 Apr 91 15:20:15-EDT From: John C Klensin Subject: Re: SIGH! Re: text --> IA5 ? To: stef@ics.uci.edu Cc: nsb@thumper.bellcore.com, ietf-822@dimacs.rutgers.edu, jwn2@qualcomm.com, David_Crocker@pa.dec.com Message-Id: <671397615.890521.KLENSIN@INFOODS.MIT.EDU> In-Reply-To: <1751.671381907@ics.uci.edu> Mail-System-Version: >I expect that we might want to change that to be RFC822bisASCII, when we >know what the new RFC number is. Question: Do we or do we not want to >cite a 1968 obsolete SI X3.4 standard in a 1991 RFC? If one wants to cite the old one, and be perfectly precise, and expect that RFC-XXXX is going to supplement 822 and not replace it, then the easiest thing to do is to cite "ASCII as defined in RFC822, reference [n]" and be done with it. The second question is more interesting, but I've got nothing else to contribute to it. Stef, before serious confusion sets in, I'd suggest dropping the "RFC822bis" terminology and using either Nathaniel's RFC-XXXX or something else. The reason is that there is *already* something that might be construed as RFC822bis and is an Internet Standard: RFC822 read through the filters and interpretations of RFC1123. Moreover, I infer from Dave's comments/questions of a week ago about weak places in 822 itself that he is contemplating a revision and tuning of 822 that, presumably, would supercede it, thereby creating, perhaps, 822bis-bis. Finally, in deference to those who are throughly sick of this discussion, and to Dave's earlier comment (which I construed as "let's make sure we agree on the conceptual problems, then quibble"), let's take the off the list. I, for one, would like to read what Nathaniel comes up with in RFC form and then comment/quibble, possibly offline relative to the list. In the interim, I'd categorize myself as part of the "throughly sick of this discussion" group. --john ------- From owner-ietf-822@dimacs.rutgers.edu Thu Apr 11 16:49:23 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA25369; Thu, 11 Apr 91 16:33:24 EDT Received: from NRI.RESTON.VA.US by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA25364; Thu, 11 Apr 91 16:33:15 EDT Received: from NRI by NRI.NRI.Reston.VA.US id aa01343; 11 Apr 91 16:26 EDT To: John C Klensin Cc: stef@ics.uci.edu, nsb@thumper.bellcore.com, ietf-822@dimacs.rutgers.edu, jwn2@qualcomm.com, David_Crocker@pa.dec.com, gvaudre@nri.reston.va.us Subject: Re: SIGH! Re: text --> IA5 ? In-Reply-To: Your message of "Thu, 11 Apr 91 15:20:15 EDT." <671397615.890521.KLENSIN@INFOODS.MIT.EDU> Date: Thu, 11 Apr 91 16:26:35 -0400 From: Greg Vaudreuil Message-Id: <9104111626.aa01343@NRI.NRI.Reston.VA.US> Lets take the opportunity to define the character set we mean when we say USasciiblitherblap. It is not unreasonable to include a chart of accepted characters and their character values. In a "ascii" rfc, that should be possible :-) Greg V. From owner-ietf-822@dimacs.rutgers.edu Fri Apr 12 09:19:27 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA20423; Fri, 12 Apr 91 09:04:36 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA20419; Fri, 12 Apr 91 09:04:34 EDT Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Fri, 12 Apr 91 09:02:12 EDT Received: by greenbush.bellcore.com (4.12/4.7) id for David_Crocker@pa.dec.com; Fri, 12 Apr 91 09:05:33 edt Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.greenbush.mouseclub.sun4.40 via MS.5.6.greenbush.mouseclub.sun4_40; Fri, 12 Apr 1991 09:05:28 -0400 (EDT) Message-Id: Date: Fri, 12 Apr 1991 09:05:28 -0400 (EDT) From: Nathaniel Borenstein To: John C Klensin , Greg Vaudreuil Subject: Re: SIGH! Re: text --> IA5 ? Cc: stef@ics.uci.edu, ietf-822@dimacs.rutgers.edu, jwn2@qualcomm.com, David_Crocker@pa.dec.com, gvaudre@nri.reston.va.us In-Reply-To: <9104111626.aa01343@NRI.NRI.Reston.VA.US> References: <9104111626.aa01343@NRI.NRI.Reston.VA.US> I used to think I knew what ASCII was. I don't any more. I'd be happy to include a reference table, but I am not going to write it. Do any of you folks who actually know what you're talking about want to provide me with such a table? Barring that, my first pass would be "insert-file /usr/pub/ascii" -- something tells me that this would not be universally acceptable.... -- Nathaniel From owner-ietf-822@dimacs.rutgers.edu Mon Apr 15 09:26:51 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA20730; Mon, 15 Apr 91 09:14:57 EDT Received: from e.ms.uky.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA20726; Mon, 15 Apr 91 09:14:53 EDT Received: from s.ms.uky.edu by g.ms.uky.edu id ab19625; 15 Apr 91 9:08 EDT Date: Mon, 15 Apr 91 9:07:33 EDT From: Daniel Chaney To: ietf-822@dimacs.rutgers.edu Subject: Please add me Message-Id: <9104150907.aa15134@s.s.ms.uky.edu> Thank you. -dan -- -- Daniel Chaney -- -- postmaster, newsguy, main archiver for ms.uky.edu (Univ of KY Math Sci) -- -- {uunet and the like}!ukma!chaney chaney@ms.uky.edu chaney@ukma.BITNET -- -- "I'll have time enough for sleep when I'm dead and in the ground" -- From owner-ietf-822@dimacs.rutgers.edu Thu Apr 18 15:57:25 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA07748; Thu, 18 Apr 91 15:46:00 EDT Received: from dkuug.dk by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA07736; Thu, 18 Apr 91 15:45:52 EDT Received: by dkuug.dk (5.64+/8+bit/IDA-1.2.8) id AA07166; Thu, 18 Apr 91 21:44:17 +0200 Date: Thu, 18 Apr 91 21:44:17 +0200 From: Keld J|rn Simonsen Message-Id: <9104181944.AA07166@dkuug.dk> To: gvaudre@nri.reston.va.us, nsb@thumper.bellcore.com Subject: Re: SIGH! Re: text --> IA5 ? Cc: David_Crocker@pa.dec.com, ietf-822@dimacs.rutgers.edu, jwn2@qualcomm.com, stef@ics.uci.edu X-Charset: ASCII X-Char-Esc: 29 About the name of ASCII: A Project Team of the European Workshop for Open Systems (EWOS PT 001, paid by the Commision of the European Communities) has produced a report on character sets. This was intended for use in "Open Systems" like OSI and POSIX, and they also addressed the issue of good unique naming of character sets. Their recommendation was to use the registration number of the ISO 2375 registry administered by ECMA. A character set could then be referenced as "ISO IR xxx" meaning ISO International Registration number xxx. The registration numbers of ISO 2375 is actually also the way character sets are referenced in OSI standards and profiles, and in European chararacter set profile standards such as the ENV 41 5xx series made by CEN/CENELEC (the Joint European Standards Institution). This information is also included in the character set work that I have distributed earlier to this list. ASCII (the 7-bit critter we know so well) has registration number 6. My naming takes the effort to make the name a token, so I call it "ISO-IR-6". Just a suggestion to make the new RFC in line with much other work in the communications world... Keld From owner-ietf-822@dimacs.rutgers.edu Thu Apr 18 19:57:25 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA16293; Thu, 18 Apr 91 19:16:05 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA16285; Thu, 18 Apr 91 19:16:02 EDT Date: Thu 18 Apr 91 19:15:35-EDT From: John C Klensin Subject: Spelling "ASCII" in ECMA or ISO To: ietf-822@dimacs.rutgers.edu Message-Id: <672016535.912671.KLENSIN@INFOODS.MIT.EDU> Mail-System-Version: Relative to using the registration number strategy, I'm hesitant for two reasons. The second may be ok, but someone should check, very carefully. (1) This is really an ANSI Standard, whose first version is of hoary vintage, and should be referenced as such. Given its special status in 822 and 821 (and, for that matter, in Telnet), I think it would be better to see the system use content identifiers that reflect "ASCII" in some form, even if every other content identifier that refers to a character set uses the ISO-RN-nn form (which I basically like, subject to the qualification below). (2) I don't have my ECMA registration file in front of me, and it isn't complete anyway, but my recollection is that registration tables for 94 character sets are registrations for GL only. That is, they have little grey areas in columns 0 and 1 and positions 2/0 and maybe 7/15. "ASCII" (as in X3.4) is a complete table, reflecting columns 0 through 7 (C0 as well as something suitable for mapping to GL). If so, you can't say "registration NNN" and then talk about CR or LF, because that registration does not define such creatures. I applaud the trend toward making everything international and elegant, but it is lots safer to apply it to "new" things than to try to retroactively apply it to things that have been in use--and well-defined-- for a long time. That said, if one followed and extended the referencing model of RFC821 and RFC822 and said, e.g., American National Standard... X3.4-1976,... and then went on to say... "for all practical intents and purposes, ISO646 (name, date) International Reference Version; ISO Registration nn mapped to GL with ISO Registration mm mapped to C0; columns 0 through 7 of ISO8859-1,2,3,...; plane 0 (i.e., 32-bit values in the range 032 000 through 032 127) of DIS10646; and UNICODE characters in columns 000 through 007; are all equivalent to this Standard. However, in the event of any ambiguity, the definitions in X3.4 apply." ... I think it would be a useful public service for readers for whom ANSI X3.4 may be the least accessible of these authoritative documents. --john ------- From owner-ietf-822@dimacs.rutgers.edu Thu Apr 18 21:57:29 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA21115; Thu, 18 Apr 91 21:40:52 EDT Received: from RUTGERS.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA21098; Thu, 18 Apr 91 21:40:38 EDT Received: from nrtc.northrop.com by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA10084; Thu, 18 Apr 91 21:40:16 EDT Received: from nma.com by nrtc.nrtc.northrop.com id ab18971; 18 Apr 91 17:36 PST Received: from odin.nma.com by nma.com id aa12515; 18 Apr 91 17:04 PDT To: Keld J|rn Simonsen Cc: gvaudre@nri.reston.va.us, nsb@thumper.bellcore.com, David_Crocker@pa.dec.com, ietf-822@dimacs.rutgers.edu, jwn2@qualcomm.com Subject: Re: SIGH! Re: text --> IA5 ? In-Reply-To: Your message of Thu, 18 Apr 91 21:44:17 +0100. <9104181944.AA07166@dkuug.dk> Reply-To: Stef@ics.uci.edu From: Einar Stefferud Date: Thu, 18 Apr 91 18:01:34 MDT Message-Id: <16386.672022894@nma.com> Sender: stef@nma.com Thanks Keld -- This is the kind of unambiguous token I was looking for, exactly! > ASCII (the 7-bit critter we know so well) has registration number 6. > My naming takes the effort to make the name a token, so I call > it "ISO-IR-6". Just a suggestion to make the new RFC in line with > much other work in the communications world... I suggest that we use it, after we make sure that "ISO-IR-6" means exactly what we mean in RFC-XXXX. I also suggest that we consider using the other tokens to identify otehr character sets or encodings, or whatever it is that we call this stuff. Cheers...\Stef From owner-ietf-822@dimacs.rutgers.edu Thu Apr 18 23:57:27 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA24187; Thu, 18 Apr 91 23:26:43 EDT Received: from Sun.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA24178; Thu, 18 Apr 91 23:26:38 EDT Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA01619; Thu, 18 Apr 91 20:26:34 PDT Received: from polya.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA18375; Thu, 18 Apr 91 20:26:26 PDT Received: by polya.Eng.Sun.COM (4.1/SMI-4.0-MHS-6.0) id AA20160; Thu, 18 Apr 91 20:26:19 PDT Date: Thu, 18 Apr 91 20:26:19 PDT From: Peter.Vanderbilt@eng.sun.com (Peter Vanderbilt) Message-Id: <9104190326.AA20160@polya.Eng.Sun.COM> To: keld@dkuug.dk Subject: Re: SIGH! Re: text --> IA5 ? Cc: ietf-822@dimacs.rutgers.edu > About the name of ASCII: [...] Their recommendation was to use > the registration number of the ISO 2375 registry administered by ECMA. > A character set could then be referenced as "ISO IR xxx" meaning ISO > International Registration number xxx. > ASCII (the 7-bit critter we know so well) has registration number 6. > My naming takes the effort to make the name a token, so I call > it "ISO-IR-6". It doesn't really matter what token we use as long as we agree what it means. But two warnings about "ISO-IR-6": First, IA5, what X.400 uses, is based on ISO-IR-2. Second: As I understand it, each registration numbers refers to only a part of a typical character set. In particular, registration numbers refer to coded character sets of size 94 or 96 or, for multibyte character sets, 94^n or 96^n. Typical character sets are larger, like 94+96 (for 8-bit) or 94+94^2+96. For example, ISO 8859/1 (Latin-1) has characters from registrations 6 and 100 -- the 6 refers to ASCII and the 100 to the right hand part of 8859/1. There are additional registration numbers for the control characters. Calling 8859/1 "ISO-IR-100" would be inexact, at best. Also I believe a commonly used character set in Japan uses ISO 2022 with characters from 14 in G0, 81 in G1 and 13 in G2. What would you use for this? Even ASCII is really composed of 6 with control characters (probably registration #1). To name the existing character set used by 822 systems, I prefer something simple like "ASCII" or "US-ASCII". The differences between versions and vintages are fairly minor and are probably not adhered to by real systems anyway. Does everybody reading this mail see "$@[]\^`{}|~" as dollar sign, at sign, square brackets, back slash, caret, back quote, curly brackets, vertical bar and tilde (hope I've got the names right!)? For the future we should nail down the character set as exactly as possible, including whether regionally varying renditions are allowed. Pete From owner-ietf-822@dimacs.rutgers.edu Fri Apr 19 02:27:30 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA28158; Fri, 19 Apr 91 02:07:49 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA28154; Fri, 19 Apr 91 02:07:45 EDT Date: Fri 19 Apr 91 02:02:50-EDT From: John C Klensin Subject: Re: SIGH! Re: text --> IA5 ? To: Peter.Vanderbilt@eng.sun.com Cc: keld@dkuug.dk, ietf-822@dimacs.rutgers.edu Message-Id: <672040970.24671.KLENSIN@INFOODS.MIT.EDU> In-Reply-To: <9104190326.AA20160@polya.Eng.Sun.COM> Mail-System-Version: Peter Vanderbilt writes, in part... >First, IA5, what X.400 uses, is based on ISO-IR-2. "Based on"? No. No more than ASCII is "based on" 6. They are, by no coincidence, identical in the graphics characters but certainly ASCII, and, if I recall, IA5, are "character set first, registration of graphical repertoire later". >Second: As I understand it, each registration numbers refers to only a >part of a typical character set. In general, for what we mean by "character set", one needs at least two--one for graphics and one for controls. For many purposes, of course, one does not care about the controls. But, in a document that references things like CR and LF, one must be careful. >For example, ISO 8859/1 (Latin-1) has characters from registrations 6 >and 100 -- the 6 refers to ASCII and the 100 to the right hand part of >8859/1. There are additional registration numbers for the control >characters. Calling 8859/1 "ISO-IR-100" would be inexact, at best. Yes. And for those who believe that "ASCII" is the only source of terrible confusion around here, note ISO8859-1 (both graphic sets and both control sets) is called "Latin-1" and that registration 100 is called--you guessed it--"Latin-1". >The differences between >versions and vintages are fairly minor and are probably not adhered to >by real systems anyway. Before our European colleagues wake up and have to generate flames early in the morning... There is an ISO Standard, 646 (note low number), which started with ASCII as a departure point. Traditionally, 646 has specified two "versions". One of those, the "international reference version" is identical to ASCII with the substitution of "universal currency symbol" for "dollar sign". The other, however, is something called the "basic version". It reserves about a half-dozen character positions that ASCII uses for special characters for "national use" characters, leading to roughly one national variation per country. And "real systems" pay attention: if nothing else, these national characters show up on keyboard keytops, printers, and usually screens. >Does everybody reading this mail see >"$@[]\^`{}|~" as dollar sign, at sign, square brackets, back slash, >caret, back quote, curly brackets, vertical bar and tilde (hope I've >got the names right!)? In a word, no. Letters with umlauts, and cedillas, and grave and acute accents, and slashes, and circles over letters, and question marks with the little curvy part at the bottom and the dot at the top, and... > For the future we should nail down the >character set as exactly as possible, including whether regionally >varying renditions are allowed. Yeah. And we need to be clear about whether we are specifying (nailing down) graphic coding only (e.g., ISO-RN-6) or both graphics and controls (e.g., ASCII). Sorry, Stef, it really isn't going to be easy :-) --john ------- From owner-ietf-822@dimacs.rutgers.edu Fri Apr 19 10:48:46 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA07697; Fri, 19 Apr 91 09:28:33 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA07693; Fri, 19 Apr 91 09:28:31 EDT Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Fri, 19 Apr 91 09:28:28 EDT Received: by greenbush.bellcore.com (4.12/4.7) id for ietf-822@dimacs.rutgers.edu; Fri, 19 Apr 91 09:31:55 edt Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.greenbush.mouseclub.sun4.40 via MS.5.6.greenbush.mouseclub.sun4_40; Fri, 19 Apr 1991 09:31:51 -0400 (EDT) Message-Id: Date: Fri, 19 Apr 1991 09:31:51 -0400 (EDT) From: Nathaniel Borenstein To: ietf-822@dimacs.rutgers.edu Subject: Re: Spelling "ASCII" in ECMA or ISO In-Reply-To: <672016535.912671.KLENSIN@INFOODS.MIT.EDU> References: <672016535.912671.KLENSIN@INFOODS.MIT.EDU> I think that John's probably right. My take on it is that we should allow all the ISO character sets to be specified in the form ISO-IR-xxx, but that the "default" content-type should be handled specially, because it probably isn't, from all I've heard, exactly the same as ISO-IR-6. We can't change the default RFC 822 body part retroactively. -- Nathaniel From owner-ietf-822@dimacs.rutgers.edu Fri Apr 19 11:42:36 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA09684; Fri, 19 Apr 91 10:26:59 EDT Received: from uvaarpa.Virginia.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA09680; Fri, 19 Apr 91 10:26:56 EDT Received: from uvacs.cs.Virginia.EDU by uvaarpa.Virginia.EDU id aa26539; 19 Apr 91 10:26 EDT Received: from wilbury.cs.Virginia.EDU by uvacs.cs.Virginia.EDU (4.1/5.1.UVA) id AA13515; Fri, 19 Apr 91 10:26:04 EDT Posted-Date: Fri, 19 Apr 91 10:27:23 EDT Return-Path: Received: by wilbury.cs.Virginia.EDU (4.1/SMI-2.0) id AA18763; Fri, 19 Apr 91 10:27:23 EDT Date: Fri, 19 Apr 91 10:27:23 EDT From: rja7m@wilbury.cs.virginia.edu Message-Id: <9104191427.AA18763@wilbury.cs.Virginia.EDU> X-Mailer: Mail User's Shell (7.2.0 10/31/90) To: ietf-822@dimacs.rutgers.edu Subject: Character set identification I think that disallowing the use of the term "ASCII" is a mistake because it is clearly understood by more people than any other term. Allowing the ECMA registrations as permitted extensions does seem reasonable, but frankly the use of these 7-bit variants is fading quickly and I'm a lot more concerned with proper handling of the 8-bit standards that all are moving towards and that will be with us a long time in the future (namely the ISO 8859/x series). The ECMA registration is "international" in the European sense but is not widely used outside of Europe. I think that omitting "ASCII" in favor of the ECMA name is a mistake. Allowing both seems a reasonable compromise. The previous note about deficiencies in ISO 646 should be given careful thought with regard to this effort. Randall Atkinson randall@Virginia.EDU From owner-ietf-822@dimacs.rutgers.edu Sat Apr 20 14:09:53 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA14450; Sat, 20 Apr 91 13:58:14 EDT Received: from dkuug.dk by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA14429; Sat, 20 Apr 91 13:57:54 EDT Received: by dkuug.dk (5.64+/8+bit/IDA-1.2.8) id AA27941; Sat, 20 Apr 91 19:57:24 +0200 Date: Sat, 20 Apr 91 19:57:24 +0200 From: Keld J|rn Simonsen Message-Id: <9104201757.AA27941@dkuug.dk> To: ietf-822@dimacs.rutgers.edu, nsb@thumper.bellcore.com Subject: Re: Spelling "ASCII" in ECMA or ISO X-Charset: ASCII X-Char-Esc: 29 > I think that John's probably right. My take on it is that we should > allow all the ISO character sets to be specified in the form ISO-IR-xxx, > but that the "default" content-type should be handled specially, because > it probably isn't, from all I've heard, exactly the same as ISO-IR-6. > We can't change the default RFC 822 body part retroactively. -- ISO-IR-6 is actually the same as ASCII, except that the control codes are not defined in ISO-IR-6. I would go with allowing them both, the ASCII name is especially convenient if the user is going to type this by hand, as ASCII is very well known, and people may have problems in remembering the relevant ISO registration number. Keld From owner-ietf-822@dimacs.rutgers.edu Sat Apr 20 16:09:57 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA17168; Sat, 20 Apr 91 16:07:41 EDT Received: from TWG.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA17164; Sat, 20 Apr 91 16:07:30 EDT Received: from Obelix.twg.com by twg.com with SMTP ; Sat, 20 Apr 91 13:05:40 PST Received: from obelix.twg.com by Obelix.TWG.COM id aa27800; 20 Apr 91 13:05 PDT To: John C Klensin Cc: ietf-822@dimacs.rutgers.edu Subject: Re: RFC-87gtwys (was: smtp charter (revised) ) In-Reply-To: Your message of Fri, 19 Apr 91 15:03:55 -0400. <672087835.816671.KLENSIN@INFOODS.MIT.EDU> Date: Sat, 20 Apr 91 13:05:11 -0700 From: David Herron Message-Id: <9104201305.aa27800@Obelix.TWG.COM> [Message redirected to ietf-822 because it's not talking about SMTP++] > >>Basically some intermediate node must try > >> to translate a message without knowledge of either the sender > >> or the receiver. > > > >Assumably the translations will be well enough defined that it > >can be performed "on the fly" by software. > You mean like from Chinese characters into English? Or from music and > pictures into ASCII? Or from an ISO ("ECMA") registration recorded last > Monday into Latin-1? :-( No, doing so requires semantic knowledge. (I have a moderately strong background in Linguistics, and know that language translation is a Hard Problem). The kind of translations which can be done "on the fly" are encoding funny bytes into printable ascii (eg UUENCODE, TEX-HEX, etc) or (perhaps, if it is known) translating one picture (or sound) format into another. The last is something to be nervous over, especially over "conversions with loss" (As X.400 puts it). Fortunately there are a couple of headers available in X.400 (and codified into RFC parlance in Steve Kille's string of RFCs ending in 1148) Conversion: (allowed|prohibited) Conversion-With-Loss: (allowed|prohibited) Assuming that each piece of a message identifies what it is then the sorts of conversions I'm talking about are doable. What I expect is that as a message leaves an Enclave (as Stef described) that anything funny about the body be translated into uuencode (or something). Some sorts of markers need to be placed in the message describing what each piece is, and the encoding be used. etc. > I'd be delighted to provide an MHS > with limit values on how much transformation I'm willing to let it do > (if you can define that scale), but the default ought to be that, if the > message can't be delivered as sent, it gets returned, not opened and > rewritten by some hidden daemon. Are the Conversion: header lines enough for you? Suppose you had a bitmap of some Known and Defined format in your message and the destination was delivering messages to a fax machine. (Because the person is away from the office, and messages are going to the hotel fax where s/he is staying). Translating text into a FAX-bitmap is pretty easy, supporting many character sets makes it a little bit harder. Translating the bitmap is doable, but since G3-FAX is "only" 100x200 dpi then that translation might entail some loss in quality. David From owner-ietf-822@dimacs.rutgers.edu Sat Apr 20 20:09:59 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA21957; Sat, 20 Apr 91 19:50:56 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA21953; Sat, 20 Apr 91 19:50:53 EDT Date: Sat 20 Apr 91 19:49:35-EDT From: John C Klensin Subject: Re: RFC-87gtwys (was: smtp charter (revised) ) To: david@twg.com Cc: ietf-822@dimacs.rutgers.edu Message-Id: <672191375.700671.KLENSIN@INFOODS.MIT.EDU> In-Reply-To: <9104201305.aa27800@Obelix.TWG.COM> Mail-System-Version: >Are the Conversion: header lines enough for you? No. The binary (with/without) granularity isn't fine enough. And what I think I learned back when I took may last course in communications and information theory over a quarter century ago, "without loss" is a really interesting philosophical concept, but impractical in practice: something about the assurance of shared semantics... :-) >Suppose you had a >bitmap of some Known and Defined format in your message and the >destination was delivering messages to a fax machine. >... This is actually a perfect example. In the general case, I don't know about the delivery device. If I start with a character stream message, one can talk about probable percentage distortion loss models which are, in general, pretty complicated--in part because, if the delivery translator prints VERY LARGE on the fax machine, 100x200 may be plenty, but, if it decides to print in 6 or 8 point, there may be big trouble. Moreover, in deciding the minimum acceptable size to print, a system that "knows" it is transmitting only upper-case ASCII can print lots smaller than the same system printing from a repertoire of a few thousand Kanji with equivalent levels of information loss (discuss this problem with almost any producer of OCR software). Even if I start with a bitmapped image at, say, 400x400 dpi and a simple graphic case, I may want/need to say "sampling and smoothing this down to 200x200 is ok, but don't go below that, and if you are going to sample and not smooth, the limit is 300x300". Those types of statements are reasonable, but a bit more complex than "allowed/prohibited". That said, this is, again, an argument for keeping the MTAs out of the business, not an argument for giving up entirely. If the dialogue between the final delivery MTA and the receiver UA can logically contain "hey, I've got this 400x400 dpi image for you, what would you like to do with it?", then answers like "wait until I find a high-resolution workstation", "go ahead and display it on this fuzzy fax and I'd see if I can read it, but save the 400x400 form in case I need to make a better plan", or "print it on the fax machine, but do every page as four so none of the dots get lost" all become options. If the sending UA (or the user driving it) wants to include headers that say "hey recipient, don't even think about reading this until you can do so at 400x400 or above", I think it is a dandy idea to have a good mechanism for passing that along, but I don't want any intermediate MTA making decisions on that basis. --john ------- From owner-ietf-822@dimacs.rutgers.edu Sun Apr 21 01:39:54 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA28887; Sun, 21 Apr 91 01:16:45 EDT Received: from RUTGERS.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA28880; Sun, 21 Apr 91 01:16:39 EDT Received: from nrtc.northrop.com by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA21218; Sun, 21 Apr 91 01:16:26 EDT Received: from nma.com by nrtc.nrtc.northrop.com id ad27531; 20 Apr 91 21:15 PST Received: from odin.nma.com by nma.com id aa15179; 20 Apr 91 20:51 PDT To: Keld J|rn Simonsen Cc: ietf-822@dimacs.rutgers.edu, nsb@thumper.bellcore.com Subject: Re: Spelling "ASCII" in ECMA or ISO In-Reply-To: Your message of Sat, 20 Apr 91 19:57:24 +0100. <9104201757.AA27941@dkuug.dk> Reply-To: Stef@ics.uci.edu From: Einar Stefferud Date: Sat, 20 Apr 91 21:48:57 MDT Message-Id: <1267.672209337@nma.com> Sender: stef@nma.com Well, we seem to have come back around full circle. I hope that what we define the default identifier to be, for what we all know and love as RFC822 ASCII, will be totally unambiguous to the casual user. With 8859-1 coming to be commonly known as 8-bit ASCII, I would hope that we make sure that casual users do not think that ASCII means 8-bit ASCII! So, I think we are back to USACII, or maybe RFC-XXXX-ASCII, just to be really clear about exactly what the default really is, and then define it with tablesincluded in an RFC-XXXX ANNEX to support resolution of bar bets and other pointless arguments about what it is supposed to mean. Best...\Stef From owner-ietf-822@dimacs.rutgers.edu Sun Apr 21 23:10:02 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA22533; Sun, 21 Apr 91 22:35:49 EDT Received: from manta.mel.dit.CSIRO.AU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA22526; Sun, 21 Apr 91 22:35:41 EDT Received: from manta.mel.dit.CSIRO.AU by manta.mel.dit.csiro.au with SMTP id AA09999 (5.65b/IDA-1.4.3/DIT-1.2 for ietf-822@dimacs.rutgers.edu); Mon, 22 Apr 91 12:34:55 +1000 Message-Id: <9104220234.AA09999@manta.mel.dit.csiro.au> To: erik@sra.co.jp Cc: ietf-822@dimacs.rutgers.edu Subject: Re: Strawman proposal In-Reply-To: Your message of "Mon, 22 Apr 91 10:35:03 +0900." <9104220135.AA08456@sran8.sra.co.jp> Date: Mon, 22 Apr 91 12:34:54 +1000 From: Bob Well this is definitely an 822 msg so I've changed the list. >After writing my previous messages, I realized that TEXT-HEX would not >work very well for Japanese. The Japanese use a form of ISO 2022 that >uses only 7 bits, but each Japanese character uses 2 of the 94 >printable ASCII characters, so changing & to && or &26 would actually >change 2 or more characters to something else (garbage). In many >cases, the user would be able to see that something happened to the >message, but sometimes the change would be subtle. In any case, this >is not very good for the Japanese users. If you use 7 bits you are probably RFC821-clean already. So I'm not sure why you'd need an escape. If you do then define a specific pair of characters to be the escape instead of a single character. The key point is that each Content-type should have its own set of Content-encodings. So you don't have to use a single character for an escape character in an encoding if that won't work well. All I ask is that you put Content-type: Japanese Content-encoding: ISO2022-x in the header of the message so that my mail UA knows how to display the message (even if I can't then read it!). > If it is rejected, we send the 8-bit data using DATA Definitely not acceptable -- but I'm not sure why you want to send 8 bit data anyway. Bob Smart From owner-ietf-822@dimacs.rutgers.edu Mon Apr 22 14:10:05 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA12653; Mon, 22 Apr 91 13:18:56 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA12649; Mon, 22 Apr 91 13:18:53 EDT Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Mon, 22 Apr 91 13:18:49 EDT Received: by greenbush.bellcore.com (4.12/4.7) id for ietf-822@dimacs.rutgers.edu; Mon, 22 Apr 91 13:22:17 edt Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.greenbush.mouseclub.sun4.40 via MS.5.6.greenbush.mouseclub.sun4_40; Mon, 22 Apr 1991 13:22:13 -0400 (EDT) Message-Id: <4c4lj560M2YtQKUHpL@thumper.bellcore.com> Date: Mon, 22 Apr 1991 13:22:13 -0400 (EDT) From: Nathaniel Borenstein To: ietf-822@dimacs.rutgers.edu Subject: A Kinder, Gentler New Draft Ned and I have completed work on a major revision of the draft RFC. The result is an RFC that is much more polished and much closer to being "finished" (whatever that means). In my next two messages, I will be posting it to the list. I will post it in two forms, a plain-text version and a PostScript version. I encourage you to print it on paper, as the PostScript version is eminently more readable. In this draft, we have taken the attitude of pretending, at least, to give definitive answers to all questions. Gone is the hemming and hawing of previous versions. In its place is a document that pretends, at least, to know what it is talking about. In some cases, it probably doesn't. Please don't interpret the firmer tone of this document as an implication that anything is set in stone; it is intended only to reflect our hope that most of the document, at least, is firmer than it used to be. Finally, I'd like to suggest a convention for structuring our comments about this document. Instead of just sending all your mail as "Re: The New Draft" or something like that, how about trying to put the section number into your Subject header? Thus, a comment on section 3.1 might have Subject: 3.1: Style #2 stinks or Subject: Appendix A: You must be kidding This might make it easier for casual readers of this list to focus on topics of interest to them. If you have comments on several sections, and it isn't too much trouble, you might think about breaking them up into several messages. (I'm inevitably going to read them all, so it really doesn't matter to me, but I know that some readers of this list have considerably more specialized interests, and this convention would be kinder to them.) I'd like to particularly draw peoples' attention to Section 2, which defines a LOT of new Content-types that have never been defined before. Some of these were defined with only minimal help from experts in the field, and could doubtless benefit enormously from further scrutiny. Also, please note that five of the references are not yet fleshed out. I think I'll be able to handle them, but didn't want to delay the draft just to complete a few references. The draft RFC will follow shortly. Fire away! -- Nathaniel From owner-ietf-822@dimacs.rutgers.edu Mon Apr 22 14:39:54 1991 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA12765; Mon, 22 Apr 91 13:20:50 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA12738; Mon, 22 Apr 91 13:20:35 EDT Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Mon, 22 Apr 91 13:20:29 EDT Received: by greenbush.bellcore.com (4.12/4.7) id for ietf-822@dimacs.rutgers.edu; Mon, 22 Apr 91 13:23:57 edt Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.greenbush.mouseclub.sun4.40 via MS.5.6.greenbush.mouseclub.sun4_40; Mon, 22 Apr 1991 13:23:51 -0400 (EDT) Message-Id: Date: Mon, 22 Apr 1991 13:23:51 -0400 (EDT) From: Nathaniel Borenstein To: ietf-822@dimacs.rutgers.edu Subject: TEXT version of Draft RFC Network Working Group -- Request for Comments: XXXX A Multipart Content-Type and Content-Encoding Mechanism for RFC 822 Messages Nathaniel Borenstein, Bellcore Ned Freed, Innosoft April 1991 Status of This Memo This RFC suggests extensions to the RFC 822 message representation protocol to allow multi-part textual and non-textual messages to be represented and exchanged without loss of information. Discussion and suggestions for improvements are welcome. This memo does not specify an Internet standard. Distribution of this memo is unlimited. If this RFC becomes a standard, it would affect the following other RFC's: Would Obsolete: RFC 934, RFC 1049, RFC 1154 Would Update: RFC 822 Would Affect: RFC 1148 Table of Contents Introduction The Content-Type Header Field The Content-Encoding Header Field Quoted-Printable Content-Encoding Quoted-Printable Content-Encoding Base64 Content-Encoding The "Multipart" Content-Type A Complex Multipart Example The Encoded-Variable Header Field Cross-References Between Encapsulated Parts Optional Content-Size Header Field Summary Acknowledgements References Appendix A: The Character Set for the MAILASCII Content-Type