Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07580; 1 Sep 93 12:01 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07576; 1 Sep 93 12:01 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa14002; 1 Sep 93 12:01 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19825; Wed, 1 Sep 93 11:36:48 EDT Received: from uu3.psi.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19821; Wed, 1 Sep 93 11:36:47 EDT Received: from bacon.UUCP by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA11339 for ; Wed, 1 Sep 93 11:24:03 -0400 Received: from stimpys.imsi.com by bacon.IMSI.COM (4.1/SMI-4.1) id AA11004; Wed, 1 Sep 93 10:10:18 EDT Received: from localhost by stimpys.imsi.com (4.1/SMI-4.1) id AA15736; Wed, 1 Sep 93 10:10:17 EDT Message-Id: <9309011410.AA15736@stimpys.imsi.com> To: Allen Gwinn Cc: ietf-822@dimacs.rutgers.edu Subject: Re: Simple Network Paging Protocol In-Reply-To: Your message of "Tue, 31 Aug 1993 16:07:08 CDT." Reply-To: rens@imsi.com Date: Wed, 01 Sep 1993 10:10:17 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Rens Troost A few comments on the protocol: 1> It seems overly complicated. If you only allow one MESS and one PAGE for each send, you shold collapse it into one verb, e.g. -> PAGE 5551212 Your network is hosed <- 250 Page Sent -> QUIT <- 221 Goodbye! I helped build a pager system with a very similar protocol. Don't needlessly multiply entities. 2> You should allow for multiple pager IDs per message. 3> Meaningful error responses should be numeric, with arbitrary ASCII strings appended for human-readability. 4> Some form of authentication should be provided. That aside, I like your approach,and this is something that sure could use standardization! Is this really appropriate for ietf-822? -Rens   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12146; 1 Sep 93 16:07 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12142; 1 Sep 93 16:07 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa23667; 1 Sep 93 16:07 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA24532; Wed, 1 Sep 93 15:41:02 EDT Received: from rutvm1.rutgers.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA24528; Wed, 1 Sep 93 15:41:01 EDT Message-Id: <9309011941.AA24528@dimacs.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RUTVM1.RUTGERS.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 1778; Wed, 01 Sep 93 15:39:55 EDT Received: from RICEVM1.RICE.EDU (NJE origin MAILER@RICEVM1) by RUTVM1.RUTGERS.EDU (LMail V1.1d/1.7f) with BSMTP id 2632; Wed, 1 Sep 1993 15:39:53 -0400 Received: from ricevm1.rice.edu (NJE origin TROTH@RICEVM1) by RICEVM1.RICE.EDU (LMail V1.1d/1.7f) with BSMTP id 5038; Wed, 1 Sep 1993 14:40:11 -0500 Mime-Version: 1.0 Content-Type: text/plain Date: Wed, 01 Sep 93 14:21:31 CDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Rick Troth Subject: Re: standards/suggestions for MIME transport of PC filetypes? To: CHRIS R BARTRAM , mmm-people@isi.edu, ietf-822@dimacs.rutgers.edu In-Reply-To: Message of Wed, 18 Aug 1993 11:57:55 -0400 from > We're working on a MIME implementation with extenstions to handle the >transport of PC files. If what you're concerned with is specifically file transfer, I'd suggest having a look at RFC 1440. > Obviously the generic APPLICATION/ type will >transport them, but we want our user agent to be able to determine >what "application" generated the file, and further to do something >"intelligent" with it, including extracting the file into an appropriate >filename (with extension) onto the PC and potentially launching the >related application. The RFC 1440 client I've written uses MIME if it can't connect via TCP directly. In this case, I chose application/octet-stream and appended things like name=filename.ext as parameters. This has worked remarkably well, if you have a reasonably well behaved MIME MUA on the receiving end. > We have to use the PC extension as a guideline for identifying the >application ... If you stick with PC-to-PC scenarios, then keying off the .EXT should work quite nicely. NeXT had a lot of success with their browser using .extensions even in the Unix (Mach, actually) world. I'd rather see this than a plethora of MIME types. > TIA, > Chris Bartram -- Rick Troth , Rice University, Information Systems   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13141; 1 Sep 93 17:01 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13137; 1 Sep 93 17:01 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa25873; 1 Sep 93 17:01 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA24953; Wed, 1 Sep 93 16:40:48 EDT Received: from dorner.slip.uiuc.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA24949; Wed, 1 Sep 93 16:40:31 EDT Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA04739 (5.65c/IDA-1.4.4 for ietf-822@dimacs.rutgers.edu); Wed, 1 Sep 1993 15:39:24 -0500 Message-Id: <199309012039.AA04739@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 1 Sep 1993 15:40:10 -0500 To: Rick Troth , CHRIS R BARTRAM , mmm-people@isi.edu, ietf-822@dimacs.rutgers.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Dorner Subject: Re: standards/suggestions for MIME transport of PC filetypes? At 2:21 PM 9/1/93 -0500, Rick Troth wrote: > If you stick with PC-to-PC scenarios, then keying off the >.EXT should work quite nicely... >I'd rather see this than a plethora of MIME types. What this solution ignores is the fact that these extensions, used in the suggested manner, are important type information, which would be well-served by a registry. Without such a registry, this solution is in fact a return to the pre-MIME world, where mailers had to rely on proprietary means, heuristics, and manual labor to move useable data from place to place. These things need to be registered somehow. What is the objection to using the existing MIME mechanisms? -- Steve Dorner, Qualcomm Inc.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13748; 1 Sep 93 17:33 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13744; 1 Sep 93 17:33 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa27143; 1 Sep 93 17:33 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA25050; Wed, 1 Sep 93 16:54:12 EDT Received: from nyse.cox.smu.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA25046; Wed, 1 Sep 93 16:54:09 EDT Received: by nyse.cox.smu.edu (Smail3.1.28.1 #1) id m0oXzBw-0000X5C; Wed, 1 Sep 93 15:54 CDT Message-Id: Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Allen Gwinn Subject: Re: Simple Network Paging Protocol To: ietf-822@dimacs.rutgers.edu Date: Wed, 1 Sep 1993 15:54:07 -0500 (CDT) In-Reply-To: <9309011410.AA15736@stimpys.imsi.com> from "Rens Troost" at Sep 1, 93 10:10:17 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2712 > 1> It seems overly complicated. If you only allow one MESS and one > PAGE for each send, you shold collapse it into one verb, e.g. > > -> PAGE 5551212 Your network is hosed > <- 250 Page Sent > -> QUIT > <- 221 Goodbye! > > I helped build a pager system with a very similar protocol. Don't > needlessly multiply entities. > > 2> You should allow for multiple pager IDs per message. Funny you should mention that :-) The reason that I did it with the PAGEr/MESSage format was so that eventually, hopefully, I could figure out a "good" way to provide for multiple pager IDs per message. As you are aware, IXO doesn't really tell you that a pager ID *was* invalid until you have assembled the whole message and sent it to the paging terminal. Big problem. This means that you can't really validate a pager ID without trying to send it a page. There are standard protocols in the paging industry that will allow you to do a validation query. That is why I've started building this protocol this way. Hopefully, this philosophy will allow for instant validation of each page in a multi-recipient message. But right now its just a "stepping stone" to get a terminal up in an easy-to-access manner. > 3> Meaningful error responses should be numeric, with arbitrary > ASCII strings appended for human-readability. I patterned this after the (yecch) POP2 protocol because of being able to report success or failure (in various degrees) by looking at the first character of the reply. I have, however, considered numeric error responses in later implementations. > 4> Some form of authentication should be provided. Yeah, yeah, I know :-) I will probably do some sort of lookup and logging of the sender at the gateway, but is this really part of the protocol? I mean, look at what they deal with now: dialup phone lines into a modem. Thats pretty anonymous. Anything we do on the net is going to be more "secure" than that. It is interesting to note that IXO does provide for a "password" to access the IXO terminal, but nobody really uses it (rather I should say "not that I know of") at public paging companies. > That aside, I like your approach,and this is something that sure could > use standardization! Thanks! This has been one of those "gonna-do's" that I have wanted to do for some time. My goal was (1) simplicity, and (2) something that would be buildable for the future. > Is this really appropriate for ietf-822? Dave Crocker threatened to have me thrown into an industrial eggbeater and turned into an omlette if I didn't :-) If this is not appropriate for this group, I will certainly refrain. Please let me know. Allen Gwinn allen@mail.cox.smu.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00701; 2 Sep 93 2:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00641; 2 Sep 93 2:44 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id bj01321; 2 Sep 93 2:44 EDT Received: from dimacs.rutgers.edu by IETF.CNRI.Reston.VA.US id aa21589; 1 Sep 93 23:47 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29301; Wed, 1 Sep 93 23:20:12 EDT Received: from THUD.CS.UTK.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29297; Wed, 1 Sep 93 23:20:11 EDT Received: from LOCALHOST by thud.cs.utk.edu with SMTP (5.61+IDA+UTK-930125/2.7c-UTK) id AA00915; Wed, 1 Sep 93 23:20:00 -0400 Message-Id: <9309020320.AA00915@thud.cs.utk.edu> To: allen@nyse.cox.smu.edu, ietf-822@dimacs.rutgers.edu Subject: Re: Simple Network Paging Protocol Cc: moore@cs.utk.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith Moore Date: Wed, 01 Sep 1993 23:19:59 -0400 X-Orig-Sender: moore@cs.utk.edu The protocol is similar enough to SMTP that I'm wondering if SMTP couldn't be adapted for paging. In particular, paging seems to be very similar to what the SEND verb used to be used for. And the SEND/SAML/SOML/MAIL scheme might allow existing mail user agents to to originate pages, resulting in better integration than if a separate protocol were used. Keith Moore   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00733; 2 Sep 93 2:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00690; 2 Sep 93 2:44 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id ac01539; 2 Sep 93 2:44 EDT Received: from dimacs.rutgers.edu by IETF.CNRI.Reston.VA.US id aa22635; 2 Sep 93 0:39 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29281; Wed, 1 Sep 93 23:07:59 EDT Received: from THUD.CS.UTK.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29277; Wed, 1 Sep 93 23:07:57 EDT Received: from LOCALHOST by thud.cs.utk.edu with SMTP (5.61+IDA+UTK-930125/2.7c-UTK) id AA00808; Wed, 1 Sep 93 23:07:26 -0400 Message-Id: <9309020307.AA00808@thud.cs.utk.edu> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith Moore To: Rick Troth Cc: Steve Dorner , CHRIS R BARTRAM , mmm-people@isi.edu, ietf-822@dimacs.rutgers.edu, moore@cs.utk.edu Subject: Re: standards/suggestions for MIME transport of PC filetypes? In-Reply-To: Your message of "Wed, 01 Sep 1993 17:34:07 CDT." <9309012250.AA25810@dimacs.rutgers.edu> Date: Wed, 01 Sep 1993 23:07:22 -0400 X-Orig-Sender: moore@cs.utk.edu My take on the use of file extensions and other platform-specific type information is a bit different. If the file you are sending is of a standard or well-known MIME content-type, then you maximize interoperability by labelling the file with that content-type, rather than with application/octet-stream. If the file you are sending is only meaningful on platform X, you might as well use X's typing mechanism to convey the type information. That way there's no chance the wrong type will be used. For PCs this information is part of the file name, and MIME already provides a convenient way to pass this information. However, there's no guarantee that the name of a file actually reflects its MIME type. A MIME mail composer that uses a file's name to determine the MIME content-type will mislabel some files. (If this happens very often, MIME mail *readers* will then be taught to examine magic numbers in body parts, because they cannot trust the content-type label in the message.) suggestions: 1. Be careful about using file names to determine the MIME content-type. composers should use magic numbers and/or sender confirmation of the type (e.g. "Send FOO.TXT as a Microsoft Word file (y/n)?") before sending. 2. If you aren't pretty sure of the MIME type, or if it is inherently platform-specific, send it as application/octet-stream. Keith   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00742; 2 Sep 93 2:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00709; 2 Sep 93 2:44 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id ad01539; 2 Sep 93 2:44 EDT Received: from dimacs.rutgers.edu by IETF.CNRI.Reston.VA.US id aa22660; 2 Sep 93 0:41 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29315; Wed, 1 Sep 93 23:24:33 EDT Received: from ppp.dbc.mtview.ca.us by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29311; Wed, 1 Sep 93 23:24:29 EDT Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA09066; Wed, 1 Sep 93 20:23:28 -0700 Reply-To: ietf-822@dimacs.rutgers.edu To: ietf-822@dimacs.rutgers.edu Cc: Dave Crocker , rens@imsi.com, Allen Gwinn Subject: Re: Simple Network Paging Protocol In-Reply-To: Your message of "Wed, 01 Sep 1993 20:06:02 PDT." <8884.746939162@dbc.mtview.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <9055.746940201.1@dbc.mtview.ca.us> Date: Wed, 01 Sep 1993 20:23:21 -0700 Message-Id: <9057.746940201@dbc.mtview.ca.us> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Marshall Rose Forgot to add something: > So, how to make this work: > > 1. Get someone to apply for, and then manage in a fair-and-open manner, > a high-level domain. > > 2. Tell the pager providers that if they had an SMTP connectivity to the > Internet, then they could get pages that way. Heck, since you don't have faxes and pagers on the same numbers, I'll tell 'ya what: If people want this approach instead, I'd be happy to ask the people who administer the tpc.int. subdomain (there's a board!) if they'd be willing to allow pager registrations under tpc.int. If they said yes, then step 1 is completely taken care of! /mtr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00781; 2 Sep 93 2:45 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00777; 2 Sep 93 2:45 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id af01608; 2 Sep 93 2:45 EDT Received: from dimacs.rutgers.edu by IETF.CNRI.Reston.VA.US id aa22823; 2 Sep 93 1:19 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29589; Thu, 2 Sep 93 00:37:45 EDT Received: from ANDREW.CMU.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29585; Thu, 2 Sep 93 00:37:44 EDT Received: from localhost (postman@localhost) by andrew.cmu.edu (8.5/8.5) id AAA28716; Thu, 2 Sep 1993 00:37:39 -0400 Received: via switchmail; Thu, 2 Sep 1993 00:37:38 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 2 Sep 1993 00:36:14 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 2 Sep 1993 00:35:55 -0400 (EDT) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.412 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Thu, 2 Sep 1993 00:35:55 -0400 (EDT) Message-Id: <4gVLUf_00WBw4WZH4q@andrew.cmu.edu> Date: Thu, 2 Sep 1993 00:35:55 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Gardiner Myers To: ietf-822@dimacs.rutgers.edu, Rick Troth Subject: Re: text/enriched In-Reply-To: <9309012300.AA25917@dimacs.rutgers.edu> References: <9309012300.AA25917@dimacs.rutgers.edu> Beak: Is << is a special case, however it is a special case of the same magnitude as . The change doesn't introduce "special case" logic, it just trades one set of logic for another. People think that << is more readable than and this justifies the change. I can't disagree with this. As I mentioned in an earlier message, does three different things, all at once: 1. It turns off filling 2. It changes the newline model 3. It turns off command interpretation (except ) It is useful to do (1) without doing (3), so a command is needed regardless of whether exists.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01867; 2 Sep 93 3:32 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aj01740; 2 Sep 93 3:32 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aq01089; 2 Sep 93 2:42 EDT Received: from dimacs.rutgers.edu by IETF.CNRI.Reston.VA.US id aa14822; 1 Sep 93 21:02 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA25814; Wed, 1 Sep 93 18:50:53 EDT Received: from rutvm1.rutgers.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA25810; Wed, 1 Sep 93 18:50:52 EDT Message-Id: <9309012250.AA25810@dimacs.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RUTVM1.RUTGERS.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 2210; Wed, 01 Sep 93 18:49:43 EDT Received: from RICEVM1.RICE.EDU (NJE origin MAILER@RICEVM1) by RUTVM1.RUTGERS.EDU (LMail V1.1d/1.7f) with BSMTP id 4386; Wed, 1 Sep 1993 18:49:42 -0400 Received: from ricevm1.rice.edu (NJE origin TROTH@RICEVM1) by RICEVM1.RICE.EDU (LMail V1.1d/1.7f) with BSMTP id 2429; Wed, 1 Sep 1993 17:49:58 -0500 Mime-Version: 1.0 Content-Type: text/plain Date: Wed, 01 Sep 93 17:34:07 CDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Rick Troth Subject: Re: standards/suggestions for MIME transport of PC filetypes? To: Steve Dorner , CHRIS R BARTRAM , mmm-people@isi.edu, ietf-822@dimacs.rutgers.edu In-Reply-To: Message of Wed, 1 Sep 1993 15:40:10 -0500 from On Wed, 1 Sep 1993 15:40:10 -0500 you said: >At 2:21 PM 9/1/93 -0500, Rick Troth wrote: >> If you stick with PC-to-PC scenarios, then keying off the >>.EXT should work quite nicely... >>I'd rather see this than a plethora of MIME types. > >What this solution ignores is the fact that these extensions, used in >the suggested manner, are important type information, which would be >well-served by a registry. Without such a registry, this solution is >in fact a return to the pre-MIME world, ... Good point, Steve. I don't know that I'd pin it all the way back to the pre-MIME days, though. But it seems reasonable to me that some things are wrapped-up in MIME who's processing, and registration, is outside of MIME. In other words, MIME doesn't have to be all-things- to-all-applications. Let me state this a little more strongly: if someone tries to grow MIME to cover too many bases, it will either become unused or hated for its monstrous size. Keep it simple and people will love it. >These things need to be registered somehow. What is the objection to >using the existing MIME mechanisms? I may not be grasping the big picture, or even exactly what you mean. I don't object to using IANA. Would such use then label said types as "MIME types"? My vocabulary would call a "MIME type" something which fits on the Content-Type: header line, and I DO NOT think it would be wise to use that for every last file type under the sun. [did I miss a discussion about this?] Say Chris wants to send a .ZIP between two PCs. If MIME is being used solely for transport (where you could use FTP or 1440 or any of several other mechanisms), then MIME doesn't care about the meaning of the . Z I P on the end of the filename. MIME doesn't even care about the contents; it's just binary. The unzipper on the receiving end cares, and I think he wants to build an MUA that will extract the binary content and offer to process it for the user. But this doesn't seem to me to require a new MIME type anywhere, especially since we're talking about something that is (today, anyway) very platform specific. >-- >Steve Dorner, Qualcomm Inc. -- Rick Troth , Rice University, Information Systems   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01910; 2 Sep 93 3:33 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id an01740; 2 Sep 93 3:33 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id ad01208; 2 Sep 93 2:42 EDT Received: from dimacs.rutgers.edu by IETF.CNRI.Reston.VA.US id aa14982; 1 Sep 93 21:32 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA25921; Wed, 1 Sep 93 19:00:14 EDT Received: from rutvm1.rutgers.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA25917; Wed, 1 Sep 93 19:00:13 EDT Message-Id: <9309012300.AA25917@dimacs.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RUTVM1.RUTGERS.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 2228; Wed, 01 Sep 93 18:59:07 EDT Received: from RICEVM1.RICE.EDU (NJE origin MAILER@RICEVM1) by RUTVM1.RUTGERS.EDU (LMail V1.1d/1.7f) with BSMTP id 4472; Wed, 1 Sep 1993 18:59:06 -0400 Received: from ricevm1.rice.edu (NJE origin TROTH@RICEVM1) by RICEVM1.RICE.EDU (LMail V1.1d/1.7f) with BSMTP id 2732; Wed, 1 Sep 1993 17:59:24 -0500 Mime-Version: 1.0 Content-Type: text/plain Date: Wed, 01 Sep 93 17:53:28 CDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Rick Troth Subject: Re: text/enriched To: Chris Newman , ietf-822@dimacs.rutgers.edu In-Reply-To: Message of Mon, 9 Aug 1993 18:05:28 -0400 (EDT) from >The changes I consider substantive from a parsing viewpoint are the > to << change, ... I particularly agree with this. << introduces "special case" logic that I think we could avoid. It's a state machine; keep it simple. I don't understand the meaning of . If it is just a way to turn off "reflow", then fine ... great! In fact, it's reasonable for enclosing indentions to affect such a . But if it is a way to temporarily suspend interpretation, YUK! Another "special case", but with a *really* ugly k-map. Nastier than <<. > - Chris -- Rick Troth , Rice University, Information Systems   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01966; 2 Sep 93 3:33 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id au01740; 2 Sep 93 3:33 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id ag01321; 2 Sep 93 2:43 EDT Received: from dimacs.rutgers.edu by IETF.CNRI.Reston.VA.US id aa15124; 1 Sep 93 21:53 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA25903; Wed, 1 Sep 93 18:58:34 EDT Received: from SIGURD.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA25899; Wed, 1 Sep 93 18:58:32 EDT Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.3-0 #1234) id <01H2FOOCFVRK8ZEX09@SIGURD.INNOSOFT.COM>; Wed, 1 Sep 1993 15:24:00 PDT Date: Wed, 01 Sep 1993 15:15:57 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ned Freed Subject: RE: standards/suggestions for MIME transport of PC filetypes? In-Reply-To: Your message dated "Wed, 01 Sep 1993 14:21:31 -0500 (CDT)" <9309011941.AA24528@dimacs.rutgers.edu> To: Rick Troth Cc: CHRIS R BARTRAM , mmm-people@isi.edu, ietf-822@dimacs.rutgers.edu Message-Id: <01H2FT3T6U6Q8ZEX09@SIGURD.INNOSOFT.COM> Mime-Version: 1.0 Content-Type: text/plain; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > If you stick with PC-to-PC scenarios, then keying off the > .EXT should work quite nicely. NeXT had a lot of success with their > browser using .extensions even in the Unix (Mach, actually) world. > I'd rather see this than a plethora of MIME types. I might agree with you in the restricted case of PC to PC communications. The real world is not so limited, however. For example, what does an extension like .DOC mean? You'll find that it had very different meanings on VMS, UNIX, DEC-10, DEC-20 and PC systems. DEC-10's often use .DOC for documentation files, and CUSP's like RUNOFF make specific assumptions about this usage. I'm not sure this carries over to DEC-20 though. On VMS .DOC files are what DECPresent produces. The internal structure of these .DOC files is DDIF (an instance of ASN.1 and BER that's close to ODA, actually). And on UNIX .DOC has no special meaning as far as I know. There are lots of other overloaded extensions that are inevitably going to cause similar problems. And there are systems which simply don't have the concept of file extensions (Macintoshes). MIME types, on the other hand, are precisely and uniquely defined. As such, they provide critical information that file names will never be able to match. Ned   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01979; 2 Sep 93 3:33 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id av01740; 2 Sep 93 3:33 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id ah01321; 2 Sep 93 2:43 EDT Received: from dimacs.rutgers.edu by IETF.CNRI.Reston.VA.US id aa15130; 1 Sep 93 21:53 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA26000; Wed, 1 Sep 93 19:37:16 EDT Received: from uxc.cso.uiuc.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA25996; Wed, 1 Sep 93 19:37:14 EDT Received: from dorner.slip.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA09573 (5.67a/IDA-1.5 for ); Wed, 1 Sep 1993 18:36:50 -0500 Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA05149 (5.65c/IDA-1.4.4 for ietf-822@dimacs.rutgers.edu); Wed, 1 Sep 1993 18:36:57 -0500 Message-Id: <199309012336.AA05149@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 1 Sep 1993 18:37:31 -0500 To: Rick Troth , CHRIS R BARTRAM , mmm-people@isi.edu, ietf-822@dimacs.rutgers.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Dorner Subject: Re: standards/suggestions for MIME transport of PC filetypes? At 5:34 PM 9/1/93 -0500, Rick Troth wrote: > Say Chris wants to send a .ZIP between two PCs. >But this doesn't seem to me to require a new MIME type anywhere, >especially since we're talking about something that is (today, anyway) >very platform specific. 1. Note well your parenthetical. More and more things are binary-interoperable. The example you're using is in fact so; I have an "Unzip" application on my Mac. 2. Is there a one-to-one mapping of three-character extension to data types? I was under the impression there was not, even if you consider only PC's. Now, MUA's must rely on other signals to differentiate data types. These other signals really need to be used uniformly and now you need a registry again. > Let me state this a little more strongly: if someone tries to >grow MIME to cover too many bases, it will either become unused or >hated for its monstrous size. Keep it simple and people will love it. Merely growing the list of subtypes doesn't make MIME any more complex. It just makes the possible information it can carry bigger. I guess if you're doing file transfer between two known-to-be-identical environments, you may as well just slap on application/octet-stream and a filename and be done with it. But if there's any chance you're going to send this file anyplace that is any different from where it came from (and I would argue that this is going to be reasonable more and more of the time), I think using a registered MIME subtype is a very smart thing to do. -- Steve Dorner, Qualcomm Inc.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01997; 2 Sep 93 3:33 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aw01740; 2 Sep 93 3:33 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id ai01321; 2 Sep 93 2:43 EDT Received: from dimacs.rutgers.edu by IETF.CNRI.Reston.VA.US id aa15135; 1 Sep 93 21:53 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA25897; Wed, 1 Sep 93 18:57:43 EDT Received: from SIGURD.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA25893; Wed, 1 Sep 93 18:57:41 EDT Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.3-0 #1234) id <01H2FUADEXZ48ZFGWT@SIGURD.INNOSOFT.COM>; Wed, 1 Sep 1993 15:57:32 PDT Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.3-0 #1234) id <01H2FOOCFVRK8ZEX09@SIGURD.INNOSOFT.COM>; Wed, 1 Sep 1993 15:14:48 PDT Date: Wed, 01 Sep 1993 15:10:47 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ned Freed Subject: RE: standards/suggestions for MIME transport of PC filetypes? In-Reply-To: Your message dated "Wed, 01 Sep 1993 15:40:10 -0500" <199309012039.AA04739@dorner.slip.uiuc.edu> To: sdorner@qualcomm.com Cc: Rick Troth , CHRIS R BARTRAM , mmm-people@isi.edu, ietf-822@dimacs.rutgers.edu Message-Id: <01H2FSSE2LJO8ZEX09@SIGURD.INNOSOFT.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT > What this solution ignores is the fact that these extensions, used in the > suggested manner, are important type information, which would be > well-served by a registry. Without such a registry, this solution is in > fact a return to the pre-MIME world, where mailers had to rely on > proprietary means, heuristics, and manual labor to move useable data from > place to place. Steve is absolutely right. In addition, file names are a lot more varied than most people might suppose. A registry must also take into account the origin of the files, leading to different registries for different types of machines. We've taken the approach in our software of making the mapping of file names to types totally configurable. Different mappings are used depending on the origin of the file. > These things need to be registered somehow. What is the objection to using > the existing MIME mechanisms? I certainly have no objection! Ned   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02069; 2 Sep 93 3:33 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id be01740; 2 Sep 93 3:33 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id ax01321; 2 Sep 93 2:43 EDT Received: from dimacs.rutgers.edu by IETF.CNRI.Reston.VA.US id aa15277; 1 Sep 93 22:11 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA28976; Wed, 1 Sep 93 21:54:17 EDT Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA28971; Wed, 1 Sep 93 21:54:14 EDT Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA20887; Wed, 1 Sep 93 18:54:07 -0700 Message-Id: <9309020154.AA20887@Mordor.Stanford.EDU> To: rens@imsi.com Cc: Allen Gwinn , ietf-822@dimacs.rutgers.edu Subject: Re: Simple Network Paging Protocol Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Wed, 01 Sep 93 10:10:17 -0400. <9309011410.AA15736@stimpys.imsi.com> Date: Wed, 01 Sep 93 18:54:07 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Crocker X-Mts: smtp quick comment on the submission of this topic to this list, earing my IESG area director hat, actually on behalf of John Klensin who was occupied at the time: ---- Included message: Is this really appropriate for ietf-822? I asked Allen to submit it. Some preliminary review of his document exposed a belief in some corners that existing email technology and/or some modification to existing email technology could do the job as well. In addition, this is the forum with the closest match of skills, semantics, etc. So, I'd like the group to offer comments and discussion on SNPP to see where it does and does not fit. Thanks. Dave   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02079; 2 Sep 93 3:33 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id bf01740; 2 Sep 93 3:33 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id bc01321; 2 Sep 93 2:44 EDT Received: from dimacs.rutgers.edu by IETF.CNRI.Reston.VA.US id aa16785; 1 Sep 93 22:43 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29011; Wed, 1 Sep 93 21:56:41 EDT Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29007; Wed, 1 Sep 93 21:56:40 EDT Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA20921; Wed, 1 Sep 93 18:56:38 -0700 Message-Id: <9309020156.AA20921@Mordor.Stanford.EDU> To: Allen Gwinn Cc: ietf-822@dimacs.rutgers.edu Subject: Re: Simple Network Paging Protocol Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Wed, 01 Sep 93 15:54:07 -0500. Date: Wed, 01 Sep 93 18:56:38 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Crocker X-Mts: smtp Really, Allen... ---- Included message: Dave Crocker threatened to have me thrown into an industrial eggbeater and turned into an omlette if I didn't :-) It was a compost heap. I'm trying to reduce cholesterol and feed the environment... d/   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02404; 2 Sep 93 4:42 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02400; 2 Sep 93 4:42 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa03482; 2 Sep 93 4:42 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA00901; Thu, 2 Sep 93 03:59:08 EDT Received: from domen.uninett.no by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA00892; Thu, 2 Sep 93 03:59:03 EDT Message-Id: <9309020759.AA00892@dimacs.rutgers.edu> Received: from localhost by domen.uninett.no with SMTP (PP) id <01861-0@domen.uninett.no>; Thu, 2 Sep 1993 09:58:33 +0200 To: Ned Freed Cc: Rick Troth , CHRIS R BARTRAM , mmm-people@isi.edu, ietf-822@dimacs.rutgers.edu Subject: Re: standards/suggestions for MIME transport of PC filetypes? In-Reply-To: Your message of "Wed, 01 Sep 1993 15:15:57 PDT." <01H2FT3T6U6Q8ZEX09@SIGURD.INNOSOFT.COM> Date: Thu, 02 Sep 1993 09:58:30 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Harald T. Alvestrand" FrameMaker suggests using .doc as the standard file type for Frame documents. Harald A   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02509; 2 Sep 93 5:15 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02505; 2 Sep 93 5:15 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04498; 2 Sep 93 5:15 EDT Received: from dimacs.rutgers.edu by IETF.CNRI.Reston.VA.US id aa00899; 2 Sep 93 3:09 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA00425; Thu, 2 Sep 93 02:51:19 EDT Received: from mail.nada.kth.se by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA00421; Thu, 2 Sep 93 02:51:17 EDT Received: from mumrik.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA14359; Thu, 2 Sep 93 08:51:11 +0200 Message-Id: <9309020651.AA14359@nada.kth.se> To: ietf-822@dimacs.rutgers.edu Cc: Dave Crocker , rens@imsi.com, Allen Gwinn Subject: Re: Simple Network Paging Protocol In-Reply-To: Your message of "Wed, 01 Sep 1993 20:06:02 PDT." <8884.746939162@dbc.mtview.ca.us> Date: Thu, 02 Sep 1993 08:51:09 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Patrik Faltstrom Marshall Rose writes: >Ok, I'll ask the obvious question then. Why can't you do this with SMTP? We are already doing paging with SMTP in Stockholm, Sweden. The PTT in sweden have a X.25 pad which you can connect to (if you are a subscriber to this service) and page. The problem we have is that the PTT charge a lot for each paging you do. About $0.5 + $0.01/character for each paging. So, we don't allow paging to ANY number, just registered ones. The text in the mail body is converted into the correct character set, and a mix of the From:-line, Subject:-line and the body is paged. paf   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06135; 2 Sep 93 10:01 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06129; 2 Sep 93 10:01 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa14889; 2 Sep 93 10:00 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02489; Thu, 2 Sep 93 09:40:14 EDT Received: from [192.105.32.2] by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02485; Thu, 2 Sep 93 09:40:10 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: CHRIS R BARTRAM Message-Id: <000XH4@KIRK.UII.COM> X-Mailer: NetMail/3000 [Version A.04 93/06/12] Mime-Version: 1.0 Content-Type: text/plain Date: Thu, 2 Sep 1993 09:38:34 -0400 X-Hpdesk-Priority: 3 (Normal Priority) Subject: Re[2]: Simple Network Paging Protocol To: ietf-822@dimacs.rutgers.edu In <8884.746939162@dbc.mtview.ca.us> Marshall Rose writes: > Ok, I'll ask the obvious question then. Why can't you do this with SMTP? > > Specifically, if you want to send a page: > > 1. Construct an e-mail message addressed to "pager@n.u.m.b.e.r.suffix", > e.g., you want to page +1-415-555-1234, address it to > > pager@4.3.2.1.5.5.5.5.1.4.1.page.net > > 2. Put the "text of the page" in the body of the message > > 3. Send it as a regular e-mail message and let the DNS route it using MXs. I'm not up on pager protocol, but having one myself from a small local company -- how does one know for a given person/pager WHICH company handles the paging for them? We might have 50 people in the company with pagers, and every one might be subscribing through different companies. Is it even likely that these companies will consider connecting to the Internet? SNPP proposes TCP-connecting to a paging service server somewhere -- how does one know WHICH service handles the pager# you're trying to page? Perhaps the domain addressing proposed above would better handle that problem, letting DNS point you to the server responsible for a given number. -Chris Bartram   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07108; 2 Sep 93 11:00 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07104; 2 Sep 93 11:00 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa17223; 2 Sep 93 11:00 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03323; Thu, 2 Sep 93 10:39:58 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03318; Thu, 2 Sep 93 10:39:56 EDT Received: from guppylake.noname (guppylake.bellcore.com) by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Thu, 2 Sep 93 10:39:43 EDT Received: by guppylake.noname (4.1/SMI-4.1) id AA22626; Thu, 2 Sep 93 10:03:13 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.guppylake.noname.sun4.41 via MS.5.6.guppylake.noname.sun4_41; Thu, 2 Sep 1993 10:03:12 -0400 (EDT) Message-Id: Date: Thu, 2 Sep 1993 10:03:12 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ietf-822@dimacs.rutgers.edu, Rick Troth , John Gardiner Myers Subject: Re: text/enriched: Throwing in the towel In-Reply-To: References: <9309012300.AA25917@dimacs.rutgers.edu> <4gVLUf_00WBw4WZH4q@andrew.cmu.edu> Oops, I should have changed the date on the document, too. Sorry....   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07930; 2 Sep 93 11:49 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07925; 2 Sep 93 11:49 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa19317; 2 Sep 93 11:49 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03361; Thu, 2 Sep 93 10:41:50 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03356; Thu, 2 Sep 93 10:41:45 EDT Received: from guppylake.noname (guppylake.bellcore.com) by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Thu, 2 Sep 93 10:40:13 EDT Received: by guppylake.noname (4.1/SMI-4.1) id AA22455; Thu, 2 Sep 93 09:58:46 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.guppylake.noname.sun4.41 via MS.5.6.guppylake.noname.sun4_41; Thu, 2 Sep 1993 09:58:44 -0400 (EDT) Message-Id: Date: Thu, 2 Sep 1993 09:58:44 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Nathaniel Borenstein X-Andrew-Message-Size: 980+2 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="Interpart.Boundary.YgVTkGa0M2UDIcojtR" To: ietf-822@dimacs.rutgers.edu, Rick Troth , John Gardiner Myers Subject: text/enriched: Throwing in the towel In-Reply-To: <4gVLUf_00WBw4WZH4q@andrew.cmu.edu> References: <9309012300.AA25917@dimacs.rutgers.edu> <4gVLUf_00WBw4WZH4q@andrew.cmu.edu> > THIS IS A MESSAGE IN 'MIME' FORMAT. Your mail reader does not support MIME. > Please read the first section, which is plain text, and ignore the rest. --Interpart.Boundary.YgVTkGa0M2UDIcojtR Content-type: text/plain; charset=US-ASCII First of all, I think John is right about "<<" -- it is a special case, but so was "", and it is more readable. I think we can keep that change. Now, I want to throw in the towel. To recap: 1. Text/richtext was supposed to be a lowest common denominator enriched text format. An explicit design goal was to sacrifice functionality in favor of consensus. 2. Text/enriched was supposed to clean up some of the problems with text/richtext, including the name, not to abandon the goals mentioned in point 1. 3. There is obviously NOT a consensus for including . Therefore, independent of its merits (i.e. I still like it!) I have come to the conclusion that we should get rid of it, in order to put this argument behind us. I think that a less ambitious "nofill" environment should suffice for most purposes. What follows are the text and postscript versons of a revised text/enriched draft that nukes verbatim in favor of nofill. Please comment. -- NB [An Andrew ToolKit view (mailobjv) was included here, but could not be displayed.][An Andrew ToolKit view (mailobjv) was included here, but could not be displayed.] --Interpart.Boundary.YgVTkGa0M2UDIcojtR Content-Type: multipart/mixed; boundary="Alternative.Boundary.YgVTkGa0M2UDAcojop" --Alternative.Boundary.YgVTkGa0M2UDAcojop Content-type: text/richtext; charset=US-ASCII Content-Transfer-Encoding: quoted-printable First of all, I think John is right about "" -- it is a special case, = but so was "lt>", and it is more readable. I think we can keep that chang= e. Now, I want to throw in the towel. To recap: 1. Text/richtext was supposed to be a lowest common denominator enriched text= format. An explicit design goal was to sacrifice functionality in favor of c= onsensus. 2. Text/enriched was supposed to clean up some of the problems with text/rich= text, including the name, not to abandon the goals mentioned in point 1. 3. There is obviously NOT a consensus for including verbatim>. Therefor= e, independent of its merits (i.e. I still like it!) I have come to the conclu= sion that we should get rid of it, in order to put this argument behind us. I= think that a less ambitious "nofill" environment should suffice for most purp= oses. What follows are the text and postscript versons of a revised text/enriched dr= aft that nukes verbatim in favor of nofill. Please comment. -- NB --Alternative.Boundary.YgVTkGa0M2UDAcojop Content-type: application/postscript Content-Description: The PostScript version of the text/enriched draft Content-Transfer-Encoding: quoted-printable %!PS-Adobe-1.0 %%Creator: guppylake:nsb (Nathaniel Borenstein) %%Title: stdin (ditroff) %%CreationDate: Thu Sep 2 09:56:38 1993 %%EndComments % lib/psdit.pro -- prolog for psdit (ditroff) files % Copyright (c) 1984, 1985 Adobe Systems Incorporated. All Rights Reserve= d. % last edit: shore Sat Nov 23 20:28:03 1985 % RCSID: %Header: psdit.pro,v 2.1 85/11/24 12:19:43 shore Rel % % Psfig RCSID $Header: psdit.pro,v 1.5 88/01/04 17:48:22 trevor Exp $ /$DITroff 180 dict def $DITroff begin /DocumentInitState [ matrix currentmatrix currentlinewidth currentlinecap= currentlinejoin currentdash currentgray currentmiterlimit ] cvx def %% Psfig additions /startFig { /SavedState save def userdict maxlength dict begin currentpoint transform DocumentInitState setmiterlimit setgray setdash setlinejoin setlinecap setlinewidth setmatrix itransform moveto /ury exch def /urx exch def /lly exch def /llx exch def /y exch 72 mul resolution div def /x exch 72 mul resolution div def = currentpoint /cy exch def /cx exch def /sx x urx llx sub div def % scaling for x /sy y ury lly sub div def % scaling for y sx sy scale % scale by (sx,sy) cx sx div llx sub cy sy div ury sub translate = /DefFigCTM matrix currentmatrix def /initmatrix { DefFigCTM setmatrix } def /defaultmatrix { DefFigCTM exch copy } def /initgraphics { DocumentInitState setmiterlimit setgray setdash = setlinejoin setlinecap setlinewidth setmatrix DefFigCTM setmatrix } def /showpage { initgraphics } def } def % Args are llx lly urx ury (in figure coordinates) /clipFig { currentpoint 6 2 roll newpath 4 copy 4 2 roll moveto 6 -1 roll exch lineto exch lineto exch lineto closepath clip newpath moveto } def % doclip, if called, will always be just after a `startfig' /doclip { llx lly urx ury clipFig } def /endFig { end SavedState restore } def /globalstart { % Push details about the enviornment on the stack. fontnum fontsize fontslant fontheight = % firstpage = mh my resolution slotno currentpoint = pagesave restore gsave = } def /globalend { grestore moveto /slotno exch def /resolution exch def /my exch def /mh exch def = % /firstpage exch def /fontheight exch def /fontslant exch def /fontsize exch def /fontnum exch def F /pagesave save def } def %% end XMOD additions /fontnum 1 def /fontsize 10 def /fontheight 10 def /fontslant 0 def /xi {0 72 11 mul translate 72 resolution div dup neg scale 0 0 moveto /fontnum 1 def /fontsize 10 def /fontheight 10 def /fontslant 0 def F /pagesave save def}def /PB{save /psv exch def currentpoint translate = resolution 72 div dup neg scale 0 0 moveto}def /PE{psv restore}def /arctoobig 90 def /arctoosmall .05 def /m1 matrix def /m2 matrix def /m3 matrix def /oldmat matrix def /tan{dup sin exch cos div}def /point{resolution 72 div mul}def /dround {transform round exch round exch itransform}def /xT{/devname exch def}def /xr{/mh exch def /my exch def /resolution exch def}def /xp{}def /xs{docsave restore end}def /xt{}def /xf{/fontname exch def /slotno exch def fontnames slotno get fontname eq = not {fonts slotno fontname findfont put fontnames slotno fontname put}if}def= /xH{/fontheight exch def F}def /xS{/fontslant exch def F}def /s{/fontsize exch def /fontheight fontsize def F}def /f{/fontnum exch def F}def /F{fontheight 0 le {/fontheight fontsize def}if fonts fontnum get fontsize point 0 0 fontheight point neg 0 0 m1 astor= e fontslant 0 ne{1 0 fontslant tan 1 0 0 m2 astore m3 concatmatrix}if makefont setfont .04 fontsize point mul 0 dround pop setlinewidth}def /X{exch currentpoint exch pop moveto show}def /N{3 1 roll moveto show}def /Y{exch currentpoint pop exch moveto show}def /S{show}def /ditpush{}def/ditpop{}def /AX{3 -1 roll currentpoint exch pop moveto 0 exch ashow}def /AN{4 2 roll moveto 0 exch ashow}def /AY{3 -1 roll currentpoint pop exch moveto 0 exch ashow}def /AS{0 exch ashow}def /MX{currentpoint exch pop moveto}def /MY{currentpoint pop exch moveto}def /MXY{moveto}def /cb{pop}def % action on unknown char -- nothing for now /n{}def/w{}def /p{pop showpage pagesave restore /pagesave save def}def /abspoint{currentpoint exch pop add exch currentpoint pop add exch}def /distance{dup mul exch dup mul add sqrt}def /dstroke{currentpoint stroke moveto}def /Dl{2 copy gsave rlineto stroke grestore rmoveto}def /arcellipse{/diamv exch def /diamh exch def oldmat currentmatrix pop currentpoint translate 1 diamv diamh div scale /rad diamh 2 div def currentpoint exch rad add exch rad -180 180 arc oldmat setmatrix}def /Dc{dup arcellipse dstroke}def /De{arcellipse dstroke}def /Da{/endv exch def /endh exch def /centerv exch def /centerh exch def /cradius centerv centerv mul centerh centerh mul add sqrt def /eradius endv endv mul endh endh mul add sqrt def /endang endv endh atan def /startang centerv neg centerh neg atan def /sweep startang endang sub dup 0 lt{360 add}if def sweep arctoobig gt {/midang startang sweep 2 div sub def /midrad cradius eradius add 2 div = def /midh midang cos midrad mul def /midv midang sin midrad mul def midh neg midv neg endh endv centerh centerv midh midv Da currentpoint moveto Da} {sweep arctoosmall ge {/controldelt 1 sweep 2 div cos sub 3 sweep 2 div sin mul div 4 mul def= centerv neg controldelt mul centerh controldelt mul endv neg controldelt mul centerh add endh add endh controldelt mul centerv add endv add centerh endh add centerv endv add rcurveto dstroke} {centerh endh add centerv endv add rlineto dstroke}ifelse}ifelse}def /Barray 200 array def % 200 values in a wiggle /D~{mark}def /D~~{counttomark Barray exch 0 exch getinterval astore /Bcontrol exch def= pop /Blen Bcontrol length def Blen 4 ge Blen 2 mod 0 eq and {Bcontrol 0 get Bcontrol 1 get abspoint /Ycont exch def /Xcont exch def Bcontrol 0 2 copy get 2 mul put Bcontrol 1 2 copy get 2 mul put Bcontrol Blen 2 sub 2 copy get 2 mul put Bcontrol Blen 1 sub 2 copy get 2 mul put /Ybi /Xbi currentpoint 3 1 roll def def 0 2 Blen 4 sub {/i exch def Bcontrol i get 3 div Bcontrol i 1 add get 3 div Bcontrol i get 3 mul Bcontrol i 2 add get add 6 div Bcontrol i 1 add get 3 mul Bcontrol i 3 add get add 6 div /Xbi Xcont Bcontrol i 2 add get 2 div add def /Ybi Ycont Bcontrol i 3 add get 2 div add def /Xcont Xcont Bcontrol i 2 add get add def /Ycont Ycont Bcontrol i 3 add get add def Xbi currentpoint pop sub Ybi currentpoint exch pop sub rcurveto }for dstroke}if}def end /ditstart{$DITroff begin /nfonts 60 def % NFONTS makedev/ditroff dependent! /fonts[nfonts{0}repeat]def /fontnames[nfonts{()}repeat]def /docsave save def }def % character outcalls /oc {/pswid exch def /cc exch def /name exch def /ditwid pswid fontsize mul resolution mul 72000 div def /ditsiz fontsize resolution mul 72 div def ocprocs name known{ocprocs name get exec}{name cb} ifelse}def /fractm [.65 0 0 .6 0 0] def /fraction {/fden exch def /fnum exch def gsave /cf currentfont def cf fractm makefont setfont 0 .3 dm 2 copy neg rmoveto fnum show rmoveto currentfont cf setfont(\244)show setfont fden show = grestore ditwid 0 rmoveto} def /oce {grestore ditwid 0 rmoveto}def /dm {ditsiz mul}def /ocprocs 50 dict def ocprocs begin (14){(1)(4)fraction}def (12){(1)(2)fraction}def (34){(3)(4)fraction}def (13){(1)(3)fraction}def (23){(2)(3)fraction}def (18){(1)(8)fraction}def (38){(3)(8)fraction}def (58){(5)(8)fraction}def (78){(7)(8)fraction}def (sr){gsave 0 .06 dm rmoveto(\326)show oce}def (is){gsave 0 .15 dm rmoveto(\362)show oce}def (->){gsave 0 .02 dm rmoveto(\256)show oce}def (<-){gsave 0 .02 dm rmoveto(\254)show oce}def (=3D=3D){gsave 0 .05 dm rmoveto(\272)show oce}def end % an attempt at a PostScript FONT to implement ditroff special chars % this will enable us to = % cache the little buggers % generate faster, more compact PS out of psdit % confuse everyone (including myself)! 50 dict dup begin /FontType 3 def /FontName /DIThacks def /FontMatrix [.001 0 0 .001 0 0] def /FontBBox [-260 -260 900 900] def% a lie but ... /Encoding 256 array def 0 1 255{Encoding exch /.notdef put}for Encoding dup 8#040/space put %space dup 8#110/rc put %right ceil dup 8#111/lt put %left top curl dup 8#112/bv put %bold vert dup 8#113/lk put %left mid curl dup 8#114/lb put %left bot curl dup 8#115/rt put %right top curl dup 8#116/rk put %right mid curl dup 8#117/rb put %right bot curl dup 8#120/rf put %right floor dup 8#121/lf put %left floor dup 8#122/lc put %left ceil dup 8#140/sq put %square dup 8#141/bx put %box dup 8#142/ci put %circle dup 8#143/br put %box rule dup 8#144/rn put %root extender dup 8#145/vr put %vertical rule dup 8#146/ob put %outline bullet dup 8#147/bu put %bullet dup 8#150/ru put %rule dup 8#151/ul put %underline pop /DITfd 100 dict def /BuildChar{0 begin /cc exch def /fd exch def /charname fd /Encoding get cc get def /charwid fd /Metrics get charname get def /charproc fd /CharProcs get charname get def charwid 0 fd /FontBBox get aload pop setcachedevice 2 setlinejoin 40 setlinewidth newpath 0 0 moveto gsave charproc grestore end}def /BuildChar load 0 DITfd put %/UniqueID 5 def /CharProcs 50 dict def CharProcs begin /space{}def /.notdef{}def /ru{500 0 rls}def /rn{0 840 moveto 500 0 rls}def /vr{0 800 moveto 0 -770 rls}def /bv{0 800 moveto 0 -1000 rls}def /br{0 750 moveto 0 -1000 rls}def /ul{0 -140 moveto 500 0 rls}def /ob{200 250 rmoveto currentpoint newpath 200 0 360 arc closepath stroke}d= ef /bu{200 250 rmoveto currentpoint newpath 200 0 360 arc closepath fill}def= /sq{80 0 rmoveto currentpoint dround newpath moveto 640 0 rlineto 0 640 rlineto -640 0 rlineto closepath stroke}def /bx{80 0 rmoveto currentpoint dround newpath moveto 640 0 rlineto 0 640 rlineto -640 0 rlineto closepath fill}def /ci{500 360 rmoveto currentpoint newpath 333 0 360 arc 50 setlinewidth stroke}def /lt{0 -200 moveto 0 550 rlineto currx 800 2cx s4 add exch s4 a4p stroke}d= ef /lb{0 800 moveto 0 -550 rlineto currx -200 2cx s4 add exch s4 a4p stroke}= def /rt{0 -200 moveto 0 550 rlineto currx 800 2cx s4 sub exch s4 a4p stroke}d= ef /rb{0 800 moveto 0 -500 rlineto currx -200 2cx s4 sub exch s4 a4p stroke}= def /lk{0 800 moveto 0 300 -300 300 s4 arcto pop pop 1000 sub 0 300 4 2 roll s4 a4p 0 -200 lineto stroke}def /rk{0 800 moveto 0 300 s2 300 s4 arcto pop pop 1000 sub 0 300 4 2 roll s4 a4p 0 -200 lineto stroke}def /lf{0 800 moveto 0 -1000 rlineto s4 0 rls}def /rf{0 800 moveto 0 -1000 rlineto s4 neg 0 rls}def /lc{0 -200 moveto 0 1000 rlineto s4 0 rls}def /rc{0 -200 moveto 0 1000 rlineto s4 neg 0 rls}def end /Metrics 50 dict def Metrics begin /.notdef 0 def /space 500 def /ru 500 def /br 0 def /lt 416 def /lb 416 def /rt 416 def /rb 416 def /lk 416 def /rk 416 def /rc 416 def /lc 416 def /rf 416 def /lf 416 def /bv 416 def /ob 350 def /bu 350 def /ci 750 def /bx 750 def /sq 750 def /rn 500 def /ul 500 def /vr 0 def end DITfd begin /s2 500 def /s4 250 def /s3 333 def /a4p{arcto pop pop pop pop}def /2cx{2 copy exch}def /rls{rlineto stroke}def /currx{currentpoint pop}def /dround{transform round exch round exch itransform} def end end /DIThacks exch definefont pop ditstart (psc)xT 576 1 1 xr 1(Times-Roman)xf 1 f 2(Times-Italic)xf 2 f 3(Times-Bold)xf 3 f 4(Times-BoldItalic)xf 4 f 5(Helvetica)xf 5 f 6(Helvetica-Bold)xf 6 f 7(Courier)xf 7 f 8(Courier-Bold)xf 8 f 9(Symbol)xf 9 f 10(DIThacks)xf 10 f 10 s 1 f xi %%EndProlog %%Page: 1 1 10 s 10 xH 0 xS 1 f 7 f 12 s 720 688(Network)N 1184(Working)X 1648(Group)X 2808(N.)X 2982 0.4125(Borenstein,)AX 3678(Bellcore)X 720 800(Request)N 1184(for)X 1416 0.4219(Comments:)AX 1996(XXXX)X 3330(April)X 3678(26,)X 3910(1993)X 1 f 18 s 1334 1136(The)N 1594(text/enriched)X 2382(M)X (IM)S 2686(E)X 2810(Content-type)X 3 f 16 s 720 1472(Status)N 1094(of)X 1233(this)X 1465(M)X 1586(em)X 1750(o)X 1 f 12 s 720 1760(This)N 926(RFC)X 1142(speci\256es)X 1508(an)X 1634(informational)X 2194(protocol)X 2550(for)X 2697(the)X 2851(Internet)X 3187(community,)X 3686(and)X 3861(requests)X 720 1872(discussion)N 1144(and)X 1307(suggestions)X 1779(for)X 1915(improvements.)X 2538(Distribution)X 3027(of)X 3131(this)X 3294(memo)X 3559(is)X 3647(unlimited.)X 3 f 16 s 720 2096(Abstract)N 1 f 12 s 720 2384(MIME)N 1039([RFC-1341,)X 1558(RFC-MIME])X 2122(de\256nes)X 2452(a)X 2553(format)X 2868(and)X 3065(general)X 3407(framework)X 3887(for)X 4058(the)X 720 2496(representation)N 1303(of)X 1420(a)X 1499(wide)X 1722(variety)X 2026(of)X 2142(data)X 2339(types)X 2578(in)X 2689(Internet)X 3025(mail.)X 3281(This)X 3488(document)X 3904(de\256nes)X 720 2608(one)N 924(particular)X 1359(type)X 1591(of)X 1737(MIME)X 2064(data,)X 2315(the)X 2499(text/enriched)X 3069(type,)X 3325(a)X 3434(re\256nement)X 3912(of)X 4058(the)X 720 2720("text/richtext")N 1300(type)X 1501(de\256ned)X 1819(in)X 1929(RFC)X 2145(1341.)X 2420(The)X 2604(text/enriched)X 3142(MIME)X 3437(type)X 3637(is)X 3735(intended)X 4101(to)X 720 2832 0.3472(facilitate)AN 1109(the)X 1277(wider)X 1546(interoperation)X 2137(of)X 2267(simple)X 2575(enriched)X 2958(text)X 3154(across)X 3445(a)X 3539(wide)X 3777(variety)X 4096(of)X 720 2944(hardware)N 1102(and)X 1265(software)X 1620(platforms.)X 3 f 16 s 720 3168(The)N 965(Text/enriched)X 1759(M)X 1880(IM)X 2051(E)X 2168(type)X 1 f 12 s 720 3456(In)N 837(order)X 1077(to)X 1189(promote)X 1547(the)X 1702(wider)X 1958 0.2083(interoperability)AX 2590(of)X 2707(simple)X 3001(formatted)X 3413(text,)X 3619(this)X 3796(document)X 720 3568(de\256nes)N 1077(an)X 1253(extremely)X 1724(simple)X 2066(subtype)X 2450(of)X 2614(the)X 2816(MIME)X 3161(content-type)X 3727("text",)X 4058(the)X 720 3680("text/enriched")N 1326(subtype.)X 1697(This)X 1892(subtype)X 2215(was)X 2388(designed)X 2754(to)X 2853(meet)X 3065(the)X 3207(following)X 3605(criteria:)X 1008 3904(1.)N 1138(The)X 1322(syntax)X 1607(must)X 1828(be)X 1953(extremely)X 2373(simple)X 2664(to)X 2773(parse,)X 3034(so)X 3153(that)X 3333(even)X 3550(teletype-)X 1008 4016(oriented)N 1366(mail)X 1580(systems)X 1926(can)X 2102(easily)X 2369(strip)X 2582(away)X 2826(the)X 2985(formatting)X 3433(information)X 1008 4128(and)N 1171(leave)X 1399(only)X 1594(the)X 1736(readable)X 2087(text.)X 1008 4352(2.)N 1133(The)X 1313(syntax)X 1594(must)X 1811(be)X 1932(extensible)X 2353(to)X 2458(allow)X 2702(for)X 2844(new)X 3034(formatting)X 3471(commands)X 1008 4464(that)N 1177(are)X 1319(deemed)X 1643(essential)X 1999(for)X 2135(some)X 2362(application.)X 1008 4688(3.)N 1130(If)X 1220(the)X 1364(character)X 1744(set)X 1877(in)X 1978(use)X 2132(is)X 2223(ASCII)X 2500(or)X 2607(an)X 2725(8-bit)X 2934(ASCII)X 3211(superset,)X 3577(then)X 3770(the)X 1008 4800(raw)N 1231(form)X 1497(of)X 1656(the)X 1853(data)X 2093(must)X 2359(be)X 2529(readable)X 2935(enough)X 3297(to)X 3451(be)X 3620(largely)X 1008 4912(unobjectionable)N 1655(in)X 1761(the)X 1910(event)X 2150(that)X 2327(it)X 2413(is)X 2509(displayed)X 2910(on)X 3038(the)X 3188(screen)X 3466(of)X 3578(the)X 3728(user)X 1008 5024(of)N 1112(a)X 1179(non-MIME-conformant)X 2116(mail)X 2312(reader.)X 1008 5248(4.)N 1156(The)X 1358(capabilities)X 1850(must)X 2089(be)X 2232(extremely)X 2670(limited,)X 3020(to)X 3147(ensure)X 3450(that)X 3647(it)X 3754(can)X 1008 5360(represent)N 1391(no)X 1517(more)X 1745(than)X 1941(is)X 2035(likely)X 2285(to)X 2390(be)X 2510(representable)X 3053(by)X 3178(the)X 3325(user's)X 3583(primary)X 1008 5472(word)N 1255(processor.)X 1721(While)X 2007(this)X 2196(limits)X 2466(what)X 2704(can)X 2889(be)X 3031(sent,)X 3261(it)X 3366(increases)X 3770(the)X 1008 5584(likelihood)N 1423(that)X 1592(what)X 1803(is)X 1891(sent)X 2070(can)X 2228(be)X 2343(properly)X 2693(displayed.)X 720 6160(Borenstein)N 1161(-)X 1217(text/enriched)X 2071(Expires)X 2389(September)X 2825(1,)X 2921(1993)X 3917(Page)X 4128(1)X 2 p %%Page: 2 2 12 s 12 xH 0 xS 1 f 720 400(Borenstein)N 1844(A)X 1937(text/enriched)X 2465(type)X 2655(for)X 2791(MIME)X 3621(April)X 3848(1993)X 4064([2])X 720 688(This)N 916(document)X 1321(de\256nes)X 1618(a)X 1686(new)X 1872(MIME)X 2159(content-type,)X 2691("text/enriched".)X 3347(The)X 3523(content-type)X 4031(line)X 720 800(for)N 868(this)X 1043(type)X 1245(may)X 1447(have)X 1665(one)X 1839(optional)X 2190(parameter,)X 2635(the)X 2788("charset")X 3174(parameter,)X 3619(with)X 3825(the)X 3978(same)X 720 912(values)N 990(permitted)X 1384(for)X 1520(the)X 1662("text/plain")X 2129(MIME)X 2414(content-type.)X 720 1136(The)N 895(syntax)X 1171(of)X 1276("text/enriched")X 1883(is)X 1973(very)X 2170(simple.)X 2501(It)X 2586(represents)X 3002(text)X 3173(in)X 3274(a)X 3343(single)X 3599(character)X 3979(set)X 4112(--)X 720 1248(US-ASCII)N 1150(by)X 1272(default,)X 1590(although)X 1953(a)X 2022(different)X 2380(character)X 2760(set)X 2893(can)X 3053(be)X 3169(speci\256ed)X 3536(by)X 3657(the)X 3800(use)X 3953(of)X 4058(the)X 720 1360("charset")N 1111(parameter.)X 1585(\(The)X 1808(semantics)X 2229(of)X 2350(text/enriched)X 2895(in)X 3011(non-ASCII)X 3478(character)X 3873(sets)X 4058(are)X 720 1472(discussed)N 1152(later)X 1388(in)X 1527(this)X 1730(document.\))X 2253(All)X 2439(characters)X 2893(represent)X 3309(themselves,)X 3824(with)X 4058(the)X 720 1584(exception)N 1134(of)X 1253(the)X 1410("<")X 1581(character)X 1974(\(ASCII)X 2295(60\),)X 2486(which)X 2760(is)X 2863(used)X 3078(to)X 3192(mark)X 3430(the)X 3588(beginning)X 4013(of)X 4133(a)X 720 1696(formatting)N 1209(command.)X 1719(Formatting)X 2229(instructions)X 2760(consist)X 3109(of)X 3271(formatting)X 3759(commands)X 720 1808(surrounded)N 1181(by)X 1306(angle)X 1544(brackets)X 1894(\("<>",)X 2165(ASCII)X 2444(60)X 2569(and)X 2737(62\).)X 2942(Each)X 3164(formatting)X 3600(command)X 4010(may)X 720 1920(be)N 840(no)X 965(more)X 1192(than)X 1387(60)X 1512(characters)X 1932(in)X 2036(length,)X 2330(all)X 2456(in)X 2559(US-ASCII,)X 3015(restricted)X 3402(to)X 3505(the)X 3651(alphanumeric)X 720 2032(and)N 894(hyphen)X 1212(\("-"\))X 1421(characters.)X 1871(Formatting)X 2334(commands)X 2786(may)X 2987(be)X 3113(preceded)X 3496(by)X 3628(a)X 3707(solidus)X 4015(\("/",)X 720 2144(ASCII)N 999(47\),)X 1180(making)X 1498(them)X 1720(negations,)X 2142(and)X 2310(such)X 2515(negations)X 2912(must)X 3127(always)X 3422(exist)X 3632(to)X 3735(balance)X 4058(the)X 720 2256(initial)N 977(opening)X 1319(commands.)X 1816(Thus,)X 2064(if)X 2155(the)X 2305(formatting)X 2744(command)X 3156("")X 3545(appears)X 3871(at)X 3973(some)X 720 2368(point,)N 974(there)X 1199(must)X 1418(later)X 1622(be)X 1745(a)X 1820("")X 2236(to)X 2343(balance)X 2670(it.)X 2803(\(NOTE:)X 3173(The)X 3354(60)X 3481(character)X 3866(limit)X 4080(on)X 720 2480(formatting)N 1166(commands)X 1622(does)X 1837(NOT)X 2073(include)X 2396(the)X 2553("<",)X 2748(">",)X 2943(or)X 3062("/")X 3206(characters)X 3636(that)X 3820(might)X 4085(be)X 720 2592(attached)N 1066(to)X 1165(such)X 1365(commands.\))X 720 2816(Formatting)N 1198(commands)X 1665(are)X 1833(always)X 2150(case-insensitive.)X 2858(That)X 3085(is,)X 3223("bold")X 3522(and)X 3711("BoLd")X 4058(are)X 720 2928(equivalent)N 1146(in)X 1245(effect,)X 1513(if)X 1596(not)X 1743(in)X 1842(good)X 2058(taste.)X 720 3152(Beyond)N 1055(tokens)X 1342(delimited)X 1743(by)X 1875("<")X 2043(and)X 2218(">",)X 2411(there)X 2641(are)X 2796(two)X 2977(other)X 3212(special)X 3517(processing)X 3965(rules.)X 720 3264(First,)N 972(a)X 1067(literal)X 1345(less-than)X 1739(sign)X 1951(\("<"\))X 2199(can)X 2385(be)X 2528(represented)X 3024(by)X 3172(a)X 3267(sequence)X 3672(of)X 3804(two)X 4000(such)X 720 3376(characters,)N 1167("<<".)X 1457(Second,)X 1796(line)X 1974(breaks)X 2258(\(CRLF)X 2563(pairs)X 2783(in)X 2891(standard)X 3250(network)X 3598(representation\))X 720 3488(are)N 882(handled)X 1231(specially.)X 1666(In)X 1790(particular,)X 2228(isolated)X 2572(CRLF)X 2856(pairs)X 3087(are)X 3249(translated)X 3667(into)X 3860(a)X 3946(single)X 720 3600(SPACE)N 1045(character.)X 1474(Sequences)X 1907(of)X 2014(N)X 2110(consecutive)X 2592(CRLF)X 2859(pairs,)X 3097(however,)X 3479(are)X 3624(translated)X 4026(into)X 720 3712(N-1)N 906(actual)X 1174(line)X 1356(breaks.)X 1692(This)X 1900(permits)X 2226(long)X 2434(lines)X 2653(of)X 2770(data)X 2968(to)X 3079(be)X 3206(represented)X 3686(in)X 3797(a)X 3876(natural-)X 720 3824(looking)N 1068(manner)X 1411(despite)X 1738(the)X 1910(frequency)X 2349(of)X 2483(line-wrapping)X 3077(in)X 3206(Internet)X 3560(mailers.)X 3946(When)X 720 3936(preparing)N 1127(the)X 1283(data)X 1482(for)X 1632(mail)X 1842(transport,)X 2246(isolated)X 2584(line)X 2767(breaks)X 3055(should)X 3348(be)X 3476(inserted)X 3818(wherever)X 720 4048(necessary)N 1127(to)X 1235(keep)X 1450(each)X 1661(line)X 1840(shorter)X 2141(than)X 2341(80)X 2471(characters.)X 2992(When)X 3256(preparing)X 3659(such)X 3869(data)X 4064(for)X 720 4160(presentation)N 1235(to)X 1354(the)X 1516(user,)X 1744(isolated)X 2088(line)X 2277(breaks)X 2572(should)X 2872(be)X 3007(replaced)X 3378(by)X 3518(a)X 3605(single)X 3878(SPACE)X 720 4272(character,)N 1136(and)X 1314(N)X 1422(consecutive)X 1916(CRLF)X 2195(pairs)X 2421(should)X 2716(be)X 2846(presented)X 3254(to)X 3368(the)X 3525(user)X 3724(as)X 3843(N-1)X 4031(line)X 720 4384(breaks.)N 720 4608(Thus)N 936(text/enriched)X 1464(data)X 1649(that)X 1818(looks)X 2050(like)X 2219(this:)X 720 6160(Borenstein)N 1161(-)X 1217(text/enriched)X 2071(Expires)X 2389(September)X 2825(1,)X 2921(1993)X 3917(Page)X 4128(2)X 3 p %%Page: 3 3 12 s 12 xH 0 xS 1 f 720 400(Borenstein)N 1844(A)X 1937(text/enriched)X 2465(type)X 2655(for)X 2791(MIME)X 3621(April)X 3848(1993)X 4064([3])X 7 f 1008 688(This)N 1298(is)X 1008 800(a)N 1124(single)X 1008 912(line)N 1008 1136(This)N 1298(is)X 1472(the)X 1008 1248(next)N 1298(line.)X 1008 1584(This)N 1298(is)X 1472(the)X 1008 1696(next)N 1298 0.4167(paragraph.)AX 1 f 720 1920(should)N 1000(be)X 1115(displayed)X 1508(by)X 1628(a)X 1695(text/enriched)X 2223(interpreter)X 2649(as)X 2753(follows:)X 7 f 1008 2144(This)N 1298(is)X 1472(a)X 1588(single)X 1994(line)X 1008 2256(This)N 1298(is)X 1472(the)X 1704(next)X 1994(line.)X 1008 2480(This)N 1298(is)X 1472(the)X 1704(next)X 1994 0.4167(paragraph.)AX 1 f 720 2704(The)N 896(formatting)X 1329(commands,)X 1796(not)X 1945(all)X 2068(of)X 2174(which)X 2436(will)X 2613(be)X 2731(implemented)X 3262(by)X 3385(all)X 3509(implementations,)X 720 2816(are)N 862(described)X 1255(in)X 1354(the)X 1496(following)X 1894(sections.)X 3 f 16 s 720 3040(Form)N 1026(atting)X 1379(Com)X 1642(m)X 1749(ands)X 1 f 12 s 720 3328(The)N 905(text/enriched)X 1444(formatting)X 1886(commands)X 2338(all)X 2470(begin)X 2719(with)X 2925()X 3657(and)X 3831(end)X 4005(with)X 720 3440(,)N 1503(affecting)X 1881(the)X 2034(formatting)X 2476(of)X 2591(the)X 2744(text)X 2923(between)X 3278(those)X 3515(two)X 3693(tokens.)X 4026(The)X 720 3552(commands)N 1161(are)X 1303(described)X 1696(here,)X 1910(grouped)X 2249(according)X 2653(to)X 2752(type.)X 3 f 14 s 720 3776(Font-Alteration)N 1503(Commands)X 1 f 12 s 720 4032(The)N 917(following)X 1338(formatting)X 1792(commands)X 2256(are)X 2421(intended)X 2801(to)X 2924(alter)X 3144(the)X 3310(font)X 3513(in)X 3636(which)X 3919(text)X 4112(is)X 720 4144(displayed,)N 1137(but)X 1284(not)X 1431(to)X 1530(alter)X 1726(the)X 1868(indentation)X 2326(or)X 2430(justi\256cation)X 2909(state)X 3110(of)X 3214(the)X 3356(text:)X 3 f 1008 4368(Bold)N 1 f 1226(--)X 1316(causes)X 1593(the)X 1737(affected)X 2074(text)X 2245(to)X 2346(be)X 2463(in)X 2564(a)X 2633(bold)X 2830(font.)X 3059(Nested)X 3352(bold)X 3550(commands)X 3994(have)X 1296 4480(the)N 1438(same)X 1660(effect)X 1904(as)X 2008(a)X 2075(single)X 2329(bold)X 2524(command.)X 3 f 1008 4592(Italic)N 1 f 1254(--)X 1350(causes)X 1633(the)X 1783(affected)X 2127(text)X 2305(to)X 2413(be)X 2537(in)X 2645(an)X 2769(italic)X 2996(font.)X 3232(Nested)X 3532(italic)X 3759(commands)X 1296 4704(have)N 1502(the)X 1644(same)X 1866(effect)X 2110(as)X 2214(a)X 2281(single)X 2535(italic)X 2753(command.)X 3 f 1008 4816(Fixed)N 1 f 1287(--)X 1400(causes)X 1700(the)X 1867(affected)X 2227(text)X 2421(to)X 2545(be)X 2685(in)X 2810(a)X 2903(\256xed)X 3145(width)X 3414(font.)X 3667(Nested)X 3984(\256xed)X 1296 4928(commands)N 1737(have)X 1943(the)X 2085(same)X 2307(effect)X 2551(as)X 2655(a)X 2722(single)X 2976(\256xed)X 3192(command.)X 3 f 1008 5040(Smaller)N 1 f 1353(--)X 1441(causes)X 1717(the)X 1860(affected)X 2196(text)X 2366(to)X 2466(be)X 2582(in)X 2682(a)X 2750(smaller)X 3059(font.)X 3287(It)X 3371(is)X 3460(recommended)X 4031(that)X 1296 5152(the)N 1449(font)X 1639(size)X 1823(be)X 1948(changed)X 2303(by)X 2433(two)X 2611(points,)X 2904(but)X 3061(other)X 3293(amounts)X 3653(may)X 3853(be)X 3978(more)X 1296 5264(appropriate)N 1779(in)X 1898(some)X 2146(environments.)X 2763(Nested)X 3075(smaller)X 3404(commands)X 3866(produce)X 1296 5376(ever-smaller)N 1834(fonts,)X 2106(to)X 2237(the)X 2411(limits)X 2686(of)X 2821(the)X 2994(implementation's)X 3724(capacity)X 4101(to)X 1296 5488(reasonably)N 1748(display)X 2061(them,)X 2313(after)X 2525(which)X 2795(further)X 3092(smaller)X 3411(commands)X 3863(have)X 4080(no)X 1296 5600(incremental)N 1776(effect.)X 720 6160(Borenstein)N 1161(-)X 1217(text/enriched)X 2071(Expires)X 2389(September)X 2825(1,)X 2921(1993)X 3917(Page)X 4128(3)X 4 p %%Page: 4 4 12 s 12 xH 0 xS 1 f 3 f 1 f 720 400(Borenstein)N 1844(A)X 1937(text/enriched)X 2465(type)X 2655(for)X 2791(MIME)X 3621(April)X 3848(1993)X 4064([4])X 3 f 1008 688(Bigger)N 1 f 1311(--)X 1405(causes)X 1686(the)X 1834(affected)X 2175(text)X 2350(to)X 2456(be)X 2578(in)X 2684(a)X 2758(bigger)X 3035(font.)X 3269(It)X 3359(is)X 3454(recommended)X 4031(that)X 1296 800(the)N 1449(font)X 1639(size)X 1823(be)X 1948(changed)X 2303(by)X 2433(two)X 2611(points,)X 2904(but)X 3061(other)X 3293(amounts)X 3653(may)X 3853(be)X 3978(more)X 1296 912(appropriate)N 1785(in)X 1910(some)X 2163(environments.)X 2785(Nested)X 3102(bigger)X 3398(commands)X 3866(produce)X 1296 1024(ever-bigger)N 1800(fonts,)X 2076(to)X 2211(the)X 2389(limits)X 2669(of)X 2809(the)X 2986(implementation's)X 3720(capacity)X 4101(to)X 1296 1136(reasonably)N 1752(display)X 2069(them,)X 2325(after)X 2541(which)X 2815(further)X 3116(bigger)X 3401(commands)X 3858(have)X 4080(no)X 1296 1248(incremental)N 1776(effect.)X 3 f 1008 1360(Underline)N 1 f 1480(--)X 1605(causes)X 1917(the)X 2096(affected)X 2468(text)X 2674(to)X 2810(be)X 2962(underlined.)X 3483(Nested)X 3812(underline)X 1296 1472(commands)N 1737(have)X 1943(the)X 2085(same)X 2307(effect)X 2551(as)X 2655(a)X 2722(single)X 2976(underline)X 3364(command.)X 720 1696(While)N 1029(the)X 1220("bigger")X 1617(and)X 1829("smaller")X 2264(operators)X 2695(are)X 2887(effectively)X 3374(inverses,)X 3787(it)X 3915(is)X 4053(not)X 720 1808(recommended,)N 1326(for)X 1474(example,)X 1861(that)X 2042("")X 2548(be)X 2675(used)X 2911(to)X 3022(end)X 3197(the)X 3350(effect)X 3605(of)X 3720("".)X 720 1920(This)N 915(is)X 1003(properly)X 1353(done)X 1564(with)X 1759("".)X 3 f 14 s 720 2144(Justi\256cation)N 1334(Commands)X 1 f 12 s 720 2400(Initially,)N 1075(text/enriched)X 1604(text)X 1774(is)X 1863(intended)X 2220(to)X 2321(be)X 2438(displayed)X 2833(fully-justi\256ed)X 3383(with)X 3580(appropriate)X 4045(\256ll,)X 720 2512(kerning,)N 1068(and)X 1237 0.2321(letter-tracking)AX 1814(as)X 1924(suits)X 2130(the)X 2278(capabilities)X 2748(of)X 2858(the)X 3006(receiving)X 3394(user)X 3583(agent)X 3821(software.)X 720 2624(Actual)N 1007(line)X 1182(width)X 1431(is)X 1525(left)X 1684(to)X 1789(the)X 1937(discretion)X 2347(of)X 2457(the)X 2605(receiver,)X 2970(which)X 3235(is)X 3329(expected)X 3702(to)X 3808(fold)X 3994(lines)X 720 2736(intelligently)N 1211(\(preferring)X 1652(soft)X 1820(line)X 1989(breaks\))X 2296(to)X 2395(the)X 2537(best)X 2716(of)X 2820(its)X 2935(ability.)X 720 2960(The)N 907(following)X 1318(commands)X 1772(alter)X 1981(that)X 2163(state.)X 2425(Each)X 2655(of)X 2772(these)X 3007(commands)X 3462(force)X 3698(a)X 3779(line)X 3962(break)X 720 3072(before)N 1009(and)X 1191(after)X 1411(the)X 1572(formatting)X 2022(command)X 2444(if)X 2545(there)X 2780(is)X 2886(not)X 3051(otherwise)X 3467(a)X 3552(line)X 3739(break.)X 4043(For)X 720 3184(example,)N 1095(if)X 1178(one)X 1341(of)X 1446(these)X 1669(commands)X 2111(occurs)X 2387(anywhere)X 2786(other)X 3009(than)X 3200(the)X 3343(beginning)X 3753(of)X 3858(a)X 3926(line)X 4096(of)X 720 3296(text)N 889(as)X 993(presented,)X 1410(a)X 1477(new)X 1661(line)X 1830(is)X 1918(begun.)X 3 f 1008 3520(Center)N 1 f 1315(--)X 1403(causes)X 1678(the)X 1820(affected)X 2155(text)X 2324(to)X 2423(be)X 2538(centered.)X 3 f 1008 3632(FlushLeft)N 1 f 1456(--)X 1568(causes)X 1867(the)X 2033(affected)X 2393(text)X 2587(to)X 2711(be)X 2851(left-justi\256ed)X 3371(with)X 3591(a)X 3683(ragged)X 3994(right)X 1296 3744(margin.)N 3 f 1008 3856(FlushRight)N 1 f 1509(--)X 1616(causes)X 1911(the)X 2073(affected)X 2428(text)X 2617(to)X 2736(be)X 2871(right-justi\256ed)X 3439(with)X 3654(a)X 3741(ragged)X 4047(left)X 1296 3968(margin.)N 720 4192(The)N 896(center,)X 1182(\257ushleft,)X 1547(and)X 1712(\257ushright)X 2107(commands)X 2551(are)X 2696(mutually)X 3066(exclusive,)X 3481(and,)X 3671(when)X 3906(nested,)X 720 4304(the)N 862(inner)X 1084(command)X 1488(takes)X 1710(precedence.)X 720 4528(Note)N 940(that)X 1118(for)X 1263(some)X 1499(non-ASCII)X 1958(character)X 2345(sets,)X 2546(full)X 2713(justi\256cation)X 3201(may)X 3400(be)X 3524(inappropriate.)X 4096(In)X 720 4640(these)N 942(cases,)X 1193(a)X 1260(user)X 1444(agent)X 1677(may)X 1867(choose)X 2158(not)X 2305(to)X 2404(justify)X 2674(such)X 2874(data.)X 3 f 14 s 720 4864(Indentation)N 1309(Commands)X 1 f 12 s 720 5120(Initially,)N 1094(text/enriched)X 1642(text)X 1831(is)X 1939(displayed)X 2352(using)X 2604(the)X 2767(maximum)X 3203(available)X 3597(margins.)X 4000(Two)X 720 5232(formatting)N 1151(commands)X 1592(may)X 1782(be)X 1897(used)X 2097(to)X 2196(affect)X 2440(the)X 2582(margins.)X 3 f 1008 5456(Indent)N 1 f 1337(--)X 1459(causes)X 1768(the)X 1944(running)X 2301(left)X 2489(margin)X 2821(to)X 2955(be)X 3105(moved)X 3426(to)X 3560(the)X 3737(right.)X 4026(The)X 1296 5568(recommended)N 1873(indentation)X 2338(change)X 2642(is)X 2737(the)X 2886(width)X 3136(of)X 3247(four)X 3438(characters,)X 3884(but)X 4037(this)X 1296 5680(may)N 1486(differ)X 1724(among)X 2010(implementations.)X 720 6160(Borenstein)N 1161(-)X 1217(text/enriched)X 2071(Expires)X 2389(September)X 2825(1,)X 2921(1993)X 3917(Page)X 4128(4)X 5 p %%Page: 5 5 12 s 12 xH 0 xS 1 f 3 f 1 f 720 400(Borenstein)N 1844(A)X 1937(text/enriched)X 2465(type)X 2655(for)X 2791(MIME)X 3621(April)X 3848(1993)X 4064([5])X 3 f 1008 688(IndentRight)N 1 f 1549(--)X 1654(causes)X 1946(the)X 2105(running)X 2445(right)X 2668(margin)X 2982(to)X 3098(be)X 3230(moved)X 3533(to)X 3649(the)X 3808(left.)X 4026(The)X 1296 800(recommended)N 1873(indentation)X 2338(change)X 2642(is)X 2737(the)X 2886(width)X 3136(of)X 3247(four)X 3438(characters,)X 3884(but)X 4037(this)X 1296 912(may)N 1486(differ)X 1724(among)X 2010(implementations.)X 720 1136(A)N 828(line)X 1012(break)X 1265(is)X 1369(NOT)X 1606(forced)X 1892(by)X 2028(a)X 2111(change)X 2424(of)X 2544(the)X 2702(margin,)X 3039(to)X 3154(permit)X 3470(the)X 3628(description)X 4096(of)X 720 1248("hanging")N 1132(text.)X 1349(Thus)X 1565(for)X 1701(example)X 2052(the)X 2194(following)X 2592(text:)X 7 f 720 1472(Now)N 954()X 1478(is)X 1655(the)X 1890(time)X 2183(for)X 2418(all)X 2653(good)X 2946(horses)X 3355(to)X 3532(come)X 3825(to)X 4002(the)X 720 1584(aid)N 963(of)X 1148(their)X 1506(stable,)X 1980(assuming)X 2512(that)X 2812 0.4219()AX 3402(any)X 3644(stable)X 4060(is)X 720 1696(really)N 1126(stable.)X 1 f 720 1920(would)N 984(be)X 1099(displayed)X 1492(in)X 1591(a)X 1658(40-character-wide)X 2383(window)X 2716(as)X 2820(follows:)X 7 f 720 2144(Now)N 952(is)X 1126(the)X 1358(time)X 1648(for)X 1880(all)X 2112(good)X 2402(horses)X 2808(to)X 952 2256(come)N 1242(to)X 1416(the)X 1648(aid)X 1880(of)X 2054(their)X 2402(stable,)X 952 2368(assuming)N 1474(that)X 1764(any)X 1996(stable)X 2402(is)X 720 2480(really)N 1126(stable.)X 3 f 14 s 720 2704(M)N 826(iscellaneous)X 1421(Commands)X 12 s 1008 2960(Excerpt)N 1 f 1373(--)X 1476(causes)X 1766(the)X 1923(affected)X 2273(text)X 2457(to)X 2571(be)X 2701(interpreted)X 3159(as)X 3279(a)X 3362(textual)X 3665(excerpt)X 3989(from)X 1296 3072(another)N 1626(source,)X 1942(probably)X 2325(a)X 2409(message)X 2775(being)X 3029(responded)X 3464(to.)X 3627(Typically)X 4037(this)X 1296 3184(will)N 1477(be)X 1599(displayed)X 1999(using)X 2238(indentation)X 2703(and)X 2873(an)X 2996(alternate)X 3361(font,)X 3572(or)X 3684(by)X 3812(indenting)X 1296 3296(lines)N 1524(and)X 1709(preceding)X 2135(them)X 2374(with)X 2591(">)X 2730(",)X 2839(but)X 3008(such)X 3230(decisions)X 3634(are)X 3797(up)X 3938(to)X 4058(the)X 1296 3408 0.2366(implementation.)AN 2002(\(Note)X 2273(that)X 2470(this)X 2661(is)X 2777(the)X 2947(only)X 3170(truly)X 3405(declarative)X 3882(markup)X 1296 3520(construct)N 1678(in)X 1782(text/enriched,)X 2339(and)X 2507(as)X 2616(such)X 2821(doesn't)X 3132(\256t)X 3240(very)X 3439(well)X 3633(with)X 3832(the)X 3978(other)X 1296 3632(facilities,)N 1680(but)X 1830(it)X 1912(describes)X 2298(a)X 2369(type)X 2563(of)X 2671(markup)X 2993(that)X 3166(is)X 3258(very)X 3457(commonly)X 3897(used)X 4101(in)X 1296 3744(email)N 1537(and)X 1702(has)X 1856(no)X 1978(procedural)X 2416(analogue.\))X 2894(Note)X 3107(that)X 3277(as)X 3382(with)X 3578(the)X 3721(justi\256cation)X 1296 3856(commands,)N 1772(the)X 1925(excerpt)X 2244(command)X 2659(implicitly)X 3071(begins)X 3358(and)X 3533(ends)X 3745(with)X 3952(a)X 4031(line)X 1296 3968(break)N 1534(if)X 1617(one)X 1780(is)X 1868(not)X 2015(already)X 2323(there.)X 3 f 1008 4080(No\256ll)N 1 f 1268(--)X 1368(causes)X 1655(the)X 1809(affected)X 2156(text)X 2337(to)X 2448(be)X 2576(displayed)X 2982(without)X 3313(\256lling)X 3580(or)X 3697(justi\256cation,)X 1296 4192(and)N 1464(hence)X 1718(without)X 2041(any)X 2209(special)X 2506(handling)X 2872(of)X 2981(CRLFs,)X 3310(but)X 3461(with)X 3660(all)X 3785(remaining)X 1296 4304(text/enriched)N 1824(features)X 2153(continuing)X 2589(to)X 2688(apply.)X 3 f 1008 4416(Param)N 1 f 1322(--)X 1422(Marks)X 1703(the)X 1857(affected)X 2204(text)X 2385(as)X 2501(command)X 2917(parameters,)X 3401(to)X 3513(be)X 3641(interpreted)X 4096(or)X 1296 4528(ignored)N 1637(by)X 1780(the)X 1945(text/enriched)X 2496(interpreter,)X 2969(but)X 3139(NOT)X 3383(to)X 3504(be)X 3641(shown)X 3937(to)X 4058(the)X 1296 4640(reader.)N 3 f 14 s 720 4864(Balancing)N 1226(and)X 1434(Nesting)X 1824(of)X 1946(Formatting)X 2523(Commands)X 1 f 12 s 720 5120(Pairs)N 951(of)X 1070(formatting)X 1516(commands)X 1972(must)X 2198(be)X 2328(properly)X 2693(balanced)X 3075(and)X 3253(nested.)X 3586(Thus,)X 3842(a)X 3925(proper)X 720 5232(way)N 904(to)X 1003(describe)X 1348(text)X 1517(in)X 4 f 1616(bold)X 1811(italics)X 1 f 2071(is:)X 7 f 10 s 1296 5456(the-text)N 1 f 12 s 1008 5648(or,)N 1136(alternately,)X 720 6160(Borenstein)N 1161(-)X 1217(text/enriched)X 2071(Expires)X 2389(September)X 2825(1,)X 2921(1993)X 3917(Page)X 4128(5)X 6 p %%Page: 6 6 12 s 12 xH 0 xS 1 f 10 s 7 f 1 f 12 s 720 400(Borenstein)N 1844(A)X 1937(text/enriched)X 2465(type)X 2655(for)X 2791(MIME)X 3621(April)X 3848(1993)X 4064([6])X 7 f 10 s 1296 672(the-text)N 1 f 12 s 1008 864(but,)N 1179(in)X 1278(particular,)X 1696(the)X 1838(following)X 2236(is)X 2324(illegal)X 2590 0.2404(text/enriched:)AX 7 f 10 s 1296 1088(the-text)N 1 f 12 s 720 1280(The)N 894(nesting)X 1197(requirement)X 1688(for)X 1825(formatting)X 2257(commands)X 2699(imposes)X 3039(a)X 3107(slightly)X 3421(higher)X 3692(burden)X 3984(upon)X 720 1392(the)N 868(composers)X 1309(of)X 1419(text/enriched)X 1952(bodies,)X 2256(but)X 2408(potentially)X 2850(simpli\256es)X 3253(text/enriched)X 3786(displayers)X 720 1504(by)N 857(allowing)X 1236(them)X 1471(to)X 1588(be)X 1721(stack-based.)X 2260(The)X 2452(main)X 2687(goal)X 2895(of)X 3017(text/enriched)X 3563(is)X 3669(to)X 3786(be)X 3919(simple)X 720 1616(enough)N 1052(to)X 1176(make)X 1434(multifont,)X 1866(formatted)X 2290(email)X 2553(widely)X 2863(readable,)X 3262(so)X 3395(that)X 3588(those)X 3839(with)X 4058(the)X 720 1728(capability)N 1136(of)X 1252(sending)X 1587(it)X 1677(will)X 1863(be)X 1990(able)X 2187(to)X 2298(do)X 2430(so)X 2551(with)X 2758(con\256dence.)X 3259(Thus)X 3487(slightly)X 3812(increased)X 720 1840(complexity)N 1188(in)X 1297(the)X 1449(composing)X 1905(software)X 2270(was)X 2453(deemed)X 2787(a)X 2863(reasonable)X 3308(tradeoff)X 3646(for)X 3791(simpli\256ed)X 720 1952(reading)N 1041(software.)X 1428(Nonetheless,)X 1954(implementors)X 2516(of)X 2628(text/enriched)X 3164(readers)X 3474(are)X 3624(encouraged)X 4101(to)X 720 2064(follow)N 999(the)X 1145(general)X 1457(Internet)X 1785(guidelines)X 2209(of)X 2317(being)X 2559(conservative)X 3073(in)X 3175(what)X 3389(you)X 3560(send)X 3763(and)X 3929(liberal)X 720 2176(in)N 842(what)X 1076(you)X 1267(accept.)X 1609(Those)X 1891(implementations)X 2582(that)X 2775(can)X 2957(do)X 3101(so)X 3234(are)X 3400(encouraged)X 3892(to)X 4015(deal)X 720 2288(reasonably)N 1161(with)X 1356(improperly)X 1808(nested)X 2078(text/enriched)X 2606(data.)X 3 f 14 s 720 2512(Unrecognized)N 1408(formatting)X 1955(commands)X 1 f 12 s 720 2768(Implementations)N 1436(must)X 1691(regard)X 2005(any)X 2212(unrecognized)X 2800(formatting)X 3276(command)X 3725(as)X 3874("no-op")X 720 2880(commands,)N 1194(that)X 1372(is,)X 1493(as)X 1606(commands)X 2056(having)X 2351(no)X 2480(effect,)X 2757(thus)X 2950 0.2784(facilitating)AX 3401(future)X 3663(extensions)X 4101(to)X 720 2992("text/enriched".)N 1350(Private)X 1647(extensions)X 2077(may)X 2267(be)X 2382(de\256ned)X 2689(using)X 2921(formatting)X 3352(commands)X 3793(that)X 3962(begin)X 720 3104(with)N 915("X-",)X 1142(by)X 1262(analogy)X 1591(to)X 1690(Internet)X 2014(mail)X 2210(header)X 2491(\256eld)X 2686(names.)X 720 3328(In)N 842(order)X 1087(to)X 1204(formally)X 1578(de\256ne)X 1856(extended)X 2247(commands,)X 2731(a)X 2817(new)X 3020(Internet)X 3363(document)X 3786(should)X 4085(be)X 720 3440(published.)N 3 f 16 s 720 3664("W)N 919(hite)X 1158(Space")X 1581(in)X 1720(Text/enriched)X 2514(Data)X 1 f 12 s 720 3952(No)N 901(special)X 1233(behavior)X 1634(is)X 1762(required)X 2147(for)X 2323(the)X 2505(SPACE)X 2867(or)X 3011(TAB)X 3267(\(HT\))X 3523(character.)X 3989(It)X 4112(is)X 720 4064(recommended,)N 1330(however,)X 1725(that,)X 1934(at)X 2044(least)X 2260(when)X 2507(\256xed-width)X 2989(fonts)X 3220(are)X 3377(in)X 3491(use,)X 3682(the)X 3839(common)X 720 4176(semantics)N 1135(of)X 1250(the)X 1403(TAB)X 1630(\(HT\))X 1857(character)X 2246(should)X 2537(be)X 2663(observed,)X 3069(namely)X 3389(that)X 3570(it)X 3660(moves)X 3947(to)X 4058(the)X 720 4288(next)N 919(column)X 1241(position)X 1584(that)X 1762(is)X 1859(a)X 1935(multiple)X 2290(of)X 2403(8.)X 2532(\(In)X 2677(other)X 2908(words,)X 3199(if)X 3291(a)X 3367(TAB)X 3592(\(HT\))X 3817(occurs)X 4101(in)X 720 4400(column)N 1056(n,)X 1175(where)X 1458(the)X 1624(leftmost)X 1988(column)X 2325(is)X 2437(column)X 2774(0,)X 2894(then)X 3108(that)X 3301(TAB)X 3541(\(HT\))X 3781(should)X 4085(be)X 720 4512(replaced)N 1087(by)X 1223(8-\()X 2 f 1335(n)X 1 f 1423(mod)X 1634(8\))X 1754(SPACE)X 2092(characters.\))X 2603(It)X 2702(should)X 2998(also)X 3193(be)X 3324(noted)X 3578(that)X 3762(some)X 4004(mail)X 720 4624(gateways)N 1108(are)X 1256(notorious)X 1649(for)X 1791(losing)X 2056(\(or,)X 2222(less)X 2396(commonly,)X 2862(adding\))X 3186(white)X 3431(space)X 3676(at)X 3777(the)X 3926(end)X 4096(of)X 720 4736(lines,)N 950(so)X 1059(reliance)X 1389(on)X 1509(SPACE)X 1831(or)X 1935(TAB)X 2151(characters)X 2566(at)X 2660(the)X 2802(end)X 2965(of)X 3069(a)X 3136(line)X 3305(is)X 3393(not)X 3540(recommended.)X 3 f 16 s 720 4960(Initial)N 1088(State)X 1398(of)X 1537(a)X 1633(text/enriched)X 2385(interpreter)X 1 f 12 s 720 5248(Text/enriched)N 1284(is)X 1376(assumed)X 1735(to)X 1838(begin)X 2080(with)X 2279(\256lled,)X 2530(fully)X 2741(justi\256ed)X 3080(text)X 3254(in)X 3358(a)X 3430(variable-width)X 4021(font)X 720 5360(in)N 826(a)X 900(normal)X 1204(typeface)X 1562(and)X 1731(a)X 1804(size)X 1984(that)X 2159(is)X 2253(average)X 2583(for)X 2725(the)X 2873(current)X 3176(display)X 3484(and)X 3653(user.)X 3867(The)X 4047(left)X 720 5472(and)N 902(right)X 1127(margins)X 1480(are)X 1641(assumed)X 2015(to)X 2133(be)X 2267(maximal,)X 2672(that)X 2860(is,)X 2991(at)X 3104(the)X 3265(leftmost)X 3624(and)X 3807(rightmost)X 720 5584(acceptable)N 1152(positions.)X 720 6160(Borenstein)N 1161(-)X 1217(text/enriched)X 2071(Expires)X 2389(September)X 2825(1,)X 2921(1993)X 3917(Page)X 4128(6)X 7 p %%Page: 7 7 12 s 12 xH 0 xS 1 f 720 400(Borenstein)N 1844(A)X 1937(text/enriched)X 2465(type)X 2655(for)X 2791(MIME)X 3621(April)X 3848(1993)X 4064([7])X 3 f 16 s 720 720(Non-ASCII)N 1377(character)X 1936(sets)X 1 f 12 s 720 1008(If)N 835(the)X 1004(character)X 1409(set)X 1567(speci\256ed)X 1961(by)X 2109(the)X 2279(charset)X 2604(parameter)X 3042(on)X 3190(the)X 3360(Content-type)X 3915(line)X 4112(is)X 720 1120(anything)N 1128(other)X 1397(than)X 1634("US-ASCII",)X 2211(this)X 2421(means)X 2738(that)X 2954(the)X 3142(text)X 3357(being)X 3641(described)X 4080(by)X 720 1232(text/enriched)N 1275(formatting)X 1733(commands)X 2201(is)X 2317(in)X 2444(a)X 2539(non-ASCII)X 3017(character)X 3423(set.)X 3630(However,)X 4058(the)X 720 1344(commands)N 1188(themselves)X 1667(are)X 1836(still)X 2032(the)X 2201(same)X 2449(ASCII)X 2749(commands)X 3216(that)X 3411(are)X 3579(de\256ned)X 3912(in)X 4037(this)X 720 1456(document.)N 1178(This)X 1379(creates)X 1677(an)X 1798(ambiguity)X 2219(only)X 2420(with)X 2622(reference)X 3012(to)X 3118(the)X 3267("<")X 3430(character,)X 3839(the)X 3988(octet)X 720 1568(with)N 917(numeric)X 1259(value)X 1494(60.)X 1664(In)X 1770(single)X 2026(byte)X 2218(character)X 2598(sets,)X 2792(such)X 2994(as)X 3100(the)X 3244(ISO-8859)X 3647(family,)X 3948(this)X 4112(is)X 720 1680(not)N 874(a)X 948(problem;)X 1327(the)X 1476(octet)X 1695(60)X 1822(can)X 1987(be)X 2109(quoted)X 2402(by)X 2529(including)X 2924(it)X 3009(twice,)X 3273(just)X 3443(as)X 3554(for)X 3697(ASCII.)X 4026(The)X 720 1792(problem)N 1077(is)X 1177(more)X 1411(complicated,)X 1943(however,)X 2333(in)X 2443(the)X 2596(case)X 2797(of)X 2912(multi-byte)X 3349(character)X 3738(sets,)X 3941(where)X 720 1904(the)N 862(octet)X 1074(60)X 1194(might)X 1443(appear)X 1724(at)X 1818(any)X 1981(point)X 2203(in)X 2302(the)X 2444(byte)X 2634(sequence)X 3011(for)X 3147(any)X 3310(of)X 3414(several)X 3711(characters.)X 720 2128(In)N 832(practice,)X 1194(however,)X 1582(most)X 1802(multibyte)X 2205(character)X 2592(sets)X 2769(address)X 3090(this)X 3262(problem)X 3616(internally.)X 4043(For)X 720 2240(example,)N 1118(the)X 1283(ISO-2022)X 1708(family)X 2007(of)X 2134(character)X 2534(sets)X 2724(can)X 2904(switch)X 3201(back)X 3429(into)X 3625(ASCII)X 3921(at)X 4037(any)X 720 2352(moment.)N 1120(Therefore)X 1536(it)X 1626(is)X 1727(speci\256ed)X 2106(that,)X 2312(before)X 2595(text/enriched)X 3136(formatting)X 3580(commands,)X 4058(the)X 720 2464(prevailing)N 1159(character)X 1561(set)X 1716(should)X 2020(be)X 2159("switched)X 2588(back")X 2857(into)X 3055(ASCII,)X 3377(and)X 3563(that)X 3755(only)X 3973(those)X 720 2576(characters)N 1139(which)X 1402(would)X 1670(be)X 1789(interpreted)X 2235(as)X 2343("<")X 2503(in)X 2606(plain)X 2827(text)X 3001(should)X 3286(be)X 3406(interpreted)X 3853(as)X 3962(token)X 720 2688(delimiters)N 1130(in)X 1229(text/enriched.)X 720 2912(The)N 902(question)X 1260(of)X 1372(what)X 1591(to)X 1698(do)X 1826(for)X 1970(hypothetical)X 2479(future)X 2741(character)X 3127(sets)X 3303(that)X 3481(do)X 3610(NOT)X 3840(subsume)X 720 3024(ASCII)N 994(is)X 1082(not)X 1229(addressed)X 1632(in)X 1731(this)X 1894(memo.)X 3 f 16 s 720 3248(M)N 841(inim)X 1091(al)X 1223(text/enriched)X 1975(conform)X 2438(ance)X 1 f 12 s 720 3536(A)N 837(minimal)X 1208(text/enriched)X 1761 0.2548(implementation)AX 2416(is)X 2529(one)X 2717(that)X 2911(converts)X 3286("<<")X 3521(to)X 3645("<",)X 3850(removes)X 720 3648(everything)N 1170(between)X 1529(a)X 1610()X 1996(command)X 2413(and)X 2589(the)X 2744(next)X 2947(balancing)X 3359()X 3772(command,)X 720 3760(removes)N 1083(all)X 1217(other)X 1452(formatting)X 1896(commands)X 2350(\(all)X 2517(text)X 2700(enclosed)X 3075(in)X 3188(angle)X 3435(brackets\),)X 3850(converts)X 720 3872(any)N 883(series)X 1126(of)X 1230(n)X 1302(CRLFs)X 1603(to)X 1702(n-1)X 1854(CRLFs,)X 2179(and)X 2342(converts)X 2692(any)X 2855(lone)X 3045(CRLF)X 3309(pairs)X 3520(to)X 3619(SPACE.)X 3 f 16 s 720 4096(Notes)N 1058(for)X 1254(Im)X 1411(plem)X 1682(entors)X 1 f 12 s 720 4384(It)N 803(is)X 892(recognized)X 1340(that)X 1510(implementors)X 2065(of)X 2170(future)X 2425(mail)X 2622(systems)X 2951(will)X 3126(want)X 3338(rich)X 3513(text)X 3683(functionality)X 720 4496(far)N 872(beyond)X 1200(that)X 1390(currently)X 1783(de\256ned)X 2111(for)X 2267(text/enriched.)X 2863(The)X 3057(intent)X 3321(of)X 3445(text/enriched)X 3993(is)X 4101(to)X 720 4608(provide)N 1039(a)X 1107(common)X 1469(format)X 1751(for)X 1888(expressing)X 2324(that)X 2494(functionality)X 3012(in)X 3112(a)X 3180(form)X 3392(in)X 3492(which)X 3752(much)X 3992(of)X 4098(it,)X 720 4720(at)N 817(least,)X 1045(will)X 1221(be)X 1338(understood)X 1791(by)X 1913(interoperating)X 2480(software.)X 2885(Thus,)X 3127(in)X 3228(particular,)X 3648(software)X 4005(with)X 720 4832(a)N 791(richer)X 1044(notion)X 1318(of)X 1426(formatted)X 1829(text)X 2002(than)X 2196(text/enriched)X 2728(can)X 2890(still)X 3063(use)X 3219(text/enriched)X 3751(as)X 3859(its)X 3978(basic)X 720 4944(representation,)N 1352(but)X 1537(can)X 1733(extend)X 2052(it)X 2168(with)X 2401(new)X 2623(formatting)X 3092(commands)X 3571(and)X 3772(by)X 3930(hiding)X 720 5056(information)N 1199(speci\256c)X 1517(to)X 1616(that)X 1785(software)X 2140(system)X 2431(in)X 2530(text/enriched)X 3058()X 3431(constructs.)X 3869(As)X 4000(such)X 720 5168(systems)N 1057(evolve,)X 1371(it)X 1458(is)X 1555(expected)X 1931(that)X 2109(the)X 2260(de\256nition)X 2662(of)X 2774(text/enriched)X 3310(will)X 3492(be)X 3615(further)X 3909(re\256ned)X 720 5280(by)N 847(future)X 1108(published)X 1513(speci\256cations,)X 2092(but)X 2246(text/enriched)X 2781(as)X 2893(de\256ned)X 3208(here)X 3406(provides)X 3769(a)X 3844(platform)X 720 5392(on)N 840(which)X 1099(evolutionary)X 1610(re\256nements)X 2083(can)X 2241(be)X 2356(based.)X 720 5616(An)N 870(expected)X 1246(common)X 1616(way)X 1809(that)X 1987(sophisticated)X 2524(mail)X 2730(programs)X 3127(will)X 3311(generate)X 3672(text/enriched)X 720 5728(data)N 917(is)X 1017(as)X 1133(part)X 1319(of)X 1435(a)X 1514 0.2562(multipart/alternative)AX 2339(construct.)X 2776(For)X 2945(example,)X 3332(a)X 3411(mail)X 3618(agent)X 3862(that)X 4042(can)X 720 5840(generate)N 1103(enriched)X 1491(mail)X 1719(in)X 1850(ODA)X 2113(format)X 2426(can)X 2616(generate)X 2999(that)X 3200(mail)X 3428(in)X 3559(a)X 3659(more)X 3914(widely)X 720 6160(Borenstein)N 1161(-)X 1217(text/enriched)X 2071(Expires)X 2389(September)X 2825(1,)X 2921(1993)X 3917(Page)X 4128(7)X 8 p %%Page: 8 8 12 s 12 xH 0 xS 1 f 720 400(Borenstein)N 1844(A)X 1937(text/enriched)X 2465(type)X 2655(for)X 2791(MIME)X 3621(April)X 3848(1993)X 4064([8])X 720 688(interoperable)N 1257(form)X 1472(by)X 1596(generating)X 2031(both)X 2230(text/enriched)X 2762(and)X 2929(ODA)X 3164(versions)X 3512(of)X 3620(the)X 3766(same)X 3991(data,)X 720 800(e.g.:)N 7 f 10 s 1008 1024(Content-type:)N 1680(multipart/alternative;)X 2784(boundary=3Dfoo)X 1008 1216(--foo)N 1008 1312(Content-type:)N 1680(text/enriched)X 1008 1504([text/enriched)N 1728(version)X 2112(of)X 2256(data])X 1008 1600(--foo)N 1008 1696(Content-type:)N 1680(application/oda)X 1008 1888([ODA)N 1248(version)X 1632(of)X 1776(data])X 1008 1984(--foo--)N 1 f 12 s 720 2176(If)N 813(such)X 1018(a)X 1090(message)X 1445(is)X 1538(read)X 1733(using)X 1970(a)X 2042(MIME-conformant)X 2808(mail)X 3010(reader)X 3281(that)X 3456(understands)X 3945(ODA,)X 720 2288(the)N 862(ODA)X 1093(version)X 1400(will)X 1574(be)X 1689(displayed;)X 2109(otherwise,)X 2531(the)X 2673(text/enriched)X 3201(version)X 3508(will)X 3682(be)X 3797(shown.)X 720 2512(In)N 866(some)X 1135(environments,)X 1749(it)X 1869(might)X 2160(be)X 2317(impossible)X 2801(to)X 2943(combine)X 3342(certain)X 3672(text/enriched)X 720 2624(formatting)N 1161(commands,)X 1635(whereas)X 1983(in)X 2091(others)X 2359(they)X 2558(might)X 2816(be)X 2940(combined)X 3353(easily.)X 3659(For)X 3825(example,)X 720 2736(the)N 885(combination)X 1414(of)X 1541()X 1867(and)X 2053()X 2402(might)X 2674(produce)X 4 f 3032(bold)X 3251(italics)X 1 f 3535(on)X 3679(systems)X 4031(that)X 720 2848(support)N 1039(such)X 1246(fonts,)X 1493(but)X 1647(there)X 1871(exist)X 2084(systems)X 2419(that)X 2595(can)X 2760(make)X 3000(text)X 3176(bold)X 3378(or)X 3489 0.3063(italicized,)AX 3899(but)X 4053(not)X 720 2960(both.)N 1000(In)X 1142(such)X 1380(cases,)X 1669(the)X 1849(most)X 2098(recently)X 2471(issued)X 2773(\(innermost\))X 3284(recognized)X 3769(formatting)X 720 3072(command)N 1124(should)X 1404(be)X 1519(preferred.)X 720 3296(One)N 908(of)X 1016(the)X 1162(major)X 1415(goals)X 1646(in)X 1749(the)X 1895(design)X 2175(of)X 2284(text/enriched)X 2817(was)X 2995(to)X 3099(make)X 3337(it)X 3420(so)X 3534(simple)X 3820(that)X 3994(even)X 720 3408(text-only)N 1109(mailers)X 1433(will)X 1623(implement)X 2076 0.1905(enriched-to-plain-text)AX 2957(translators,)X 3422(thus)X 3622(increasing)X 4058(the)X 720 3520(likelihood)N 1138(that)X 1310(enriched)X 1669(text)X 1841(will)X 2018(become)X 2346("safe")X 2607(to)X 2710(use)X 2866(very)X 3065(widely.)X 3403(To)X 3538(demonstrate)X 4037(this)X 720 3632(simplicity,)N 1167(an)X 1295(extremely)X 1718(simple)X 2012(C)X 2113(program)X 2476(that)X 2658(converts)X 3021(text/enriched)X 3562(input)X 3797(into)X 3983(plain)X 720 3744(text)N 889(output)X 1159(is)X 1247(included)X 1603(in)X 1702(Appendix)X 2105(A.)X 3 f 16 s 720 3968(Extensions)N 1343(to)X 1482(text/enriched)X 1 f 12 s 720 4256(It)N 816(is)X 917(expected)X 1297(that)X 1479(various)X 1799(mail)X 2009(system)X 2314(authors)X 2635(will)X 2823(desire)X 3091(extensions)X 3535(to)X 3648(text/enriched.)X 720 4368(The)N 908(simple)X 1203(syntax)X 1492(of)X 1610(text/enriched,)X 2176(and)X 2352(the)X 2507(speci\256cation)X 3031(that)X 3213(unrecognized)X 3769(formatting)X 720 4480(commands)N 1161(should)X 1441(simply)X 1727(be)X 1842(ignored,)X 2184(are)X 2326(intend)X 2591(to)X 2690(promote)X 3035(such)X 3235(extensions.)X 720 4704(Beyond)N 1068(simply)X 1379(de\256ning)X 1743(new)X 1952(formatting)X 2408(commands,)X 2898(however,)X 3303(it)X 3407(may)X 3623(sometimes)X 4085(be)X 720 4816(necessary)N 1126(to)X 1233(de\256ne)X 1499(formatting)X 1937(commands)X 2385(that)X 2561(can)X 2726(take)X 2918(arguments.)X 3398(This)X 3600(is)X 3695(the)X 3844(intended)X 720 4928(use)N 874(of)X 980(the)X 1125()X 1501(construct.)X 1929(In)X 2036(particular,)X 2457(software)X 2815(that)X 2987(wished)X 3286(to)X 3388(extend)X 3672(text/enriched)X 720 5040(to)N 820(include)X 1129(colored)X 1443(text)X 1613(might)X 1863(de\256ne)X 2123(an)X 2239("x-color")X 2620(environment)X 3132(which)X 3392(always)X 3684(began)X 3938(with)X 4133(a)X 720 5152(color)N 942(name)X 1175(parameter,)X 1609(to)X 1708(indicate)X 2038(the)X 2180(desired)X 2482(color)X 2704(for)X 2840(the)X 2982(affected)X 3317(text.)X 3 f 16 s 720 5296(An)N 915(Exam)X (ple)S 1 f 12 s 720 5520(Putting)N 1022(all)X 1143(this)X 1306(together,)X 1670(the)X 1812(following)X 2210("text/enriched")X 2840(body)X 3056(fragment:)X 720 6160(Borenstein)N 1161(-)X 1217(text/enriched)X 2071(Expires)X 2389(September)X 2825(1,)X 2921(1993)X 3917(Page)X 4128(8)X 9 p %%Page: 9 9 12 s 12 xH 0 xS 1 f 10 s 7 f 1 f 12 s 720 400(Borenstein)N 1844(A)X 1937(text/enriched)X 2465(type)X 2655(for)X 2791(MIME)X 3621(April)X 3848(1993)X 4064([9])X 7 f 10 s 1296 672(From:)N 1584(Nathaniel)X 2064(Borenstein)X 2592()X 1296 768(To:)N 1488(Ned)X 1680(Freed)X 1968()X 1296 864(Content-type:)N 1968(text/enriched)X 1296 1056(Now)N 2112(is)X 2256(the)X 2448(time)X 2688(for)X 2880(all)X 1296 1152(good)N 1536(men)X 1344 1248(\(and)N 2016(<\))X 2976(to)X 1296 1344(come)N 1296 1536(to)N 1440(the)X 1632(aid)X 1824(of)X 1968(their)X 1296 1824(redbeloved)N 1296 1920(country.)N 1296 2112(By)N 1440(the)X 1632(way,)X 1872(I)X 1968(think)X 2256(that)X 2496()X 1296 2304(should)N 1296 2496(REALLY)N 1632(be)X 1776(called)X 1296 2688()N 1296 2784(and)N 1488(that)X 1728(I)X 1824(am)X 1968(always)X 2304(right.)X 1296 2976(--)N 1440(the)X 1632(end)X 1 f 12 s 720 3168(represents)N 1140(the)X 1288(following)X 1693(formatted)X 2099(text)X 2275(\(which)X 2573(will,)X 2778(no)X 2905(doubt,)X 3179(look)X 3381(somewhat)X 3802(cryptic)X 4101(in)X 720 3280(the)N 862(text-only)X 1234(version)X 1541(of)X 1645(this)X 1808(document\):)X 3 f 1008 3504(Now)N 1 f 1218(is)X 1306(the)X 1448(time)X 1644(for)X 2 f 1780(all)X 1 f 1906(good)X 2122(men)X 10 s 2312(\(and)X 2475(\))X 12 s 2852(to)X 2951(come)X 1008 3616(to)N 1107(the)X 1249(aid)X 1391(of)X 1495(their)X 1008 3840(beloved)N 1337(country.)X 1008 3952(By)N 1144(the)X 1286(way,)X 1494(I)X 1550(think)X 1772(that)X 1941()X 1008 4064(should)N 1008 4176(REALLY)N 1411(be)X 1526(called)X 1008 4288()N 1008 4400(and)N 1171(that)X 1340(I)X 1396(am)X 1538(always)X 1829(right.)X 1008 4512(--)N 1096(the)X 1238(end)X 720 4736(where)N 989(the)X 1141(word)X 1372("beloved")X 1789(would)X 2063(be)X 2188(in)X 2297(red)X 2454(on)X 2584(a)X 2661(color)X 2893(display)X 3205(if)X 3298(the)X 3451(receiving)X 3845(software)X 720 4848(implemented)N 1248(the)X 1390("x-color")X 1770(extension.)X 3 f 600 5072(Security)N 966(Considerations)X 1 f 720 5296(Security)N 1084(issues)X 1356(are)X 1517(not)X 1683(discussed)X 2094(in)X 2212(this)X 2394(memo,)X 2702(as)X 2825(the)X 2986(mechanism)X 3468(raises)X 3731(no)X 3871(security)X 720 5408(issues.)N 3 f 600 5632(Author's)N 991(Address)X 1 f 720 6160(Borenstein)N 1161(-)X 1217(text/enriched)X 2071(Expires)X 2389(September)X 2825(1,)X 2921(1993)X 3917(Page)X 4128(9)X 10 p %%Page: 10 10 12 s 12 xH 0 xS 1 f 720 400(Borenstein)N 1844(A)X 1937(text/enriched)X 2465(type)X 2655(for)X 2791(MIME)X 3573(April)X 3800(1993)X 4016([10])X 720 688(For)N 877(more)X 1099(information,)X 1602(the)X 1744(author)X 2014(of)X 2118(this)X 2281(document)X 2685(may)X 2875(be)X 2990(contacted)X 3384(via)X 3526(Internet)X 3850(mail:)X 2 f 2025 912(Nathaniel)N 2429(S.)X 2525(Borenstein)X 2039 1024(MRE)N 2261(2D-296,)X 2602(Bellcore)X 2229 1136(445)N 2397(South)X 2640(St.)X 1936 1248(Morristown,)N 2437(NJ)X 2568(07962-1910)X 2000 1472(Phone:)N 2302(+1)X 2439(201)X 2607(829)X 2775(4270)X 2036 1584(Fax:)N 2266(+1)X 2403(201)X 2571(829)X 2739(5963)X 1980 1696(Email:)N 2266(nsb@bellcore.com)X 3 f 16 s 720 1920(Acknowledgem)N 1559(ents)X 1 f 12 s 720 2208(This)N 920(document)X 1330(re\257ects)X 1638(the)X 1786(input)X 2014(of)X 2124(many)X 2368(contributors,)X 2887(readers,)X 3219(and)X 3388(implementors)X 3948(of)X 4058(the)X 720 2320(original)N 1076(MIME)X 1393(speci\256cation,)X 1960(RFC)X 2197(1341.)X 2493(The)X 2698(current)X 3026(draft)X 3263(also)X 3473(re\257ects)X 3806(particular)X 720 2432(contributions)N 1252(and)X 1415(comments)X 1835(from)X 2046(Terry)X 2284(Crowley)X 2639(and)X 2802(Rhys)X 3023(Weatherley.)X 3 f 600 2656(References)N 1 f 720 2880([RFC-1341])N 1252(Borenstein,)X 1756(N.,)X 1937(and)X 2140(N.)X 2297(Freed,)X 2628("MIME)X 3016(\(Multipurpose)X 3630(Internet)X 3994(Mail)X 720 2992(Extensions\):)N 1230(Mechanisms)X 1745(for)X 1886(Specifying)X 2332(and)X 2500(Describing)X 2951(the)X 3098(Format)X 3404(of)X 3512(Internet)X 3840(Message)X 720 3104(Bodies",)N 1074(RFC)X 1279(1341,)X 1519(June,)X 1743(1992.)X 720 3328([RFC-MIME])N 1314(Borenstein,)X 1811(N.,)X 1984(and)X 2179(N.)X 2328(Freed,)X 2651("MIME)X 3031(\(Multipurpose)X 3637(Internet)X 3994(Mail)X 720 3440(Extensions\))N 1200(Part)X 1381(One:)X 1618(Mechanisms)X 2130(for)X 2268(Specifying)X 2711(and)X 2876(Describing)X 3324(the)X 3468(Format)X 3771(of)X 3876(Internet)X 720 3552(Message)N 1080(Bodies",)X 1434(RFC)X 1639(********,)X 2071(*****,)X 2359(1993.)X 3 f 16 s 720 3776(Appendix)N 1285(A)X 1409(--)X 1527(A)X 1651(Sim)X 1865(ple)X 2061(enriched-to-plain)X 3041(Translator)X 3664(in)X 3803(C)X 1 f 12 s 720 4064(One)N 916(of)X 1032(the)X 1186(major)X 1447(goals)X 1686(in)X 1797(the)X 1951(design)X 2238(of)X 2354(the)X 2508(text/enriched)X 3049(subtype)X 3385(of)X 3502(the)X 3657(text)X 3839(Content-)X 720 4176(Type)N 959(is)X 1064(to)X 1180(make)X 1430(formatted)X 1846(text)X 2032(so)X 2157(simple)X 2454(that)X 2639(even)X 2861(text-only)X 3249(mailers)X 3573(will)X 3763(implement)X 720 4288 0.1905(enriched-to-plain-text)AN 1597(translators,)X 2058(thus)X 2254(increasing)X 2686(the)X 2840(likelihood)X 3267(that)X 3448(multifont)X 3844(text)X 4026(will)X 720 4400(become)N 1061("safe")X 1335(to)X 1451(use)X 1620(very)X 1832(widely.)X 2183(To)X 2331(demonstrate)X 2843(this)X 3023(simplicity,)X 3474(what)X 3701(follows)X 4029(is)X 4133(a)X 720 4512(simple)N 1008(C)X 1103(program)X 1460(that)X 1636(converts)X 1993(text/enriched)X 2528(input)X 2757(into)X 2938(plain)X 3162(text)X 3338(output.)X 3663(Note)X 3881(that)X 4058(the)X 720 4624(local)N 946(newline)X 1289(convention)X 1754(\(the)X 1941(single)X 2208(character)X 2599(represented)X 3080(by)X 3213("\\n"\))X 3435(is)X 3536(assumed)X 3904(by)X 4037(this)X 720 4736(program,)N 1094(but)X 1241(that)X 1410(special)X 1702(CRLF)X 1966(handling)X 2327(might)X 2576(be)X 2691(necessary)X 3089(on)X 3209(some)X 3436(systems..)X 7 f 8 s 1008 4960(#include)N 1350 -0.4219()AX 1008 5040(#include)N 1350 -0.4219()AX 1008 5200(main\(\))N 1274({)X 1160 5280(int)N 1312(c,)X 1426(i,)X 1540 -0.4167(paramct=3D0,)AX 1958 -0.4091(newlinect=3D0,)AX 2452 -0.4219(nofill=3D0;)AX 1160 5360(char)N 1350 -0.4167(token[62],)AX 1768(*p;)X 1160 5520(while)N 1388 -0.4000(\(\(c=3Dgetc\(stdin\)\))AX 2034(!=3D)X 2148(EOF\))X 2338({)X 1 f 12 s 720 6128(Borenstein)N 1161(-)X 1217(text/enriched)X 2071(Expires)X 2389(September)X 2825(1,)X 2921(1993)X 3869(Page)X 4080(10)X 11 p %%Page: 11 11 12 s 12 xH 0 xS 1 f 8 s 7 f 1 f 12 s 720 368(Borenstein)N 1844(A)X 1937(text/enriched)X 2465(type)X 2655(for)X 2791(MIME)X 3573(April)X 3800(1993)X 4016([11])X 7 f 8 s 1312 656(if)N 1426(\(c)X 1540(=3D=3D)X 1654('<'\))X 1844({)X 1464 736 -0.4091(newlinect=3D0;)AN 1464 816(c)N 1540(=3D)X 1616 -0.4091(getc\(stdin\);)AX 1464 896(if)N 1578(\(c)X 1692(=3D=3D)X 1806('<'\))X 1996({)X 1616 976(if)N 1730(\(paramct)X 2072(<=3D)X 2186(0\))X 2300(putc\(c,)X 2604(stdout\);)X 1464 1056(})N 1540(else)X 1730({)X 1692 1136 -0.4219(ungetc\(c,)AN 2072(stdin\);)X 1692 1216(for)N 1844(\(i=3D0,)X 2072(p=3Dtoken;)X 2414 -0.4018(\(c=3Dgetc\(stdin\)\))AX 3022(!=3D)X 3136(EOF)X 3288(&&)X 3402(c)X 3478(!=3D)X 3592('>';)X 3782(i++\))X 3972({)X 1844 1296(if)N 1958(\(i)X 2072(<)X 2148 -0.4000(sizeof\(token\)-1\))AX 2794(*p++)X 2984(=3D)X 3060 -0.4167(isupper\(c\))AX 3478(?)X 3554 -0.4167(tolower\(c\))AX 3972(:)X 4048(c;)X 1692 1376(})N 1692 1456(*p)N 1806(=3D)X 1882('\\0';)X 1692 1536(if)N 1806(\(c)X 1920(=3D=3D)X 2034(EOF\))X 2224(break;)X 1692 1616(if)N 1806 -0.4038(\(strcmp\(token,)AX 2376("param"\))X 2718(=3D=3D)X 2832(0\))X 1844 1696 -0.4167(paramct++;)AN 1692 1776(else)N 1882(if)X 1996 -0.4038(\(strcmp\(token,)AX 2566 -0.4219("nofill"\))AX 2946(=3D=3D)X 3060(0\))X 1844 1856 -0.4219(nofill++;)AN 1692 1936(else)N 1882(if)X 1996 -0.4038(\(strcmp\(token,)AX 2566 -0.4219("/param"\))AX 2946(=3D=3D)X 3060(0\))X 1844 2016 -0.4167(paramct--;)AN 1692 2096(else)N 1882(if)X 1996 -0.4038(\(strcmp\(token,)AX 2566 -0.4167("/nofill"\))AX 2984(=3D=3D)X 3098(0\))X 1844 2176 -0.4219(nofill--;)AN 1540 2336(})N 1312 2416(})N 1388(else)X 1578({)X 1464 2496(if)N 1578(\(paramct)X 1920(>)X 1996(0\))X 1616 2576(;)N 1692(/*)X 1806(ignore)X 2072(params)X 2338(*/)X 1464 2656(else)N 1654(if)X 1768(\(c)X 1882(=3D=3D)X 1996('\\n')X 2186(&&)X 2300(nofill)X 2566(<=3D)X 2680(0\))X 1616 2736(if)N 1730 -0.4091(\(++newlinect)AX 2224(>)X 2300(1\))X 2414({)X 1768 2816(putc\(c,)N 2072(stdout\);)X 1616 2896(})N 1692(else)X 1882({)X 1768 2976(putc\(')N 2034(',)X 2148(stdout\);)X 1616 3056(})N 1464 3136(else)N 1654({)X 1616 3216 -0.4219(newlinect)AN 1996(=3D)X 2072(0;)X 1616 3296(putc\(c,)N 1920(stdout\);)X 1464 3376(})N 1312 3456(})N 1160 3536(})N 1160 3616(/*)N 1274(The)X 1426 -0.4219(following)AX 1806(line)X 1996(is)X 2110(only)X 2300(needed)X 2566(with)X 2756 -0.4038(line-buffering)AX 3326(*/)X 1160 3696 -0.4167(putc\('\\n',)AN 1578(stdout\);)X 1160 3776(exit\(0\);)N 1008 3856(})N 1008 4016 -0.4038(lc2strncmp\(s1,)AN 1578(s2,)X 1730(len\))X 1008 4096(char)N 1198(*s1,)X 1388(*s2;)X 1008 4176(int)N 1160(len;)X 1008 4256({)N 1160 4336(if)N 1274(\(!s1)X 1464(||)X 1578(!s2\))X 1768(return)X 2034(\(-1\);)X 1160 4416(while)N 1388(\(*s1)X 1578(&&)X 1692(*s2)X 1844(&&)X 1958(len)X 2110(>)X 2186(0\))X 2300({)X 1296 4496(if)N 1410(\(*s1)X 1600(!=3D)X 1714(*s2)X 1866(&&)X 1980 -0.4062(\(tolower\(*s1\))AX 2512(!=3D)X 2626(*s2\)\))X 2854 -0.4125(return\(-1\);)AX 1296 4576(++s1;)N 1524(++s2;)X 1752(--len;)X 1160 4656(})N 1160 4736(if)N 1274(\(len)X 1464(<=3D)X 1578(0\))X 1692 -0.4167(return\(0\);)AX 1160 4816 -0.4125(return\(\(*s1)AN 1616(=3D=3D)X 1730(*s2\))X 1920(?)X 1996(0)X 2072(:)X 2148(-1\);)X 1008 4896(})N 1 f 12 s 720 5056(It)N 842(should)X 1161(be)X 1315(noted)X 1593(that)X 1802(one)X 2005(can)X 2203(do)X 2363(considerably)X 2919(better)X 3203(than)X 3433(this)X 3636(in)X 3775(displaying)X 720 5168(text/enriched)N 1260(data)X 1457(on)X 1589(a)X 1668(dumb)X 1923(terminal.)X 2329(In)X 2445(particular,)X 2874(one)X 3048(can)X 3217(replace)X 3531(font)X 3721(information)X 720 5280(such)N 949(as)X 1082("bold")X 1384(with)X 1608(textual)X 1924(emphasis)X 2335(\(like)X 2565(*this*)X 2853(or)X 3034(_T_H_I_S_\).)X 3620(One)X 3833(can)X 4021(also)X 720 5392(properly)N 1132(handle)X 1475(the)X 1679(text/enriched)X 2269(formatting)X 2762(commands)X 3264(regarding)X 3718(indentation,)X 720 5504(justi\256cation,)N 1229(and)X 1398(others.)X 1687(However,)X 2093(the)X 2241(above)X 2501(program)X 2857(is)X 2952(all)X 3080(that)X 3256(is)X 2 f 3351(necessary)X 1 f 3761(in)X 3867(order)X 4101(to)X 720 5616(present)N 1049(text/enriched)X 1603(on)X 1749(a)X 1842(dumb)X 2111(terminal)X 2483(without)X 2827(showing)X 3202(the)X 3370(user)X 3580(any)X 3769(formatting)X 720 5728(artifacts.)N 720 6160(Borenstein)N 1161(-)X 1217(text/enriched)X 2071(Expires)X 2389(September)X 2825(1,)X 2921(1993)X 3869(Page)X 4080(11)X 12 p %%Page: 12 12 12 s 12 xH 0 xS 1 f 720 400(Borenstein)N 1844(A)X 1937(text/enriched)X 2465(type)X 2655(for)X 2791(MIME)X 3573(April)X 3800(1993)X 4016([12])X 3 f 16 s 720 720(Appendix)N 1285(B)X 1402(--)X 1520(Differences)X 2172(from)X 2475(RFC)X 2769(1341)X 3089(text/richtext)X 1 f 12 s 720 944(Text/enriched)N 1301(is)X 1410(a)X 1498(clari\256cation,)X 2028(simpli\256cation,)X 2627(and)X 2811(re\256nement)X 3268(of)X 3393(the)X 3556(type)X 3767(de\256ned)X 4096(as)X 720 1056 0.2552(text/richtext)AN 1238(in)X 1364(RFC)X 1596(1341.)X 1886(For)X 2069(the)X 2237(bene\256t)X 2549(of)X 2679(those)X 2932(who)X 3147(are)X 3315(already)X 3649(familiar)X 4005(with)X 720 1168 0.2356(text/richtext,)AN 1257(or)X 1383(for)X 1541(those)X 1790(who)X 2001(want)X 2234(to)X 2355(exploit)X 2669(the)X 2833(similarities)X 3308(to)X 3430(be)X 3568(able)X 3776(to)X 3898(display)X 720 1280 0.2552(text/richtext)AN 1221(data)X 1416(with)X 1621(their)X 1832(text/enriched)X 2370(software,)X 2759(the)X 2911(differences)X 3373(between)X 3728(the)X 3880(two)X 4058(are)X 720 1392(summarized)N 1234(here.)X 1467(Note,)X 1721(however,)X 2119(that)X 2307(text/enriched)X 2854(is)X 2961(intended)X 3337(to)X 3456(make)X 3709 0.2552(text/richtext)AX 720 1504(obsolete,)N 1089(so)X 1198(it)X 1276(is)X 1364(not)X 1511(recommended)X 2081(that)X 2250(new)X 2434(software)X 2 f 2789(generate)X 1 f 3150 0.2356(text/richtext.)AX 720 1728(0.)N 842(The)X 1018(name)X 1254("richtext")X 1654(was)X 1830(changed)X 2178(to)X 2280("enriched",)X 2741(both)X 2939(to)X 3041(differentiate)X 3540(the)X 3685(two)X 3856(versions)X 720 1840(and)N 888(because)X 1222("richtext")X 1624(created)X 1932(widespread)X 2399(confusion)X 2807(with)X 3007(Microsoft's)X 3483(Rich)X 3693(Text)X 3898(Format)X 720 1952(\(RTF\).)N 720 2176(1.)N 870(Clari\256cations.)X 1491(Many)X 1769(things)X 2059(were)X 2301(ambiguous)X 2778(or)X 2913(unspeci\256ed)X 3406(in)X 3536(the)X 3709 0.2552(text/richtext)AX 720 2288(de\256nition,)N 1163(particularly)X 1658(the)X 1826(initial)X 2102(state)X 2329(and)X 2517(the)X 2684(semantics)X 3113(of)X 3242(richtext)X 3586(with)X 3806(multibyte)X 720 2400(character)N 1107(sets.)X 1332(However,)X 1741(such)X 1951(differences)X 2413(are)X 2565(OPERATIONALLY)X 3398(irrelevant,)X 3826(since)X 4058(the)X 720 2512(clari\256cations)N 1269(offered)X 1598(in)X 1724(this)X 1914(document)X 2344(are)X 2512(at)X 2632(least)X 2859(reasonable)X 3321(interpretations)X 3928(of)X 4058(the)X 720 2624 0.2552(text/richtext)AN 1211(speci\256cation.)X 720 2848(2.)N 842(Newline)X 1194(semantics)X 1600(have)X 1808(changed.)X 2203(In)X 2309 0.2356(text/richtext,)AX 2826(all)X 2949(CRLFs)X 3253(were)X 3467(mapped)X 3799(to)X 3901(spaces,)X 720 2960(and)N 892(line)X 1070(breaks)X 1354(were)X 1574(indicated)X 1961(by)X 2089("".)X 2430(This)X 2633(has)X 2793(been)X 3007(replaced)X 3366(by)X 3494(the)X 3644("n-1")X 3882(rule)X 4064(for)X 720 3072(CRLFs.)N 720 3296(3.)N 844(The)X 1022(representation)X 1596(of)X 1704(a)X 1775(literal)X 2029("<")X 2189(character)X 2571(was)X 2748("")X 3017(in)X 3121 0.2356(text/richtext,)AX 3641(but)X 3793(is)X 3886("<<")X 4101(in)X 720 3408(text/enriched.)N 720 3632(4.)N 840(The)X 1014("no\256ll")X 1319(command)X 1723(did)X 1870(not)X 2017(exist)X 2223(in)X 2322 0.2356(text/richtext.)AX 720 3856(5.)N 840(The)X 1014("param")X 1357(command)X 1761(did)X 1908(not)X 2055(exist)X 2261(in)X 2360 0.2356(text/richtext.)AX 720 4080(6.)N 898(The)X 1130(following)X 1586(commands)X 2085(from)X 2354 0.2552(text/richtext)AX 2903(have)X 3167(been)X 3432(REMOVED)X 3989(from)X 720 4192 0.2404(text/enriched:)AN 1299(,)X 1969(,)X 2602(,)X 3528(,)X 720 4304(,)N 1414(,)X 2220(,)X 2839(,)X 3442(,)X 720 4416(,)N 1280(,)X 2015(,)X 2714(,)X 3162(,)X 3436(,)X 3720(and)X 3883(.)X 720 4640(7.)N 850(All)X 1007(claims)X 1293(of)X 1408(SGML)X 1709(compatibility)X 2259(have)X 2476(been)X 2693(dropped.)X 3091(However,)X 3502(with)X 3708(the)X 3861(possible)X 720 4752(exceptions)N 1163(of)X 1274(the)X 1423(new)X 1614(semantics)X 2025(for)X 2168(CRLF)X 2439(and)X 2609("<<")X 2826(can)X 2991(be)X 3113(implemented,)X 3672(text/enriched)X 720 4864(should)N 1000(be)X 1115(no)X 1235(less)X 1403(SGML-friendly)X 2030(than)X 2220 0.2552(text/richtext)AX 2711(was.)X 720 5088(8.)N 840(In)X 944 0.2356(text/richtext,)AX 1459(there)X 1676(were)X 1887(three)X 2104(commands)X 2545(\(,)X 2861(,)X 3139(and)X 3302(\))X 3584(that)X 3753(did)X 3900(not)X 4048(use)X 720 5200(balanced)N 1109(closing)X 1433(delimiters.)X 1937(Since)X 2196(all)X 2338(of)X 2463(these)X 2706(have)X 2933(been)X 3160(eliminated,)X 3637(there)X 3875(are)X 4038(NO)X 720 5312(exceptions)N 1156(to)X 1255(the)X 1397(nesting/balancing)X 2101(rules)X 2312(in)X 2411(text/enriched.)X 720 5536(9.)N 869(The)X 1072(limit)X 1308(on)X 1457(the)X 1628(size)X 1831(of)X 1964(formatting)X 2424(tokens)X 2728(has)X 2909(been)X 3144(increased)X 3561(from)X 3801(40)X 3951(to)X 4080(60)X 720 5648(characters.)N 720 6160(Borenstein)N 1161(-)X 1217(text/enriched)X 2071(Expires)X 2389(September)X 2825(1,)X 2921(1993)X 3869(Page)X 4080(12)X 13 p %%Page: 13 13 12 s 12 xH 0 xS 1 f 720 400(Borenstein)N 1844(A)X 1937(text/enriched)X 2465(type)X 2655(for)X 2791(MIME)X 3573(April)X 3800(1993)X 4016([13])X 3 f 14 s 1877 912(Table)N 2178(of)X 2300(Contents)X 1 f 12 s 768 1304(Status)N 1027(of)X 1131(this)X 1294(Memo)X 1560(....................................................................= ...................................)X 4128(1)X 768 1472(Abstract)N 1104(....................................................................= ......................................................)X 4128(1)X 768 1640(The)N 942(Text/enriched)X 1502(MIME)X 1787(type)X 1968(....................................................................= ..................)X 4128(1)X 768 1808(Formatting)N 1220(Commands)X 1680(....................................................................= ..............................)X 4128(3)X 912 1920(Font-Alteration)N 1535(Commands)X 1992(....................................................................= .................)X 4128(3)X 912 2032(Justi\256cation)N 1401(Commands)X 1848(....................................................................= .......................)X 4128(4)X 912 2144(Indentation)N 1375(Commands)X 1824(....................................................................= ........................)X 4128(4)X 912 2256(Miscellaneous)N 1492(Commands)X 1944(....................................................................= ...................)X 4128(5)X 912 2368(Balancing)N 1327(and)X 1490(Nesting)X 1813(of)X 1917(Formatting)X 2369(Commands...................................................)X 4128(5)X 912 2480(Unrecognized)N 1476(formatting)X 1907 0.0641(commands.....................................................= ..................)AX 4128(6)X 720 2648(6)N 4032(......)X 768 2816(Initial)N 1023(State)X 1240(of)X 1344(a)X 1411(text/enriched)X 1939(interpreter)X 2352(....................................................................= ..)X 4128(6)X 768 2984(Non-ASCII)N 1239(character)X 1617(sets)X 1776(....................................................................= ..........................)X 4128(7)X 768 3152(Minimal)N 1124(text/enriched)X 1652(conformance)X 2160(....................................................................= ..........)X 4128(7)X 768 3320(Notes)N 1016(for)X 1152(Implementors)X 1704(....................................................................= .............................)X 4128(7)X 768 3488(Extensions)N 1214(to)X 1313(text/enriched)X 1824(....................................................................= ........................)X 4128(8)X 768 3656(An)N 909(Example)X 1272(....................................................................= ...............................................)X 4128(8)X 768 3824 0.0457(Acknowledgements.........................................= ...............................................................)AN 4080(10)X 768 3992(Appendix)N 1171(A)X 1264(--)X 1352(A)X 1445(Simple)X 1742(enriched-to-plain)X 2430(Translator)X 2850(in)X 2949(C)X 3024(..........................................)X 4080(10)X 768 4160(Appendix)N 1171(B)X 1259(--)X 1347(Differences)X 1820(from)X 2031(RFC)X 2236(1341)X 2452 0.2552(text/richtext)AX 2928(..............................................)X 4080(12)X 720 6160(Borenstein)N 1161(-)X 1217(text/enriched)X 2071(Expires)X 2389(September)X 2825(1,)X 2921(1993)X 3869(Page)X 4080(13)X 13 p %%Trailer xt xs --Alternative.Boundary.YgVTkGa0M2UDAcojop Content-type: text/richtext; charset=US-ASCII Content-Transfer-Encoding: quoted-printable --Alternative.Boundary.YgVTkGa0M2UDAcojop Content-type: text/plain Content-Description: The ASCII version of the text/enriched draft Content-Transfer-Encoding: quoted-printable Network Working Group N. Borenstein, Bellcore Request for Comments: XXXX April 26, 1993 The text/enriched MIME Content-type Status of this Memo This RFC specifies an informational protocol for the Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Abstract MIME [RFC-1341, RFC-MIME] defines a format and general framework for the representation of a wide variety of data types in Internet mail. This document defines one particular type of MIME data, the text/enriched type, a refinement of the "text/richtext" type defined in RFC 1341. The text/enriched MIME type is intended to facilitate the wider interoperation of simple enriched text across a wide variety of hardware and software platforms. The Text/enriched MIME type In order to promote the wider interoperability of simple formatted text, this document defines an extremely simple subtype of the MIME content-type "text", the "text/enriched" subtype. This subtype was designed to meet the following criteria: 1. The syntax must be extremely simple to parse, so that even teletype-oriented mail systems can easily strip away the formatting information and leave only the readable text. 2. The syntax must be extensible to allow for new formatting commands that are deemed essential for some application. Borenstein - text/eExpires September 1, 1993 Page 1 Borenstein A text/enriched type for MIME April 1993 [2] 3. If the character set in use is ASCII or an 8- bit ASCII superset, then the raw form of the data must be readable enough to be largely unobjectionable in the event that it is displayed on the screen of the user of a non-MIME-conformant mail reader. 4. The capabilities must be extremely limited, to ensure that it can represent no more than is likely to be representable by the user's primary word processor. While this limits what can be sent, it increases the likelihood that what is sent can be properly displayed. This document defines a new MIME content-type, "text/enriched". The content-type line for this type may have one optional parameter, the "charset" parameter, with the same values permitted for the "text/plain" MIME content-type. The syntax of "text/enriched" is very simple. It represents text in a single character set -- US-ASCII by default, although a different character set can be specified by the use of the "charset" parameter. (The semantics of text/enriched in non-ASCII character sets are discussed later in this document.) All characters represent themselves, with the exception of the "<" character (ASCII 60), which is used to mark the beginning of a formatting command. Formatting instructions consist of formatting commands surrounded by angle brackets ("<>", ASCII 60 and 62). Each formatting command may be no more than 60 characters in length, all in US-ASCII, restricted to the alphanumeric and hyphen ("-") characters. Formatting commands may be preceded by a solidus ("/", ASCII 47), making them negations, and such negations must always exist to balance the initial opening commands. Thus, if the formatting command "" appears at some point, there must later be a "" to balance it. (NOTE: The 60 character limit on formatting commands does NOT include the "<", ">", or "/" characters that might be attached to such commands.) Formatting commands are always case-insensitive. That is, "bold" and "BoLd" are equivalent in effect, if not in good taste. Borenstein - text/eExpires September 1, 1993 Page 2 Borenstein A text/enriched type for MIME April 1993 [3] Beyond tokens delimited by "<" and ">", there are two other special processing rules. First, a literal less-than sign ("<") can be represented by a sequence of two such characters, "<<". Second, line breaks (CRLF pairs in standard network representation) are handled specially. In particular, isolated CRLF pairs are translated into a single SPACE character. Sequences of N consecutive CRLF pairs, however, are translated into N-1 actual line breaks. This permits long lines of data to be represented in a natural- looking manner despite the frequency of line-wrapping in Internet mailers. When preparing the data for mail transport, isolated line breaks should be inserted wherever necessary to keep each line shorter than 80 characters. When preparing such data for presentation to the user, isolated line breaks should be replaced by a single SPACE character, and N consecutive CRLF pairs should be presented to the user as N-1 line breaks. Thus text/enriched data that looks like this: This is a single line This is the next line. This is the next paragraph. should be displayed by a text/enriched interpreter as follows: This is a single line This is the next line. This is the next paragraph. The formatting commands, not all of which will be implemented by all implementations, are described in the following sections. Formatting Commands The text/enriched formatting commands all begin with Borenstein - text/eExpires September 1, 1993 Page 3 Borenstein A text/enriched type for MIME April 1993 [4] and end with , affecting the formatting of the text between those two tokens. The commands are described here, grouped according to type. Font-Alteration Commands The following formatting commands are intended to alter the font in which text is displayed, but not to alter the indentation or justification state of the text: Bold -- causes the affected text to be in a bold font. Nested bold commands have the same effect as a single bold command. Italic -- causes the affected text to be in an italic font. Nested italic commands have the same effect as a single italic command. Fixed -- causes the affected text to be in a fixed width font. Nested fixed commands have the same effect as a single fixed command. Smaller -- causes the affected text to be in a smaller font. It is recommended that the font size be changed by two points, but other amounts may be more appropriate in some environments. Nested smaller commands produce ever-smaller fonts, to the limits of the implementation's capacity to reasonably display them, after which further smaller commands have no incremental effect. Bigger -- causes the affected text to be in a bigger font. It is recommended that the font size be changed by two points, but other amounts may be more appropriate in some environments. Nested bigger commands produce ever-bigger fonts, to the limits of the implementation's capacity to reasonably display them, after which further bigger commands have no incremental effect. Underline -- causes the affected text to be underlined. Nested underline commands have the same effect as a single underline command. While the "bigger" and "smaller" operators are effectively inverses, it is not recommended, for example, that "" be used to end the effect of "". This is properly done with "". Justification Commands Borenstein - text/eExpires September 1, 1993 Page 4 Borenstein A text/enriched type for MIME April 1993 [5] Initially, text/enriched text is intended to be displayed fully-justified with appropriate fill, kerning, and letter- tracking as suits the capabilities of the receiving user agent software. Actual line width is left to the discretion of the receiver, which is expected to fold lines intelligently (preferring soft line breaks) to the best of its ability. The following commands alter that state. Each of these commands force a line break before and after the formatting command if there is not otherwise a line break. For example, if one of these commands occurs anywhere other than the beginning of a line of text as presented, a new line is begun. Center -- causes the affected text to be centered. FlushLeft -- causes the affected text to be left- justified with a ragged right margin. FlushRight -- causes the affected text to be right- justified with a ragged left margin. The center, flushleft, and flushright commands are mutually exclusive, and, when nested, the inner command takes precedence. Note that for some non-ASCII character sets, full justification may be inappropriate. In these cases, a user agent may choose not to justify such data. Indentation Commands Initially, text/enriched text is displayed using the maximum available margins. Two formatting commands may be used to affect the margins. Indent -- causes the running left margin to be moved to the right. The recommended indentation change is the width of four characters, but this may differ among implementations. IndentRight -- causes the running right margin to be moved to the left. The recommended indentation change is the width of four characters, but this may differ among implementations. A line break is NOT forced by a change of the margin, to permit the description of "hanging" text. Thus for example Borenstein - text/eExpires September 1, 1993 Page 5 Borenstein A text/enriched type for MIME April 1993 [6] the following text: Now is the time for all good horses to come to the aid of their stable, assuming that any stable is really stable. would be displayed in a 40-character-wide window as follows: Now is the time for all good horses to come to the aid of their stable, assuming that any stable is really stable. Miscellaneous Commands Excerpt -- causes the affected text to be interpreted as a textual excerpt from another source, probably a message being responded to. Typically this will be displayed using indentation and an alternate font, or by indenting lines and preceding them with "> ", but such decisions are up to the implementation. (Note that this is the only truly declarative markup construct in text/enriched, and as such doesn't fit very well with the other facilities, but it describes a type of markup that is very commonly used in email and has no procedural analogue.) Note that as with the justification commands, the excerpt command implicitly begins and ends with a line break if one is not already there. Nofill -- causes the affected text to be displayed without filling or justification, and hence without any special handling of CRLFs, but with all remaining text/enriched features continuing to apply. Param -- Marks the affected text as command parameters, to be interpreted or ignored by the text/enriched interpreter, but NOT to be shown to the reader. Balancing and Nesting of Formatting Commands Pairs of formatting commands must be properly balanced and nested. Thus, a proper way to describe text in bold italics is: Borenstein - text/eExpires September 1, 1993 Page 6 Borenstein A text/enriched type for MIME April 1993 [7] the-text or, alternately, the-text but, in particular, the following is illegal text/enriched: the-text The nesting requirement for formatting commands imposes a slightly higher burden upon the composers of text/enriched bodies, but potentially simplifies text/enriched displayers by allowing them to be stack-based. The main goal of text/enriched is to be simple enough to make multifont, formatted email widely readable, so that those with the capability of sending it will be able to do so with confidence. Thus slightly increased complexity in the composing software was deemed a reasonable tradeoff for simplified reading software. Nonetheless, implementors of text/enriched readers are encouraged to follow the general Internet guidelines of being conservative in what you send and liberal in what you accept. Those implementations that can do so are encouraged to deal reasonably with improperly nested text/enriched data. Unrecognized formatting commands Implementations must regard any unrecognized formatting command as "no-op" commands, that is, as commands having no effect, thus facilitating future extensions to "text/enriched". Private extensions may be defined using formatting commands that begin with "X-", by analogy to Internet mail header field names. In order to formally define extended commands, a new Internet document should be published. "White Space" in Text/enriched Data No special behavior is required for the SPACE or TAB (HT) character. It is recommended, however, that, at least when fixed-width fonts are in use, the common semantics of the TAB (HT) character should be observed, namely that it moves Borenstein - text/eExpires September 1, 1993 Page 7 Borenstein A text/enriched type for MIME April 1993 [8] to the next column position that is a multiple of 8. (In other words, if a TAB (HT) occurs in column n, where the leftmost column is column 0, then that TAB (HT) should be replaced by 8-(n mod 8) SPACE characters.) It should also be noted that some mail gateways are notorious for losing (or, less commonly, adding) white space at the end of lines, so reliance on SPACE or TAB characters at the end of a line is not recommended. Initial State of a text/enriched interpreter Text/enriched is assumed to begin with filled, fully justified text in a variable-width font in a normal typeface and a size that is average for the current display and user. The left and right margins are assumed to be maximal, that is, at the leftmost and rightmost acceptable positions. Non-ASCII character sets If the character set specified by the charset parameter on the Content-type line is anything other than "US-ASCII", this means that the text being described by text/enriched formatting commands is in a non-ASCII character set. However, the commands themselves are still the same ASCII commands that are defined in this document. This creates an ambiguity only with reference to the "<" character, the octet with numeric value 60. In single byte character sets, such as the ISO-8859 family, this is not a problem; the octet 60 can be quoted by including it twice, just as for ASCII. The problem is more complicated, however, in the case of multi-byte character sets, where the octet 60 might appear at any point in the byte sequence for any of several characters. In practice, however, most multibyte character sets address this problem internally. For example, the ISO-2022 family of character sets can switch back into ASCII at any moment. Therefore it is specified that, before text/enriched formatting commands, the prevailing character set should be "switched back" into ASCII, and that only those characters which would be interpreted as "<" in plain text should be interpreted as token delimiters in text/enriched. Borenstein - text/eExpires September 1, 1993 Page 8 Borenstein A text/enriched type for MIME April 1993 [9] The question of what to do for hypothetical future character sets that do NOT subsume ASCII is not addressed in this memo. Minimal text/enriched conformance A minimal text/enriched implementation is one that converts "<<" to "<", removes everything between a command and the next balancing command, removes all other formatting commands (all text enclosed in angle brackets), converts any series of n CRLFs to n-1 CRLFs, and converts any lone CRLF pairs to SPACE. Notes for Implementors It is recognized that implementors of future mail systems will want rich text functionality far beyond that currently defined for text/enriched. The intent of text/enriched is to provide a common format for expressing that functionality in a form in which much of it, at least, will be understood by interoperating software. Thus, in particular, software with a richer notion of formatted text than text/enriched can still use text/enriched as its basic representation, but can extend it with new formatting commands and by hiding information specific to that software system in text/enriched constructs. As such systems evolve, it is expected that the definition of text/enriched will be further refined by future published specifications, but text/enriched as defined here provides a platform on which evolutionary refinements can be based. An expected common way that sophisticated mail programs will generate text/enriched data is as part of a multipart/alternative construct. For example, a mail agent that can generate enriched mail in ODA format can generate that mail in a more widely interoperable form by generating both text/enriched and ODA versions of the same data, e.g.: Content-type: multipart/alternative; boundary=3Dfoo --foo Content-type: text/enriched Borenstein - text/eExpires September 1, 1993 Page 9 Borenstein A text/enriched type for MIME April 1993 [10] [text/enriched version of data] --foo Content-type: application/oda [ODA version of data] --foo-- If such a message is read using a MIME-conformant mail reader that understands ODA, the ODA version will be displayed; otherwise, the text/enriched version will be shown. In some environments, it might be impossible to combine certain text/enriched formatting commands, whereas in others they might be combined easily. For example, the combination of and might produce bold italics on systems that support such fonts, but there exist systems that can make text bold or italicized, but not both. In such cases, the most recently issued (innermost) recognized formatting command should be preferred. One of the major goals in the design of text/enriched was to make it so simple that even text-only mailers will implement enriched-to-plain-text translators, thus increasing the likelihood that enriched text will become "safe" to use very widely. To demonstrate this simplicity, an extremely simple C program that converts text/enriched input into plain text output is included in Appendix A. Extensions to text/enriched It is expected that various mail system authors will desire extensions to text/enriched. The simple syntax of text/enriched, and the specification that unrecognized formatting commands should simply be ignored, are intend to promote such extensions. Beyond simply defining new formatting commands, however, it may sometimes be necessary to define formatting commands that can take arguments. This is the intended use of the construct. In particular, software that wished to extend text/enriched to include colored text might define an "x-color" environment which always began with a color name parameter, to indicate the desired color for the affected Borenstein - text/eExpires September 1, 1993 Page 10 Borenstein A text/enriched type for MIME April 1993 [11] text. An Example Putting all this together, the following "text/enriched" body fragment: From: Nathaniel Borenstein To: Ned Freed Content-type: text/enriched Now is the time for all good men (and <) to come to the aid of their redbeloved country. By the way, I think that should REALLY be called and that I am always right. -- the end represents the following formatted text (which will, no doubt, look somewhat cryptic in the text-only version of this document): Now is the time for all good men (and ) to come to the aid of their beloved country. By the way, I think that should REALLY be called Borenstein - text/eExpires September 1, 1993 Page 11 Borenstein A text/enriched type for MIME April 1993 [12] and that I am always right. -- the end where the word "beloved" would be in red on a color display if the receiving software implemented the "x-color" extension. Security Considerations Security issues are not discussed in this memo, as the mechanism raises no security issues. Author's Address For more information, the author of this document may be contacted via Internet mail: Nathaniel S. Borenstein MRE 2D-296, Bellcore 445 South St. Morristown, NJ 07962-1910 Phone: +1 201 829 4270 Fax: +1 201 829 5963 Email: nsb@bellcore.com Acknowledgements This document reflects the input of many contributors, readers, and implementors of the original MIME specification, RFC 1341. The current draft also reflects particular contributions and comments from Terry Crowley and Rhys Weatherley. References [RFC-1341] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1341, June, 1992. [RFC-MIME] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Borenstein - text/eExpires September 1, 1993 Page 12 Borenstein A text/enriched type for MIME April 1993 [13] Internet Message Bodies", RFC ********, *****, 1993. Appendix A -- A Simple enriched-to-plain Translator in C One of the major goals in the design of the text/enriched subtype of the text Content-Type is to make formatted text so simple that even text-only mailers will implement enriched-to-plain-text translators, thus increasing the likelihood that multifont text will become "safe" to use very widely. To demonstrate this simplicity, what follows is a simple C program that converts text/enriched input into plain text output. Note that the local newline convention (the single character represented by "\n") is assumed by this program, but that special CRLF handling might be necessary on some systems.. #include #include main() { int c, i, paramct=3D0, newlinect=3D0, nofill=3D0; char token[62], *p; while ((c=3Dgetc(stdin)) !=3D EOF) { if (c =3D=3D '<') { newlinect=3D0; c =3D getc(stdin); if (c =3D=3D '<') { if (paramct <=3D 0) putc(c, stdout); } else { ungetc(c, stdin); for (i=3D0, p=3Dtoken; (c=3Dgetc(stdin= )) !=3D EOF && c !=3D '>'; i++) { if (i < sizeof(token)-1) *p++ =3D isupper(c) ? tolower(c) : c; } *p =3D '\0'; if (c =3D=3D EOF) break; if (strcmp(token, "param") =3D=3D 0) paramct++; else if (strcmp(token, "nofill") =3D=3D= 0) nofill++; Borenstein - text/eExpires September 1, 1993 Page 13 Borenstein A text/enriched type for MIME April 1993 [14] else if (strcmp(token, "/param") =3D=3D= 0) paramct--; else if (strcmp(token, "/nofill") =3D=3D= 0) nofill--; } } else { if (paramct > 0) ; /* ignore params */ else if (c =3D=3D '\n' && nofill <=3D 0) if (++newlinect > 1) { putc(c, stdout); } else { putc(' ', stdout); } else { newlinect =3D 0; putc(c, stdout); } } } /* The following line is only needed with line- buffering */ putc('\n', stdout); exit(0); } lc2strncmp(s1, s2, len) char *s1, *s2; int len; { if (!s1 || !s2) return (-1); while (*s1 && *s2 && len > 0) { if (*s1 !=3D *s2 && (tolower(*s1) !=3D *s2)) return= (- 1); ++s1; ++s2; --len; } if (len <=3D 0) return(0); return((*s1 =3D=3D *s2) ? 0 : -1); } It should be noted that one can do considerably better than this in displaying text/enriched data on a dumb terminal. In particular, one can replace font information such as "bold" with textual emphasis (like *this* or _T_H_I_S_). Borenstein - text/eExpires September 1, 1993 Page 14 Borenstein A text/enriched type for MIME April 1993 [15] One can also properly handle the text/enriched formatting commands regarding indentation, justification, and others. However, the above program is all that is necessary in order to present text/enriched on a dumb terminal without showing the user any formatting artifacts. Appendix B -- Differences from RFC 1341 text/richtext Text/enriched is a clarification, simplification, and refinement of the type defined as text/richtext in RFC 1341. For the benefit of those who are already familiar with text/richtext, or for those who want to exploit the similarities to be able to display text/richtext data with their text/enriched software, the differences between the two are summarized here. Note, however, that text/enriched is intended to make text/richtext obsolete, so it is not recommended that new software generate text/richtext. 0. The name "richtext" was changed to "enriched", both to differentiate the two versions and because "richtext" created widespread confusion with Microsoft's Rich Text Format (RTF). 1. Clarifications. Many things were ambiguous or unspecified in the text/richtext definition, particularly the initial state and the semantics of richtext with multibyte character sets. However, such differences are OPERATIONALLY irrelevant, since the clarifications offered in this document are at least reasonable interpretations of the text/richtext specification. 2. Newline semantics have changed. In text/richtext, all CRLFs were mapped to spaces, and line breaks were indicated by "". This has been replaced by the "n-1" rule for CRLFs. 3. The representation of a literal "<" character was "" in text/richtext, but is "<<" in text/enriched. 4. The "nofill" command did not exist in text/richtext. 5. The "param" command did not exist in text/richtext. 6. The following commands from text/richtext have been REMOVED from text/enriched: , , , , , , Borenstein - text/eExpires September 1, 1993 Page 15 Borenstein A text/enriched type for MIME April 1993 [16] , , , , , , , , , and . 7. All claims of SGML compatibility have been dropped. However, with the possible exceptions of the new semantics for CRLF and "<<" can be implemented, text/enriched should be no less SGML-friendly than text/richtext was. 8. In text/richtext, there were three commands (, , and ) that did not use balanced closing delimiters. Since all of these have been eliminated, there are NO exceptions to the nesting/balancing rules in text/enriched. 9. The limit on the size of formatting tokens has been increased from 40 to 60 characters. Borenstein - text/eExpires September 1, 1993 Page 16 Borenstein A text/enriched type for MIME April 1993 [17] Table of Contents Status of this Memo..................................... 1 Abstract................................................ 1 The Text/enriched MIME type............................. 1 Formatting Commands..................................... 3 Font-Alteration Commands.......................... 4 Justification Commands............................ 4 Indentation Commands.............................. 5 Miscellaneous Commands............................ 6 Balancing and Nesting of Formatting Commands...... 6 Unrecognized formatting commands.................. 7 7 ... Initial State of a text/enriched interpreter............ 8 Non-ASCII character sets................................ 8 Minimal text/enriched conformance....................... 9 Notes for Implementors.................................. 9 Extensions to text/enriched............................. 10 An Example.............................................. 11 Acknowledgements........................................ 12 Appendix A -- A Simple enriched-to-plain Translator in C...1= 3 Appendix B -- Differences from RFC 1341 text/richtext... 15 Borenstein - text/eExpires September 1, 1993 Page 17 --Alternative.Boundary.YgVTkGa0M2UDAcojop Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable --Alternative.Boundary.YgVTkGa0M2UDAcojop-- --Interpart.Boundary.YgVTkGa0M2UDIcojtR--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08158; 2 Sep 93 12:00 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08154; 2 Sep 93 12:00 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa20063; 2 Sep 93 12:00 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04123; Thu, 2 Sep 93 11:37:48 EDT Received: from ppp.dbc.mtview.ca.us by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04117; Thu, 2 Sep 93 11:37:45 EDT Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA15667; Thu, 2 Sep 93 08:35:16 -0700 To: CHRIS R BARTRAM Reply-To: ietf-822@dimacs.rutgers.edu Cc: ietf-822@dimacs.rutgers.edu Subject: Re: Re[2]: Simple Network Paging Protocol In-Reply-To: Your message of "Thu, 02 Sep 1993 09:38:34 EDT." <000XH4@KIRK.UII.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <15661.746984109.1@dbc.mtview.ca.us> Date: Thu, 02 Sep 1993 08:35:10 -0700 Message-Id: <15664.746984110@dbc.mtview.ca.us> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Marshall Rose Right. In effect, there are two issues: 1. Which server you select to send the page. My answer: DNS 2. How you send the page to the server. My answer: SMTP /mtr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08479; 2 Sep 93 12:33 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08475; 2 Sep 93 12:33 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa21386; 2 Sep 93 12:33 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04615; Thu, 2 Sep 93 12:20:30 EDT Received: from venera.isi.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04611; Thu, 2 Sep 93 12:20:28 EDT Received: from btn.isi.edu by venera.isi.edu (5.65c/5.61+local-13) id ; Thu, 2 Sep 1993 09:20:16 -0700 Date: Thu, 2 Sep 93 09:20:13 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: touch@isi.edu Posted-Date: Thu, 2 Sep 93 09:20:13 -0700 Message-Id: <9309021620.AA03664@btn.isi.edu> Received: by btn.isi.edu (NX5.67c/4.0.3-4) id ; Thu, 2 Sep 93 09:20:13 -0700 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) To: "Harald T. Alvestrand" Subject: Re: standards/suggestions for MIME transport of PC filetypes? Cc: Ned Freed , Rick Troth , CHRIS R BARTRAM , mmm-people@isi.edu, ietf-822@dimacs.rutgers.edu > From: "Harald T. Alvestrand" > > FrameMaker suggests using .doc as the standard file type for > Frame documents. > > Harald A > Well, even FrameMaker isn't consistent within itself. .doc is standard for the SunOS version. .frame is the standard for the NeXT version There is no extension attached for the MacOS version. Note that the binaries are interoperable, i.e., to open a .frame on SunOS, no conversion is required, only renaming to .doc. Joe Touch touch@isi.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08855; 2 Sep 93 13:00 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08851; 2 Sep 93 13:00 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa22465; 2 Sep 93 13:00 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04610; Thu, 2 Sep 93 12:20:27 EDT Received: from [192.105.32.2] by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04605; Thu, 2 Sep 93 12:20:23 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: CHRIS R BARTRAM Message-Id: <000XHR@KIRK.UII.COM> X-Mailer: NetMail/3000 [Version A.04 93/06/12] Mime-Version: 1.0 Content-Type: text/plain Date: Thu, 2 Sep 1993 12:17:39 -0400 X-Hpdesk-Priority: 3 (Normal Priority) Subject: Re[2]: standards/suggestions for MIME transport of PC filetypes? To: Harald.T.Alvestrand@uninett.no, ietf-822@dimacs.rutgers.edu, mmm-people@isi.edu In <9309020758.AA16109@daffy.uii.com> "Harald T. Alvestrand" writes: > FrameMaker suggests using .doc as the standard file type for > Frame documents. Since I started this thread, I'll add that a strictly pc extension scheme is not a viable solution for us. Our e-mail system runs on HP3000 minicomputer systems, where the "extension" portion of a name (i.e. ".doc") would be interpreted as a group (directory level). Since emulators talking to our package run in DOS, WINDOWS, OS/2, Unix, and on Macs, file extensions by themselves don't mean much (in a general case). What we ARE doing, is adopting a scheme which will utilize a standardized table of types and mappable applications (per platform) which a user can easily extend. We'll be using supported (and in cases hope to register new MIME types/subtypes where it makes sense), but will also as a last resort attempt to map "extensions" on application/octet types to appropriate applications on some platforms -- not a perfect solution, and it obviously won't work in many cases, but it does allow us to progress with registering valid MIME types and still have a workable solution that will work with some of the other implementations I've seen out there. At least a "guess" for otherwise generic attachments is a step ahead of just forcing the user to try and figure it out (of course, you have to give them the option of overriding the "guess"). (We are also using an experimental X-subtype for HP3000 files which allows us to identify those that have unique (non-portable) attributes not otherwise representable via the content-type headers, so we KNOW not to try and handle them as PC (or other platform) files. We plan to register the format and subtype at a later date, along with an RFC describing the format.) I think this works within the design and intention of MIME -- it provides the functionality we desire without changing the structure of MIME. -Chris Bartram   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09237; 2 Sep 93 13:30 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09233; 2 Sep 93 13:30 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa23624; 2 Sep 93 13:30 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04694; Thu, 2 Sep 93 12:41:44 EDT Received: from uxc.cso.uiuc.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04690; Thu, 2 Sep 93 12:41:42 EDT Received: from dorner.slip.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA25400 (5.67a/IDA-1.5 for ); Thu, 2 Sep 1993 11:41:07 -0500 Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA06142 (5.65c/IDA-1.4.4 for jgm+@cmu.edu); Thu, 2 Sep 1993 11:41:23 -0500 Message-Id: <199309021641.AA06142@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 2 Sep 1993 11:41:46 -0500 To: Nathaniel Borenstein , ietf-822@dimacs.rutgers.edu, Rick Troth , John Gardiner Myers Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Dorner Subject: Re: text/enriched: Throwing in the towel At 9:58 AM 9/2/93 -0400, Nathaniel Borenstein wrote: > Text/enriched is assumed to begin with filled, fully > justified text I suppose that at this stage of the game I would be shot if I suggested that fully justified text, absent a very good hyphenation algorithm and language-specific database, is less legible than ragged right, and so should NOT be the default? -- Steve Dorner, Qualcomm Inc.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09751; 2 Sep 93 14:00 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09747; 2 Sep 93 14:00 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa24867; 2 Sep 93 14:00 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07181; Thu, 2 Sep 93 13:13:56 EDT Received: from eco.twg.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07177; Thu, 2 Sep 93 13:13:54 EDT Received: from LOCAL.eco.twg.com by eco.twg.com (5.67/ECO.m-$Revision: 2.16 $) id AA25836; Thu, 2 Sep 93 13:13:57 -0400 Message-Id: <9309021713.AA25836@eco.twg.com> Received: from apache.twg.com by apache.twg.com id <2795-0@apache.twg.com>; Thu, 2 Sep 1993 10:13:46 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: David Herron Subject: Re: Simple Network Paging Protocol To: IPM Return Requested Date: Thu, 2 Sep 93 10:13:43 PDT In-Reply-To: Your message of Wed, 01 Sep 1993 20:23:21 -0700.<9057.746940201@dbc.mtview.ca.us> Sensitivity: Personal Conversion: Prohibited Conversion-With-Loss: Prohibited Encoding: 1 TEXT How does SNPP compare with what the Radio Mail people are doing?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10165; 2 Sep 93 14:24 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10161; 2 Sep 93 14:24 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa25725; 2 Sep 93 14:24 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04843; Thu, 2 Sep 93 12:58:02 EDT Received: from [192.127.251.3] by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04814; Thu, 2 Sep 93 12:57:17 EDT Received: from ciss by ncrhub1.NCR.COM id aa07545; 2 Sep 93 2:17 EDT Date: 2 Sep 93 02:13:13 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: MAILER-DAEMON@ciss.daytonoh.ncr.com Subject: Returned mail To: ietf-822@dimacs.rutgers.edu Message-Id: <9309020217.aa07545@ncrhub1.NCR.COM> Your mail could not be delivered because of the following reason: ----- Transcript of session follows ----- The name 'tom.moore' is similar to the following name. Consider resending your message using it. Address: thomas.j.moore@DaytonOH.NCR.COM Department: U.S. Group dayton Office ----- Unsent message follows ----- From dimacs.rutgers.edu!ietf-822 Thu Sep 2 02:13:16 1993 remote from ncrhub1 Received: from ncrgw1 by ncrhub1.NCR.COM id ac07465; 2 Sep 93 2:12 EDT Received: by ncrgw1.NCR.COM; 2 Sep 93 02:11:46 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29274; Wed, 1 Sep 93 23:07:29 EDT Received: from ppp.dbc.mtview.ca.us by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29270; Wed, 1 Sep 93 23:07:26 EDT Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA08885; Wed, 1 Sep 93 20:06:04 -0700 To: Dave Crocker Cc: rens@imsi.com, Allen Gwinn , ietf-822@dimacs.rutgers.edu Reply-To: ietf-822@dimacs.rutgers.edu Subject: Re: Simple Network Paging Protocol In-Reply-To: Your message of "Wed, 01 Sep 1993 18:54:07 PDT." <9309020154.AA20887@Mordor.Stanford.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <8882.746939161.1@dbc.mtview.ca.us> Date: Wed, 01 Sep 1993 20:06:02 -0700 Message-Id: <8884.746939162@dbc.mtview.ca.us> From: Marshall Rose Ok, I'll ask the obvious question then. Why can't you do this with SMTP? Specifically, if you want to send a page: 1. Construct an e-mail message addressed to "pager@n.u.m.b.e.r.suffix", e.g., you want to page +1-415-555-1234, address it to pager@4.3.2.1.5.5.5.5.1.4.1.page.net 2. Put the "text of the page" in the body of the message 3. Send it as a regular e-mail message and let the DNS route it using MXs. Right now, we do this for facsimile transmissions in the Internet. If I want to fax to +1-415-968-2510, I send to remote-printer.marshall_rose@0.1.5.2.8.6.9.5.1.4.1.tpc.int The pager case is even simpler cause a pager is (usually) carried by one person. So, how to make this work: 1. Get someone to apply for, and then manage in a fair-and-open manner, a high-level domain. 2. Tell the pager providers that if they had an SMTP connectivity to the Internet, then they could get pages that way. /mtr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10262; 2 Sep 93 14:30 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10257; 2 Sep 93 14:30 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa26027; 2 Sep 93 14:30 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07171; Thu, 2 Sep 93 13:12:40 EDT Received: from eco.twg.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07167; Thu, 2 Sep 93 13:12:37 EDT Received: from LOCAL.eco.twg.com by eco.twg.com (5.67/ECO.m-$Revision: 2.16 $) id AA25816; Thu, 2 Sep 93 13:12:55 -0400 Message-Id: <9309021712.AA25816@eco.twg.com> Received: from apache.twg.com by apache.twg.com id <2544-0@apache.twg.com>; Thu, 2 Sep 1993 10:10:28 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: David Herron Subject: Re: Simple Network Paging Protocol To: IPM Return Requested Cc: IPM Return Requested Date: Thu, 2 Sep 93 10:10:24 PDT In-Reply-To: Your message of Wed, 01 Sep 1993 23:19:59 -0400.<9309020320.AA00915@thud.cs.utk.edu> Sensitivity: Personal Conversion: Prohibited Conversion-With-Loss: Prohibited Encoding: 54 TEXT , 4 TEXT My take... There is already a widely available *and* working infrastructure which carries store-and-forward traffic. That is.. E-Mail. So like there's an Experiment in "Remote Printing" going on there could be an experiment in "Remote Paging". Rather.. The fact that it is a pager message would be a side effect of the address it is sent to. At the `delivery' point it might be sent into a little queuing system which used an SNPP-like protocol to get through the final hop into the pager. For SNPP to succeed it would have to create a parallel infrastructure which does `store-and-forward'. Moving on to general issues.. E-Mail isn't the only sort of store and forward activity around. On Bitnet they make much use of unsolicited file transfer (rather than the recipient having to request a file, the sender can send a file) which could be usefully implemented in SaF style. Then there are messages of the type meant to be carried by SEND/SAML/SOML. Also real honest-to-goodness print queuing (with named printers, paper attributes like page length & width, request postscript or HPGL, etc) should be in SaF style. This is what comes to mind after a moments thought. With enough different application areas needing an SaF infrastructure perhaps it is worthwhile creating a new general purpose SaF protocol. One to which could be added new SaF applications as needed. Which had some management abilities so one might be able to find out which spooling site has their print job/mail message/etc and perhaps cancel it or see what is holding it up. SaF application areas named above: E-Mail, Unsolicited file transfer (perhaps also solicited file transfer), SNPP, SEND/SAML/SOML, print queuing. If done right it could be transferrable in a half duplex fashion like BSMTP. And reach into places which can't to IP (bitnet, UUCP, etc). All these application areas can be layered on top of E-Mail. Especially with good choices of MIME body part types. So it might not be worth the trouble to invent a new SaF infrastructure. On the other hand maybe there is a user perception problem .. if it is transferred using `e-mail' then isn't it e-mail? How can it be e-mail but something that's not e-mail? Or is that part of the purpose in the remote printing experiment? To show that e-mail can be a general SaF transport protocol? About the only idea above I'd like to see developed more is the management aspect. Users are *frequently* asking to be able to cancel messages that are in transport. Or to find out what's holding up their e-mail. Or... If E-Mail is used for other application areas then the requests will increase. Most print queuing systems include an ability to look and see where your print job is, cancel it, see what's holding it up, etc. <- David Herron (work) (home) <- <- All hard work brings a profit, but mere talk leads only to poverty. <- Proverbs 14:23   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10774; 2 Sep 93 15:00 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10770; 2 Sep 93 15:00 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa27156; 2 Sep 93 15:00 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07516; Thu, 2 Sep 93 14:06:58 EDT Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07512; Thu, 2 Sep 93 14:06:57 EDT Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA09975; Thu, 2 Sep 93 11:06:47 -0700 Message-Id: <9309021806.AA09975@Mordor.Stanford.EDU> To: Steve Dorner Cc: Nathaniel Borenstein , ietf-822@dimacs.rutgers.edu, Rick Troth , John Gardiner Myers Subject: Re: text/enriched: Throwing in the towel Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Thu, 02 Sep 93 11:41:46 -0500. <199309021641.AA06142@dorner.slip.uiuc.edu> Date: Thu, 02 Sep 93 11:06:47 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Crocker X-Mts: smtp ---- Included message: At 9:58 AM 9/2/93 -0400, Nathaniel Borenstein wrote: > Text/enriched is assumed to begin with filled, fully > justified text I suppose that at this stage of the game I would be shot if I suggested that fully justified text, absent a very good hyphenation algorithm and language-specific database, is less legible than ragged right, and so should NOT be the default? Ignoring the usual loss of rights-to-comment that accrue (i.e., don't accrue) to someone who has been studiously ignoring this thread, I want to underscore Steve's point with another one: fixed-width text is LESS readable when left/right justified. Ragged is considerably easier to read. d/   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11267; 2 Sep 93 15:31 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11263; 2 Sep 93 15:31 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa28454; 2 Sep 93 15:31 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07530; Thu, 2 Sep 93 14:09:26 EDT Received: from qualcomm.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07526; Thu, 2 Sep 93 14:09:24 EDT Received: from middleearth.qualcomm.com by qualcomm.com; id AA08359 sendmail 5.65/QC-main-2.1 via SMTP Thu, 2 Sep 93 11:09:16 -0700 for ietf-822@dimacs.rutgers.edu Message-Id: <9309021809.AA08359@qualcomm.com> X-Sender: jwn2@wizard.qualcomm.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 2 Sep 1993 11:09:17 -0700 To: ietf-822@dimacs.rutgers.edu, CHRIS R BARTRAM Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Noerenberg Subject: Re: Re[2]: Simple Network Paging Protocol Cc: ietf-822@dimacs.rutgers.edu At 8:35 AM 9/2/93 -0700, Marshall Rose wrote: >Right. In effect, there are two issues: > >1. Which server you select to send the page. My answer: DNS > >2. How you send the page to the server. My answer: SMTP > SMTP works fine for us at QUALCOMM. One of our network engineers cooked up a server that responds to email messages such as: ----------------------- to: pager subject: username 555-1212 ----------------------- If you know someone has an alpha pager (info which is in our PH database), you can send more elaborate messages. john noerenberg jwn2@qualcomm.com noerenberg.j (Applelink) ====================================================================== Keep Ithaka always in your mind. Arriving there is what you are destined for. -- Ithaka, Constantine Peter Cavafy [1911] ======================================================================   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12151; 2 Sep 93 15:55 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12145; 2 Sep 93 15:55 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa29495; 2 Sep 93 15:55 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07715; Thu, 2 Sep 93 14:48:02 EDT Received: from rutvm1.rutgers.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07711; Thu, 2 Sep 93 14:48:02 EDT Message-Id: <9309021848.AA07711@dimacs.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RUTVM1.RUTGERS.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 5055; Thu, 02 Sep 93 14:46:55 EDT Received: from RICEVM1.RICE.EDU (NJE origin MAILER@RICEVM1) by RUTVM1.RUTGERS.EDU (LMail V1.1d/1.7f) with BSMTP id 4336; Thu, 2 Sep 1993 14:46:54 -0400 Received: from ricevm1.rice.edu (NJE origin TROTH@RICEVM1) by RICEVM1.RICE.EDU (LMail V1.1d/1.7f) with BSMTP id 9167; Thu, 2 Sep 1993 13:47:12 -0500 Mime-Version: 1.0 Content-Type: text/plain Date: Thu, 02 Sep 93 13:42:31 CDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Rick Troth Subject: Re: text/enriched To: John Gardiner Myers Cc: ietf-822@dimacs.rutgers.edu In-Reply-To: Your message of Thu, 2 Sep 1993 00:35:55 -0400 (EDT) ><< is a special case, however it is a special case of the same >magnitude as . The change doesn't introduce "special case" logic, >it just trades one set of logic for another. It hits my parser in a completely different way that does require "special case" logic. Everywhere else I can "look between the angle brackets", but here I have to explicitly look for an immediate following second open angle bracket, and if it's there I must NOT look for a close. And along this line, I'd just as soon require that > be coded as , but I suppose that wouldn't fly with anyone either. :-( To avoid rehashing the olde argument, I won't say anything about cosmetics being totally unimportant to processable text. -- Rick Troth , Rice University, Information Systems   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12523; 2 Sep 93 16:15 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12519; 2 Sep 93 16:15 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa00468; 2 Sep 93 16:15 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08347; Thu, 2 Sep 93 15:44:44 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08343; Thu, 2 Sep 93 15:44:43 EDT Received: from guppylake.noname (guppylake.bellcore.com) by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Thu, 2 Sep 93 15:44:13 EDT Received: by guppylake.noname (4.1/SMI-4.1) id AA01329; Thu, 2 Sep 93 15:40:53 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.guppylake.noname.sun4.41 via MS.5.6.guppylake.noname.sun4_41; Thu, 2 Sep 1993 15:40:51 -0400 (EDT) Message-Id: Date: Thu, 2 Sep 1993 15:40:51 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ietf-822@dimacs.rutgers.edu, Rick Troth , John Gardiner Myers , Steve Dorner Subject: Re: text/enriched: Throwing in the towel In-Reply-To: <199309021641.AA06142@dorner.slip.uiuc.edu> References: <199309021641.AA06142@dorner.slip.uiuc.edu> Excerpts from mail: 2-Sep-93 Re: text/enriched: Throwing.. Steve Dorner@qualcomm.co (433*) > I suppose that at this stage of the game I would be shot if I suggested > that fully justified text, absent a very good hyphenation algorithm and > language-specific database, is less legible than ragged right, and so > should NOT be the default? Well, there's some important weasel words here. To quote the draft: > Initially, text/enriched text is intended to be displayed > fully-justified with appropriate fill, kerning, and letter-tracking as > suits the capabilities of the receiving user agent software. Actual > line width is left to the discretion of the receiver, which is expected > to fold lines intelligently (preferring soft line breaks) to the best of its ability. Note the "as suits the capabilities..." clause. In particular, I'd interpret this to mean that if you can't do proportional spacing, for example, or if for any other reason you can't make it look good, you don't have to justify it. That was my intent, anyway. If you don't fully justify it, it won't change the content at all, so you should only fully justify it if you think you can make it look good that way given the technology you have at your disposal. Did other people not interpret it that way? -- Nathaniel   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12724; 2 Sep 93 16:32 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12720; 2 Sep 93 16:32 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa01061; 2 Sep 93 16:32 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08649; Thu, 2 Sep 93 16:13:53 EDT Received: from uxc.cso.uiuc.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08645; Thu, 2 Sep 93 16:13:43 EDT Received: from dorner.slip.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA01831 (5.67a/IDA-1.5 for ); Thu, 2 Sep 1993 15:12:38 -0500 Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA06566 (5.65c/IDA-1.4.4 for jgm+@cmu.edu); Thu, 2 Sep 1993 15:11:57 -0500 Message-Id: <199309022011.AA06566@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 2 Sep 1993 15:12:20 -0500 To: Nathaniel Borenstein , ietf-822@dimacs.rutgers.edu, Rick Troth , John Gardiner Myers Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Dorner Subject: Re: text/enriched: Throwing in the towel At 3:40 PM 9/2/93 -0400, Nathaniel Borenstein wrote: > Initially, text/enriched text is intended to be displayed > fully-justified with appropriate fill, kerning, and letter-tracking as > suits the capabilities of the receiving user agent software. I'm certainly *capable* of justifying text using spaces. This led me to believe that I was *required* to do so. The fact that your text/plain alternative used this method reinforced in my mind the idea that this was expected behavior (understood that there is no explicit tie between the formatting of your message and the standard). So, if in my judgement justification would lessen the legibility of the text, I am allowed to eschew it, regardless of the sender's implicit or explicit instructions? Can I get that in writing? :-) -- Steve Dorner, Qualcomm Inc.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13402; 2 Sep 93 17:06 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13392; 2 Sep 93 17:06 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa02339; 2 Sep 93 17:05 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08749; Thu, 2 Sep 93 16:23:38 EDT Received: from ANDREW.CMU.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08745; Thu, 2 Sep 93 16:23:37 EDT Received: from localhost (postman@localhost) by andrew.cmu.edu (8.5/8.5) id QAA18143; Thu, 2 Sep 1993 16:23:32 -0400 Received: via switchmail; Thu, 2 Sep 1993 16:23:31 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 2 Sep 1993 16:22:46 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 2 Sep 1993 16:22:44 -0400 (EDT) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.412 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Thu, 2 Sep 1993 16:22:41 -0400 (EDT) Message-Id: Date: Thu, 2 Sep 1993 16:22:41 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Gardiner Myers To: ietf-822@dimacs.rutgers.edu Subject: Re: text/enriched: Throwing in the towel In-Reply-To: References: <9309012300.AA25917@dimacs.rutgers.edu> <4gVLUf_00WBw4WZH4q@andrew.cmu.edu> Beak: Is My comments on the revised draft: Nofill should probably be documented in the "Justification Commands" section. I don't follow why turning off filling necessarily changes the newline model. The same avoid-transport-line-wrapping argument for the base text/enriched newline model would appear to also apply to text inside nofill. The minimal conformance section does not mention the need to track the newline model change caused by . The minimal conformance section does not mention the special-case beginning-of-line handling of
, , , and . The sample parser does not do this handling. The sample parser contains the unreferenced function lc2strncmp(). The sample parser appears to botch the following stream: foo << bar baz -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15769; 2 Sep 93 21:03 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15765; 2 Sep 93 21:03 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa11103; 2 Sep 93 21:03 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA09912; Thu, 2 Sep 93 18:38:08 EDT Received: from uqcspe.cs.uq.oz.au by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA09908; Thu, 2 Sep 93 18:38:06 EDT Received: from everest.cs.uq.oz.au by uqcspe.cs.uq.oz.au id ; Fri, 3 Sep 93 08:36:21 +1000 Date: Fri, 3 Sep 93 08:36:20 +1000 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: rhys@cs.uq.oz.au Message-Id: <9309022236.AA18000@client> To: TROTH@ricevm1.rice.edu, ietf-822@dimacs.rutgers.edu, jgm+@cmu.edu, nsb@thumper.bellcore.com, sdorner@qualcomm.com Subject: Re: text/enriched: Throwing in the towel >I suppose that at this stage of the game I would be shot if I suggested >that fully justified text, absent a very good hyphenation algorithm and >language-specific database, is less legible than ragged right, and so >should NOT be the default? Give the man a cigar! This is certainly the case for net communications. In fact, I recall a USENET style recommendation of exactly this. Cheers, Rhys.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16300; 2 Sep 93 22:00 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16296; 2 Sep 93 22:00 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa12750; 2 Sep 93 22:00 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA10146; Thu, 2 Sep 93 19:55:14 EDT Received: from uxc.cso.uiuc.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA10142; Thu, 2 Sep 93 19:55:12 EDT Received: from dorner.slip.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA06221 (5.67a/IDA-1.5 for ); Thu, 2 Sep 1993 18:54:43 -0500 Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA06914 (5.65c/IDA-1.4.4 for jgm+@cmu.edu); Thu, 2 Sep 1993 18:55:04 -0500 Message-Id: <199309022355.AA06914@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 2 Sep 1993 18:55:23 -0500 To: Nathaniel Borenstein , ietf-822@dimacs.rutgers.edu, Rick Troth , John Gardiner Myers Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Dorner Subject: Re: text/enriched: Throwing in the towel At 7:33 PM 9/2/93 -0400, Nathaniel Borenstein wrote: >look best locally. What I had in mind for the default state of >text/enriched is more or less "it might be justified and it might not, >depending on what works and looks good locally." So then why not say exactly that, instead of saying that full justification is the default? I think not specifying it gives you several advantages: 1. It does not give the impression that justification really ought to be done, either to users or to implementors, thus removing an encouragement to doing justification where it is not needed. 2. It removes an ambiguity. If justification is on by default, but I'm allowed to not justify if I don't want to, then what do I do if the user explicitly specifies justification? Am I also allowed to not justify? If I need not obey the explicit directive, then the sender can't force justification. If I must obey the explicit directive, but need not obey the default, then the default state is not the same as fully justified anyway. I think it would be better to leave the initial state unspecified, and say so. But it's not that big a deal if I'm allowed to ignore it, so I won't belabor the point further. -- Steve Dorner, Qualcomm Inc.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17690; 2 Sep 93 22:31 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17686; 2 Sep 93 22:31 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa13819; 2 Sep 93 22:31 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA10084; Thu, 2 Sep 93 19:35:32 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA10080; Thu, 2 Sep 93 19:35:31 EDT Received: from guppylake.noname (guppylake.bellcore.com) by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Thu, 2 Sep 93 19:35:12 EDT Received: by guppylake.noname (4.1/SMI-4.1) id AA02528; Thu, 2 Sep 93 19:33:39 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.guppylake.noname.sun4.41 via MS.5.6.guppylake.noname.sun4_41; Thu, 2 Sep 1993 19:33:38 -0400 (EDT) Message-Id: Date: Thu, 2 Sep 1993 19:33:38 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ietf-822@dimacs.rutgers.edu, Rick Troth , John Gardiner Myers , Steve Dorner Subject: Re: text/enriched: Throwing in the towel In-Reply-To: <199309022011.AA06566@dorner.slip.uiuc.edu> References: <199309022011.AA06566@dorner.slip.uiuc.edu> Excerpts from mail: 2-Sep-93 Re: text/enriched: Throwing.. Steve Dorner@qualcomm.co (823*) > I'm certainly *capable* of justifying text using spaces. This led me to > believe that I was *required* to do so. The fact that your text/plain > alternative used this method reinforced in my mind the idea that this was > expected behavior (understood that there is no explicit tie between the > formatting of your message and the standard). Well, as I've learned the hard way, you have to be very careful with the wording of standards; if it doesn't say "shall" or "must", I don't think you can consider it mandatory. But I can see where the current situation would give you that impression. > So, if in my judgement justification would lessen the legibility of the > text, I am allowed to eschew it, regardless of the sender's implicit or > explicit instructions? Can I get that in writing? :-) Will email suffice? Or do you want a fax of my signature? How about a scanned-in image of my signature in blood? Is full color necessary? Seriously, I think that common denominator enriched text is a very new thing, and I really don't pretend to know what is right. I would be prepared to argue, however, that "right" is critically dependent on the overall environment in which the mail is read, since there's no hope for perfect fidelity anyway. (Even PostScript doesn't always get perfect fidelity -- consider fonts and resolution -- and we were shooting for something a LOT simpler than PostScript.) If you're integrating mail into a coherent system that provides a document processor in which everything IS fully justified, it makes sense to show the email that way. If you're integrating it into a system where text is NOT generally fully justified, it makes sense to show it that way. I really think this is like font specification, which is left out of text/enriched for a very good reason, i.e. you don't know what fonts are available or will look best locally. What I had in mind for the default state of text/enriched is more or less "it might be justified and it might not, depending on what works and looks good locally." I suspect that this lack of specificity is either insane or brilliant, but I could be wrong.... -- Nathaniel   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20114; 2 Sep 93 23:32 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20110; 2 Sep 93 23:32 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa15921; 2 Sep 93 23:32 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12982; Thu, 2 Sep 93 21:34:00 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12978; Thu, 2 Sep 93 21:33:58 EDT Received: from guppylake.noname (guppylake.bellcore.com) by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Thu, 2 Sep 93 21:33:41 EDT Received: by guppylake.noname (4.1/SMI-4.1) id AA03692; Thu, 2 Sep 93 21:30:06 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.guppylake.noname.sun4.41 via MS.5.6.guppylake.noname.sun4_41; Thu, 2 Sep 1993 21:30:05 -0400 (EDT) Message-Id: Date: Thu, 2 Sep 1993 21:30:05 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ietf-822@dimacs.rutgers.edu, Rick Troth , John Gardiner Myers , Steve Dorner Subject: Re: text/enriched: Throwing in the towel In-Reply-To: <199309022355.AA06914@dorner.slip.uiuc.edu> References: <199309022355.AA06914@dorner.slip.uiuc.edu> OK, makes sense. How would people feel about changing "fully-justified with appropriate fill" to "fully filled"? I think that's the only reference in the whole document to real justification. We could also elminate the two references to "ragged margins" and thus make justification entirely unspecified. I'd be happy with that....   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02906; 3 Sep 93 9:01 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02902; 3 Sep 93 9:01 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa10902; 3 Sep 93 9:01 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA15925; Fri, 3 Sep 93 08:46:18 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA15921; Fri, 3 Sep 93 08:46:17 EDT Received: from guppylake.noname (guppylake.bellcore.com) by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Fri, 3 Sep 93 08:46:11 EDT Received: by guppylake.noname (4.1/SMI-4.1) id AA06059; Fri, 3 Sep 93 08:42:12 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.guppylake.noname.sun4.41 via MS.5.6.guppylake.noname.sun4_41; Fri, 3 Sep 1993 08:42:11 -0400 (EDT) Message-Id: Date: Fri, 3 Sep 1993 08:42:11 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Nathaniel Borenstein X-Andrew-Message-Size: 976+0 Mime-Version: 1.0 Content-Type: text/richtext; charset=US-ASCII Content-Transfer-Encoding: quoted-printable To: ietf-822@dimacs.rutgers.edu, John Gardiner Myers Subject: Re: text/enriched: Throwing in the towel In-Reply-To: Message from "John Gardiner Myers " dated "Thu, 2 Sep 1993 16:22:41 -0400 (EDT)" References: <9309012300.AA25917@dimacs.rutgers.edu> <4gVLUf_00WBw4WZH4q@andrew.cmu.edu> Most of your comments make perfect sense and I'll incorporate them, thanks. Excerpts from mail: 2-Sep-93 Re: text/enriched: Throwing.. John= Gardiner Myers@cmu. (897) I don't follow why turning off filling necessarily changes the newlin= e model. The same avoid-transport-line-wrapping argument for the base text/enriched newline model would appear to also apply to text inside nofill. Eek! I presume you're referring to the clause "and hence without any special = handling of CRLFs". I believe that was mindlesly copied from the old "verbati= m" language. I've elminated it. The minimal conformance section does not mention the special-case= beginning-of-line handling of center>, flushleft>, flushright>, a= nd excerpt>. The sample parser does not do this handling. Well, I wasn't thinking of this as part of the necessary minimum. Should it b= e? The sample parser appears to botch the following stream: It seemed fine to me. Can you define "botch"? -- Nathaniel   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03396; 3 Sep 93 9:36 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03392; 3 Sep 93 9:36 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa11983; 3 Sep 93 9:36 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA16482; Fri, 3 Sep 93 09:18:21 EDT Received: from att-out.att.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA16477; Fri, 3 Sep 93 09:18:17 EDT Message-Id: <9309031318.AA16477@dimacs.rutgers.edu> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "t.l.hansen" To: ietf-822@dimacs.rutgers.edu Date: 3 Sep 1993 8:48 EDT Subject: Re: text/enriched References: <9309021848.AA07711@dimacs.rutgers.edu> << I particularly agree with this. << introduces "special case" logic that << I think we could avoid. It's a state machine; keep it simple. < It hits my parser in a completely different way that does require "special < case" logic. Everywhere else I can "look between the angle brackets", < but here I have to explicitly look for an immediate following second open < angle bracket, and if it's there I must NOT look for a close. Parsers can be written in many ways, some of which work better with the rules than others. If you were writing this in lex, the rules to handle << and <...> would look something like << return '<'; ]*> strcpy(token, yytext); return RTOKEN; <[^>]*> strcpy(token, yytext); return TOKEN; That doesn't look like any special case logic to me! :-) Now, if you want to talk about special case logic, how about the fact that doesn't have a corresponding ? Now THAT's a special case! :-) Sorry, to me, your arguments aren't sufficient to override the fact that "<<" LOOKS better than . Which means that I completely disagree with the semi-statement made here. < To avoid rehashing the olde argument, I won't say anything about < cosmetics being totally unimportant to processable text. Tony Hansen hansen@pegasus.att.com, tony@attmail.com att!pegasus!hansen, attmail!tony   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04042; 3 Sep 93 10:04 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04037; 3 Sep 93 10:04 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa13273; 3 Sep 93 10:04 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA16905; Fri, 3 Sep 93 09:39:58 EDT Received: from eskimo.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA16900; Fri, 3 Sep 93 09:39:52 EDT Received: by eskimo.com (5.65c/1.35) id AA05709; Fri, 3 Sep 1993 06:40:21 -0700 Date: Fri, 3 Sep 1993 06:40:21 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Summit Message-Id: <199309031340.AA05709@eskimo.com> To: ietf-822@dimacs.rutgers.edu, nsb@bellcore.com Subject: risks of markup (bold, etc.) Cc: scs@eskimo.com I came across this item in the RISKS digest, and thought it appropriate to this list. (Apologies if it has appeared here already; I no longer subscribe. Also, for that reason, please CC me with any replies you want me to see.) I sincerely hope that no MIME richtext/enrichedtext implementations will ever have the problem discussed here, but I suppose the possibility can't be ruled out. Problems like this, if they occurred too often, could really put a damper on the spread of enriched text schemes. If, to ensure that emphasized words retain their emphasis by retaining their mere presence, one has to avoid using an enriched text scheme's emphasis operator, one might wonder why one is using the enriched text scheme at all. If there are related IETF mailing lists dealing specifically with enriched text issues, could someone (i.e. Nathaniel, lest several people do it) forward this message to those lists? Forwarded message: RISKS-LIST: RISKS-FORUM Digest Wednesday 14 July 1993 Volume 14 : Issue 75 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ------------------------------ Date: Wed, 7 Jul 1993 09:44:07 +0200 From: roeber@axcrnb.cern.ch (Frederick G.M. Roeber) Subject: Re: Important words in other fonts Recently I have been working with the "World Wide Web," a project designed to unite the various data resources on the internet into a common web of information. The Web began a few years ago at CERN. I am working at CERN as well, and some people who saw my work or articles thought I was an official web project member. So, on my 'signature' page ( http://info.cern.ch/roeber/fgmr.html ) I included a disclaimer: Please note: I am not an official member .... The lingua franca of the web is HTML, or hypertext markup language, which is based on SGML. The codes in angle brackets above are SGML, and stand for bold and italics. I looked at my page with my whiz-bang X-based web browser (NCSA Mosaic), and sure enough the line appeared with nice bold and italicised words. A short time later, I got a call from a somewhat annoyed web project guy, demanding to know why I was claiming to be an offical member. It seems that on his NeXT browser, the word "not" was mysteriously absent. The problem was that his browser didn't support italics. Why? Well, when the Web began it was "hypertext" based. Everything was supposed to be simple, plain text accessible by everybody. Though HTML was based on SGML, this was more to be "standard" than to support fancy markups. The core team had a nice plan as to how they would expand, slowly and in step. Then the NCSA came along, with their elegant multimedia X-based browser. Suddenly the web became "hypermedia," and (as it supported much more of SGML), even plain text could be marked up in much fancier ways. So people started writing documents depending on the capabilities of NCSA Mosaic, leaving the earlier browsers behind. In this case, that lapse changed the entire meaning of a rather important sentence. There are a few points here: 1) In important sentences of electronic documents, don't put important words (like "not") in other fonts or representations. 2) In fact, avoid needless font and representation twiddling. 3) Don't assume everybody has the same advanced tools you do. 4) If you're going to use a standard, use *all* of the standard. HTML is based on SGML. The code is legitimate SGML. 5) If you can't represent a requested font, for pete's sake don't just ignore the text! Put it up however you can. In this case, when I protested my innocence, the other guy loaded up the page on the old line-mode browser on the VM system. This browser ignores virtually all markup commands, so the unadorned sentence -- including the 'not' -- appeared. 6) If you launch a project in to the public, be prepared for someone to take the ball and outrun you. You can't stay firmly in control. This emphasizes point 4 -- the whole point of "standards" is so that when this happens, things are still compatible. Frederick G. M. Roeber, CERN/PPE, 1211 Geneva 23, Switzerland roeber@cern.ch or roeber@caltech.edu | work: +41 22 767 31 80   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05677; 3 Sep 93 11:34 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05673; 3 Sep 93 11:34 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa17540; 3 Sep 93 11:34 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA18151; Fri, 3 Sep 93 11:14:29 EDT Received: from nyse.cox.smu.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA18147; Fri, 3 Sep 93 11:14:28 EDT Received: by nyse.cox.smu.edu (Smail3.1.28.1 #1) id m0oYcqJ-0000X5C; Fri, 3 Sep 93 10:14 CDT Message-Id: Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Allen Gwinn Subject: SNPP - A Clarification To: ietf-822@dimacs.rutgers.edu Date: Fri, 3 Sep 1993 10:14:26 -0500 (CDT) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1584 > In <8884.746939162@dbc.mtview.ca.us> Marshall Rose writes: > > > Ok, I'll ask the obvious question then. Why can't you do this with SMTP? There seems to be some confusion surrounding the purpose and intent of SNPP. Here are the constraints: 1) The protocol MUST be simple enough for someone to use via a telnet session, so that even if there is never a paging client developed to interface with it, it is still usable. 2) This *cannot* be a store and forward function. It must run real time and report immediate success or failure. In the "Real" world, page latency is critical. As a doctor, when my patient suffers cardiac arrest, I need to be notified *then*! To send messages via email is not acceptable to me, because if the message didn't go through, I want my answering service to know about it *then* and take action under plan "B" (a modem to a dial-up line). SNPP is designed to sit on a box (gateway) plugged into the Internet on one side, and a serial line to an IXO port on the other. It is designed to have real-time interaction, and real-time response reporting. In other words, when you have finished a message, requested a "Send" and received the message "Page Sent," this means that the data has actually been delivered to the paging terminal and is being processed to the uplink. About 20 seconds later, your recipient's beeper should ring. I guess the key words here are "real time" and "simplicity." I know that this was a point of a little confusion, and hopefully this will clear it up. Allen   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06880; 3 Sep 93 12:42 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06876; 3 Sep 93 12:42 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa22213; 3 Sep 93 12:42 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA18730; Fri, 3 Sep 93 12:11:20 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA18726; Fri, 3 Sep 93 12:11:18 EDT Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-13 #2603) id <01H2I6R42JS0000FA3@INFOODS.UNU.EDU>; Fri, 3 Sep 1993 12:10:25 EDT Date: Fri, 03 Sep 1993 12:10:25 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John C Klensin Subject: Re: risks of markup (bold, etc.) In-Reply-To: <199309031340.AA05709@eskimo.com> To: scs@eskimo.com Cc: ietf-822@dimacs.rutgers.edu, nsb@bellcore.com, timbl@www.cern.ch, risks@csl.sri.com Message-Id: <747072625.433593.KLENSIN@INFOODS.UNU.EDU> X-Envelope-To: ietf-822@DIMACS.RUTGERS.EDU Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Mail-System-Version: >Why? Well, when the Web began it was "hypertext" based. Everything was >supposed to be simple, plain text accessible by everybody. Though HTML was >based on SGML, this was more to be "standard" than to support fancy markups. >The core team had a nice plan as to how they would expand, slowly and in step. >Then the NCSA came along, with their elegant multimedia X-based browser. >Suddenly the web became "hypermedia," and (as it supported much more of SGML), >even plain text could be marked up in much fancier ways. So people started >writing documents depending on the capabilities of NCSA Mosaic, leaving the >earlier browsers behind. In this case, that lapse changed the entire meaning >of a rather important sentence. > >There are a few points here: >... Steve and Frederick, I think one could draw some slightly different lessons from this. Maybe the differences might tell us something. Proposed alternate main principle: Any time one designs something that can be extended, it is necessary to be extremely clear about what an "old" processor should do when it encounters an unrecognized extension. If that action is "discard", then one has to be hyper-careful about what extensions are permitted. In some cases, clever design would make lexical distinctions between (SGML-speak) "safe to discard tag", "safe to discard element", and "not save to ignore" extensions that would permit old processors to behave with relative intelligence. In more conventional language, these would be equivalent to "save to discard verb", "save to discard entire sentence/command/statement", "better reject program until this can be figured out". > 4) If you're going to use a standard, use *all* of the standard. > HTML is based on SGML. The code is legitimate SGML. SGML is just a language that mostly specifies syntax, not semantics. is "legitimate SGML" because the syntax rules are met. So is this whole message. But that isn't the point, any more than having a lexically-correct Fortran program proves that it is useful for a particular application or even that it will compile. Or that requiring that a C program exercise every feature of that language and every library routine would make sense. Which codes are really "legitimate" depends on a document type definition, i.e., what HTML really is defined as being. "" is either legitimate there, or it isn't. If an HTML composing agent permits use of , and isn't in the DTD, then the composing agent is broken. If an HTML reader-browser receives an element and doesn't know what to do with it (presumably because it was written against an earlier DTD or DTD-concept), it has bad data on its hands. Programs that ignore obvious bad data on the theory that anything unrecognized is noise are likely to get into all sorts of trouble--that is nothing new. Now, in the HTML / WWW case in particular, I'd think that even a weak browsing engine has to have hypertext pop-up or exploder capability. Elementary robust programming strategies would argue that encourntering an unknown element should cause the user to see an "unrecognized element, ..., what do you want to do about it" message to appear. These things are language processors, and we all know those things happen in language processors. john   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08390; 3 Sep 93 13:34 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08386; 3 Sep 93 13:34 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa24434; 3 Sep 93 13:34 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA21214; Fri, 3 Sep 93 13:07:17 EDT Received: from PO2.ANDREW.CMU.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA21210; Fri, 3 Sep 93 13:07:15 EDT Received: from localhost (postman@localhost) by po2.andrew.cmu.edu (8.5/8.5) id NAA06921; Fri, 3 Sep 1993 13:07:13 -0400 Received: via switchmail; Fri, 3 Sep 1993 13:07:13 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 3 Sep 1993 13:06:36 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 3 Sep 1993 13:06:32 -0400 (EDT) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.412 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Fri, 3 Sep 1993 13:06:29 -0400 (EDT) Message-Id: Date: Fri, 3 Sep 1993 13:06:29 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Gardiner Myers To: ietf-822@dimacs.rutgers.edu Subject: Re: text/enriched: Throwing in the towel In-Reply-To: References: <9309012300.AA25917@dimacs.rutgers.edu> <4gVLUf_00WBw4WZH4q@andrew.cmu.edu> Beak: Is Nathaniel Borenstein writes > Eek! I presume you're referring to the clause "and hence without > any special handling of CRLFs". I believe that was mindlesly copied > from the old "verbatim" language. I've elminated it. You should also eliminate the corresponding code in the minimal parser. > It seemed fine to me. Can you define "botch"? I don't have a machine-readable copy of the code, so it's hard for me to verify, but I think it translates the stream as: foo < bar baz When the spec says it should be: foo < bar baz _.John   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08957; 3 Sep 93 14:03 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08953; 3 Sep 93 14:03 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa25764; 3 Sep 93 14:03 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA21265; Fri, 3 Sep 93 13:15:27 EDT Received: from PO2.ANDREW.CMU.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA21261; Fri, 3 Sep 93 13:15:24 EDT Received: from localhost (postman@localhost) by po2.andrew.cmu.edu (8.5/8.5) id NAA07090; Fri, 3 Sep 1993 13:15:22 -0400 Received: via switchmail; Fri, 3 Sep 1993 13:15:18 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 3 Sep 1993 13:13:19 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 3 Sep 1993 13:13:16 -0400 (EDT) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.412 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Fri, 3 Sep 1993 13:13:13 -0400 (EDT) Message-Id: Date: Fri, 3 Sep 1993 13:13:13 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Gardiner Myers To: ietf-822@dimacs.rutgers.edu Subject: Re: text/enriched: Throwing in the towel In-Reply-To: References: <9309012300.AA25917@dimacs.rutgers.edu> <4gVLUf_00WBw4WZH4q@andrew.cmu.edu> Beak: is Not Nathaniel Borenstein writes > It seemed fine to me. Can you define "botch"? Never mind, I found the line of code I was overlooking. On the other hand, while the spec says to convert a seqence of N CRLF's to N-1 CRLF's, the code instead converts a sequence of N CRLF's to a SPACE and N-1 CRLF's. The putc(' ', stdout) call should be at the points in the routine where newlinect is set to 0, conditionalized on (newlinect == 1).   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09831; 3 Sep 93 14:32 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09827; 3 Sep 93 14:32 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa27051; 3 Sep 93 14:32 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA21354; Fri, 3 Sep 93 13:31:57 EDT Received: from eskimo.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA21350; Fri, 3 Sep 93 13:31:54 EDT Received: by eskimo.com (5.65c/1.35) id AA14637; Fri, 3 Sep 1993 10:31:28 -0700 Date: Fri, 3 Sep 1993 10:31:28 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Summit Message-Id: <199309031731.AA14637@eskimo.com> To: KLENSIN@infoods.mit.edu Subject: Re: risks of markup (bold, etc.) In-Reply-To: <747072625.433593.KLENSIN@INFOODS.UNU.EDU> Cc: ietf-822@dimacs.rutgers.edu, timbl@www.cern.ch, scs@eskimo.com In <747072625.433593.KLENSIN@INFOODS.UNU.EDU>, you wrote: > I think one could draw some slightly different lessons from this. Maybe > the differences might tell us something. > > Proposed alternate main principle: Any time one designs something that > can be extended, it is necessary to be extremely clear about what an > "old" processor should do when it encounters an unrecognized extension. Absolutely. I passed along the note from RISKS more or less without comment (I would have drawn slightly different conclusions, also), but John presents a vitally important fundamental principle (which I have been known to advocate, myself). Far too few specifications devote any thought to evolution and extension mechanisms, perhaps assuming that implementors of version 1 prototypes will all "do the right thing." Experience shows, however, that they rarely do. > If that action is "discard", then one has to be hyper-careful about > what extensions are permitted. In some cases, clever design would > make lexical distinctions between (SGML-speak) "safe to discard tag", > "safe to discard element", and "not save to ignore" extensions that > would permit old processors to behave with relative intelligence. In fact, we had discussions of this sort of issue, with respect to richtext/enrichedtext, a few months back. Sometimes it's entirely appropriate to disregard unrecognized information, but in the case of a markup language it's pretty obvious that it is not appropriate (especially when the information is user text which is merely surrounded by an unrecognized delimiter). Personally, I am much more interested in the design and specification issues (i.e. "don't discard unrecognized text," or John's deeper "plan a specification for growth, and define up-front the behavior to be taken by initial implementations in the face of eventual newer data"), and I would tend to place the "blame" in the WWW/hypertext anecdote on the misbehavior of the implementation which silently discarded the italicized text. But, in the larger picture (which is what the RISKS list often gives you good glimpses of), it may not matter whether it was a specification problem or an implementation problem, or whether it was an uninteresting example of an old problem we'd all seen before: if the system fails, the system gets the blame. Steve Summit scs@eskimo.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12664; 3 Sep 93 16:06 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12660; 3 Sep 93 16:06 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa00859; 3 Sep 93 16:06 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA22635; Fri, 3 Sep 93 15:39:03 EDT Received: from ppp.dbc.mtview.ca.us by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA22631; Fri, 3 Sep 93 15:39:00 EDT Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA07591; Fri, 3 Sep 93 12:37:52 -0700 To: Allen Gwinn Reply-To: ietf-822@dimacs.rutgers.edu Cc: ietf-822@dimacs.rutgers.edu Subject: Re: SNPP - A Clarification In-Reply-To: Your message of "Fri, 03 Sep 1993 10:14:26 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <7585.747085069.1@dbc.mtview.ca.us> Date: Fri, 03 Sep 1993 12:37:50 -0700 Message-Id: <7588.747085070@dbc.mtview.ca.us> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Marshall Rose Your message leaves me confused. In terms of simplicity: SNPP is no less complicated than SMTP. Further, in terms of clients, there are dozens of different SMTP clients, all of which hide the protocol from the user. In terms of store-and-forward: if you think paging networks are reliable, you probably haven't used one recently. In the SF area, pages take on the average of 5 minutes to be delivered, and one out of every three of my pages gets dropped. Because paging networks are simplex, there is simply no way to ensure reliable behavior. The best you can do is report that IXO said it accepted the page. Beyond that, anything else is a fiction. So, I think we are back to: why do we need another protocol (and associated infrastructure), when we already have a widespread SMTP infrastructure... /mtr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13744; 3 Sep 93 17:31 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13738; 3 Sep 93 17:31 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa04518; 3 Sep 93 17:31 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA25822; Fri, 3 Sep 93 16:56:42 EDT Received: from nyse.cox.smu.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA25817; Fri, 3 Sep 93 16:56:39 EDT Received: by nyse.cox.smu.edu (Smail3.1.28.1 #1) id m0oYiBR-0000X5C; Fri, 3 Sep 93 15:56 CDT Message-Id: Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Allen Gwinn Subject: Re: SNPP - A Clarification To: ietf-822@dimacs.rutgers.edu Date: Fri, 3 Sep 1993 15:56:36 -0500 (CDT) In-Reply-To: <7588.747085070@dbc.mtview.ca.us> from "Marshall Rose" at Sep 3, 93 12:37:50 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1812 > In terms of simplicity: SNPP is no less complicated than SMTP. Further, > in terms of clients, there are dozens of different SMTP clients, all of > which hide the protocol from the user. Yes, but none are specifically designed with paging in mind, are they? > In terms of store-and-forward: if you think paging networks are > reliable, you probably haven't used one recently. In the SF area, pages > take on the average of 5 minutes to be delivered, and one out of every > three of my pages gets dropped. Because paging networks are simplex, > there is simply no way to ensure reliable behavior. The best you can do > is report that IXO said it accepted the page. Beyond that, anything > else is a fiction. Actually, it depends on how you implement your paging network. I am working with a major nationwide paging firm. If your pages are taking 5 minutes on average to be delivered, you should probably check them out. Numeric pages average 16 seconds, nationwide, and alpha pages are sent within 1 minute. All systems are monitored at the transmitter, and should there be a problem, pages can be held and retransmitted. Still, just because there may be problems with one part of a system, isn't particularly good justification for breaking other parts. I can at least guarantee that information reaches the IXO. I cannot justify degrading reliability by rationalizing that paging delivery is unreliable. Too many people do that with too many things as is. > So, I think we are back to: why do we need another protocol (and > associated infrastructure), when we already have a widespread SMTP > infrastructure... Because I cannot see how SMTP is going to address all of these concerns. If I am missing something, perhaps you can help clarify the missed point. Thanks for your input. Allen   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14061; 3 Sep 93 18:01 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14057; 3 Sep 93 18:01 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa05447; 3 Sep 93 18:01 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA28222; Fri, 3 Sep 93 17:52:07 EDT Received: from att-out.att.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA28218; Fri, 3 Sep 93 17:52:04 EDT Message-Id: <9309032152.AA28218@dimacs.rutgers.edu> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "t.l.hansen" To: ietf-822@dimacs.rutgers.edu Date: 3 Sep 1993 13:46 EDT Subject: Re: text/enriched References: <9309031318.AA16477@dimacs.rutgers.edu> < I don't understand the meaning of . If it is just a way to < turn off "reflow", then fine ... great! In fact, it's reasonable for < enclosing indentions to affect such a . But if it is a way to < temporarily suspend interpretation, YUK! Another "special case", but < with a *really* ugly k-map. Nastier than <<. Aside from the ugliness of the syntax of how to turn it off, the functionality of is absolutely necessary. In fact, I've implemented some mail generating code that I don't see how to implement easily without using . Like I said before, the code to implement was all of ~25 lines in the metamail richtext program. No, should NOT be removed. Tony Hansen hansen@pegasus.att.com, tony@attmail.com att!pegasus!hansen, attmail!tony   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14495; 3 Sep 93 18:31 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14491; 3 Sep 93 18:31 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa06465; 3 Sep 93 18:31 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA28158; Fri, 3 Sep 93 17:47:05 EDT Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA28154; Fri, 3 Sep 93 17:47:04 EDT Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA08947; Fri, 3 Sep 93 14:47:02 -0700 Message-Id: <9309032147.AA08947@Mordor.Stanford.EDU> To: Allen Gwinn Cc: ietf-822@dimacs.rutgers.edu Subject: Re: SNPP - A Clarification Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Fri, 03 Sep 93 15:56:36 -0500. Date: Fri, 03 Sep 93 14:47:02 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Crocker X-Mts: smtp Allen, Without commenting on the various details under discussion, I want to raise a couple of questions: Why does SMTP "inherently" incur the delay that you cite? While it is certainly true that general use of it involves various sources of store-and-forward delay, I believe that none of that is required, if a given sender wishes to accomplish a "direct" interactive link to a given receiver. That is, there is a big difference between protocol design and operational configuration. On the matter of user agents, you are simultaneously challenging the lack of any UA's designed specifically for paging while also stating a desire to allow Telnet interaction with an SNPP server. These sound like competing arguments, to me. (However, the argument for allowing Telnet access reminds me of the original arguments for the design of FTP, 20 years ago...) Dave   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14959; 3 Sep 93 19:14 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14955; 3 Sep 93 19:14 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa08203; 3 Sep 93 19:14 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA28335; Fri, 3 Sep 93 18:06:20 EDT Received: from dorner.slip.uiuc.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA28331; Fri, 3 Sep 93 18:06:13 EDT Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA01040 (5.65c/IDA-1.4.4 for ietf-822@dimacs.rutgers.edu); Fri, 3 Sep 1993 17:05:52 -0500 Message-Id: <199309032205.AA01040@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 3 Sep 1993 17:06:17 -0500 To: Allen Gwinn , ietf-822@dimacs.rutgers.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Dorner Subject: Re: SNPP - A Clarification At 10:14 AM 9/3/93 -0500, Allen Gwinn wrote: >SNPP is designed to sit on a box (gateway) plugged into the Internet on >one side, and a serial line to an IXO port on the other. It is designed to >have real-time interaction, and real-time response reporting. In other >words, when you have finished a message, requested a "Send" and received the >message "Page Sent," this means that the data has actually been delivered >to the paging terminal and is being processed to the uplink. About >20 seconds later, your recipient's beeper should ring. > >I guess the key words here are "real time" and "simplicity." I know that >this was a point of a little confusion, and hopefully this will clear >it up. I can see that there is a significant benefit to doing "SNPP" to the paging center over doing SMTP to some random Internet host, which is then trusted to talk to the paging center "eventually". But is there a big functional difference between doing "SNPP" to the paging center and doing SMTP to the paging center? Seems to me that you don't need a new protocol, you only need to be able to do the old protocol to a specific server. This lets you use existing SMTP clients if you want, or do it by hand (SMTP isn't hard to do--ask any sophomoric mail forger). It lets you entrust your page to the winds by dumping it out on the store & forward mail network, or be quite specific by connecting directly to the server you trust to deliver your page. Furthermore, it gives non-Internet connected folks the ability to page, from BITNet/UUCP/Compuserve/etc.. -- Steve Dorner, Qualcomm Inc.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15096; 3 Sep 93 19:31 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15092; 3 Sep 93 19:31 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa08938; 3 Sep 93 19:31 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA28666; Fri, 3 Sep 93 19:15:20 EDT Received: from eco.twg.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA28662; Fri, 3 Sep 93 19:15:18 EDT Received: from LOCAL.eco.twg.com by eco.twg.com (5.67/ECO.m-$Revision: 2.16 $) id AA01875; Fri, 3 Sep 93 19:15:15 -0400 Message-Id: <9309032315.AA01875@eco.twg.com> Received: from apache.twg.com by apache.twg.com id <8773-0@apache.twg.com>; Fri, 3 Sep 1993 16:15:11 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: David Herron Subject: Re: SNPP - A Clarification To: IPM Return Requested Date: Fri, 3 Sep 93 16:15:09 PDT In-Reply-To: Your message of Fri, 03 Sep 93 14:47:02 -0700.<9309032147.AA08947@Mordor.Stanford.EDU> Sensitivity: Personal Conversion: Prohibited Conversion-With-Loss: Prohibited Encoding: 15 TEXT So since SNPP is not to be SaF then: It will be unable to send page's from a non-IP connected site? Which leaves out UUCP, BITNET and many corporate `internal' networks. (like the one where I'm typing this message) It will be unable to deal with temporarily unreachable page transmitters. Just wanting to understand the tradeoffs involved. David   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15768; 3 Sep 93 20:37 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15764; 3 Sep 93 20:37 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa11203; 3 Sep 93 20:37 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29158; Fri, 3 Sep 93 20:18:58 EDT Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29154; Fri, 3 Sep 93 20:18:57 EDT Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA11031; Fri, 3 Sep 93 17:18:56 -0700 Message-Id: <9309040018.AA11031@Mordor.Stanford.EDU> To: ietf-822@dimacs.rutgers.edu Subject: IANA registration of header names Contact: work Contact: home Date: Fri, 03 Sep 93 17:18:55 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Crocker X-Mts: smtp Folks, We periodically see requests for "valid" or "reserved" RFC822 header names. To my knowledge, no compendium with that list has been created. My constructive thought for the day was to observe that this is a very well understood phenomenon and could be reduced to a rather menial effort: The IANA serves to list all sorts of tables of registered names and values. RFC822 didn't cite it because a) I didn't think of it, and b) IANA wasn't quite serving the pervasive role it now does. But it now does. While there are many header names that are effectively reserved and used but not documented, there are others that are very much registered. I propose that we put the list together and forward it to IANA. They have already agreed to incorporate it. Do we have a volunteer to act as editor? Dave   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15862; 3 Sep 93 21:04 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15858; 3 Sep 93 21:04 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa12248; 3 Sep 93 21:04 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29044; Fri, 3 Sep 93 20:10:01 EDT Received: from moon.src.honeywell.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29039; Fri, 3 Sep 93 20:09:56 EDT Return-Path: Received: from smaug.src.honeywell.com by src.honeywell.com (4.0/smail2.6.3/SRCv0.25); Fri, 3 Sep 93 19:09:52 CDT id AA28127 for ietf-822@dimacs.rutgers.edu at dimacs.rutgers.edu Posted-Date: Fri, 3 Sep 1993 19:09:50 -0500 (CDT) Received: by smaug.src.honeywell.com (4.0/SMI-3.2) id AA10905; Fri, 3 Sep 93 19:09:51 CDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Danny Iacovou Message-Id: <9309040009.AA10905@smaug.src.honeywell.com> Subject: Re: SNPP - A Clarification To: ietf-822@dimacs.rutgers.edu Date: Fri, 3 Sep 1993 19:09:50 -0500 (CDT) In-Reply-To: <7588.747085070@dbc.mtview.ca.us> from "Marshall Rose" at Sep 3, 93 12:37:50 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3150 Marshall Rose writes: > > So, I think we are back to: why do we need another protocol (and > associated infrastructure), when we already have a widespread SMTP > infrastructure... I guess I don't understand what this sudden rush to implement a paging protocol is all about. I already have a paging protocol, had it for years. The applications build on top of it are really Hot as well. This is how my current pagind set-up works: I sit on my terminal and all of a sudden I hear a . I then look around to see that is wrong, when all of a sudden I notice that this little window in the bottom of my screen is now colored white on black (rather than the default black on white). The window also has a picture on it, mine has a picture of a mailbox on it, and the little lever on the mailbox is upright (default position is downright). Other people around here have similar pagers, some people have these little windows that speak to them whereas mine just goes . I have also seen other pagers that also go but at the same time they show a picture of the person paging them. Since my pager isn't smart enough to show my who is paging me I need to find out for myself. I normally do this by typing "elm" on the UNIX command line. Other people around here invoke "mail" or other such paging acknowledgement utilities. Anyway, I then find out who had paged me - I also get a message from the person. Sometimes just the subject line has a message, but other times the person leaves me a page that takes screenfulls of reading. . Another Hot thing about my pager is that recently I can also be paged via groovy multimedia pages - these pages are my favorite. I can also page someone if I really wanted to. I have access to many networks (UUCP, BITNET, COMPUSERVE, PRODIGY, etc etc etc). The thing that bums me about paging someone is that is might take a few minutes to page him. When I am so impatient and can't wait a few minutes for a page to go through I use a different form of pager. This new pager goes and forces me to dial some numbers. The bad thing about this pager is that I have to "pay" for it:-(. The good thing about this pager is that if the person I am paging is not next to a computer, and he is wearing a little box on his belt, I can still make contact. Anyway, I guess what I am saying, is that unless SNPP can provide me with something I don't already have, a "paging" protocol will only serve to confuse me (do I really need another little window in the corner of my terminal? - I don't think so). What I do need so for a way to be paged when I am not next to a computer, or a phone, or carrying a pager with me. (putting a longer string around 2 tin cans is cheating). -------------------------------------------------------------------------------- Neophytos Iacovou Honeywell Systems & Research Center iacovou@src.honeywell.com Minneapolis, Mn, 55418   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16004; 3 Sep 93 21:34 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16000; 3 Sep 93 21:34 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa13257; 3 Sep 93 21:34 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01935; Fri, 3 Sep 93 21:15:50 EDT Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01931; Fri, 3 Sep 93 21:15:49 EDT Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA13593; Fri, 3 Sep 93 18:15:36 -0700 Message-Id: <9309040115.AA13593@Mordor.Stanford.EDU> To: Danny Iacovou Cc: ietf-822@dimacs.rutgers.edu Subject: Re: SNPP - A Clarification Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Fri, 03 Sep 93 19:09:50 -0500. <9309040009.AA10905@smaug.src.honeywell.com> Date: Fri, 03 Sep 93 18:15:35 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Crocker X-Mts: smtp Danny, I believe that the system that you describe for yourself works quite well, but does not work so well while you are at the grocery store, gas station, visiting a relative, or otherwise 'untethered'. For such situations, there is an installed base of small, portable devices, called pagers. Allen (and others) is concerened with facilitating access to that broadcast system, using Internet mechanisms for input. d/   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17472; 3 Sep 93 22:38 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17468; 3 Sep 93 22:38 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa15574; 3 Sep 93 22:38 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02335; Fri, 3 Sep 93 22:22:59 EDT Received: from ics.uci.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02331; Fri, 3 Sep 93 22:22:58 EDT Received: from nma.com by q2.ics.uci.edu id ab01428; 3 Sep 93 19:20 PDT Received: from localhost by odin.nma.com id aa07966; 3 Sep 93 18:59 PDT To: Allen Gwinn Cc: ietf-822@dimacs.rutgers.edu Subject: Re: SNPP - A Clarification In-Reply-To: Your message of "Fri, 03 Sep 1993 10:14:26 CDT." Reply-To: Stef@nma.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Einar Stefferud Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 03 Sep 1993 18:59:20 -0700 Message-Id: <7964.747107960@odin.nma.com> X-Orig-Sender: stef@nma.com I just reviewed this thread, and I must say that using SMTP and MIME content-types appears to me to greatly expand the range of things you can do with paging. If you want one-hop relaiability, then you configure your neytwork to be able to always reach the pager station in one hop, or notify someone that one-hop service is not available at the time. Unavailability can be due to the pager station being out of service, or due to some obstacle that can be routed around iwth a bit of store and forward. But, the big plus I see for simpoly using SMTP is that anyopne anywhere on the Email Internet can also reach the pager with ordinary mail. Of course it will be important for them to understand the difference in the Quality of Service. But, I see no reason why SMTP is not as good as your new SNPP when it is used over a one-hop configuration. Cheers...\Stef   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03376; 4 Sep 93 15:30 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03372; 4 Sep 93 15:30 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa26069; 4 Sep 93 15:30 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08451; Sat, 4 Sep 93 15:05:26 EDT Received: from dorner.slip.uiuc.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08447; Sat, 4 Sep 93 15:05:22 EDT Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA00356 (5.65c/IDA-1.4.4 for ietf-822@dimacs.rutgers.edu); Sat, 4 Sep 1993 14:05:49 -0500 Message-Id: <199309041905.AA00356@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 4 Sep 1993 14:05:43 -0500 To: ietf-822@dimacs.rutgers.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Dorner Subject: Re: text/enriched At 11:31 AM 9/4/93 -0500, Rick Troth wrote: > Sure, << looks better. Again, so what? >For pete's sake, don't make the protocol fit your eyes, >it's gotta fit the "eyes" of a myriad of different computers, >most of which neither you nor I have seen. The desire is for the protocol to fit the eyes of people using mail readers that do not understand the spec. The difficulty of writing a parser for text/richtext or text/enriched is hardly significant compared with the other problems mailer authors must tackle (RFC 822 address syntax, for example), so I really don't think implementation difficulty is an issue. If, by complicating the syntax a little, we can make something that is acceptable to non-MIME readers, that's definitely worthwhile. However, all the flak my users have given me about quoted-printable leads me to believe that this goal (acceptability of raw rich text to non-MIME readers) is laughable. Yes, nerds may prefer "x << y" 10:1 over "x y", but there are many users who will hate them both. And those users will complain to the senders, and the senders will stop sending text/rich to non-MIME mailers, making the looks of text/rich utterly irrelevant. So I guess I agree that how it looks is probably not important. No one will see it that way anyway. -- Steve Dorner, Qualcomm Inc.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03501; 4 Sep 93 16:00 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03497; 4 Sep 93 16:00 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa27412; 4 Sep 93 16:00 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08536; Sat, 4 Sep 93 15:17:37 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08532; Sat, 4 Sep 93 15:17:36 EDT Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-13 #2603) id <01H2JTFD9S40000GKY@INFOODS.UNU.EDU>; Sat, 4 Sep 1993 15:16:58 EDT Date: Sat, 04 Sep 1993 15:16:57 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John C Klensin Subject: Re: text/enriched: Throwing in the towel In-Reply-To: To: nsb@thumper.bellcore.com Cc: ietf-822@dimacs.rutgers.edu, TROTH@ricevm1.rice.edu, jgm+@cmu.edu, sdorner@qualcomm.com Message-Id: <747170217.728593.KLENSIN@INFOODS.UNU.EDU> X-Envelope-To: ietf-822@DIMACS.RUTGERS.EDU Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Mail-System-Version: >What I had in mind for the default state of >text/enriched is more or less "it might be justified and it might not, >depending on what works and looks good locally." Nathaniel, It seems to me that what you are saying here might be translated into: (i) If justification is neither specified nor prohibited by the text, the output should be justified or not depending on implementation choices and local conventions. (ii) The person creating an enhanced text file can explicitly specify whether or not justification is to be performed; if she does, you pay attention. If that is the intent (and consensus), why not just say it? What I think we have learned by now about slightly ambiguous specs is that, rather than creating flexibility, they plant the seeds to religious wars about what was really meant. --john   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03658; 4 Sep 93 16:30 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03654; 4 Sep 93 16:29 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa28542; 4 Sep 93 16:29 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08827; Sat, 4 Sep 93 15:55:46 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08823; Sat, 4 Sep 93 15:55:45 EDT Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-13 #2603) id <01H2JTFD9S40000GKY@INFOODS.UNU.EDU>; Sat, 4 Sep 1993 15:55:11 EDT Date: Sat, 04 Sep 1993 15:55:11 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John C Klensin Subject: Re: text/enriched In-Reply-To: <199309041905.AA00356@dorner.slip.uiuc.edu> To: sdorner@qualcomm.com Cc: ietf-822@dimacs.rutgers.edu Message-Id: <747172511.94593.KLENSIN@INFOODS.UNU.EDU> X-Envelope-To: ietf-822@DIMACS.RUTGERS.EDU Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Mail-System-Version: >Yes, nerds may prefer "x << y" 10:1 over "x y", but there are many >users who will hate them both. And those users will complain to the >senders, and the senders will stop sending text/rich to non-MIME mailers, >making the looks of text/rich utterly irrelevant. Steve, This brings us nearly full circle on an old argument. To the degree to which your observation is true, you have just said "users won't be able to tolerate richtext without composing and display agents". But, if we basically assume that composing and display agents are going to be required for all functions except debugging (and nerd-nerd communication), then it is rational to make the language richer and let it support a broader range of specifications. Down that path lies not merely , but SGML with a fairly rich DTD. john   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03722; 4 Sep 93 16:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03718; 4 Sep 93 16:44 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa29074; 4 Sep 93 16:44 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08794; Sat, 4 Sep 93 15:52:10 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08788; Sat, 4 Sep 93 15:52:09 EDT Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-13 #2603) id <01H2JTFD9S40000GKY@INFOODS.UNU.EDU>; Sat, 4 Sep 1993 15:51:35 EDT Date: Sat, 04 Sep 1993 15:51:34 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John C Klensin Subject: Re: SNPP - A Clarification In-Reply-To: <199309032205.AA01040@dorner.slip.uiuc.edu> To: sdorner@qualcomm.com Cc: allen@nyse.cox.smu.edu, ietf-822@dimacs.rutgers.edu Message-Id: <747172294.651593.KLENSIN@INFOODS.UNU.EDU> X-Envelope-To: ietf-822@DIMACS.RUTGERS.EDU Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Mail-System-Version: Allen, Let me take a half-step past Steve Dorner's comments, with which I basically agree... What you are hearing, I think, is a general sense that "one more protocol" is worse than "pushing a little on an existing one", just in terms of what is already deployed. We've got about 20 years of Internet experience to attest to the wisdom of that. You seem to have two main problems with using SMTP. One seems to be complexity; but people on this list are arguing forcefully that SMTP isn't inherently more complex than what you are proposing. The other seems to be the risks of getting involved in a store-and- forward situation. One way to eliminate that is to use SMTP client-to- remote server, just as you propose with SNPP. That was, curiously, the normal situation in early internet mail implementations: wide adoption of "send it to the local server and let it cope" came only later. The design ideas suggested below are not proposals but weak strawmen intended to help open up the discussion and thinking a bit. We do have some interesting artifacts lying around in SMTP that were intended for direct delivery to terminals (with or without "delivery to mailbox" fallbacks). It might be worthwhile for you to take a look at SEND FROM and its two cousins (SAML and SOML). In principle, if you really didn't want any relaying, you could even define an SMTP service extension of either the "don't relay at all" or the "deliver by YYYYMMDD HHMMSS or tell me" persuasions. Dealing with those service extensions would require changing clients and servers, but those changes are typically smaller than deploying a new protocol. And, by continuing to use the mail infrastructure, it is plausible that you could get pages through gateways from other mail services--e.g., by having a MIME message with specific content sent to a gateway that would set up the appropriate extended SMTP machinery from the message content. Eliminating the requirement for IP-connected Internet use only would seem like an advantage too. And it seems to me that you haven't argued for "real time" as much as for "fast delivery or notification". Let me make another suggestion: if you, and the "major national paging firm", invent a new protocol, its use will end up localized to a few gateway servers and clients that speak directly to them, probably by typing commands over a telnet connection (a nasty business, since everything has to be correct). The rest of the folks you are hearing from here, if they want to communicate with pagers offered by that firm, will just set up a mail-based protocol by which messages can be sent to pagers by routing them to gateways that accept SMTP/822/MIME and produce SNPP. Marshall suggested a variation on that theme in one of his notes, paralleling the remote printing experiment. If that is the case, the discussion here turns into one of whether there is value in injecting an SNPP middleman between SMTP/822/MIME machinery, which will be used anyway, and IXO on the far end. --john   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03754; 4 Sep 93 16:59 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03750; 4 Sep 93 16:59 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa29522; 4 Sep 93 16:59 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA09052; Sat, 4 Sep 93 16:30:12 EDT Received: from dorner.slip.uiuc.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA09048; Sat, 4 Sep 93 16:30:08 EDT Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA00423 (5.65c/IDA-1.4.4 for ietf-822@DIMACS.RUTGERS.EDU); Sat, 4 Sep 1993 15:30:20 -0500 Message-Id: <199309042030.AA00423@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 4 Sep 1993 15:30:13 -0500 To: John C Klensin Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Dorner Subject: Re: text/enriched Cc: ietf-822@dimacs.rutgers.edu At 3:55 PM 9/4/93 -0400, John C Klensin wrote: >basically assume that composing and display agents are going to be >required for all functions except debugging (and nerd-nerd >communication), then it is rational to make the language richer and let >it support a broader range of specifications. Seems to me like there are three goals: 1. Provide enough "rich" to be useful. 2. Make the language easy to implement, so that it gets widely implemented. 3. Keep the result readable (writeable) without a parser (composer). It would seem to me that 1 & 3 both argue for a more powerful language. (The more power you have, the fewer directives you need to do what you want, and so the easier the raw text is to read.) So I don't see that saying that 3 is wishful thinking necessarily frees you to use a more powerful language; the power restriction comes from 2, not 3. Anyway, I don't think it matters at all whether enriched uses << or . The marginal differences in acceptability to non-MIME users and difficulty to MIME software authors are so tiny as to be beneath notice. -- Steve Dorner, Qualcomm Inc.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04146; 4 Sep 93 18:59 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04142; 4 Sep 93 18:59 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa03524; 4 Sep 93 18:59 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA09492; Sat, 4 Sep 93 18:35:10 EDT Received: from att-out.att.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA09488; Sat, 4 Sep 93 18:35:09 EDT Message-Id: <9309042235.AA09488@dimacs.rutgers.edu> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "t.l.hansen" To: ietf-822@dimacs.rutgers.edu Date: 4 Sep 1993 18:28 EDT Subject: Re: text/enriched References: <9309041821.AA08140@dimacs.rutgers.edu> < Sure, << looks better. Again, so what? For pete's sake, don't make < the protocol fit your eyes, it's gotta fit the "eyes" of a myriad of < different computers, most of which neither you nor I have seen. The users are always more important than the computer. If it takes a slightly more complex task to get the computer to make life easier for the user, too bad. Enough said. Tony Hansen hansen@pegasus.att.com, tony@attmail.com att!pegasus!hansen, attmail!tony   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04352; 4 Sep 93 20:05 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04348; 4 Sep 93 20:05 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa05725; 4 Sep 93 20:05 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA09761; Sat, 4 Sep 93 19:31:15 EDT Received: from alsvid.une.edu.au by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA09755; Sat, 4 Sep 93 19:31:12 EDT Received: by alsvid.une.edu.au id AA05178 (5.65c8+/IDA-1.4.4 for dimacs.rutgers.edu!ietf-822); Sun, 5 Sep 1993 09:31:03 +1000 Date: Sun, 5 Sep 1993 09:31:03 +1000 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: KLENSIN@wnet.edex.edu.au Message-Id: <199309042331.AA05178@alsvid.une.edu.au> Received: by wnet.edex.edu.au (\/<>\/ SmailAmiga 1.02j21) id ; Sun, 5 Sep 1993 07:27:50 +1000 Apparently-To: ietf-822@dimacs.rutgers.edu From dimacs.rutgers.edu!owner-ietf-822 Sat Sep 4 11:16:57 1993 Received: from dimacs.rutgers.edu by alsvid.une.edu.au with SMTP id AA14584 (5.65c8+/IDA-1.4.4 for ); Sun, 5 Sep 1993 06:41:55 +1000 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08536; Sat, 4 Sep 93 15:17:37 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08532; Sat, 4 Sep 93 15:17:36 EDT Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-13 #2603) id <01H2JTFD9S40000GKY@INFOODS.UNU.EDU>; Sat, 4 Sep 1993 15:16:58 EDT In-Reply-To: X-Envelope-To: ietf-822@DIMACS.RUTGERS.EDU Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Mail-System-Version: Message-Id: <747170217.728593.KLENSIN@INFOODS.UNU.EDU> Date: Sat, 04 Sep 1993 15:16:57 -0400 (EDT) From: John C Klensin To: nsb@thumper.bellcore.com Cc: ietf-822@dimacs.rutgers.edu, TROTH@ricevm1.rice.edu, jgm+@cmu.edu, sdorner@qualcomm.com Subject: Re: text/enriched: Throwing in the towel >What I had in mind for the default state of >text/enriched is more or less "it might be justified and it might not, >depending on what works and looks good locally." Nathaniel, It seems to me that what you are saying here might be translated into: (i) If justification is neither specified nor prohibited by the text, the output should be justified or not depending on implementation choices and local conventions. (ii) The person creating an enhanced text file can explicitly specify whether or not justification is to be performed; if she does, you pay attention. If that is the intent (and consensus), why not just say it? What I think we have learned by now about slightly ambiguous specs is that, rather than creating flexibility, they plant the seeds to religious wars about what was really meant. --john   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04451; 4 Sep 93 20:34 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04447; 4 Sep 93 20:34 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa06752; 4 Sep 93 20:34 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA09765; Sat, 4 Sep 93 19:31:17 EDT Received: from alsvid.une.edu.au by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA09757; Sat, 4 Sep 93 19:31:14 EDT Received: by alsvid.une.edu.au id AA05215 (5.65c8+/IDA-1.4.4 for dimacs.rutgers.edu!ietf-822); Sun, 5 Sep 1993 09:31:10 +1000 Date: Sun, 5 Sep 1993 09:31:10 +1000 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: sdorner@wnet.edex.edu.au Message-Id: <199309042331.AA05215@alsvid.une.edu.au> Received: by wnet.edex.edu.au (\/<>\/ SmailAmiga 1.02j21) id ; Sun, 5 Sep 1993 07:28:04 +1000 Apparently-To: ietf-822@dimacs.rutgers.edu From dimacs.rutgers.edu!owner-ietf-822 Sat Sep 4 09:05:43 1993 Received: from dimacs.rutgers.edu by alsvid.une.edu.au with SMTP id AA10980 (5.65c8+/IDA-1.4.4 for ); Sun, 5 Sep 1993 06:11:55 +1000 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08451; Sat, 4 Sep 93 15:05:26 EDT Received: from dorner.slip.uiuc.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08447; Sat, 4 Sep 93 15:05:22 EDT Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA00356 (5.65c/IDA-1.4.4 for ietf-822@dimacs.rutgers.edu); Sat, 4 Sep 1993 14:05:49 -0500 X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <199309041905.AA00356@dorner.slip.uiuc.edu> Date: Sat, 4 Sep 1993 14:05:43 -0500 From: sdorner@qualcomm.com (Steve Dorner) To: ietf-822@dimacs.rutgers.edu Subject: Re: text/enriched At 11:31 AM 9/4/93 -0500, Rick Troth wrote: > Sure, << looks better. Again, so what? >For pete's sake, don't make the protocol fit your eyes, >it's gotta fit the "eyes" of a myriad of different computers, >most of which neither you nor I have seen. The desire is for the protocol to fit the eyes of people using mail readers that do not understand the spec. The difficulty of writing a parser for text/richtext or text/enriched is hardly significant compared with the other problems mailer authors must tackle (RFC 822 address syntax, for example), so I really don't think implementation difficulty is an issue. If, by complicating the syntax a little, we can make something that is acceptable to non-MIME readers, that's definitely worthwhile. However, all the flak my users have given me about quoted-printable leads me to believe that this goal (acceptability of raw rich text to non-MIME readers) is laughable. Yes, nerds may prefer "x << y" 10:1 over "x y", but there are many users who will hate them both. And those users will complain to the senders, and the senders will stop sending text/rich to non-MIME mailers, making the looks of text/rich utterly irrelevant. So I guess I agree that how it looks is probably not important. No one will see it that way anyway. -- Steve Dorner, Qualcomm Inc.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04530; 4 Sep 93 21:05 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04526; 4 Sep 93 21:05 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa08438; 4 Sep 93 21:05 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA09868; Sat, 4 Sep 93 20:00:04 EDT Received: from alsvid.une.edu.au by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA09855; Sat, 4 Sep 93 19:59:58 EDT Received: by alsvid.une.edu.au id AA08771 (5.65c8+/IDA-1.4.4 for dimacs.rutgers.edu!ietf-822); Sun, 5 Sep 1993 09:59:51 +1000 Date: Sun, 5 Sep 1993 09:59:51 +1000 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: KLENSIN@wnet.edex.edu.au Message-Id: <199309042359.AA08771@alsvid.une.edu.au> Received: by wnet.edex.edu.au (\/<>\/ SmailAmiga 1.02j21) id ; Sun, 5 Sep 1993 07:28:43 +1000 Apparently-To: ietf-822@dimacs.rutgers.edu From dimacs.rutgers.edu!owner-ietf-822 Sat Sep 4 11:55:11 1993 Received: from dimacs.rutgers.edu by alsvid.une.edu.au with SMTP id AA18151 (5.65c8+/IDA-1.4.4 for ); Sun, 5 Sep 1993 07:11:47 +1000 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08827; Sat, 4 Sep 93 15:55:46 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08823; Sat, 4 Sep 93 15:55:45 EDT Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-13 #2603) id <01H2JTFD9S40000GKY@INFOODS.UNU.EDU>; Sat, 4 Sep 1993 15:55:11 EDT In-Reply-To: <199309041905.AA00356@dorner.slip.uiuc.edu> X-Envelope-To: ietf-822@DIMACS.RUTGERS.EDU Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Mail-System-Version: Message-Id: <747172511.94593.KLENSIN@INFOODS.UNU.EDU> Date: Sat, 04 Sep 1993 15:55:11 -0400 (EDT) From: John C Klensin To: sdorner@qualcomm.com Cc: ietf-822@dimacs.rutgers.edu Subject: Re: text/enriched >Yes, nerds may prefer "x << y" 10:1 over "x y", but there are many >users who will hate them both. And those users will complain to the >senders, and the senders will stop sending text/rich to non-MIME mailers, >making the looks of text/rich utterly irrelevant. Steve, This brings us nearly full circle on an old argument. To the degree to which your observation is true, you have just said "users won't be able to tolerate richtext without composing and display agents". But, if we basically assume that composing and display agents are going to be required for all functions except debugging (and nerd-nerd communication), then it is rational to make the language richer and let it support a broader range of specifications. Down that path lies not merely , but SGML with a fairly rich DTD. john   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04594; 4 Sep 93 21:26 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04590; 4 Sep 93 21:26 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa09066; 4 Sep 93 21:26 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA09859; Sat, 4 Sep 93 19:59:59 EDT Received: from alsvid.une.edu.au by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA09853; Sat, 4 Sep 93 19:59:51 EDT Received: by alsvid.une.edu.au id AA08749 (5.65c8+/IDA-1.4.4 for dimacs.rutgers.edu!ietf-822); Sun, 5 Sep 1993 09:59:47 +1000 Date: Sun, 5 Sep 1993 09:59:47 +1000 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: KLENSIN@wnet.edex.edu.au Message-Id: <199309042359.AA08749@alsvid.une.edu.au> Received: by wnet.edex.edu.au (\/<>\/ SmailAmiga 1.02j21) id ; Sun, 5 Sep 1993 07:28:25 +1000 Apparently-To: ietf-822@dimacs.rutgers.edu From dimacs.rutgers.edu!owner-ietf-822 Sat Sep 4 11:51:34 1993 Received: from dimacs.rutgers.edu by alsvid.une.edu.au with SMTP id AA16497 (5.65c8+/IDA-1.4.4 for ); Sun, 5 Sep 1993 06:57:55 +1000 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08794; Sat, 4 Sep 93 15:52:10 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08788; Sat, 4 Sep 93 15:52:09 EDT Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-13 #2603) id <01H2JTFD9S40000GKY@INFOODS.UNU.EDU>; Sat, 4 Sep 1993 15:51:35 EDT In-Reply-To: <199309032205.AA01040@dorner.slip.uiuc.edu> X-Envelope-To: ietf-822@DIMACS.RUTGERS.EDU Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Mail-System-Version: Message-Id: <747172294.651593.KLENSIN@INFOODS.UNU.EDU> Date: Sat, 04 Sep 1993 15:51:34 -0400 (EDT) From: John C Klensin To: sdorner@qualcomm.com Cc: allen@nyse.cox.smu.edu, ietf-822@dimacs.rutgers.edu Subject: Re: SNPP - A Clarification Allen, Let me take a half-step past Steve Dorner's comments, with which I basically agree... What you are hearing, I think, is a general sense that "one more protocol" is worse than "pushing a little on an existing one", just in terms of what is already deployed. We've got about 20 years of Internet experience to attest to the wisdom of that. You seem to have two main problems with using SMTP. One seems to be complexity; but people on this list are arguing forcefully that SMTP isn't inherently more complex than what you are proposing. The other seems to be the risks of getting involved in a store-and- forward situation. One way to eliminate that is to use SMTP client-to- remote server, just as you propose with SNPP. That was, curiously, the normal situation in early internet mail implementations: wide adoption of "send it to the local server and let it cope" came only later. The design ideas suggested below are not proposals but weak strawmen intended to help open up the discussion and thinking a bit. We do have some interesting artifacts lying around in SMTP that were intended for direct delivery to terminals (with or without "delivery to mailbox" fallbacks). It might be worthwhile for you to take a look at SEND FROM and its two cousins (SAML and SOML). In principle, if you really didn't want any relaying, you could even define an SMTP service extension of either the "don't relay at all" or the "deliver by YYYYMMDD HHMMSS or tell me" persuasions. Dealing with those service extensions would require changing clients and servers, but those changes are typically smaller than deploying a new protocol. And, by continuing to use the mail infrastructure, it is plausible that you could get pages through gateways from other mail services--e.g., by having a MIME message with specific content sent to a gateway that would set up the appropriate extended SMTP machinery from the message content. Eliminating the requirement for IP-connected Internet use only would seem like an advantage too. And it seems to me that you haven't argued for "real time" as much as for "fast delivery or notification". Let me make another suggestion: if you, and the "major national paging firm", invent a new protocol, its use will end up localized to a few gateway servers and clients that speak directly to them, probably by typing commands over a telnet connection (a nasty business, since everything has to be correct). The rest of the folks you are hearing from here, if they want to communicate with pagers offered by that firm, will just set up a mail-based protocol by which messages can be sent to pagers by routing them to gateways that accept SMTP/822/MIME and produce SNPP. Marshall suggested a variation on that theme in one of his notes, paralleling the remote printing experiment. If that is the case, the discussion here turns into one of whether there is value in injecting an SNPP middleman between SMTP/822/MIME machinery, which will be used anyway, and IXO on the far end. --john   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08064; 4 Sep 93 23:01 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08060; 4 Sep 93 23:01 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa12522; 4 Sep 93 23:01 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12451; Sat, 4 Sep 93 22:26:49 EDT Received: from netcom.netcom.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12447; Sat, 4 Sep 93 22:26:48 EDT Received: from netcom4.netcom.com by netcom.netcom.com (5.65/SMI-4.1/Netcom) id AA28135; Sat, 4 Sep 93 19:27:03 -0700 Date: Sat, 4 Sep 93 19:27:03 -0700 Message-Id: <9309050227.AA28135@netcom.netcom.com> To: ietf-822@dimacs.rutgers.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Marcus Colombano Subject: Re: text/enriched The "Rich Text Format" is a standard document ASCII exchange format. The format is opennly documented and supported by a number of document processing programs such as Wordperfect, MS Word, FrameMaker, PageMaker, Quark Express and so on. Has anyone considered this as a format to approach as a standard. Marcus V. Colombano Avantgarde/US 440 Merchant Street 2nd Floor San Franicisco, CA 94111 Tele: 415-397-4733 Fax: 415-434-0711 Email: mcolomba@netcom.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15131; 5 Sep 93 19:00 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15127; 5 Sep 93 19:00 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa22645; 5 Sep 93 19:00 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19485; Sun, 5 Sep 93 18:47:00 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19481; Sun, 5 Sep 93 18:46:59 EDT Received: from guppylake.noname (guppylake.bellcore.com) by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Sun, 5 Sep 93 18:46:38 EDT Received: by guppylake.noname (4.1/SMI-4.1) id AA23074; Sun, 5 Sep 93 18:47:13 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.guppylake.noname.sun4.41 via MS.5.6.guppylake.noname.sun4_41; Sun, 5 Sep 1993 18:47:12 -0400 (EDT) Message-Id: <8gWalk20M2UD8coj5t@thumper.bellcore.com> Date: Sun, 5 Sep 1993 18:47:12 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ietf-822@dimacs.rutgers.edu, nsb@bellcore.com, Steve Summit Subject: Re: risks of markup (bold, etc.) Cc: scs@eskimo.com In-Reply-To: <199309031340.AA05709@eskimo.com> References: <199309031340.AA05709@eskimo.com> Excerpts from mail: 3-Sep-93 risks of markup (bold, etc.) Steve Summit@eskimo.com (4326) > If there are related IETF mailing lists dealing specifically with > enriched text issues, could someone (i.e. Nathaniel, lest several > people do it) forward this message to those lists? I don't think there are any such lists. I also think that the "minimal conformance" section of the richtext & text/enriched documents make it pretty clear that text in an unimplemented formatting environment should NOT be thrown away... -- NB   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15307; 5 Sep 93 20:00 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15303; 5 Sep 93 20:00 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa24830; 5 Sep 93 20:00 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19653; Sun, 5 Sep 93 19:45:41 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19649; Sun, 5 Sep 93 19:45:40 EDT Received: from guppylake.noname (guppylake.bellcore.com) by thumper.bellcore.com (4.1/4.7) id for ietf-822@DIMACS.RUTGERS.EDU; Sun, 5 Sep 93 19:45:21 EDT Received: by guppylake.noname (4.1/SMI-4.1) id AA26584; Sun, 5 Sep 93 19:45:56 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.guppylake.noname.sun4.41 via MS.5.6.guppylake.noname.sun4_41; Sun, 5 Sep 1993 19:45:55 -0400 (EDT) Message-Id: <0gWbcny0M2UDIcocx0@thumper.bellcore.com> Date: Sun, 5 Sep 1993 19:45:55 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: John C Klensin Subject: Re: text/enriched: Throwing in the towel Cc: ietf-822@dimacs.rutgers.edu, TROTH@ricevm1.rice.edu, jgm+@cmu.edu, sdorner@qualcomm.com In-Reply-To: <747170217.728593.KLENSIN@INFOODS.UNU.EDU> References: <747170217.728593.KLENSIN@INFOODS.UNU.EDU> Excerpts from mail: 4-Sep-93 Re: text/enriched: Throwing.. John C Klensin@INFOODS.U (852*) > If that is the intent (and consensus), why not just say it? What I > think we have learned by now about slightly ambiguous specs is that, > rather than creating flexibility, they plant the seeds to religious wars > about what was really meant. Good point. I'll work on the wording. -- NB   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23679; 6 Sep 93 9:31 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23675; 6 Sep 93 9:31 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa21626; 6 Sep 93 9:31 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA26083; Mon, 6 Sep 93 09:15:33 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA26079; Mon, 6 Sep 93 09:15:32 EDT Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-13 #2603) id <01H2ME90IUB4000GVO@INFOODS.UNU.EDU>; Mon, 6 Sep 1993 09:15:03 EDT Date: Mon, 06 Sep 1993 09:15:02 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John C Klensin Subject: Re: WWW-RISKS-822ext comments In-Reply-To: <9309060804.AA03903@www3.cern.ch> To: timbl@nxoc01.cern.ch Cc: ietf-822@dimacs.rutgers.edu, risks@csl.sri.com Message-Id: <747321302.940593.KLENSIN@INFOODS.UNU.EDU> X-Envelope-To: ietf-822@DIMACS.RUTGERS.EDU Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Mail-System-Version: Tim Berners-Lee (Peter and 822ext recipients who don't know, Tim is the co-ordinator and main force behind the WWW effort) writes on Mon, 06 Sep 1993 10:04:56 +0200: >I seem to have missed this thread up to your message of > >Fri, 03 Sep 1993 12:28:34 -0400 (EDT) so i'd be interested to >know the original distribution. Perhasp I am missing from a list. > >> Proposed alternate main principle: Any time one designs something >> that can be extended, it is necessary to be extremely clear about >> what an "old" processor should do when it encounters an >> unrecognized extension. > >The HTML spec always intended that unknown tags or attributes >should be ignored, in the sense that the parser should behave as >though the TAG were not there, and process the content of the >element as though it had been content of the containing element. >This is also specified for HTML+. > >This means that the client which says it accepts HTML means that it >wil accept HTMLL with unknown junk which it will ignore. If a server >requires understanding of new tags, then the server has to invent a >suitable name for the new Content-Type and can't serve it as HTML. >Clients understanding the new type mention that in the HTTP >request, and so get it. >Which is the behaviour one wants of course. > >I don't see any value in saying "This is _kinda_ like HTML but if >you treat it as HTML you'll screw up". So I don't see much value in >allowing a form of tag for "incompatible extenstions". I agree >that having a way of distinguishing "safe to discard element" >would have been useful. Like -- what, tags beginning with "Z"? >It would have to be a rapid retrofit! > >Tim Berners-Lee Tim, The original note, which might be described as "new versions considered harmful" was posted to the ACM Risks forum (mailing list and newsgroup). That was followed by the posting of a copy to ietf-822 (the MIME list) as a cautionary note about some of the things that are being proposed with Nathaniel's "text/enhanced" (formerly "richtext") proposal. I didn't assume that you had a problem, only that you should be aware that the discussion had come up. The problem that stimulated the note apparently involved a client that discarded an element, rather than the associated tags. From your description, such a client is broken. Having not looked at the HTML definition language recently, that might have resulted from hasty reading, but that --and just sloppy program-writing-- are "risks" as much as bad definition. Seems to me that the value of defining an "incompatible extensions" model arises if one wants "version N" systems to be able to accept "version N+1" files. That is a design decision, one way or the other. But, if the answer is "no, don't even try to guess", it seems to me that must be very clear. In the particular case cited, the contention was that you shifted to "version 2" without any explanation or warning as a consequence of subsuming SGML. We would all agree that such shifts are a bad idea, but apparently some client-writers didn't get the message, which is a problem, somewhere. john   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23811; 6 Sep 93 10:00 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23807; 6 Sep 93 10:00 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa22608; 6 Sep 93 10:00 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA26165; Mon, 6 Sep 93 09:30:13 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA26161; Mon, 6 Sep 93 09:30:12 EDT Received: from guppylake.noname (guppylake.bellcore.com) by thumper.bellcore.com (4.1/4.7) id for ietf-822@DIMACS.RUTGERS.EDU; Mon, 6 Sep 93 09:29:54 EDT Received: by guppylake.noname (4.1/SMI-4.1) id AA10034; Mon, 6 Sep 93 09:30:29 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.guppylake.noname.sun4.41 via MS.5.6.guppylake.noname.sun4_41; Mon, 6 Sep 1993 09:30:28 -0400 (EDT) Message-Id: Date: Mon, 6 Sep 1993 09:30:28 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: John C Klensin Subject: Re: text/enriched: Throwing in the towel Cc: ietf-822@dimacs.rutgers.edu, TROTH@ricevm1.rice.edu, jgm+@cmu.edu, sdorner@qualcomm.com In-Reply-To: <747170217.728593.KLENSIN@INFOODS.UNU.EDU> References: <747170217.728593.KLENSIN@INFOODS.UNU.EDU> OK, I've changed the "Justification Commands" section to look like this -- comments welcome. Fill/Justification Commands Initially, text/enriched text is intended to be displayed fully filled with appropriate kerning and letter-tracking as suits the capabilities of the receiving user agent software. Actual line width is left to the discretion of the receiver, which is expected to fold lines intelligently (preferring soft line breaks) to the best of its ability. The following commands alter that state. Each of these commands force a line break before and after the formatting command if there is not otherwise a line break. For example, if one of these commands occurs anywhere other than the beginning of a line of text as presented, a new line is begun. Center -- causes the affected text to be centered. FlushLeft -- causes the affected text to be left-justified with a ragged right margin. FlushRight -- causes the affected text to be right-justified with a ragged left margin. Nofill -- causes the affected text to be displayed without filling or justification. The center, flushleft, and flushright commands are mutually exclusive, and, when nested, the inner command takes precedence. Whether or not text is justified by default (padded to create a smooth right margin) is unspecified, and depends on the capabilities of the local software and hardware and the tastes of the implementors. However, justification should not be performed inside of center, flushleft, flushright, or nofill environments. Note also that for some non-ASCII character sets, full justification may be fundamentally inappropriate.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24432; 6 Sep 93 13:33 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24428; 6 Sep 93 13:33 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa28442; 6 Sep 93 13:33 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29625; Mon, 6 Sep 93 13:26:32 EDT Received: from nyse.cox.smu.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29621; Mon, 6 Sep 93 13:26:31 EDT Received: by nyse.cox.smu.edu (Smail3.1.28.1 #1) id m0oZkKi-0000XEC; Mon, 6 Sep 93 12:26 CDT Message-Id: Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Allen Gwinn Subject: Re: SNPP - A Clarification To: Dave Crocker Date: Mon, 6 Sep 1993 12:26:27 -0500 (CDT) Cc: ietf-822@dimacs.rutgers.edu In-Reply-To: <9309061616.AA04626@Mordor.Stanford.EDU> from "Dave Crocker" at Sep 6, 93 09:16:13 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1590 > First, you may note that I'm copying John Klensin. He's an area director > for applications, under which this probably falls, and I'm not. I took > the initial contact with you to help off-load some work from him and because > I'm interested in the topic. But I want to make sure he is fully in the > loop on this. Your note doesn't contain anything that feels "private" so > i'm including him, but don't want to take liberties too far. Oh, I'm sorry. I meant to copy that to the list, but did not. Let me see if I can find a copy of it, and I'll forward it. > To quote an old joke, that means that we are mostly just haggling price. :-) > Therefore, if the IXO/TAP gateway did not like the pager "PIN" > number, the only way to be notified of failure is via email. > > I'll note that I'd expect the pin number to be in the email address, so > that that particular rejection could be in response to the RCPT-TO exchange. No! You can't do that, because the PIN can't even be presented to the IXO until *after* the DATA exchange. The packet going from the gateway to the IXO is made up of PIN+MESSAGE. You have to have the message in order to ship the PIN across. You should think of the exchange, rather than validating a PIN, the IXO terminal tells you "whether the page made it or not" and a reason. Therefore, the confirmation *must* take place after the final CRLF-.-CRLF (in the DATA segment). How much of a protocol change would this take to SMTP to allow immediate verification of receipt by the IXO terminal? How long would it take to "standardize?"   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24542; 6 Sep 93 14:00 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24538; 6 Sep 93 14:00 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa29197; 6 Sep 93 14:00 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29633; Mon, 6 Sep 93 13:27:37 EDT Received: from nyse.cox.smu.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29629; Mon, 6 Sep 93 13:27:36 EDT Received: by nyse.cox.smu.edu (Smail3.1.28.1 #1) id m0oZkLn-0000XEC; Mon, 6 Sep 93 12:27 CDT Message-Id: Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Allen Gwinn Subject: Re: SNPP - A Clarification To: ietf-822@dimacs.rutgers.edu Date: Mon, 6 Sep 1993 12:27:34 -0500 (CDT) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3383 Before I start, let me say that you have talked me into adding support for SMTP sessions into the ultimate goal of the paging system. I am not, however, convinced to drop SNPP. > Without commenting on the various details under discussion, I want to > raise a couple of questions: Why does SMTP "inherently" incur the > delay that you cite? While it is certainly true that general use of it > involves various sources of store-and-forward delay, I believe that > none of that is required, if a given sender wishes to accomplish a > "direct" interactive link to a given receiver. It isn't really the possible delay as much as it is the interaction with SMTP. I realize that SMTP could probably be modified to allow for a specific type of message to be aimed directly at a pager (maybe?). But if the message originated from a UUCP site, while perfectly legal to deliver it, the real time advantages that I seek would not be possible. SNPP, as I have said time and time again, is a simple protocol designed for immediate interaction with the paging terminal, replacing a phone line. It is not intended to be a two-way path for electronic mail. I do want to provide support for email connections, but want to do it right. Right now, I just want to get something up and running-- something that I've already developed, and that works. How long do you think it would take to get a full mail gateway into place and make modifications to SMTP to allow for immediate status reporting of failed or delivered pages? Case in point: you have to provide the beeper "PIN" and the message body itself to present to the IXO/TAP terminal in order to even get the terminal to tell you if the PIN was valid. In other words, the entire message (header and all) must be completely delivered before message validation can occur. It is my understanding that you cannot immediately reject a message on the DATA portion of the message--only on information contained in the header (RCPT TO in this case). Since you can't validate the page until after the DATA, you can't immediately reject it. Is this not the case? Therefore, if the IXO/TAP gateway did not like the pager "PIN" number, the only way to be notified of failure is via email. Don't you think that this would make a simple UA rather cumbersome to create? Consider one sitting on a PC running a Clarkson packet driver. It would have to sit there with an SMTP server active for a period of time after a page had been sent waiting for a bounce message that may or may not come. > That is, there is a big difference between protocol design and operational > configuration. > > On the matter of user agents, you are simultaneously challenging the > lack of any UA's designed specifically for paging while also stating a > desire to allow Telnet interaction with an SNPP server. These sound > like competing arguments, to me. (However, the argument for allowing > Telnet access reminds me of the original arguments for the design of > FTP, 20 years ago...) Actually not competing arguments. I want to be able to tell people how they can send messages to their beepers via the Internet starting "next Tuesday," and "this" is how they can do it. I also want to provide a spec so that software providers can create simple UA's to eventually do the job--perhaps integrating support for them into existing products.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03122; 4 Sep 93 14:30 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03118; 4 Sep 93 14:30 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa24067; 4 Sep 93 14:30 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08144; Sat, 4 Sep 93 14:21:58 EDT Received: from rutvm1.rutgers.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08140; Sat, 4 Sep 93 14:21:57 EDT Resent-Message-Id: <9309041821.AA08140@dimacs.rutgers.edu> Message-Id: <9309041821.AA08140@dimacs.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RUTVM1.RUTGERS.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 8981; Sat, 04 Sep 93 12:38:09 EDT Received: from RICEVM1.RICE.EDU (NJE origin MAILER@RICEVM1) by RUTVM1.RUTGERS.EDU (LMail V1.1d/1.7f) with BSMTP id 9616; Sat, 4 Sep 1993 12:38:09 -0400 Received: from ricevm1.rice.edu (NJE origin TROTH@RICEVM1) by RICEVM1.RICE.EDU (LMail V1.1d/1.7f) with BSMTP id 8514; Sat, 4 Sep 1993 11:38:27 -0500 Mime-Version: 1.0 Content-Type: text/plain Resent-Date: Sat, 04 Sep 93 11:38:18 CDT Resent-From: Rick Troth Resent-To: ietf-822@dimacs.rutgers.edu Mime-Version: 1.0 Content-Type: text/plain Date: Sat, 04 Sep 93 11:31:32 CDT Sender:ietf-archive-request@ricevm1.rice.edu From: Rick Troth Subject: Re: text/enriched To: "t.l.hansen" In-Reply-To: Your message of 3 Sep 1993 8:48 EDT >Now, if you want to talk about special case logic, how about the fact that > doesn't have a corresponding ? Now THAT's a special case! :-) doesn't change the state of the parser, does. Parser doesn't care, though, if there's no , it just keeps bolding the text until it gets EOF from the MUA. >Sorry, to me, your arguments aren't sufficient to override the fact that >"<<" LOOKS better than . Sure, << looks better. Again, so what? For pete's sake, don't make the protocol fit your eyes, it's gotta fit the "eyes" of a myriad of different computers, most of which neither you nor I have seen. > Tony Hansen > hansen@pegasus.att.com, tony@attmail.com > att!pegasus!hansen, attmail!tony -- Rick Troth , Rice University, Information Systems -- Rick Troth , Rice University, Information Systems   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25691; 6 Sep 93 15:00 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25687; 6 Sep 93 15:00 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa01192; 6 Sep 93 15:00 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29901; Mon, 6 Sep 93 14:33:38 EDT Received: from dorner.slip.uiuc.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29897; Mon, 6 Sep 93 14:33:32 EDT Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA01177 (5.65c/IDA-1.4.4 for ietf-822@dimacs.rutgers.edu); Mon, 6 Sep 1993 13:33:53 -0500 Message-Id: <199309061833.AA01177@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 6 Sep 1993 13:33:52 -0500 To: Allen Gwinn , ietf-822@dimacs.rutgers.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Dorner Subject: Re: SNPP - A Clarification At 12:27 PM 9/6/93 -0500, Allen Gwinn wrote: >SMTP. I realize that SMTP could probably be modified to allow for a >specific type of message to be aimed directly at a pager (maybe?). No modification to SMTP is necessary. You just need the "pager" to accept SMTP, just like you would need the "pager" to accept SNPP. >if the message originated from a UUCP site, while perfectly legal to >deliver it, the real time advantages that I seek would not be possible. SNPP would not be possible AT ALL from a UUCP site. So that fact that SMTP couldn't be done in real time from a UUCP site is not meaningful. >do you think it would take to get a full mail gateway into place >and make modifications to SMTP to allow for immediate status reporting >of failed or delivered pages? I don't see that any modifications to SMTP are necessary. >It is my understanding that you cannot immediately >reject a message on the DATA portion of the message--only >on information contained in the header (RCPT TO in this case). >Since you can't validate the page until after the DATA, you >can't immediately reject it. Is this not the case? It is not the case. I know of two major mailers that do in fact accept or reject messages based on the message data. All it takes is for the receiver SMTP to return something other than a 200-series error code in response to the DATA command. sndr: mail from: rcvr: 200 ok sndr: rcpt to: rcvr: 200 ok sndr: data rcvr: 354 fine sndr: to: pager sndr: from: someone sndr: x-pager-pin: 12345 sndr: sndr: Fire! Fire! sndr: . rcvr: 555 Invalid PIN. Page not accepted. OR rcvr: 456 Paging network down. Try later. OR rcvr: 200 Page transmitted. -- Steve Dorner, Qualcomm Inc.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27487; 6 Sep 93 15:30 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27483; 6 Sep 93 15:30 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa01955; 6 Sep 93 15:30 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29959; Mon, 6 Sep 93 14:43:53 EDT Received: from sayshell.umd.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29955; Mon, 6 Sep 93 14:43:44 EDT Received: from localhost by sayshell.umd.edu (NX5.67c/NeXT-1.0) id AA03336; Mon, 6 Sep 93 14:43:24 -0400 Message-Id: <9309061843.AA03336@sayshell.umd.edu> To: Allen Gwinn Cc: ietf-822@dimacs.rutgers.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Louis A. Mamakos" Subject: Re: SNPP - A Clarification In-Reply-To: Your message of "Mon, 06 Sep 1993 12:27:34 CDT." Date: Mon, 06 Sep 1993 14:43:24 -0400 X-Orig-Sender: louie@sayshell.umd.edu > It isn't really the possible delay as much as it is the interaction with > SMTP. I realize that SMTP could probably be modified to allow for a > specific type of message to be aimed directly at a pager (maybe?). But > if the message originated from a UUCP site, while perfectly legal to > deliver it, the real time advantages that I seek would not be possible. > SNPP, as I have said time and time again, is a simple protocol designed > for immediate interaction with the paging terminal, replacing a phone > line. It is not intended to be a two-way path for electronic mail. On the other hand, the UUCP site has no chance at all at using the SNPP over a TCP connection, so a few minutes delay vs. infinity perhaps isn't so bad. > I do want to provide support for email connections, but want to do > it right. Right now, I just want to get something up and running-- > something that I've already developed, and that works. How long > do you think it would take to get a full mail gateway into place > and make modifications to SMTP to allow for immediate status reporting > of failed or delivered pages? We've already developed and use in production an EMAIL to IXO paging gateway, and it works just fine. Our network management software doesn't use it, as it just generates pages directly, but other folks do use it. It simply pages the Subject: line of the email message as well as sending the message via email to the recipient. I don't know why I'd want to throw this away and use SNPP since it doesn't seem to buy me anything. > Case in point: you have to provide the beeper "PIN" and the > message body itself to present to the IXO/TAP terminal in > order to even get the terminal to tell you if the PIN was > valid. In other words, the entire message (header and all) > must be completely delivered before message validation can > occur. It is my understanding that you cannot immediately > reject a message on the DATA portion of the message--only > on information contained in the header (RCPT TO in this case). > Since you can't validate the page until after the DATA, you > can't immediately reject it. Is this not the case? Given a typical SMTP dialog like: 220 ni.umd.edu 5.65c/IDA-1.4.4 Sendmail is ready at Mon, 6 Sep 1993 14:28:16 -0400 >>> HELO sayshell.umd.edu 250 Hello sayshell.umd.edu, pleased to meet you >>> MAIL From: 250 ... Sender ok >>> RCPT To: 250 ... Recipient ok >>> DATA 354 Enter mail, end with "." on a line by itself >>> . 250 Ok >>> QUIT 221 ni.umd.edu closing connection There's no reason why the response to the CR LF '.' CR LF terminating the data can't be something othe rthan '250 Ok'. According to RFC-821 (that documents SMTP), the valid responses to the second phase of the data command are 250 ok 552 Requested mail action aborted; exceeded storage allocation 554 Transaction failed 451 Requested action aborted; local error in processing 452 Requested action not taken: unsufficient system storage You could certain return something other than "Transaction failed" as descriptive text if the PIN number (which no IXO system I've seen ever uses) was wrong. > Therefore, if the IXO/TAP gateway did not like the pager "PIN" > number, the only way to be notified of failure is via email. > Don't you think that this would make a simple UA rather > cumbersome to create? Consider one sitting on a PC running > a Clarkson packet driver. It would have to sit there with an SMTP > server active for a period of time after a page had been sent > waiting for a bounce message that may or may not come. Don't have the client wait around; return an error at the end of the DATA command. Of course, he still will never know that the page was delivered or not, due to lack of coverage, pager being turned off, etc. > Actually not competing arguments. I want to be able to tell people > how they can send messages to their beepers via the Internet starting > "next Tuesday," and "this" is how they can do it. I also want to > provide a spec so that software providers can create simple UA's to > eventually do the job--perhaps integrating support for them into > existing products. The way that we tell people is to send mail to username.beep@foo.dom.ain, which will page the "username" person. Nothing different than they've been doing for years, other than the addition of the ".beep" suffix on the user name. You have to be careful not to build too high a level of expection that devliver of the message will actually occur. As Marshall Rose pointed out, delays of 10 or 15 minutes are not unusual here in the Washington, DC area either. And given the open-loop nature of the page, you don't know that you missed a page because you were in an area of bad coverage. Frankly, I'd rather just have an RPC to the paging system rather than anything that has to go via an IXO gateway. Those paging system are just plain ugly. In any case, doing IXO is not that difficult; we do it in an expect script (checksums and all). Louis A. Mamakos University of Maryland, College Park   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27600; 6 Sep 93 16:00 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27596; 6 Sep 93 16:00 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa02702; 6 Sep 93 16:00 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA00980; Mon, 6 Sep 93 15:53:05 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA00976; Mon, 6 Sep 93 15:53:03 EDT Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-13 #2603) id <01H2ME90IUB4000GVO@INFOODS.UNU.EDU>; Mon, 6 Sep 1993 15:52:36 EDT Date: Mon, 06 Sep 1993 15:52:36 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John C Klensin Subject: Microsoft RTF (was: Re: text/enriched) In-Reply-To: <9309050227.AA28135@netcom.netcom.com> To: mcolomba@netcom.com Cc: ietf-822@dimacs.rutgers.edu Message-Id: <747345156.488799.KLENSIN@INFOODS.UNU.EDU> X-Envelope-To: ietf-822@DIMACS.RUTGERS.EDU Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Mail-System-Version: >The "Rich Text Format" is a standard document ASCII exchange format. The >format is opennly documented and supported by a number of document >processing programs such as Wordperfect, MS Word, FrameMaker, PageMaker, >Quark Express and so on. > >Has anyone considered this as a format to approach as a standard. Yes. Please see the archives before restarting this discussion. Note that your description includes several assertions/beliefs that are at least controversial and may not be true. john   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27678; 6 Sep 93 16:30 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27674; 6 Sep 93 16:30 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa04025; 6 Sep 93 16:30 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01024; Mon, 6 Sep 93 16:03:01 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01020; Mon, 6 Sep 93 16:03:00 EDT Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-13 #2603) id <01H2ME90IUB4000GVO@INFOODS.UNU.EDU>; Mon, 6 Sep 1993 16:02:31 EDT Date: Mon, 06 Sep 1993 16:02:31 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John C Klensin Subject: Re: SNPP - A Clarification In-Reply-To: To: allen@nyse.cox.smu.edu Cc: dcrocker@mordor.stanford.edu, ietf-822@dimacs.rutgers.edu Message-Id: <747345751.265799.KLENSIN@INFOODS.UNU.EDU> X-Envelope-To: ietf-822@DIMACS.RUTGERS.EDU Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Mail-System-Version: >How much of a protocol change would this take to SMTP to allow >immediate verification of receipt by the IXO terminal? None. This is a valid implementation decision. >How long >would it take to "standardize?" Minus ten years? john   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27760; 6 Sep 93 17:01 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27756; 6 Sep 93 17:01 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa05064; 6 Sep 93 17:00 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01015; Mon, 6 Sep 93 16:00:27 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01011; Mon, 6 Sep 93 16:00:26 EDT Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-13 #2603) id <01H2ME90IUB4000GVO@INFOODS.UNU.EDU>; Mon, 6 Sep 1993 15:59:42 EDT Date: Mon, 06 Sep 1993 15:59:42 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John C Klensin Subject: Re: text/enriched: Throwing in the towel In-Reply-To: To: nsb@thumper.bellcore.com Cc: ietf-822@dimacs.rutgers.edu, TROTH@ricevm1.rice.edu, jgm+@cmu.edu, sdorner@qualcomm.com Message-Id: <747345582.154799.KLENSIN@INFOODS.UNU.EDU> X-Envelope-To: ietf-822@DIMACS.RUTGERS.EDU Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Mail-System-Version: Center -- causes the affected text to be centered. FlushLeft -- causes the affected text to be left-justified with a ragged right margin. FlushRight -- causes the affected text to be right-justified with a ragged left margin. Nofill -- causes the affected text to be displayed without filling or justification. Nathaniel, Looks good, if that is what you want. I would have expected to see an explicit: FlushBoth -- causes the affected text to be filled and padded so as to create smooth left and right margins, i.e., fully justified, overriding the recommendation below. My personal aesthetics are such that it won't be missed; just want to be sure that everyone has the same understanding about what is to be agreed upon. john   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27895; 6 Sep 93 17:20 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27891; 6 Sep 93 17:20 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa05722; 6 Sep 93 17:20 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01123; Mon, 6 Sep 93 16:10:12 EDT Received: from THUD.CS.UTK.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01119; Mon, 6 Sep 93 16:10:11 EDT Received: from LOCALHOST by thud.cs.utk.edu with SMTP (5.61+IDA+UTK-930125/2.7c-UTK) id AA29244; Mon, 6 Sep 93 16:09:09 -0400 Message-Id: <9309062009.AA29244@thud.cs.utk.edu> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith Moore To: Allen Gwinn Cc: ietf-822@dimacs.rutgers.edu, moore@cs.utk.edu Subject: Re: SNPP - A Clarification In-Reply-To: Your message of "Mon, 06 Sep 1993 12:27:34 CDT." Date: Mon, 06 Sep 1993 16:09:08 -0400 X-Orig-Sender: moore@cs.utk.edu To: ietf-822@dimacs.rutgers.edu Subject: Re: SNPP - A Clarification Date: Mon, 6 Sep 1993 12:27:34 -0500 (CDT) Re: immediate status reporting of SMTP. An SMTP server *can* report a failure after the DATA command, but only for the entire envelope -- not on a per-recipient basis. If the message is short, and there is only one recipient, it doesn't really matter that much whether the recipient is declared invalid immediately after RCPT or after the DATA command. So for single recipient pages, an SMTP server could probably deliver the message immediately and report the status after the DATA command. Only for multiple recipients (with some successful deliveries and some failures), would the SMTP server have to mail back replies. None of this requires modifications to SMTP. Modifications to SMTP might still be useful to handle things like "deliver within ### seconds else fail", but aren't required for basic pager support. Keith Moore   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29524; 6 Sep 93 21:31 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa29520; 6 Sep 93 21:31 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa13055; 6 Sep 93 21:31 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03297; Mon, 6 Sep 93 21:01:10 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03277; Mon, 6 Sep 93 21:01:09 EDT Received: from guppylake.noname (guppylake.bellcore.com) by thumper.bellcore.com (4.1/4.7) id for ietf-822@DIMACS.RUTGERS.EDU; Mon, 6 Sep 93 21:00:55 EDT Received: by guppylake.noname (4.1/SMI-4.1) id AA20988; Mon, 6 Sep 93 21:01:29 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.guppylake.noname.sun4.41 via MS.5.6.guppylake.noname.sun4_41; Mon, 6 Sep 1993 21:01:29 -0400 (EDT) Message-Id: Date: Mon, 6 Sep 1993 21:01:29 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: John C Klensin Subject: Re: text/enriched: Throwing in the towel Cc: ietf-822@dimacs.rutgers.edu, TROTH@ricevm1.rice.edu, jgm+@cmu.edu, sdorner@qualcomm.com In-Reply-To: <747345582.154799.KLENSIN@INFOODS.UNU.EDU> References: <747345582.154799.KLENSIN@INFOODS.UNU.EDU> Excerpts from mail: 6-Sep-93 Re: text/enriched: Throwing.. John C Klensin@INFOODS.U (808*) > FlushBoth -- causes the affected text to be filled and padded so as > to create smooth left and right margins, i.e., fully justified, > overriding the recommendation below. > My personal aesthetics are such that it won't be missed; just want to be > sure that everyone has the same understanding about what is to be agreed > upon. Well, this is meaningless on systems that don't support justification, and the default state on systems that do, so I'm not convinced the environment is necessary. You can always just terminate your flushleft/flushright/center environment....   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03920; 6 Sep 93 23:30 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03916; 6 Sep 93 23:30 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa16589; 6 Sep 93 23:30 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA05940; Mon, 6 Sep 93 23:19:41 EDT Received: from dorner.slip.uiuc.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA05936; Mon, 6 Sep 93 23:19:31 EDT Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA01443 (5.65c/IDA-1.4.4 for ietf-822@DIMACS.RUTGERS.EDU); Mon, 6 Sep 1993 22:19:25 -0500 Message-Id: <199309070319.AA01443@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 6 Sep 1993 22:19:18 -0500 To: Nathaniel Borenstein , John C Klensin Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Dorner Subject: Re: text/enriched: Throwing in the towel Cc: ietf-822@dimacs.rutgers.edu, TROTH@ricevm1.rice.edu, jgm+@cmu.edu At 9:01 PM 9/6/93 -0400, Nathaniel Borenstein wrote: >Well, this is meaningless on systems that don't support justification, >and the default state on systems that do, so I'm not convinced the >environment is necessary. You can always just terminate your >flushleft/flushright/center environment.... Hmmm. So, to be absolutely clear, enriched has four states for justification: 1. fully justified or not, depending on the reader implementation's discretion 2. left justified 3. right justified 4. centered The default is state 1, and leaving all other states returns us to state 1. Correct? It would seem to be cleaner to have this set of states instead: 1. fully justified 2. left justified 3. right justified 4. centered And then to say that a reading implementation should pick the appropriate default between state 1 and state 2 (for left->right systems, states 1 and 3 for right->left). There isn't much practical difference, but it seems somehow more orderly. -- Steve Dorner, Qualcomm Inc.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01168; 7 Sep 93 7:01 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01164; 7 Sep 93 7:01 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa08144; 7 Sep 93 7:00 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08194; Tue, 7 Sep 93 06:34:17 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08190; Tue, 7 Sep 93 06:34:15 EDT Received: from guppylake.noname (guppylake.bellcore.com) by thumper.bellcore.com (4.1/4.7) id for ietf-822@DIMACS.RUTGERS.EDU; Tue, 7 Sep 93 06:34:01 EDT Received: by guppylake.noname (4.1/SMI-4.1) id AA25869; Tue, 7 Sep 93 06:34:34 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.guppylake.noname.sun4.41 via MS.5.6.guppylake.noname.sun4_41; Tue, 7 Sep 1993 06:34:33 -0400 (EDT) Message-Id: Date: Tue, 7 Sep 1993 06:34:33 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ietf-822@dimacs.rutgers.edu Subject: Re: text/enriched: Throwing in the towel In-Reply-To: <199309070319.AA01443@dorner.slip.uiuc.edu> References: <199309070319.AA01443@dorner.slip.uiuc.edu> Steve is right, as are those who've pointed out to me privately than an explicit would be handy for including excerpts from other messages. The current version of the justification prose follows.... Fill/Justification Commands Initially, text/enriched text is intended to be displayed fully filled with appropriate kerning and letter-tracking as suits the capabilities of the receiving user agent software. Actual line width is left to the discretion of the receiver, which is expected to fold lines intelligently (preferring soft line breaks) to the best of its ability. The following commands alter that state. Each of these commands force a line break before and after the formatting command if there is not otherwise a line break. For example, if one of these commands occurs anywhere other than the beginning of a line of text as presented, a new line is begun. Center -- causes the affected text to be centered. FlushLeft -- causes the affected text to be left-justified with a ragged right margin. FlushRight -- causes the affected text to be right-justified with a ragged left margin. FlushBoth -- causes the affected text to be filled and padded so as to create smooth left and right margins, i.e., to be fully justified. Nofill -- causes the affected text to be displayed without filling or justification. The center, flushleft, flushright, flushboth, and nofill commands are mutually exclusive, and, when nested, the inner command takes precedence. Whether or not text is justified by default (that is, whether the default environment is flushleft or flushboth) is unspecified, and depends on the capabilities of the local software and hardware and the tastes of the implementors. On systems where justification is considered undesirable, the flushboth environment may be identical to the flushleft environment (or flushright for right-to-left languages). However, justification should not be performed inside of center, flushleft, flushright, or nofill environments. Note also that for some non-ASCII character sets, full justification may be fundamentally inappropriate.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08887; 7 Sep 93 12:07 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08873; 7 Sep 93 12:07 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa26489; 7 Sep 93 12:06 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA11834; Tue, 7 Sep 93 11:28:01 EDT Received: from att-out.att.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA11830; Tue, 7 Sep 93 11:28:00 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: gsheehan@attmail.com Message-Version: 2 Date: Tue Sep 7 14:31:24 GMT 1993 Original-From: attmail!gsheehan (Gregory C Sheehan ) Message-Service: mail Received: from gsheehan by attmail; Tue Sep 7 14:31:24 GMT 1993 Mts-Message-Id: Ua-Content-Id: Email-Version: 2 X-Orig-Sender: moore@cs.utk.edu Phone: +1 908 949 9442 Subject: Re: standards/suggestions for MIME transport of PC filetypes? In-Reply-To: Your message of "Thu, 26 Aug 1993 14:05:00 PDT." <9308262223.AA20119@itgmsm> Ua-Message-Id: To: attmail!arch2!gcs@rutgers.edu Cc: ray@dimacs.rutgers.edu Cc: ietf-822@dimacs.rutgers.edu Message-Id: <9308271827.AA18335@thud.cs.utk.edu> Content-Type: text Content-Length: 1031 It is unwise to associate the content-type with a specific program name. Sometimes there will be more than one possible application that can deal with a particular content-type. Other times there will be one program used to display the content on the screen, while another one is used to print it on paper. And worst of all, this promotes the idea that a content-type is specific to a particular platform. I realize this is often the case now but platform-specific file formats are going to fall into disfavor (IMHO). As soon as you add a version parameter you have to define what it means. Does my reader have to have exactly the same version? Or any later version? Is "later" defined by comparing numerically or in ASCII collating sequence? Hopefully the various vendors will define file formats (and content-types) that are not specific to a particular platform, to be used when excanging data through the mail. Until then, we may well need content-types named product-x-by-vendor-y-for-operating-system-z Keith Moore   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09284; 7 Sep 93 12:31 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09280; 7 Sep 93 12:31 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa27881; 7 Sep 93 12:31 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12150; Tue, 7 Sep 93 11:52:06 EDT Received: from att-out.att.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12146; Tue, 7 Sep 93 11:52:05 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: gsheehan@attmail.com Message-Version: 2 Date: Tue Sep 7 14:24:27 GMT 1993 Original-From: attmail!gsheehan (Gregory C Sheehan ) Message-Service: mail Received: from gsheehan by attmail; Tue Sep 7 14:24:27 GMT 1993 Mts-Message-Id: Ua-Content-Id: Email-Version: 2 Phone: +1 908 949 9442 Subject: Re: standards/suggestions for MIME transport of PC filetypes? In-Reply-To: <9308262223.AA20119@itgmsm> Ua-Message-Id: To: attmail!arch2!gcs@rutgers.edu Cc: ray@dimacs.rutgers.edu Cc: ietf-822@dimacs.rutgers.edu Message-Id: <746463669.817392.KLENSIN@INFOODS.UNU.EDU> X-Envelope-To: ietf-822@DIMACS.RUTGERS.EDU Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT Mail-System-Version: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Length: 1206 >A quick look at this seems to imply that the following information needs to >be carried in some field, (i.e. subtype): > >Application Name == Application that the data are intended for >Environment == i.e. DOS, Windows, OS2 version of the product >Version Number == The product version number for that environment. > >An example might look like this for an application called "FOO" where FOO is >the subtype of the application content type, and the Environment and Version >are parameters of this subtype. I see a possibly-important distinction here, and am not sure what is being proposed. Possibility 1: The above constitutes a start at good guidance about issues to be thought of in the context of the application, possible interpreters of the application's files that are not the application itself, etc. But the decisions as to what to use ultimately get worked out on a FOO by FOO basis, since different applications may have different requirements. Possibility 2: This is a proposal for redefining the MIME "application" major type in a way that would add more structure to it, i.e., to standardize or possibly require the "environment" and "version" parameters. john   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09683; 7 Sep 93 13:04 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09679; 7 Sep 93 13:04 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa29557; 7 Sep 93 13:04 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12168; Tue, 7 Sep 93 11:53:12 EDT Received: from att-out.att.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12164; Tue, 7 Sep 93 11:53:09 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: gsheehan@attmail.com Message-Version: 2 Date: Tue Sep 7 14:25:31 GMT 1993 Original-From: attmail!gsheehan (Gregory C Sheehan ) Message-Service: mail Received: from gsheehan by attmail; Tue Sep 7 14:25:31 GMT 1993 Mts-Message-Id: Ua-Content-Id: Email-Version: 2 Phone: +1 908 949 9442 Subject: Re[2]: standards/suggestions for MIME transport of PC filetypes? Ua-Message-Id: To: attmail!arch2!gcs@rutgers.edu Cc: ietf-822@dimacs.rutgers.edu Message-Id: <000X5P@KIRK.UII.COM> X-Mailer: NetMail/3000 [Version A.04 93/06/12] Mime-Version: 1.0 X-Hpdesk-Priority: 3 (Normal Priority) Content-Type: text/plain Content-Length: 2702 In <9308262223.AA20119@itgmsm> sukvg@microsoft.com writes: > I have had a few discussions on how useful it would be to have specific > content-type application subtypes that define the application that the data > are intended for, and I agree with Steve's comment that it is infact very > useful to know what the "incomprehensible gook" is when we get it, but that > it should not require that a MIME reader have to support displaying it > without any help. > > A quick look at this seems to imply that the following information needs to > be carried in some field, (i.e. subtype): > > Application Name == Application that the data are intended for > Environment == i.e. DOS, Windows, OS2 version of the product > Version Number == The product version number for that environment. > > An example might look like this for an application called "FOO" where FOO is > the subtype of the application content type, and the Environment and Version > are parameters of this subtype. > > Intended for a DOS version of this product > > Application\FOO; Environment="DOS"; Version="3.24a" > > Intended for a Windows version of this product > > Application\FOO; Environment="WINDOWS"; Version="5.12" We considered these possibilities as well in our implementation but came to the conclusion that overqualifying the items in the headers really didn't help a mime reader much. As an implementer, we could never hope to correctly identify all the different types/environments/versions out there, and adding these fields to the headers implies that the reader ought to know what's relevant in (at least some) cases. Personally, I think a better approach is to follow the current registration procedures for MIME types, and let people that know the data files decide when a type is portable by defining a new application subtype for filetypes that are going to be portable. If wordperfect (for example) is deemed to be a useful document type, and version x.1 documents are not compatible with version y.2, then register a different subtype for each, and let the MIME UAs pass them through the same type of generic viewer/lookup process we do now. I think we get the desired functionality without changing the MIME structure. For those packages that already implement the same format across platforms, only one subtype would be needed and the generic MIME UA neither knows nor cares. If the format is portable, I don't think the platform or version would be of concern to either a user or UA. For now we're going to do it that way, while adding the kludge to check the ;NAME= to try and handle the exceptions by looking for .EXTensions. -Chris Bartram   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09729; 7 Sep 93 13:06 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09725; 7 Sep 93 13:06 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa29773; 7 Sep 93 13:06 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12031; Tue, 7 Sep 93 11:40:06 EDT Received: from att-out.att.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12027; Tue, 7 Sep 93 11:40:05 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: gsheehan@attmail.com Message-Version: 2 Date: Tue Sep 7 14:37:27 GMT 1993 Original-From: attmail!gsheehan (Gregory C Sheehan ) Message-Service: mail Received: from gsheehan by attmail; Tue Sep 7 14:37:27 GMT 1993 Mts-Message-Id: Ua-Content-Id: Email-Version: 2 Phone: +1 908 949 9442 Subject: Re: standards/suggestions for MIME transport of PC filetypes? In-Reply-To: <9308271827.AA18335@thud.cs.utk.edu> Ua-Message-Id: To: attmail!arch2!gcs@rutgers.edu Cc: sukvg@dimacs.rutgers.edu Cc: ietf-822@dimacs.rutgers.edu Message-Id: <746571209.506392.KLENSIN@INFOODS.UNU.EDU> X-Envelope-To: ietf-822@DIMACS.RUTGERS.EDU Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT Mail-System-Version: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Length: 4496 >It is unwise to associate the content-type with a specific program name. >Sometimes there will be more than one possible application that can deal >with a particular content-type. Other times there will be one program used Keith, I think that sometimes we get sloppy about language and confused about what we are talking about. At least I hope that is what is happening here. To pick on WordPerfect, since people have been using it in examples, we could have application/WordPerfect-the-application or application/the-file-format-WordPerfect-uses-by-default we could call either "WordPerfect", although I agree that it is the second we want to use/describe/register, not the first. >As soon as you add a version parameter you have to define what it means. Sure. But you don't need the same answer for all application subtypes, which is the problem with making a general rule. >Until then, we may well need content-types named >product-x-by-vendor-y-for-operating-system-z Well, file-format-produced/read-by-product-x-by-vendor-y-for-operating-system-z But I think something is getting lost in trying to generalize. Let's try a slightly different model of what is going on, then come back to WordPerfect (real example this time). Assume that, in writing Content-type: application/foo; baz-string we are just trying to give sufficient information to an applications-dispatcher (something that sends things *to* an application or processor based on a file type) to: o determine where to send the thing or o determine that it doesn't know what to do with it. In this model, while we have provided some lexical structure to "baz-string" for our general convenience, its semantics are strictly up to the application or processor-- we would expect the dispatcher to just pass that information along in some sort of structure, not, in general, to try to interpret it usefully. Now let's assume we have an application from Crock Company called "Crock" and which uses "Crock files". Files for version 2 of Crock are completely non-interoperable with version 1 and vice versa; nearly the only thing they have in common is the Crock name. Interplatform differences are as bad or worse. This situation is stupid, but not uncommon at present. Now, if someone wants to register (a) Crock type(s), they would be well advised to register application/Crock-file-version-1-DOS application/Crock-file-version-2-DOS application/Crock-file-version-1-UNIX etc. If they instead register application/Crock-file; platform=... ; version=... then the dispatcher is going to need to engage in a dialogue with potential Crock-agents (dispatching targets) as to whether _this_ Crock file is one that they can handle. In this case, the Crock-agents at least have the platform and version info to help, assume that is Crock-systematic (as you know, sometimes it isn't). If it were absent, they would have to look at the file and just return "not me, try someone else" as that dialogue. But WordPerfect files (e.g.) are a different case. There is a canonic rule about what major and minor versions mean. The application program of the same name at a given version will read the files of all earlier versions, and competent WordPerfect-to-something conversion programs do this too (it isn't hard, and WP Corp nearly gives away the tools). So a sensible person might want to register application/WordPerfect-file; version=N.m; platform=xxx Interestingly, file format versions for WordPerfect don't necessarily correspond to product release versions: probably 99% of users don't have a clue as to the file format versions they are using. And "platform" may be completely unnecessary. The problem is that one would need more information than is available to me as a sometime-developer to know whether it is necessary to specify "platform" or whether version information should be specified in terms of product versions or file versions. I don't know how to get good advice on that without getting the vendor involved in a major way. We also have a conflict here between content-subtypes for exchange among consenting adults using the same (or naturally interoperable) products and content-subtypes for interoperability. For the latter, we should be ignoring all of this platform- and implementor-specific stuff and concentrating on formats that are implemented on many platforms and for which stable public specifications are available. --john   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10211; 7 Sep 93 13:34 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10207; 7 Sep 93 13:34 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa00961; 7 Sep 93 13:34 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA13095; Tue, 7 Sep 93 12:59:58 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA13087; Tue, 7 Sep 93 12:59:57 EDT Received: from guppylake.noname (guppylake.bellcore.com) by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Tue, 7 Sep 93 12:59:52 EDT Received: by guppylake.noname (4.1/SMI-4.1) id AA19762; Tue, 7 Sep 93 13:00:26 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.guppylake.noname.sun4.41 via MS.5.6.guppylake.noname.sun4_41; Tue, 7 Sep 1993 13:00:24 -0400 (EDT) Message-Id: Date: Tue, 7 Sep 1993 13:00:24 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: Yutaka Sato/=?ISO-2022-JP?B?GyRAOjRGI0stGyhK?= , ietf-822@dimacs.rutgers.edu Subject: Re: error message of metamail In-Reply-To: References: <8gX=Uem0M2UDEcog9K@thumper.bellcore.com> I'm very sorry that some mail from Yutaka Sato has gotten overlooked in the midst of everyone's summer vacations: > I hope the message/partial type to be more ROBUST against some ill > mannered MTAs and MUAs which automatically insert something before > or after a message body. > For example, I know a mail-list handler and a mail-to-news gateway, > which insert additional information at beginning of bodies of resent > messages. And "Inews" appends ".signature" file at the end of > article body. > Can I save partical messages from such destructions ? > If there is no way to do so, I wish some extension to be added to > the spec. of message/partial, or need new content type like > "MESSAGE/ROBUST-PARTIAL" to be introduced. I think the most > naive solution is introducing "boundary" parameter to the partial > message, and wrap up the message body with the defined boundary. > (Such MTAs/MUAs are also harmful to all of basic content-types like > audio and image, but they can be saved by enclosing them in a > multipart message.) I think this message is worth answering, but I don't see any good answer. In particular, I haven't been able to come up with a better answer than "the programs that do these things should be made MIME-smart." I think that a message/robust-partial would be a major new complication to MIME at this point. Does anyone have any other ideas? The only other one that occurs to me is wrapping each message/partial up as a one-part multipart message, since multipart has this robustness quality you seek. Note that in these casees, the things prepended or appended to the body will be thrown away, so this still doesn't change the general advice that it would make sense to update these programs and make them MIME-smart.... -- Nathaniel   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11138; 7 Sep 93 14:02 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11129; 7 Sep 93 14:02 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa02782; 7 Sep 93 14:02 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA15944; Tue, 7 Sep 93 13:53:17 EDT Received: from etlpost.etl.go.jp by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA15938; Tue, 7 Sep 93 13:53:02 EDT Received: from etlpom.etl.go.jp by etlpost.etl.go.jp (5.67+1.6W/2.7W) id AA21963; Wed, 8 Sep 93 02:52:37 JST Received: by etlpom.etl.go.jp (4.1/6.4J.6-ETLpom.MASTER) id AA02679; Wed, 8 Sep 93 02:52:35 JST Received: by etlkbs.etl.go.jp (4.1/6.4J.6-ETL.SLAVE) id AA09756; Wed, 8 Sep 93 02:53:31 JST Date: Wed, 8 Sep 93 02:53:31 JST Return-Path: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: nsb@thumper.bellcore.com Cc: ietf-822@dimacs.rutgers.edu Subject: Robustness of message/partial Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Yutaka Sato/=?ISO-2022-JP?B?GyRAOjRGI0stGyhK?= Organization: Electrotechnical Laboratory, Tsukuba Science City Message-Id: References: <8gX=Uem0M2UDEcog9K@thumper.bellcore.com> In message on 09/08/93(02:00:24) you Nathaniel Borenstein wrote: |I'm very sorry that some mail from Yutaka Sato has gotten overlooked in |the midst of everyone's summer vacations: The original subject was "Robustness of message/partial" :-) |> I hope the message/partial type to be more ROBUST against some ill |> mannered MTAs and MUAs which automatically insert something before |> or after a message body. | |> For example, I know a mail-list handler and a mail-to-news gateway, |> which insert additional information at beginning of bodies of resent |> messages. And "Inews" appends ".signature" file at the end of |> article body. | |> Can I save partial messages from such destructions ? | |> If there is no way to do so, I wish some extension to be added to |> the spec. of message/partial, or need new content type like |> "MESSAGE/ROBUST-PARTIAL" to be introduced. I think the most |> naive solution is introducing "boundary" parameter to the partial |> message, and wrap up the message body with the defined boundary. | |> (Such MTAs/MUAs are also harmful to all of basic content-types like |> audio and image, but they can be saved by enclosing them in a |> multipart message.) | |I think this message is worth answering, but I don't see any good |answer. In particular, I haven't been able to come up with a better |answer than "the programs that do these things should be made |MIME-smart." I think that a message/robust-partial would be a major new |complication to MIME at this point. Does anyone have any other ideas? | |The only other one that occurs to me is wrapping each message/partial up |as a one-part multipart message, since multipart has this robustness |quality you seek. Note that in these casees, the things prepended or |appended to the body will be thrown away, so this still doesn't change |the general advice that it would make sense to update these programs and |make them MIME-smart.... -- Nathaniel Although I think your idea is good, I can point out a problem of it. It may make automatic collection of partial messages expensive because we must peep the body of each message to examine if it is a partial message of the currently assembling message. But practically, it will not be so expensive because we can get hints from the Subject field before investigating the body part header to get the parameters "id" and "number" of the encapsulated partial message. I prefer your idea to mine. Yutaka -- Yutaka Sato Information Base Section ELECTROTECHNICAL LABORATORY 1-1-4 Umezono, Tsukuba, Ibaraki, 305 Japan   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16161; 7 Sep 93 18:05 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16157; 7 Sep 93 18:05 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa16446; 7 Sep 93 18:05 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA18522; Tue, 7 Sep 93 17:38:21 EDT Received: from eco.twg.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA18518; Tue, 7 Sep 93 17:38:18 EDT Received: from LOCAL.eco.twg.com by eco.twg.com (5.67/ECO.m-$Revision: 2.16 $) id AA06361; Tue, 7 Sep 93 17:37:22 -0400 Message-Id: <9309072137.AA06361@eco.twg.com> Received: from apache.twg.com by apache.twg.com id <26787-0@apache.twg.com>; Tue, 7 Sep 1993 14:37:39 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: David Herron Subject: Idle curiosity -- Time to implement MIME To: IETF-822 Discussion Date: Tue, 7 Sep 93 14:37:37 PDT Sensitivity: Personal Conversion: Prohibited Conversion-With-Loss: Prohibited Encoding: 17 TEXT Idle curiosity mind you ... Those of you who have implemented MIME from scratch please try and answer the following question: How much effort (man months?) did it take to implement a MIME parser? The parser must produce a data structure within which the body parts are attached. Must be able to produce a new instance of the message (or any body part) from the data structure. There must be no policy decisions in the parser on the order of presenting the body parts; that is decided by other code. Don't include RichText implementation .. David   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16440; 7 Sep 93 18:32 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16436; 7 Sep 93 18:32 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa18142; 7 Sep 93 18:32 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA18931; Tue, 7 Sep 93 18:21:23 EDT Received: from ppp.dbc.mtview.ca.us by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA18927; Tue, 7 Sep 93 18:21:20 EDT Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA00228; Tue, 7 Sep 93 15:20:02 -0700 To: David Herron Reply-To: IETF-822 Discussion Cc: IETF-822 Discussion Subject: Re: Idle curiosity -- Time to implement MIME In-Reply-To: Your message of "Tue, 07 Sep 1993 14:37:37 PDT." <9309072137.AA06361@eco.twg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <208.747440398.1@dbc.mtview.ca.us> Date: Tue, 07 Sep 1993 15:19:59 -0700 Message-Id: <211.747440399@dbc.mtview.ca.us> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Marshall Rose > How much effort (man months?) did it take to implement a MIME parser? It took less than one week to write the first version of mhn. This was a lot more than the parser. There was a beta period of several months in which some bugs were fixed and some enhancements added. Until last week when a new bug was reported, I hadn't had to crack the code for about four months... /mtr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16769; 7 Sep 93 19:32 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16765; 7 Sep 93 19:32 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa21622; 7 Sep 93 19:32 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19392; Tue, 7 Sep 93 19:22:18 EDT Received: from uqcspe.cs.uq.oz.au by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19388; Tue, 7 Sep 93 19:22:16 EDT Received: from everest.cs.uq.oz.au by uqcspe.cs.uq.oz.au id ; Wed, 8 Sep 93 09:21:59 +1000 Date: Wed, 8 Sep 93 09:21:58 +1000 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: rhys@cs.uq.oz.au Message-Id: <9309072321.AA03504@client> To: david@twg.com, ietf-822@dimacs.rutgers.edu Subject: Re: Idle curiosity -- Time to implement MIME >Idle curiosity mind you ... > >Those of you who have implemented MIME from scratch please try and answer >the following question: > >How much effort (man months?) did it take to implement a MIME parser? Just the parsing code, or the whole viewing she-bang? I whipped up a C++ parser for MIME messages in a couple of weeks in my spare time. It builds a data structure, and does some mailcap-like lookups to find programs to pass body parts off to if they aren't understood internally. The viewing pieces (for Microsoft Windows) took a little longer, and are still evolving. >There must be no policy decisions in the parser on the order of presenting >the body parts; that is decided by other code. My code does have a few policy decisions: multipart messages are assumed to be presented in order. Multipart/alternative messages have all alternatives loaded into memory, and then I use some heuristics to determine which one to display, but leaving open the option for other alternatives to be displayed later. But, if you were perverse enough, you could traverse the data structure in any way you wanted. >Don't include RichText implementation .. I haven't got that far yet: working on it now. C++ is ideally suited to parsing MIME messages if you choose the right model. Mine uses a kind of "filter stream": bytes are extracted from the raw message with one filter, quoted-printable and base64 are stripped by the next one, the message is split at boundary lines for multipart body parts in the next, and the final filter handles the particular kind of body part (text/plain, text/enriched, image/gif, etc). Just add a new subclass, and presto, a new filter! By glueing together filters, you can do almost any kind of parsing. e.g. to parse an base64'ed image/gif inside a multipart/mixed, inside a multipart/alternative, you'd link together the following filters: gif -> base64 -> multipart -> multipart -> read Each filter calls on the next to get more bytes, and as far as it is concerned it is just calling a normal system call like "read". Filters are gradually added and removed from the list as you move down through the message. Cheers, Rhys.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17314; 7 Sep 93 21:37 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17310; 7 Sep 93 21:37 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa26435; 7 Sep 93 21:37 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA22361; Tue, 7 Sep 93 21:06:50 EDT Received: from SIGURD.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA22357; Tue, 7 Sep 93 21:06:46 EDT Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.3-0 #1234) id <01H2NW4YYTSW8Y4YM2@SIGURD.INNOSOFT.COM>; Tue, 7 Sep 1993 18:06:14 PDT Date: Tue, 07 Sep 1993 17:50:16 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ned Freed Subject: Re: Idle curiosity -- Time to implement MIME In-Reply-To: Your message dated "Tue, 07 Sep 1993 14:37:37 -0700 (PDT)" <9309072137.AA06361@eco.twg.com> To: David Herron Cc: IETF-822 Discussion Message-Id: <01H2OCJ0803G8Y4YM2@SIGURD.INNOSOFT.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > How much effort (man months?) did it take to implement a MIME parser? It is hard for me to say for sure -- I implemented my MIME parser very early and then updated it to track changes in the specification. In addition, my parser supports nested encodings (but decodes all of them in a single pass). This complicates things quite a bit, but this was part of the specification when I wrote the code and I never bothered to tear it all out. When you knock off all the tracking activity I figure it took about 1.5 weeks. (I wrote the decoder during the Atlanta IETF in the evening. The rest took about a week of additional work.) > The parser must produce a data structure within which the body parts > are attached. Must be able to produce a new instance of the message > (or any body part) from the data structure. Sure, my code does all this and lots more stuff as well, like on-the-fly downgrading from 8bit MIME to 7bit MIME. > There must be no policy decisions in the parser on the order of presenting > the body parts; that is decided by other code. This is actually a problem in my case. The problem isn't the data structure, which is reasonably straightforward, but the language used to specify processing order, alternative selection, etc. I've yet to come up with a decent grammar that let's people tell the code what they want. (Recall that I build gateways, not user agents.) > Don't include RichText implementation .. I'm not. Ned P.S. I should also mention that I code my email software in a mixture of Pascal and C. Pascal's lexical scoping was what made the single-pass nested decoder not only doable but rather elegant. It would be a really nasty bit of code in C and would have taken far longer to write and debug.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20868; 7 Sep 93 23:03 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20864; 7 Sep 93 23:03 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa29501; 7 Sep 93 23:03 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA22843; Tue, 7 Sep 93 22:44:40 EDT Received: from Sun.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA22839; Tue, 7 Sep 93 22:44:39 EDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA12848; Tue, 7 Sep 93 19:44:31 PDT Received: from vision.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA26268; Tue, 7 Sep 93 19:46:55 PDT Received: by vision.Eng.Sun.COM (5.0/SMI-SVR4) id AA12021; Tue, 7 Sep 93 19:44:23 PDT Date: Tue, 7 Sep 93 19:44:23 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Vincent Lau Message-Id: <9309080244.AA12021@vision.Eng.Sun.COM> To: ietf-822@dimacs.rutgers.edu, david@twg.com Subject: Re: Idle curiosity -- Time to implement MIME X-Sun-Charset: US-ASCII Content-Length: 1458 >How much effort (man months?) did it take to implement a MIME parser? I integrated the MIME (based on the spec from Atlanta IETF) parser (read-only) into Sun's Mailtool (User Agent) in about 2 weeks. Then I spent 2 more weeks to convert Sun's propriertary Mailtool attachment format to and from MIME format, but kept the UI and behavior identical. Finally, I spent another 2 weeks to allow Mailtool to handle the conversion between Multipart message to and from non-Multipart message. By the Santa Fe IETF meeting, I had a working version of Mailtool that could send/receive MIME message and converted back/forth to Sun's propriertary attachment format. >The parser must produce a data structure within which the body parts >are attached. Must be able to produce a new instance of the message >(or any body part) from the data structure. > My parser produced a generalized structure for MIME and Sun's attachment format. It used Sun's Classing Engine to map the content-type to the proper message viewing program. >There must be no policy decisions in the parser on the order of presenting >the body parts; that is decided by other code. > The parser didn't impose any policy on the body parts. But the Mailtool (UA) did because I tried to make the seamless integration of MIME into the Mailtool. The Mailtool treated the first text body part differently. >Don't include RichText implementation .. No, I didn't implement RichText. -Vincent   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01477; 8 Sep 93 8:00 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01473; 8 Sep 93 8:00 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa01621; 8 Sep 93 8:00 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA24928; Wed, 8 Sep 93 07:31:51 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA24924; Wed, 8 Sep 93 07:31:50 EDT Received: from guppylake.noname (guppylake.bellcore.com) by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Wed, 8 Sep 93 07:31:42 EDT Received: by guppylake.noname (4.1/SMI-4.1) id AA18781; Wed, 8 Sep 93 07:32:17 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.guppylake.noname.sun4.41 via MS.5.6.guppylake.noname.sun4_41; Wed, 8 Sep 1993 07:32:16 -0400 (EDT) Message-Id: <0gXQ=0i0M2UDQcoa8t@thumper.bellcore.com> Date: Wed, 8 Sep 1993 07:32:16 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: IETF-822 Discussion , David Herron Subject: Re: Idle curiosity -- Time to implement MIME In-Reply-To: Message from " David Herron " dated "Tue, 7 Sep 93 14:37:37 PDT" I've implemented MIME twice, one of which it's easy to answer about. I added MIME support to Andrew in about 3 days. It doesn't quite meet your criteria for data structures directly, because it does on-the-fly translation into Andrew format, which does have pretty much all the properties you mention. And this DOES include richtext support, by the way. Metamail is harder to answer about. It is a standalone program that liberally accepts a vast superset of MIME and does any number of things with it. The first version of metamail was written BEFORE any of the MIME discussions started, as an implementation vehicle for other mail experiments I was performing, notably ATOMICMAIL. There has been a working version of metamail that corresponded to every single draft of the MIME specification. All in all, I've probably put six months of work into metamail, but this clearly is a vast overstatement of the amount of effort involved in implementing MIME.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01533; 8 Sep 93 8:02 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01529; 8 Sep 93 8:02 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id ac01818; 8 Sep 93 8:02 EDT Received: from dimacs.rutgers.edu by IETF.CNRI.Reston.VA.US id aa00692; 8 Sep 93 5:59 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA24305; Wed, 8 Sep 93 03:04:17 EDT Received: from tel13.tel.vtt.fi by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA24301; Wed, 8 Sep 93 03:04:15 EDT Received: by tel13.tel.vtt.fi id AA01775 (5.65c/IDA-1.4.4 for ietf-822@dimacs.rutgers.edu); Wed, 8 Sep 1993 10:04:44 +0300 Date: Wed, 8 Sep 1993 10:04:44 +0300 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Markku Savela Message-Id: <199309080704.AA01775@tel13.tel.vtt.fi> To: ietf-822@dimacs.rutgers.edu In-Reply-To: "David Herron"'s message of Tue, 7 Sep 93 14:37:37 PDT <9309072137.AA06361@eco.twg.com> Subject: Idle curiosity -- Time to implement MIME Reply-To: Markku Savela >How much effort (man months?) did it take to implement a MIME parser? The real time from start to end was about 1 month (I did this last April), and some occasional fixes and tweaks once in while later. But, for the plain parser part, I think I go with the others here: 2-3 weeks testing and all included. (Mailing this just to give a data point of yet another independent MIME parser implementation. Is someone making a count of them? :-) --msa   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01543; 8 Sep 93 8:02 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01539; 8 Sep 93 8:02 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id ad01818; 8 Sep 93 8:02 EDT Received: from dimacs.rutgers.edu by IETF.CNRI.Reston.VA.US id aa00701; 8 Sep 93 6:00 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA23697; Wed, 8 Sep 93 01:51:38 EDT Received: from eitech.eitech.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA23693; Wed, 8 Sep 93 01:51:37 EDT Received: by eitech.com (4.1/SMI-4.1) id AA01316; Tue, 7 Sep 93 22:50:44 PDT Date: Tue, 7 Sep 93 22:50:44 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Jay C. Weber" Message-Id: <9309080550.AA01316@eitech.com> To: david@twg.com, ietf-822@dimacs.rutgers.edu Subject: Re: Idle curiosity -- Time to implement MIME I did the MIME parser for ServiceMail in about one week, though it was probably another week total over the subsequent year for bug fixes and full MIME support (fixing quotation in parameters, getting message reassembly right). Jay Weber Enterprise Integration Technologies   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02133; 8 Sep 93 8:30 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02129; 8 Sep 93 8:30 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa03067; 8 Sep 93 8:30 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA24952; Wed, 8 Sep 93 07:46:36 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA24948; Wed, 8 Sep 93 07:46:35 EDT Received: from guppylake.noname (guppylake.bellcore.com) by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Wed, 8 Sep 93 07:46:32 EDT Received: by guppylake.noname (4.1/SMI-4.1) id AA19620; Wed, 8 Sep 93 07:47:06 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.guppylake.noname.sun4.41 via MS.5.6.guppylake.noname.sun4_41; Wed, 8 Sep 1993 07:47:05 -0400 (EDT) Message-Id: <4gXQMtq0M2UD4coaVf@thumper.bellcore.com> Date: Wed, 8 Sep 1993 07:47:05 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: info-mime@thumper.bellcore.com, ietf-822@dimacs.rutgers.edu Subject: MIME T-shirts wanted Recently someone asked me if MIME was making me rich. This made me laugh, because I'm a researcher on a salary for a company that doesn't make or sell MIME products, so the answer is a resounding no. In fact, I replied, I've never made a penny from MIME, but I have received a couple of very nice free T-shirts plugging products that implement MIME. This has percolated through the bizarre corridors of my mind to the point where I have set myself a goal of having the world's most complete MIME-related T-shirt collection. SO.... if your company implements both MIME and T-shirts, how about sending me one? I promise to make an effort to wear it on at least one or two occasions when your competitors will be genuinely annoyed by it. (I took great delight in wearing DEC T-shirts when the IBM folks came to visit CMU & see how their money was being spent on the Andrew project.) Please send T-shirts to: Nathaniel Borenstein 25 Washington Avenue Morristown, NJ 07960 Thanks in advance to all you good sports out there.... -- Nathaniel   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02630; 8 Sep 93 9:01 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02626; 8 Sep 93 9:01 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa04260; 8 Sep 93 9:01 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA25278; Wed, 8 Sep 93 08:44:41 EDT Received: from gw1.att.com.239.20.192.IN-ADDR.ARPA by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA25274; Wed, 8 Sep 93 08:44:40 EDT Message-Id: <9309081244.AA25274@dimacs.rutgers.edu> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "t.l.hansen" To: ietf-822@dimacs.rutgers.edu Date: 8 Sep 1993 8:27 EDT Subject: re: Idle curiosity -- Time to implement MIME References: <199309080704.AA01775@tel13.tel.vtt.fi> < How much effort (man months?) did it take to implement a MIME parser? I've written several filter programs which have MIME parsers in them. Each one took just a few days to write. The MIME parsing is the easy part. Most of the time was spent on figuring out what to do with the data which the parser had split apart, rather than figuring out how to do the parsing. Tony Hansen hansen@pegasus.att.com, tony@attmail.com att!pegasus!hansen, attmail!tony P.S. Do people still use the antiquated term "man months" instead of "staff months"? I'm shocked! :-)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04722; 8 Sep 93 10:31 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04718; 8 Sep 93 10:31 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa07623; 8 Sep 93 10:31 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA26749; Wed, 8 Sep 93 10:20:55 EDT Received: from [192.105.32.2] by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA26745; Wed, 8 Sep 93 10:20:50 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: CHRIS R BARTRAM Message-Id: <000XUH@KIRK.UII.COM> X-Mailer: NetMail/3000 [Version A.04 93/06/12] Mime-Version: 1.0 Content-Type: text/plain Date: Wed, 8 Sep 1993 10:16:03 -0500 X-Hpdesk-Priority: 3 (Normal Priority) Subject: Re: MIME T-shirts wanted To: nsb@thumper.bellcore.com Cc: info-mime@thumper.bellcore.com, ietf-822@dimacs.rutgers.edu In <4gXQMtq0M2UD4coaVf@thumper.bellcore.com> Nathaniel Borenstein writes: > This has percolated through the bizarre corridors of my mind to the > point where I have set myself a goal of having the world's most complete > MIME-related T-shirt collection. SO.... if your company implements both > MIME and T-shirts, how about sending me one? I promise to make an > effort to wear it on at least one or two occasions when your competitors > will be genuinely annoyed by it. (I took great delight in wearing DEC > T-shirts when the IBM folks came to visit CMU & see how their money was > being spent on the Andrew project.) Please send T-shirts to: > > Nathaniel Borenstein > 25 Washington Avenue > Morristown, NJ 07960 > > Thanks in advance to all you good sports out there.... -- Nathaniel Nathaniel, How about a NetMail/3000 baseball cap? (We don't do shirts yet...) (Feel free to wear it with your DEC shirt when IBM comes calling... We run on HP3000 systems, so you're sure to annoy them all! ;-) ) -Chris Bartram 3k Associates   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07338; 8 Sep 93 12:02 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07334; 8 Sep 93 12:02 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa11006; 8 Sep 93 12:02 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA27536; Wed, 8 Sep 93 11:43:14 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA27532; Wed, 8 Sep 93 11:43:13 EDT Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Wed, 8 Sep 93 11:43:11 EDT Received: by greenbush.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Wed, 8 Sep 93 11:43:10 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.greenbush.galaxy.sun4.41 via MS.5.6.greenbush.galaxy.sun4_41; Wed, 8 Sep 1993 11:43:06 -0400 (EDT) Message-Id: <4gXTq_C0M2YtMY581u@thumper.bellcore.com> Date: Wed, 8 Sep 1993 11:43:06 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Nathaniel Borenstein X-Andrew-Message-Size: 376+0 Mime-Version: 1.0 Content-Type: text/richtext; charset=US-ASCII Content-Transfer-Encoding: quoted-printable To: CHRIS R BARTRAM Subject: Re: MIME T-shirts wanted Cc: info-mime@thumper.bellcore.com, ietf-822@dimacs.rutgers.edu In-Reply-To: <000XUH@KIRK.UII.COM> References: <000XUH@KIRK.UII.COM> Excerpts from info-metamail: 8-Sep-93 Re: MIME T-shirts wanted = CHRIS R BARTRAM@SPSUP-1. (1160*) How about a NetMail/3000 baseball cap? (We don't do shirts yet...)<= nl> (Feel free to wear it with your DEC shirt when IBM comes calling... We= run on HP3000 systems, so you're sure to annoy them all! ;-) ) Sounds wonderful! Now all I'll need is some MIME pants..... -- Nathaniel=   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00873; 9 Sep 93 5:02 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id ah00830; 9 Sep 93 5:02 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa04237; 8 Sep 93 21:03 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04363; Wed, 8 Sep 93 20:54:27 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04359; Wed, 8 Sep 93 20:54:26 EDT Received: from guppylake.noname (guppylake.bellcore.com) by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Wed, 8 Sep 93 20:54:22 EDT Received: by guppylake.noname (4.1/SMI-4.1) id AA05322; Wed, 8 Sep 93 20:54:58 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.guppylake.noname.sun4.41 via MS.5.6.guppylake.noname.sun4_41; Wed, 8 Sep 1993 20:54:57 -0400 (EDT) Message-Id: <8gXbvVm0M2UD9gcpw4@thumper.bellcore.com> Date: Wed, 8 Sep 1993 20:54:57 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: Ned Freed Subject: Re: MIME T-shirts wanted Cc: info-mime@thumper.bellcore.com, ietf-822@dimacs.rutgers.edu In-Reply-To: <01H2PPV37Q548Y4ZU5@SIGURD.INNOSOFT.COM> References: <01H2PPV37Q548Y4ZU5@SIGURD.INNOSOFT.COM> Actually, Ned, you were the FIRST to give me a MIME-related t-shirt; it just never occurred to me you'd want to wear your competitors' advertisements....   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00898; 9 Sep 93 5:02 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id am00830; 9 Sep 93 5:02 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa05491; 8 Sep 93 21:35 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04302; Wed, 8 Sep 93 20:39:39 EDT Received: from SIGURD.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04298; Wed, 8 Sep 93 20:39:37 EDT Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.3-0 #1234) id <01H2PCPHJ00W8Y4ZU5@SIGURD.INNOSOFT.COM>; Wed, 8 Sep 1993 17:39:23 PDT Date: Wed, 08 Sep 1993 17:31:43 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ned Freed Subject: Re: MIME T-shirts wanted In-Reply-To: Your message dated "Wed, 08 Sep 1993 07:47:05 -0400 (EDT)" <4gXQMtq0M2UD4coaVf@thumper.bellcore.com> To: Nathaniel Borenstein Cc: info-mime@thumper.bellcore.com, ietf-822@dimacs.rutgers.edu Message-Id: <01H2PPV37Q548Y4ZU5@SIGURD.INNOSOFT.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT > ... > This has percolated through the bizarre corridors of my mind to the > point where I have set myself a goal of having the world's most complete > MIME-related T-shirt collection. SO.... if your company implements both > MIME and T-shirts, how about sending me one? I promise to make an > effort to wear it on at least one or two occasions when your competitors > will be genuinely annoyed by it. (I took great delight in wearing DEC > T-shirts when the IBM folks came to visit CMU & see how their money was > being spent on the Andrew project.) Please send T-shirts to: > Nathaniel Borenstein > 25 Washington Avenue > Morristown, NJ 07960 > Thanks in advance to all you good sports out there.... -- Nathaniel Well, speaking as a MIME coauthor I'm hurt -- what about *my* t-shirt collection? (Just kidding!) Actually, I'm in a bit of a better position than Nathaniel, since I work for a company that does sell MIME products and hence has things to trade. If anyone sends me a t-shirt (or whatever) I'll return the favor and send you one of ours. Please note that this will just be one of our regular t-shirts. No way am I going to give up the "Foxtrot U-406 Soviet Submarine Tour" t-shirt I'm wearing at the moment. (And if you think the t-shirt is a collector's item you should have seen the sub!) I already wear our main competitor's t-shirt on (in)appropriate occasions, so wearing ones for other products will not be a problem. My address is: Ned Freed Innosoft International, Inc. 250 West First St., Suite 240 Claremont, CA 91711 Thanks... This could be fun... Ned   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00739; 9 Sep 93 9:01 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00735; 9 Sep 93 9:01 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa17827; 9 Sep 93 9:01 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA09806; Thu, 9 Sep 93 08:32:32 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA09802; Thu, 9 Sep 93 08:32:31 EDT Received: from guppylake.noname (guppylake.bellcore.com) by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Thu, 9 Sep 93 08:32:24 EDT Received: by guppylake.noname (4.1/SMI-4.1) id AA12205; Thu, 9 Sep 93 08:32:59 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.guppylake.noname.sun4.41 via MS.5.6.guppylake.noname.sun4_41; Thu, 9 Sep 1993 08:32:58 -0400 (EDT) Message-Id: <0gXm9uS0M2UD1gcwMZ@thumper.bellcore.com> Date: Thu, 9 Sep 1993 08:32:58 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ietf-822@dimacs.rutgers.edu, Stef@nma.com Subject: Re: text/enriched: Throwing in the towel In-Reply-To: <985.747548488@odin.nma.com> References: <985.747548488@odin.nma.com> Stef -- you are absolutely right that the prose I last posted was insufficiently user-focused. How about replacing the last paragraph as follows: Whether or not text is justified by default (that is, whether the default environment is flushleft, flushright, or flushboth) is unspecified, and depends on the preferences of the user, the capabilities of the local software and hardware, the nature of the character set in use, and the tastes of the implementors. On systems where justification is considered undesirable, the flushboth environment may be identical to the default environment. Note that justification should never be performed inside of center, flushleft, flushright, or nofill environments. Note also that for some non-ASCII character sets, full justification may be fundamentally inappropriate.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02690; 9 Sep 93 10:02 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02685; 9 Sep 93 10:02 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa20782; 9 Sep 93 10:02 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA11106; Thu, 9 Sep 93 09:52:12 EDT Received: from ivory.educom.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA11102; Thu, 9 Sep 93 09:52:10 EDT Received: from [192.52.179.3] (conklin-mac.educom.edu) by ivory.educom.edu (5.65c/1.34 (EDUCOM)) id AA09755; Thu, 9 Sep 1993 09:50:43 -0400 Message-Id: <199309091350.AA09755@ivory.educom.edu> Date: Thu, 9 Sep 1993 09:52:01 -0500 To: Stef@nma.com, ietf-822@dimacs.rutgers.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jim Conklin X-Sender: conklin@educom.edu Subject: Re: text/enriched: Throwing in the towel As a user, I agree with Stef. I get very tired of receiving mail in which extra spaces have been inserted in order to justify the text, and I would be delighted to have the control to prevent that! >I want the spec to say that it should be left to the user in a proper >implementation. If this is not appropriate to say in the spec, then >reference the user as having the choice, and do not mention the >implementor. In short, my MH should allow me to select the default >with a command switch. (Same functionality goes for my Eudora!) If FlushBoth is intended to include left and right indentation, which is what I understood from the discussion of its use for quoted material, I don't believe the spec is clear on that, either. (My personal preference for quoted material, by the way, is just decreased margins, not that plus justification.) And why is "nofill" indented as if it were part of FlushBoth in the spec? Thanks for the good work! Jim >} >} Center -- causes the affected text to be centered. >} FlushLeft -- causes the affected text to be left-justified with >} a ragged right margin. >} FlushRight -- causes the affected text to be right-justified >} with a ragged left margin. >} FlushBoth -- causes the affected text to be filled and padded so >} as to create smooth left and right margins, i.e., to be fully >} justified. >} Nofill -- causes the affected text to be displayed without >} filling or justification. >}   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05750; 9 Sep 93 11:33 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05742; 9 Sep 93 11:33 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa24952; 9 Sep 93 11:32 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA11924; Thu, 9 Sep 93 11:12:06 EDT Received: from dorner.slip.uiuc.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA11920; Thu, 9 Sep 93 11:11:58 EDT Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA04182 (5.65c/IDA-1.4.4 for ietf-822@dimacs.rutgers.edu); Thu, 9 Sep 1993 10:11:40 -0500 Message-Id: <199309091511.AA04182@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 9 Sep 1993 10:11:45 -0500 To: Jim Conklin , Stef@nma.com, ietf-822@dimacs.rutgers.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Dorner Subject: Re: text/enriched: Throwing in the towel At 9:52 AM 9/9/93 -0500, Jim Conklin wrote: > As a user, I agree with Stef. I get very tired of receiving mail in >which extra spaces have been inserted in order to justify the text, and I >would be delighted to have the control to prevent that! I think there are two issues that are being muddled. 1. The DEFAULT state of full justification. The standard should leave the default up to the reader (implementor or user). That is, if the sender does not explicity specify a justification, the reader is free to choose what it likes. 2. What happens when the sender EXPLICITLY requests . Perhaps I am misunderstanding, but I seem to be hearing people who want to allow the reader to ignore even an explicit specification. This brings up a really interesting issue; just whose text is it anyway? Should the sender be able to specify how his text looks? Should the reader be able to read the text in whatever way he likes best? Is full justification so very different from other formatting attributes that we can rationally say the reader should control it, even though the sender controls everything else? Is it the business of the standard to address these issues? I would be inclined to write the standard such that an explicit directive must be obeyed if possible. People who don't like full justification would have two avenues of redress: 1. Inflict out-of-band bodily harm on the misguided souls who use full justification. 2. Use implementations that allow them to control the justification, in an unashamedly non-MIME-compliant manner. As an MUA author, I feel no guilt about doing weird things AT THE USER'S REQUEST. -- Steve Dorner, Qualcomm Inc.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06441; 9 Sep 93 12:02 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06437; 9 Sep 93 12:02 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa26169; 9 Sep 93 12:02 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12083; Thu, 9 Sep 93 11:31:01 EDT Received: from ivory.educom.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12079; Thu, 9 Sep 93 11:30:59 EDT Received: from [192.52.179.3] (conklin-mac.educom.edu) by ivory.educom.edu (5.65c/1.34 (EDUCOM)) id AA10103; Thu, 9 Sep 1993 11:29:34 -0400 Message-Id: <199309091529.AA10103@ivory.educom.edu> Date: Thu, 9 Sep 1993 11:30:51 -0500 To: Steve Dorner , ietf-822@dimacs.rutgers.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jim Conklin X-Sender: conklin@educom.edu Subject: Re: text/enriched: Throwing in the towel Steve Dorner writes > ... >2. What happens when the sender EXPLICITLY requests . Perhaps I >am misunderstanding, but I seem to be hearing people who want to allow the >reader to ignore even an explicit specification. Or any other kind of justification, for that matter. Much as I don't care for justified text, I agree that the sender has first right to specify what his/her message should look like, even though my comment may not have given that impression. But if the sender doesn't specify... And no out-of-band bodily harm over text justification, please! There's enough violence without that! ;-) Jim   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02499; 9 Sep 93 14:14 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ai02459; 9 Sep 93 14:14 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa27358; 9 Sep 93 12:31 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12554; Thu, 9 Sep 93 12:26:16 EDT Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12550; Thu, 9 Sep 93 12:26:15 EDT Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA11419; Thu, 9 Sep 93 09:26:09 -0700 Message-Id: <9309091626.AA11419@Mordor.Stanford.EDU> To: Jim Conklin Cc: Stef@nma.com, ietf-822@dimacs.rutgers.edu Subject: Re: text/enriched: Throwing in the towel Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Thu, 09 Sep 93 09:52:01 -0500. <199309091350.AA09755@ivory.educom.edu> Date: Thu, 09 Sep 93 09:26:09 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Crocker X-Mts: smtp Interesting... ---- Included message: I get very tired of receiving mail in which extra spaces have been inserted in order to justify the text, and I would be delighted to have the control to prevent that! This is a frequent view in our community, yet it is exactly contrary to typical views among the human communication folks. The sender of a message is trying to create some effect. Visual organization to the message is part of that effort. Hence, the sender typically wants to be able to specify the visual characteristics of the message. This technology of ours allows us to make considerable mayhem of that and we will have to live with it. But we ought to understand the difficulty it imposes. If I throw together a message with a system that uses crufty courier font and trivial formatting, I have certain expectations about the way the recipient will "process" things. But if the recipient views it with spiffy New Century Schoolbook, etc., a very different effect may accrue. Worse, the sender is likely to have no way of knowing how the message will be viewed. This is messy stuff. Dave   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03202; 9 Sep 93 14:31 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03197; 9 Sep 93 14:31 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa03154; 9 Sep 93 14:31 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA15607; Thu, 9 Sep 93 14:07:09 EDT Received: from umail.umd.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA15603; Thu, 9 Sep 93 14:07:08 EDT Received: by umail.UMD.EDU (5.57/Ultrix3.0-C) id AA10748; Thu, 9 Sep 93 14:07:06 -0400 Date: Thu, 9 Sep 93 14:07:05 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dana S Emery To: ietf-822@dimacs.rutgers.edu Subject: Re: text/enriched: Throwing in the towel Message-Id: In-Reply-To: Your message <199309091529.AA10103@ivory.educom.edu> of Thu, 9 Sep 1993 11:30:51 -0500 Content-Type: TEXT/plain; charset=US-ASCII I think this question of nofill (defaults et al) is being muddled by a lack of recognition of one issue, some UA are capable of presenting justified text from simple inspection of an ascii stream, others have to modify that stream in order to convince a dumb display agent to display it for them. When the user retains access to the original form of the message, no harm is done by such modification, but if the user is made to cope with the results of the interjected spaces and reflowed lines, then one has to pause for thought. I think the default state should be nofill, it seems cleaner to me. I observe that Wordperfect is unique among the wordprocessors of my acquaintance in that it presumes full justification by default, Word, Writenow, Fullwrite Pro, Nissus, MacWrite all use system-justified as the default (ie, if system is arabic, right justified, for swedish, left justified). I wonder if there is any corelation between those who are arguing for full-justification and a preference for WP? -- dana s emery   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05781; 9 Sep 93 15:46 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05777; 9 Sep 93 15:46 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa07313; 9 Sep 93 15:45 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA16201; Thu, 9 Sep 93 15:02:36 EDT Received: from ics.uci.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA16197; Thu, 9 Sep 93 15:02:35 EDT Received: from nma.com by q2.ics.uci.edu id ac13926; 9 Sep 93 10:30 PDT Received: from localhost by odin.nma.com id aa02232; 9 Sep 93 9:33 PDT To: Nathaniel Borenstein Cc: ietf-822@dimacs.rutgers.edu Subject: Re: text/enriched: Throwing in the towel In-Reply-To: Your message of "Thu, 09 Sep 1993 08:32:58 EDT." <0gXm9uS0M2UD1gcwMZ@thumper.bellcore.com> Reply-To: Stef@nma.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Einar Stefferud Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 09 Sep 1993 09:33:53 -0700 Message-Id: <2230.747592433@odin.nma.com> X-Orig-Sender: stef@nma.com You include the "PREFERENCE" of the USER but also allow for the "TASTES" of the IMPLEMENTORS. I would simply omit mention of the IMPLEMENTORS in this text. They are the ones who read these specs, and they will be given carte blanche to screw the users with their "TASTES". I realize that we do not specify implementation details, such as USER interface options vs IMPLEMENTOR choices, but lets not allow the suggestion that this is a simple implmentor choice to be given so much force. As I see it, the implementors are going to impose their will on the design in any case, whether you mention them or not, so just omit them from the text. Now, the sentence that leaves me entirely baffled is still there: "On systems where justification is considered undesirable, the flushboth environment may be identical to the default environment." What does it mean to say: "the flushboth environment may be identical to the default environment". I just don't get it...\Stef From your message Thu, 9 Sep 1993 08:32:58 -0400 (EDT): } }Stef -- you are absolutely right that the prose I last posted was }insufficiently user-focused. How about replacing the last paragraph as }follows: } }Whether or not text is justified by default (that is, whether the }default environment is flushleft, flushright, or flushboth) is }unspecified, and depends on the preferences of the user, the }capabilities of the local software and hardware, the nature of the }character set in use, and the tastes of the implementors. On systems }where justification is considered undesirable, the flushboth environment }may be identical to the default environment. Note that justification }should never be performed inside of center, flushleft, flushright, or }nofill environments. Note also that for some non-ASCII character sets, }full justification may be fundamentally inappropriate.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08714; 9 Sep 93 18:35 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08709; 9 Sep 93 18:35 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa14927; 9 Sep 93 18:35 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA18911; Thu, 9 Sep 93 18:19:10 EDT Received: from ics.uci.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA18907; Thu, 9 Sep 93 18:19:09 EDT Received: from nma.com by q2.ics.uci.edu id ab28895; 9 Sep 93 13:00 PDT Received: from localhost by odin.nma.com id aa02974; 9 Sep 93 12:45 PDT To: ietf-822@dimacs.rutgers.edu Subject: Re: text/enriched: Throwing in the towel In-Reply-To: Your message of "Thu, 09 Sep 1993 09:26:09 PDT." <9309091626.AA11419@Mordor.Stanford.EDU> Reply-To: Stef=mime@nma.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Einar Stefferud Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 09 Sep 1993 12:45:22 -0700 Message-Id: <2972.747603922@odin.nma.com> X-Orig-Sender: stef@nma.com What we have here is a perfectly normal, and expected, problem stemming from our great progress in delaying the binding time of pixels to document real estate locations from creation time to reading time. I am sure this was discussed long ago in MsgGroup somewhere. This is not limited to MIME or text/enriched. it is a great conundrum of our technology, wherein the originator has lost control of what the reader will see. Are we trying to solve this great problem, or just trying to avoid tripping over it in text/enriched? Cheers...\Stef From DCrocker's message Thu, 09 Sep 93 09:26:09 -0700: } }Interesting... } } ---- Included message: } } I get very tired of receiving mail in } which extra spaces have been inserted in order to justify the text, and I } would be delighted to have the control to prevent that! } }This is a frequent view in our community, yet it is exactly contrary to }typical views among the human communication folks. The sender of a }message is trying to create some effect. Visual organization to the }message is part of that effort. Hence, the sender typically wants to }be able to specify the visual characteristics of the message. } }This technology of ours allows us to make considerable mayhem of that and }we will have to live with it. But we ought to understand the difficulty }it imposes. } }If I throw together a message with a system that uses crufty courier }font and trivial formatting, I have certain expectations about the way }the recipient will "process" things. But if the recipient views it }with spiffy New Century Schoolbook, etc., a very different effect may }accrue. Worse, the sender is likely to have no way of knowing how }the message will be viewed. } }This is messy stuff. } }Dave   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11044; 9 Sep 93 20:32 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11040; 9 Sep 93 20:32 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa19670; 9 Sep 93 20:32 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19356; Thu, 9 Sep 93 20:00:57 EDT Received: from alpha.Xerox.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19352; Thu, 9 Sep 93 20:00:56 EDT Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <12127>; Thu, 9 Sep 1993 17:00:34 -0700 Received: by holmes.parc.xerox.com id <16134>; Thu, 9 Sep 1993 17:00:27 -0700 Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41 via MS.5.6.holmes.parc.xerox.com.sun4_41; Thu, 9 Sep 1993 17:00:21 -0700 (PDT) Message-Id: Date: Thu, 9 Sep 1993 17:00:21 -0700 X-Orig-Sender: Bill Janssen Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bill Janssen To: Jim Conklin , Dave Crocker Subject: Re: text/enriched: Throwing in the towel Cc: Stef@nma.com, ietf-822@dimacs.rutgers.edu In-Reply-To: <9309091626.AA11419@Mordor.Stanford.EDU> References: <9309091626.AA11419@Mordor.Stanford.EDU> Excerpts from ext.ietf-822: 9-Sep-93 Re: text/enriched: Throwing.. Dave Crocker@mordor.stan (1133) > This is messy stuff. I don't think it's quite that bad, thanks to MIME. If you want control over presentation, use a format that gives you that control. Thanks to ghostscript and ghostview, I have no problems with receiving messages formatted with PostScript; thanks to XMosaic, I have no problems with receiving messages formatted with HTML; thanks to CMU's Andrew Toolkit, I have no problem with receiving messages formatted with ATK's various object pickling formats. Bill   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11517; 9 Sep 93 21:04 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11513; 9 Sep 93 21:04 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa20866; 9 Sep 93 21:04 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19553; Thu, 9 Sep 93 20:56:19 EDT Received: from uxc.cso.uiuc.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19549; Thu, 9 Sep 93 20:56:17 EDT Received: from dorner.slip.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA04341 (5.67a/IDA-1.5 for ); Thu, 9 Sep 1993 19:55:51 -0500 Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA05077 (5.65c/IDA-1.4.4 for ietf-822@dimacs.rutgers.edu); Thu, 9 Sep 1993 19:56:41 -0500 Message-Id: <199309100056.AA05077@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 9 Sep 1993 19:56:33 -0500 To: Bill Janssen , Jim Conklin , Dave Crocker Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Dorner Subject: Re: text/enriched: Throwing in the towel Cc: Stef@nma.com, ietf-822@dimacs.rutgers.edu At 5:00 PM 9/9/93 -0700, Bill Janssen wrote: >use a format that gives you that control. Thanks to >ghostscript and ghostview, I have no problems with receiving messages >formatted with PostScript; thanks to XMosaic, I have no problems with >receiving messages formatted with HTML; thanks to CMU's Andrew Toolkit, >I have no problem with receiving messages formatted with ATK's various >object pickling formats. The problem with that approach is that you lose the ability to control how it looks on the screens of millions of users who do NOT have PS, HTML, or Andrew interpreters. How it looks to them is "like a whole lot of junk". And the real issue here is where the control belongs, not "I want control". As a sender, I don't want my dox to be illegible on the reader's screen because I chose a font he can't render well; on the other hand, I don't want his goofy font with all sorts of funny glyphs to make my text illegible, either. As a reader, I don't want to have to put up with someone WHO INSISTS ON TYPING IN ALL CAPITAL LETTERS ALL THE TIME FOR NO DISCRENABLE REASON, but I also don't want to miss LEGITIMATE emphasis. There ARE issues here. (Though whether we can solve them in text/enriched is itself one of the issues.) -- Steve Dorner, Qualcomm Inc.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13802; 9 Sep 93 22:34 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13798; 9 Sep 93 22:34 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa24753; 9 Sep 93 22:34 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA22044; Thu, 9 Sep 93 22:10:42 EDT Received: from alpha.Xerox.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA22040; Thu, 9 Sep 93 22:10:40 EDT Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <12478>; Thu, 9 Sep 1993 19:10:13 -0700 Received: by holmes.parc.xerox.com id <16134>; Thu, 9 Sep 1993 19:10:10 -0700 Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41 via MS.5.6.holmes.parc.xerox.com.sun4_41; Thu, 9 Sep 1993 19:10:06 -0700 (PDT) Message-Id: Date: Thu, 9 Sep 1993 19:10:06 -0700 X-Orig-Sender: Bill Janssen Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bill Janssen To: Bill Janssen , Jim Conklin , Dave Crocker , Steve Dorner Subject: Re: text/enriched: Throwing in the towel Cc: Stef@nma.com, ietf-822@dimacs.rutgers.edu In-Reply-To: <199309100056.AA05077@dorner.slip.uiuc.edu> References: <199309100056.AA05077@dorner.slip.uiuc.edu> Excerpts from direct: 9-Sep-93 Re: text/enriched: Throwing.. Steve Dorner@qualcomm.co (1280*) > The problem with that approach is that you lose the ability to control how > it looks on the screens of millions of users who do NOT have PS, HTML, or > Andrew interpreters. How it looks to them is "like a whole lot of junk". Well, that's the trade-off. Another of the things that people want is portability, so that everyone can read their message. Unfortunately, portability and explicit presentation control seem diametrically opposed, so that you always need to trade one for the other. Bill   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03935; 10 Sep 93 9:03 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03931; 10 Sep 93 9:03 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa12186; 10 Sep 93 9:03 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA25303; Fri, 10 Sep 93 08:51:25 EDT Received: from relay1.UU.NET by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA25299; Fri, 10 Sep 93 08:51:24 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: beyond!eng!tcrowley@uunet.uu.net Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA19126; Fri, 10 Sep 93 08:51:02 -0400 Received: from beyond.UUCP by uucp2.uu.net with UUCP/RMAIL (queueing-rmail) id 084915.23282; Fri, 10 Sep 1993 08:49:15 EDT Received: by beyond.UUCP Fri, 10 Sep 93 08:49:18 EDT Message-Id: Date: Fri, 10 Sep 93 08:49:18 EDT To: David Herron , ietf-822@dimacs.rutgers.edu MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Subject: Re: Idle curiosity -- Time to implement MIME X-Mailer: UGate [Ver. 1.65] >> How much effort (man months?) did it take to implement a MIME parser? When implementing MIME in Slate, I wrote filters from MIME into Slate's native compound document format (including richtext) and added the ability to write a Slate document out as a MIME multipart message. Also hooked these capabilities up to the user-interface and to the mail-incorporation interface. This took a total of about 3 weeks. I used Nathaniel's code for QP and Base64 encoding/decoding. Terry   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06659; 10 Sep 93 10:33 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06648; 10 Sep 93 10:33 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa16264; 10 Sep 93 10:33 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA26770; Fri, 10 Sep 93 10:24:04 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA26766; Fri, 10 Sep 93 10:24:03 EDT Received: from guppylake.noname (guppylake.bellcore.com) by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Fri, 10 Sep 93 10:23:59 EDT Received: by guppylake.noname (4.1/SMI-4.1) id AA10955; Fri, 10 Sep 93 10:24:35 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.guppylake.noname.sun4.41 via MS.5.6.guppylake.noname.sun4_41; Fri, 10 Sep 1993 10:24:34 -0400 (EDT) Message-Id: <0gY8sWm0M2UDRgcwZS@thumper.bellcore.com> Date: Fri, 10 Sep 1993 10:24:34 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: Stef@nma.com Subject: Re: text/enriched: Throwing in the towel Cc: ietf-822@dimacs.rutgers.edu In-Reply-To: <2230.747592433@odin.nma.com> References: <2230.747592433@odin.nma.com> Excerpts from mail: 9-Sep-93 Re: text/enriched: Throwing.. Einar Stefferud@nma.com (1886*) > I would simply omit mention of the IMPLEMENTORS in this text. Yeah, you're probably right. Consider it done. > Now, the sentence that leaves me entirely baffled is still there: > "On systems where justification is considered undesirable, > the flushboth environment > may be identical to the default environment." > What does it mean to say: > "the flushboth environment may be identical to the default environment". What I meant was that it would be either flushleft or flushright, depending on the character set. Should I word it that way instead? -- NB   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07296; 10 Sep 93 11:04 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07291; 10 Sep 93 11:03 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa17595; 10 Sep 93 11:03 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA26828; Fri, 10 Sep 93 10:28:15 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA26824; Fri, 10 Sep 93 10:28:14 EDT Received: from guppylake.noname (guppylake.bellcore.com) by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Fri, 10 Sep 93 10:28:07 EDT Received: by guppylake.noname (4.1/SMI-4.1) id AA11212; Fri, 10 Sep 93 10:28:43 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.guppylake.noname.sun4.41 via MS.5.6.guppylake.noname.sun4_41; Fri, 10 Sep 1993 10:28:42 -0400 (EDT) Message-Id: <4gY8wOq0M2UD9gcx83@thumper.bellcore.com> Date: Fri, 10 Sep 1993 10:28:42 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ietf-822@dimacs.rutgers.edu, Stef=mime@nma.com Subject: Re: text/enriched: Throwing in the towel In-Reply-To: <2972.747603922@odin.nma.com> References: <2972.747603922@odin.nma.com> Excerpts from mail: 9-Sep-93 Re: text/enriched: Throwing.. Einar Stefferud@nma.com (1764*) > Are we trying to solve this great problem, or just trying to avoid > tripping over it in text/enriched? Stef is right on the money, as usual. There is NO WAY that a format as simple as text/enriched is going to solve a problem as thorny as "sender intention versus recipient preferences", nor was it intended to. I think we should be very careful not to overgeneralize this problem. The text/enriched format is intended to be sufficiently rich to allow some emphasis, etc., but explicitly NOT to provide WYSIWYG capability or advanced formatting capability. Let's skip the grander problems and concentrate on what should be in this less ambitious format. If justification is fundamentally too controversial, perhaps we should just declare that text/enriched doesn't support justification, nuke the "flushboth" environment, and be done with it? I would not have a problem with that, actually; I think that little is gained by it. (To my mind, the most important things in text/enriched are things like bold and italics. Really.) -- Nathaniel   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09231; 10 Sep 93 13:02 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09227; 10 Sep 93 13:02 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa23576; 10 Sep 93 13:02 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA27943; Fri, 10 Sep 93 12:49:54 EDT Received: from ppp.dbc.mtview.ca.us by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA27939; Fri, 10 Sep 93 12:49:45 EDT Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA26946; Fri, 10 Sep 93 09:48:40 -0700 To: ietf-822@dimacs.rutgers.edu Subject: Hypothetically speaking... Reply-To: ietf-822@dimacs.rutgers.edu Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-Id: <26943.747679716.0@dbc.mtview.ca.us> Date: Fri, 10 Sep 1993 09:48:38 -0700 Message-Id: <26945.747679718@dbc.mtview.ca.us> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Marshall Rose ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26943.747679716.1@dbc.mtview.ca.us> I suppose if one were to write a set of technical procedures for radio paging over the Internet, with the goal of maximizing leverage of the existing infrastructure, it might look like this. One might observe a rather striking resemblence to RFC 1486... /mtr ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26943.747679716.2@dbc.mtview.ca.us> Content-Description: hypothetical description 2. Naming, Addressing, and Routing A radio pager is identified by a telephone number, e.g., +1 415 940 8776 where "+1" indicates the IDDD country code, and the remaining string is a telephone number within that country. 2.1. Addressing This number is used to construct the address of a radio pager server, which forms the recipient address for the message, e.g., either pager@6.7.7.8.0.4.9.5.1.4.1.tpc.int or pager.ATOM@6.7.7.8.0.4.9.5.1.4.1.tpc.int where "ATOM" is an (optional) RFC 822 atom [1], an opaque string for use in recipient identification, and the domain-part is constructed by reversing the telephone number, converting each digit to a domain-label, and being placed under "tpc.int." Note that the mailbox syntax is purposefully restricted in the interests of pragmatism. To paraphrase RFC 822, an atom is defined as: atom = 1*atomchar atomchar= / / "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / "~" Finally, note that some Internet mail software (especially gateways from outside the Internet) impose stringent limitations on the size of a mailbox-string. Thus, originating user agents should take care in limiting the local-part to no more than 70 or so characters. 2.2. Routing The message is routed in exactly the same fashion as all other electronic mail, i.e., using the MX algorithm [2]. Since a radio pager server might be able to access many radio pagers, the wildcarding facilities of the DNS [3,4] are used accordingly. For example, if a radio pager server residing at "dbc.mtview.ca.us" was willing to access any radio pager with a telephone number prefix of +1 415 940 then this resource record might be present *.0.4.9.5.1.4.1.tpc.int. IN MX 10 dbc.mtview.ca.us. Naturally, if several radio pager servers were willing to access any radio pager in that prefix, multiple MX resource records would be present. It should be noted that the presence of a wildcard RR which matches a radio pager server's address does not imply that the corresponding telephone number is valid, or, if valid, that a radio pager is identified by the phone number. Rather, the presence of a wildcard RR indicates that a radio pager server is willing to attempt access. 3. Procedure When information is to be sent to a radio pager, the user application constructs an RFC 822 message, containing a "Message-ID" field and a textual content (e.g., a "text/plain" content [5]). The message is then sent to the radio pager server's electronic mail address. 3.1. MAILing versus SENDing An SMTP client communicating with a radio pager server may use attempt either the MAIL or SEND command. The radio pager server MUST support the MAIL command, and MAY support any of the SEND, SOML, or SAML commands. If the MAIL command is used, then a positive completion reply to both the RCPT and DATA commands indicates, at a minimum, that the message has been queued for transmission into the radio paging network for the recipient, but is at least queued for transmission into the radio paging network. If the SEND command is used, then a positive completion reply to both the RCPT and DATA commands indicates that the message has been accepted by the radio paging network for delivery to the recipient. If the SOML or SAML command is used, then a positive completion reply to both the RCPT and DATA commands indicates that the message may have been accepted by the radio paging network for delivery to the recipient. 4. Usage Examples 4.1. MIME-based To: pager@6.7.7.8.0.4.9.5.1.4.1.tpc.int cc: Marshall Rose From: Carl Malamud Date: Thu, 22 Jul 1993 08:38:00 -0800 Subject: First example Message-ID: <19930908220700.1@malamud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii A brief textual message. 4.2. Non-MIME To: pager@6.7.7.8.0.4.9.5.1.4.1.tpc.int cc: Marshall Rose From: Carl Malamud Date: Thu, 22 Jul 1993 08:38:00 -0800 Subject: Second example Message-ID: <19930908220700.2@malamud.com> Another brief textual message. 5. Security Considerations Internet mail may be subject to monitoring by third parties, and in particular, message relays. 6. Acknowledgements This document was motiviated by "Simple Network Paging Protocol - Version 1", by Allen Gwinn of Southern Methodist University. 7. References [1] Crocker, D.H., "Standard for the Format of ARPA Internet Text Messages", RFC 822, University of Delaware, August, 1982. [2] Partridge, C., "Mail Routing and the Domain System", BBN Laboratories, RFC 974, January, 1986. [3] Mockapetris, P.V., "Domain Names -- Concepts and Facilities", RFC 1034, Information Sciences Institute, November, 1987. [4] Mockapetris, P.V., "Domain Names -- Implementation and Specification", RFC 1035, Information Sciences Institute, November, 1987. [5] Borenstein, N. and N. Freed, "MIME: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1341, Bellcore, Innosoft, June, 1992. ------- =_aaaaaaaaaa0--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11641; 10 Sep 93 14:38 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11635; 10 Sep 93 14:38 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa27915; 10 Sep 93 14:38 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA00886; Fri, 10 Sep 93 14:14:10 EDT Received: from umail.umd.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA00882; Fri, 10 Sep 93 14:14:09 EDT Received: by umail.UMD.EDU (5.57/Ultrix3.0-C) id AA26116; Fri, 10 Sep 93 14:14:03 -0400 Date: Fri, 10 Sep 93 14:14:00 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dana S Emery To: ietf-822@dimacs.rutgers.edu Subject: Re: text/enriched: Throwing in the towel Message-Id: In-Reply-To: Your message <4gY8wOq0M2UD9gcx83@thumper.bellcore.com> of Fri, 10 Sep 1993 10:28:42 -0400 (EDT) Content-Type: TEXT/plain; charset=US-ASCII > perhaps we should just declare that text/enriched > doesn't support justification, nuke the > "flushboth" environment, and be done with it? I would > not have a problem with that, actually; I think that > little is gained by it. ok by me, I never liked the justification stuff anyway; even with all the help the the Mac OS gives me, dealing with it is still a zoo. -- dana s emery   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12807; 10 Sep 93 15:10 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12803; 10 Sep 93 15:10 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa29577; 10 Sep 93 15:10 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA00934; Fri, 10 Sep 93 14:22:57 EDT Received: from umail.umd.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA00930; Fri, 10 Sep 93 14:22:55 EDT Received: by umail.UMD.EDU (5.57/Ultrix3.0-C) id AA26602; Fri, 10 Sep 93 14:22:52 -0400 Date: Fri, 10 Sep 93 14:22:51 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dana S Emery To: ietf-822@dimacs.rutgers.edu Subject: Re: Hypothetically speaking... Message-Id: In-Reply-To: Your message <26945.747679718@dbc.mtview.ca.us> of Fri, 10 Sep 1993 09:48:38 -0700 Content-Type: TEXT/plain; charset=US-ASCII > 2. Naming, Addressing, and Routing > > A radio pager is identified by a telephone number, > e.g., > > +1 415 940 8776 > > where "+1" indicates the IDDD country code, and the > remaining string is a telephone number within that > country. devils advocate hat on >:-)> is it necessarily the case that _all_ telephone numbers associated with pagers will _have_ international access, and thus have international numbers? Without that international code disambiguation seems hopeless. I suppose one should defer the Q of interplanetary telephony to a later spec :-). -- dana s emery   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13251; 10 Sep 93 15:36 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13247; 10 Sep 93 15:36 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa00947; 10 Sep 93 15:36 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01840; Fri, 10 Sep 93 15:25:49 EDT Received: from ppp.dbc.mtview.ca.us by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01835; Fri, 10 Sep 93 15:25:46 EDT Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA01392; Fri, 10 Sep 93 12:24:35 -0700 To: Dana S Emery Reply-To: ietf-822@dimacs.rutgers.edu Cc: ietf-822@dimacs.rutgers.edu Subject: Re: Hypothetically speaking... In-Reply-To: Your message of "Fri, 10 Sep 1993 14:22:51 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <1386.747689071.1@dbc.mtview.ca.us> Date: Fri, 10 Sep 1993 12:24:32 -0700 Message-Id: <1389.747689072@dbc.mtview.ca.us> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Marshall Rose > is it necessarily the case that _all_ telephone numbers > associated with pagers will _have_ international access, and > thus have international numbers? Without that international > code disambiguation seems hopeless. Well, I could probably get a limited area 800 number and have it go to my pager... (-: /mtr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15498; 10 Sep 93 17:36 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15494; 10 Sep 93 17:36 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa06529; 10 Sep 93 17:36 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03204; Fri, 10 Sep 93 16:59:19 EDT Received: from rutvm1.rutgers.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03200; Fri, 10 Sep 93 16:59:16 EDT Message-Id: <9309102059.AA03200@dimacs.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RUTVM1.RUTGERS.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 2081; Fri, 10 Sep 93 16:58:09 EDT Received: from RICEVM1.RICE.EDU (NJE origin MAILER@RICEVM1) by RUTVM1.RUTGERS.EDU (LMail V1.1d/1.7f) with BSMTP id 1137; Fri, 10 Sep 1993 16:58:09 -0400 Received: from ricevm1.rice.edu (NJE origin TROTH@RICEVM1) by RICEVM1.RICE.EDU (LMail V1.1d/1.7f) with BSMTP id 5313; Fri, 10 Sep 1993 15:58:30 -0500 Mime-Version: 1.0 Content-Type: text/plain Date: Fri, 10 Sep 93 15:56:09 CDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Rick Troth Subject: Re: Hypothetically speaking... To: Marshall Rose , ietf-822@dimacs.rutgers.edu In-Reply-To: Message of Fri, 10 Sep 1993 09:48:38 -0700 from >2.1. Addressing > >This number is used to construct the address of a radio pager server, >which forms the recipient address for the message, e.g., either > > pager@6.7.7.8.0.4.9.5.1.4.1.tpc.int > >or > > pager.ATOM@6.7.7.8.0.4.9.5.1.4.1.tpc.int I still don't understand why this (and like-minded print or FAX servers) aren't addressed according to: pager+4159408776@pagerserver.tpc.int or even just +4159408776@pagerserver.tpc.int There's certainly nothing wrong with exploiting DNS and MX to solve this problem, but I'd like to hear from those who have considered the alternative(s) and prefer the above scheme (or don't). -- Rick Troth , Rice University, Information Systems   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16164; 10 Sep 93 18:32 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16159; 10 Sep 93 18:32 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa08713; 10 Sep 93 18:31 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03533; Fri, 10 Sep 93 18:02:01 EDT Received: from sunic.sunet.se by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03529; Fri, 10 Sep 93 18:02:00 EDT Received: by sunic.sunet.se (5.65c8-/1.28) id AA25145; Sat, 11 Sep 1993 00:01:35 +0200 Date: Sat, 11 Sep 1993 0:01:32 MET DST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Johnny Eriksson To: Rick Troth Cc: Marshall Rose , ietf-822@dimacs.rutgers.edu Subject: Re: Hypothetically speaking... In-Reply-To: Your message of Fri, 10 Sep 93 15:56:09 CDT Message-Id: > >2.1. Addressing > > > >This number is used to construct the address of a radio pager server, > >which forms the recipient address for the message, e.g., either > > > > pager@6.7.7.8.0.4.9.5.1.4.1.tpc.int > > > >or > > > > pager.ATOM@6.7.7.8.0.4.9.5.1.4.1.tpc.int > > I still don't understand why this (and like-minded > print or FAX servers) aren't addressed according to: > > pager+4159408776@pagerserver.tpc.int > > or even just > > +4159408776@pagerserver.tpc.int Scaling. Your proposal makes every message go to thru one single machine, bringing it to it's knees. Now or tomorrow. Or yester- day. --Johnny   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16439; 10 Sep 93 19:01 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16434; 10 Sep 93 19:01 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa09751; 10 Sep 93 19:01 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03730; Fri, 10 Sep 93 18:47:09 EDT Received: from SIGURD.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03726; Fri, 10 Sep 93 18:47:03 EDT Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.3-0 #1234) id <01H2S8J2CHNK9AMEML@SIGURD.INNOSOFT.COM>; Fri, 10 Sep 1993 15:46:53 PDT Date: Fri, 10 Sep 1993 15:29:08 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ned Freed Subject: RE: Hypothetically speaking... In-Reply-To: Your message dated "Fri, 10 Sep 1993 15:56:09 -0500 (CDT)" <9309102059.AA03200@dimacs.rutgers.edu> To: Rick Troth Cc: Marshall Rose , ietf-822@dimacs.rutgers.edu Message-Id: <01H2SEJ9QPGK9AMEML@SIGURD.INNOSOFT.COM> Mime-Version: 1.0 Content-Type: text/plain; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > I still don't understand why this (and like-minded > print or FAX servers) aren't addressed according to: > pager+4159408776@pagerserver.tpc.int > or even just > +4159408776@pagerserver.tpc.int What is pagerserver in this example? Do you mean for it to be a system that is run by some big service provider that splits out FAXes based on private routing information? If this is in fact the case, then the questions to ask are: (1) Who runs and pays for this server? It is going to have to either be huge or highly replicated to handle the load. It sounds pretty expensive to me... (2) What sort of private routing information is it using? Who provides it? What format is it in? Who keeps it up to date? (3) What's the rationale for setting up and maintaining such a server? Why would I want to do it? This simple does not scale at all well. Not only does it fail the absolute test on not being able to handle the traffic, it depends on a local nondistributed source of information which, as far as I know, does not exist in any real sense. (Of course you can use the DNS to provide the information. But if you do this why not just take advantage of the fact that everyone has access to the DNS and can do the routing for themselves with no central server involvement?) Or perhaps you are proposing that there be lots of pagerserver.tpc.int machines out there, each providing access to some different portion of the spectrum. But how do you pick the right one to use? Either you do it or the servers have to do it themselves. In either case you still have the problem of getting the right information to do routing, and once again the DNS provides the most viable solution. So why not use an address format that lets existing software do the routing with no changes or enhancements? > There's certainly nothing wrong with exploiting DNS and MX to solve this > problem, but I'd like to hear from those who have considered the > alternative(s) and prefer the above scheme (or don't). The fundamental reason for choosing this format of name is quite simple -- it is the only one that works using existing DNS-based routing technology. (You can quibble about what the localpart should look like, but the phone number has to be in the domain part in order for existing DNS routing to work. And the routing has to be done on a per-digit basis, and the digits have to be ordered the way they are.) Once you pick the DNS and decide to use existing routing capabilities and the existing SMTP infrastructure, you are pretty much locked into the present scheme. MIME taught us a lot of things, but possibly the most important is that the installed base is a major factor to be reckoned with. Schemes that involve new protocols and new servers are much harder to deploy than schemes that leverage off the installed base are. As a purely practical matter it would not have been possible for the remote printing experiment to be where it is now without taking advantage of the installed base's existing capabilities. New protocols are great things. New servers with complex capabilities are also great things. But they need to give us some capability existing services lack. Ned   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16697; 10 Sep 93 19:31 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16693; 10 Sep 93 19:31 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa10693; 10 Sep 93 19:31 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03840; Fri, 10 Sep 93 19:05:44 EDT Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03836; Fri, 10 Sep 93 19:05:43 EDT Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA07011; Fri, 10 Sep 93 16:05:32 -0700 Message-Id: <9309102305.AA07011@Mordor.Stanford.EDU> To: Johnny Eriksson Cc: Rick Troth , Marshall Rose , ietf-822@dimacs.rutgers.edu Subject: Re: Hypothetically speaking... Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Sat, 11 Sep 93 00:01:32 +0700. Date: Fri, 10 Sep 93 16:05:31 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Crocker X-Mts: smtp ---- Included message: > I still don't understand why this (and like-minded > print or FAX servers) aren't addressed according to: > > pager+4159408776@pagerserver.tpc.int > Scaling. Your proposal makes every message go to thru one single machine, bringing it to it's knees. Now or tomorrow. Or yester- day. Exactly right. And just to provide some extra detail to hammer this point home: By having the phone number as part of the domain name, you can have different paging servers provide service to different sets of telephone numbers. Since this reflect the currently reality of paging operation, it is an essential requirement for the Internet interface to it. Dave   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16976; 10 Sep 93 20:01 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16971; 10 Sep 93 20:01 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa11599; 10 Sep 93 20:01 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03900; Fri, 10 Sep 93 19:17:45 EDT Received: from rutvm1.rutgers.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03896; Fri, 10 Sep 93 19:17:44 EDT Message-Id: <9309102317.AA03896@dimacs.rutgers.edu> Received: from RUTVM1.RUTGERS.EDU by RUTVM1.RUTGERS.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 2424; Fri, 10 Sep 93 19:16:37 EDT Received: from RICEVM1.RICE.EDU (NJE origin MAILER@RICEVM1) by RUTVM1.RUTGERS.EDU (LMail V1.1d/1.7f) with BSMTP id 2753; Fri, 10 Sep 1993 19:16:37 -0400 Received: from ricevm1.rice.edu (NJE origin TROTH@RICEVM1) by RICEVM1.RICE.EDU (LMail V1.1d/1.7f) with BSMTP id 0317; Fri, 10 Sep 1993 18:16:55 -0500 Mime-Version: 1.0 Content-Type: text/plain Date: Fri, 10 Sep 93 18:15:22 CDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Rick Troth Subject: Re: Hypothetically speaking... To: ietf-822@dimacs.rutgers.edu Thanks very much for the replies. I'm sold. -- Rick Troth , Rice University, Information Systems   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17714; 10 Sep 93 21:02 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17710; 10 Sep 93 21:02 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa14363; 10 Sep 93 21:02 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04208; Fri, 10 Sep 93 20:41:09 EDT Received: from relay2.UU.NET by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04204; Fri, 10 Sep 93 20:41:09 EDT Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA14720; Fri, 10 Sep 93 20:41:07 -0400 Received: from verifone.UUCP by uucp6.uu.net with UUCP/RMAIL (queueing-rmail) id 203925.7169; Fri, 10 Sep 1993 20:39:25 EDT Received: by verifone.com with UUCP/PMDF (DECUS UUCP); Fri, 10 Sep 1993 14:37:25 -1000 Received: from verifone.com by verifone.com (PMDF V4.2-11 #2386) id <01H2SC0HPG40929YSG@verifone.com>; Fri, 10 Sep 1993 14:37:18 -1000 Date: Fri, 10 Sep 1993 14:37:18 -1000 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "James H. Thompson - HNL" Subject: What is text/plain? To: ietf-822@dimacs.rutgers.edu Message-Id: <01H2SC0HRL9U929YSG@verifone.com> Organization: VeriFone X-Ps-Qualifiers: /FONT=Courier-Bold/LINES=66/LEFT_MARGIN=36/CALCULATE/TOP_MARGIN=36/BOTTOM_MARGIN=36 X-Envelope-To: dimacs.rutgers.edu!ietf-822 X-Vms-To: IN%"ietf-822@dimacs.rutgers.edu" X-Vms-Cc: JIMMY_T Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT I was looking for a definition of the MIME text/plain subtype. In MIME I found: From RFC 1346 - MIME > > 7.1.2 The Text/plain subtype > > The primary subtype of text is "plain". This indicates > plain (unformatted) text. The default Content-Type for > Internet mail, "text/plain; charset=us-ascii", describes > existing Internet practice, that is, it is the type of body ^^^^^^^^^^^^^^^^^^^^^^ > defined by RFC 822. ^^^^^^^^^^^^^^^^^^ > In RFC-822 I found: From RFC 822 > > A general "memo" framework is used. That is, a message con- > sists of some information in a rigid format, followed by the main > part of the message, with a format that is not specified in this ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > document. The syntax of several fields of the rigidly-formated ^^^^^^^^ > ("headers") section is defined in this specification; some of > these fields must be included in all messages. > In comp.mail.mime, Steve Dorner, Qualcomm Inc said: > The MIME spec probably ought to say that RFC 821 defines existing Internet > practice so far as message bodies go. It's the one that specifies things > like 7 bits only and lines <1000 characters (pp 41-43). -- I'm confused! Jim +------------------------------------+--------------------------------------+ | James H. Thompson | jimmy_t@verifone.com (Internet) | | VeriFone Inc. | uunet!verifone!jimmy_t (UUCP) | | 100 Kahelu Avenue | 808-623-2911 (Phone) | | Mililani, HI 96789 | 808-625-3201 (FAX) | +------------------------------------+--------------------------------------+   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18257; 10 Sep 93 22:06 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18253; 10 Sep 93 22:06 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa16641; 10 Sep 93 22:06 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA06599; Fri, 10 Sep 93 21:52:34 EDT Received: from gw1.att.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA06595; Fri, 10 Sep 93 21:52:33 EDT Message-Id: <9309110152.AA06595@dimacs.rutgers.edu> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "t.l.hansen" To: ietf-822@dimacs.rutgers.edu Date: 10 Sep 1993 21:44 EDT Subject: Re: Hypothetically speaking... References: <9309102059.AA03200@dimacs.rutgers.edu> From: Rick Troth < I still don't understand why this (and like-minded print or FAX servers) < aren't addressed according to: < pager+4159408776@pagerserver.tpc.int < or even just < +4159408776@pagerserver.tpc.int < There's certainly nothing wrong with exploiting DNS and MX to solve this < problem, but I'd like to hear from those who have considered the < alternative(s) and prefer the above scheme (or don't). AT&T Mail uses something similar for its fax deliveries. You address the message to attmail!fax!+4159408776 or (after domain-style addresses are finally implemented) +4159408776@fax.attmail.com I think this is definitely more intuitive than something like fax@6.7.7.8.0.4.9.5.1.4.1.attmail.com. Tony Hansen hansen@pegasus.att.com, tony@attmail.com att!pegasus!hansen, attmail!tony   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19676; 10 Sep 93 22:33 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19672; 10 Sep 93 22:33 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa17779; 10 Sep 93 22:33 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA06617; Fri, 10 Sep 93 22:00:28 EDT Received: from gw1.att.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA06613; Fri, 10 Sep 93 22:00:27 EDT Message-Id: <9309110200.AA06613@dimacs.rutgers.edu> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "t.l.hansen" To: ietf-822@dimacs.rutgers.edu Date: 10 Sep 1993 21:54 EDT Subject: Re: Hypothetically speaking... References: << I still don't understand why this (and like-minded print or FAX servers) << aren't addressed according to: << pager+4159408776@pagerserver.tpc.int << or even just << +4159408776@pagerserver.tpc.int < Scaling. Your proposal makes every message go to thru one single machine, < bringing it to it's knees. Now or tomorrow. Or yester- day. Not hardly. Many implementations may force the messages to go through one single machine, but that is not inherent in the address. AT&T Mail supports a fax addressing scheme similar to that shown above, and it definitely does NOT use a single machine to do its fax deliveries. Tony Hansen hansen@pegasus.att.com, tony@attmail.com att!pegasus!hansen, attmail!tony   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22037; 10 Sep 93 23:03 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22033; 10 Sep 93 23:03 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa18795; 10 Sep 93 23:03 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA06634; Fri, 10 Sep 93 22:15:19 EDT Received: from ppp.dbc.mtview.ca.us by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA06630; Fri, 10 Sep 93 22:15:16 EDT Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA24227; Fri, 10 Sep 93 19:14:06 -0700 To: "t.l.hansen" Reply-To: ietf-822@dimacs.rutgers.edu Cc: ietf-822@dimacs.rutgers.edu Subject: Re: Hypothetically speaking... In-Reply-To: Your message of "10 Sep 1993 21:44:00 EDT." <9309110152.AA06595@dimacs.rutgers.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <24219.747713643.1@dbc.mtview.ca.us> Date: Fri, 10 Sep 1993 19:14:04 -0700 Message-Id: <24225.747713644@dbc.mtview.ca.us> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Marshall Rose > ... (after domain-style addresses are finally implemented) > > +4159408776@fax.attmail.com > > I think this is definitely more intuitive than something like > > fax@6.7.7.8.0.4.9.5.1.4.1.attmail.com. More intuitive yes, more scalable no. Of course, one would hope that the user would have a UI that would deal with the actual formation of the address. Perhaps even something that would take it in your format and map it to the tpc.int format... /mtr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22407; 10 Sep 93 23:34 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22403; 10 Sep 93 23:34 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa20072; 10 Sep 93 23:34 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA06724; Fri, 10 Sep 93 23:03:06 EDT Received: from sayshell.umd.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA06720; Fri, 10 Sep 93 23:03:05 EDT Received: from localhost by sayshell.umd.edu (NX5.67c/NeXT-1.0) id AA15843; Fri, 10 Sep 93 23:03:01 -0400 Message-Id: <9309110303.AA15843@sayshell.umd.edu> To: "t.l.hansen" Cc: ietf-822@dimacs.rutgers.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Louis A. Mamakos" Subject: Re: Hypothetically speaking... In-Reply-To: Your message of "10 Sep 1993 21:44:00 EDT." <9309110152.AA06595@dimacs.rutgers.edu> Date: Fri, 10 Sep 1993 23:03:01 -0400 X-Orig-Sender: louie@sayshell.umd.edu > or (after domain-style addresses are finally implemented) > > +4159408776@fax.attmail.com > > I think this is definitely more intuitive than something like > > fax@6.7.7.8.0.4.9.5.1.4.1.attmail.com. But the whole point of the latter address is that you can use DNS delegations and DNS wildcard RRs to refer to different gateway points. This would usually be used to get you close so that only local telephone calls need be made, or so the individual numbers or exchanges can be delegated to specific gateways. Take a look at the TPC.INT stuff for "remote printing" email -> FAX gateway for more details. Louis A. Mamakos University of Maryland, College Park   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01531; 11 Sep 93 4:48 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01521; 11 Sep 93 4:48 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id ae02230; 11 Sep 93 4:47 EDT Received: from [128.6.75.16] by IETF.CNRI.Reston.VA.US id aa00776; 11 Sep 93 3:08 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07418; Sat, 11 Sep 93 02:33:52 EDT Received: from THOR.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07414; Sat, 11 Sep 93 02:33:50 EDT Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-14 #1234) id <01H2M1WOUCQO8WVYP9@INNOSOFT.COM>; Fri, 10 Sep 1993 23:33:40 PST Date: Fri, 10 Sep 1993 23:05:25 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ned Freed Subject: Re: What is text/plain? In-Reply-To: Your message dated "Fri, 10 Sep 1993 14:37:18 -1000" <01H2SC0HRL9U929YSG@verifone.com> To: "James H. Thompson - HNL" Cc: ietf-822@dimacs.rutgers.edu Message-Id: <01H2SUU02YZE8WVYP9@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > I was looking for a definition of the MIME text/plain subtype. > In MIME I found: > > 7.1.2 The Text/plain subtype > > > > The primary subtype of text is "plain". This indicates > > plain (unformatted) text. The default Content-Type for > > Internet mail, "text/plain; charset=us-ascii", describes > > existing Internet practice, that is, it is the type of body > ^^^^^^^^^^^^^^^^^^^^^^ > > defined by RFC 822. > ^^^^^^^^^^^^^^^^^^ > In RFC-822 I found: > From RFC 822 > > A general "memo" framework is used. That is, a message con- > > sists of some information in a rigid format, followed by the main > > part of the message, with a format that is not specified in this > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > document. The syntax of several fields of the rigidly-formated > ^^^^^^^^ > > ("headers") section is defined in this specification; some of > > these fields must be included in all messages. I entirely fail to see what the problem is here. Perhaps you need to read both specifications in their entirety, rather than quoting isolated and incomplete passages? RFC822 also says: > Messages consist of lines of text. No special provisions > are made for encoding drawings, facsimile, speech, or structured > text. No significant consideration has been given to questions > of data compression or to transmission and storage efficiency, And: > The body is simply a sequence of lines containing ASCII charac- > ters. It is separated from the headers by a null line (i.e., a > line with nothing preceding the CRLF). There's more but I won't bother with it here. This collectively defines how the body of a message is structured, and is what RFC1341 is talking about. The "format" of the body, in RFC822 parlance, is *explicitly* left undefined. This lack of defined format in the case of text/plain is explicitly reiterated by RFC1341. The lack of defined format means that you cannot assume that the material in the body is FORTRAN, C, TeX, nroff, a Haiku, a Sonnet, in English, Spanish, French, German, in any single language, in any language whatsoever, etc. etc. etc. It could be all of these things, none of them, something else, or some hybrid. Since the format of a text/plain body is not defined all we are concerned about is structure. And RFC822 gives us all the structure we need: A message body consists of sequences ASCII characters with CRLF delimiters between them. We call these sequences "lines". > In comp.mail.mime, Steve Dorner, Qualcomm Inc said: > > The MIME spec probably ought to say that RFC 821 defines existing Internet > > practice so far as message bodies go. It's the one that specifies things > > like 7 bits only and lines <1000 characters (pp 41-43). You appear to be confusing format and structure. Format defines some sort of semantics for the object and may impose syntax limitations. The structure is purely syntactic; no semantics are implied by it. (This is stretching things a bit, since the use of ASCII imposes some restrictions on syntax as implying some semantics. But it isn't that much of a stretch, as base64 encoding shows.) In any case, the omission of the RFC821 rules from RFC1341 was the subject of considerable discussion and is quite intentional. These are RFC821's own restrictions. They are not MIME restrictions and imposing them on MIME would be a really terrible idea. MIME is designed so it can be used in conjunction with pure binary transports -- places where there are no line length limits, no character set restrictions, no 7bit restrictions, etc. etc. etc. And MIME is being using in such environments today. Restrictions like these are transport issues and nothing more. MIME is designed to work in environments that impose such restrictions but is in no way dependent on the restrictions. This is what transport neutrality is all about. All in all, it is amazing how cleanly it all fits together. Ned   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01565; 11 Sep 93 4:48 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01546; 11 Sep 93 4:48 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id ai02230; 11 Sep 93 4:47 EDT Received: from dimacs.rutgers.edu by IETF.CNRI.Reston.VA.US id aa00977; 11 Sep 93 3:35 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07512; Sat, 11 Sep 93 02:57:55 EDT Received: from THOR.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07508; Sat, 11 Sep 93 02:57:53 EDT Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-14 #1234) id <01H2M1WOUCQO8WVYP9@INNOSOFT.COM>; Fri, 10 Sep 1993 23:57:46 PST Date: Fri, 10 Sep 1993 23:39:08 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ned Freed Subject: RE: Hypothetically speaking... In-Reply-To: Your message dated "Fri, 10 Sep 1993 21:54 -0400 (EDT)" <9309110200.AA06613@dimacs.rutgers.edu> To: hansen@pegasus.att.com Cc: ietf-822@dimacs.rutgers.edu Message-Id: <01H2SVNW5FA28WVYP9@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > > Scaling. Your proposal makes every message go to thru one single machine, > > bringing it to it's knees. Now or tomorrow. Or yester- day. > Not hardly. Many implementations may force the messages to go through one > single machine, but that is not inherent in the address. AT&T Mail supports > a fax addressing scheme similar to that shown above, and it definitely does > NOT use a single machine to do its fax deliveries. Of course you can implement anything you want in any way you like. You can route on the Fruit-of-the-day: header if it suits your fancy. But the existing routing structure provided by the DNS and MX records is already in place. Replacing or enhancing it would be a monumental undertaking if it could be done at all (which I strongly doubt). So, given that: (1) We have a system in place that represents billions of dollars of investment. (2) It isn't going to go away and isn't likely to be updated or updateable. (3) It can be used, with no modifications, to give us the service we want. (4) It imposes some restrictions on address format, but the restrictions are entirely reasonable, and no other format will work. There is only one rational choice, and it is the one Marshall and Carl made. (I expect nothing less from engineers of their caliber.) I also don't entirely agree with the evaluations of the relative intuitiveness of the two formats. Specifically, neither of them are especially intuitive to an unsophisticated user, and I don't think comparing the degree of nonintuitiveness of two nonintuitive formats is a useful exercise. (As it happens I have substantial experience with the address format you propose, since my software uses something quite close to it.) In either case a decent front end is urgently needed, and not just for addresses -- cover page information usually has to be provided as well. Once this is done the underlying address format ceases to be an issue aside from its ability to interwork with Internet mail. Ned   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01728; 11 Sep 93 5:06 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01724; 11 Sep 93 5:06 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa02957; 11 Sep 93 5:06 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08077; Sat, 11 Sep 93 04:28:18 EDT Received: from isrgwy.isr.recruit.co.jp by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08073; Sat, 11 Sep 93 04:28:14 EDT Received: from terra.isr.recruit.co.jp by isrgwy.isr.recruit.co.jp (5.65+1.6W/6.4J.6-MDC-1.0) id AA08786; Sat, 11 Sep 93 17:32:46 JST Received: from localhost by terra.isr.recruit.co.jp (4.1/6.4J.6-MDC-1.0) id AA06042; Sat, 11 Sep 93 17:29:38 JST Return-Path: Message-Id: <9309110829.AA06042@terra.isr.recruit.co.jp> To: ietf-822@dimacs.rutgers.edu Cc: suzuki@isr.recruit.co.jp Subject: unsubscribe Date: Sat, 11 Sep 93 17:29:38 JST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Katsunori Suzuki Please unsubscribe me from this mailing list. Thank you in advance. Katsunori Suzuki   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06566; 11 Sep 93 15:03 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06562; 11 Sep 93 15:03 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa21021; 11 Sep 93 15:03 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12182; Sat, 11 Sep 93 14:51:20 EDT Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12178; Sat, 11 Sep 93 14:51:19 EDT Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA29712; Sat, 11 Sep 93 11:51:16 -0700 Message-Id: <9309111851.AA29712@Mordor.Stanford.EDU> To: "t.l.hansen" Cc: ietf-822@dimacs.rutgers.edu Subject: Re: Hypothetically speaking... Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of 10 Sep 93 21:54:00 -0400. <9309110200.AA06613@dimacs.rutgers.edu> Date: Sat, 11 Sep 93 11:51:15 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Crocker X-Mts: smtp Tony (et al), I suspect there is a key point of design (architecture) being missed, here. A note from Ned Freed asserted the "operational" implication of this architectural point, but just in case the underlying framework is being missed: A sender needs to specify an "address"; the transport system needs to route it; and the receiver needs to be ready with server arms open and waiting. This model can be made more complicated by having the routing be a multi-phase thing, so that the decision process isn't specified globally. But some set of decisions have to figure out how to get from sender to receiver. (Stupidly basic stuff, I know, but bear with me.) In Internet email, addresses are of the formal local-part@global-part. The semantics of the global part are truly global. ANYONE can parse and comprehend them. The semantics of the local part are truly local. NOONE but the entity referenced in the global part is allowed to believe it has the slightest clue as to the meaning of the local-part string. What this means is that: 1. Placement of the telephone number in the global string means that the global "routing" system, in the form of DNS registration, lets different servers plug in in different places, without any particular coordination among themselves. Further, it means that the sender needs no special knowledge. They specify the phone number, as a classic "address" (which says where a thing is but not how to get to it) and let DNS resolution and IP routing figure out the rest. 2. Placement of the telephone number in the local string means either that the global part needs to have its own special semantics or that the global part is used only for partial routing and that the local part then must be further processed, to send the message on, to the real final destination. In the attmail example, note that the sender must know to specify attmail. The fact that attmail has multiple fax servers is special knowledge to attmail and is handled as part of the "further" processing I cited. Once we start having these servers provided by a very large number of independent organizations, then I'm not sure how we do the addressing. Remember that the global-part is the only place we should put "global" addressing information and remember that NOONE is allowed to interpret the local-part, other than the global-part referent. So, alternative 1 results in some astonishingly clean behaviors: 1. Standard format for ALL fax. The only thing that varies is the phone number. 2. No redundant addressing information in the string. 3. Scalable at the whim of the servers. Users are oblivious. 4. Variable scope for servers. If I want a server just for my home, I can register it and don't have to get anyone's permission except for regular DNS registration. The same holds for country-level service provision, for the really ambitious servers. Dave   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05735; 13 Sep 93 2:42 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05731; 13 Sep 93 2:42 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa01828; 13 Sep 93 2:42 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01878; Mon, 13 Sep 93 02:09:36 EDT Received: from taunivm.tau.ac.il by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01874; Mon, 13 Sep 93 02:09:31 EDT Message-Id: <9309130609.AA01874@dimacs.rutgers.edu> Received: from TAUNIVM.TAU.AC.IL by VM.TAU.AC.IL (IBM VM SMTP V2R1) with BSMTP id 9050; Mon, 13 Sep 93 08:09:43 IST Received: from VM.TAU.AC.IL (NJE origin HANK@TAUNIVM) by TAUNIVM.TAU.AC.IL (LMail V1.1d/1.7f) with BSMTP id 3132; Mon, 13 Sep 1993 08:09:43 +0200 Date: Mon, 13 Sep 93 08:08:34 IST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Hank Nussbacher Subject: Re: SNPP To: ietf-822@dimacs.rutgers.edu Mime-Version: 1.0 Content-Type: Text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT > PAGEr > > The PAGEr command sets the pager ID (PID) number, for the > transaction, into the gateway. The PID used must reside in the TAP > terminal (and there is where it should be validated). Limited > validation may optionally be done on the server (such as all > numeric, and ID length), or it can all be done by the TAP terminal > at the time the page is sent. Duplicating the PAGEr command before > SENDing the message should produce an "!ERROR, Already Entered" > message, and allow the user to continue. > > MESSage > > The MESSage command sets the numeric or alphanumeric message for > the transaction, into the gateway. Limited validation of the > message may be done on the SNPP server (such as length), but type- > of-message validation should be done on the TAP terminal. > Duplicating the MESSage command before SENDing the message should > produce an "!ERROR, Already Entered" message, and allow the user to > continue. I would like to see the two system negotiate a connection. One parameter I can think of is message limit. The server might only want to accept messages up to say 200 characters (suppose by mistake a user sends a 3 page email message to the user or even worse someone who has it out for you sends to your beeper a Unix core dump :-)). So I would like to see when the client says 'PAGE nnnnnnn' that the server come back with 'Ok, limit=mmm'. This way the client can't complain that he didn't know that some trailing characters were gonna get lost. You allude to length but don't specify it clearly enough. I would also like to see the ability to send multiline MESSages. You don't specify what constitutes the end of the MESS - would it be NL/CR? I would also like to see mention of 7bit vs 8bit. As we know, the older SMTP is 7bit limited. That means that national language support has to go via MIME until everyone implements EHLO. Today, places that speak languages other than English and US-ASCII, need to use Base64 and Quoted-Printable to communicate. I would hope that SNPP, starting from scratch would be 8bit and specified as such. Let me add my vote that SNPP should not be batch, or store and forward or email. It should be realtime/online/interactive. Paging someone means *now*. Not in 30 minutes to be read, not the following day, but now. Hank Nussbacher vm.biu.ac.il Israel   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07227; 13 Sep 93 6:33 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07223; 13 Sep 93 6:33 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa07694; 13 Sep 93 6:33 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02830; Mon, 13 Sep 93 06:24:21 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02826; Mon, 13 Sep 93 06:24:20 EDT Received: from guppylake.noname (guppylake.bellcore.com) by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Mon, 13 Sep 93 06:24:15 EDT Received: by guppylake.noname (4.1/SMI-4.1) id AA11968; Mon, 13 Sep 93 06:24:52 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.guppylake.noname.sun4.41 via MS.5.6.guppylake.noname.sun4_41; Mon, 13 Sep 1993 06:24:51 -0400 (EDT) Message-Id: Date: Mon, 13 Sep 1993 06:24:51 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ietf-822@dimacs.rutgers.edu, "t.l.hansen" Subject: Re: Hypothetically speaking... In-Reply-To: <9309110200.AA06613@dimacs.rutgers.edu> References: <9309110200.AA06613@dimacs.rutgers.edu> Excerpts from mail: 10-Sep-93 Re: Hypothetically speaking... t.l.hansen@pegasus.att.c (730) > << I still don't understand why this (and like-minded print or FAX servers) > << aren't addressed according to: > << pager+4159408776@pagerserver.tpc.int > << or even just > << +4159408776@pagerserver.tpc.int > < Scaling. Your proposal makes every message go to thru one single machine, > < bringing it to it's knees. Now or tomorrow. Or yester- day. > Not hardly. Many implementations may force the messages to go through one > single machine, but that is not inherent in the address. AT&T Mail supports > a fax addressing scheme similar to that shown above, and it definitely does > NOT use a single machine to do its fax deliveries. Dave Crocker did his usual thorough job in addressing this, but I thought I'd take a stab at being very pithy. It is incorrect to claim that the "pager+###@faxhost" approach cannot easily be made to scale. However, it is (I believe) correct to claim that it cannot be made to be SEPARATELY ADMINISTERED (e.g. by competitive paging services) without the creation of considerable new mechanism. The DNS approach allows scaling and independent administration without any new mechanism. Now, if AT&T had a monopoly on paging services, this wouldn't matter...   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09709; 13 Sep 93 9:35 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09705; 13 Sep 93 9:35 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa13829; 13 Sep 93 9:35 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03939; Mon, 13 Sep 93 09:18:06 EDT Received: from uxc.cso.uiuc.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03935; Mon, 13 Sep 93 09:18:02 EDT Received: from dorner.slip.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA15472 (5.67a/IDA-1.5 for ); Mon, 13 Sep 1993 08:17:39 -0500 Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA07514 (5.65c/IDA-1.4.4 for ietf-822@dimacs.rutgers.edu); Mon, 13 Sep 1993 08:18:49 -0500 Message-Id: <199309131318.AA07514@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 13 Sep 1993 08:18:23 -0500 To: Nathaniel Borenstein , ietf-822@dimacs.rutgers.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Dorner Subject: Re: Hypothetically speaking... At 6:24 AM 9/13/93 -0400, Nathaniel Borenstein wrote: >It is incorrect to claim that the "pager+###@faxhost" approach cannot >easily be made to scale. However, it is (I believe) correct to claim >that it cannot be made to be SEPARATELY ADMINISTERED (e.g. by >competitive paging services) without the creation of considerable new >mechanism. The DNS approach allows scaling and independent >administration without any new mechanism. Now, if AT&T had a monopoly >on paging services, this wouldn't matter... I do not understand this comment. It would seem to me that the situation is really the reverse: pager+####@page.region.att.com pager+####@beeper.region.mci.com pager+####@pager.region.sprint.com Or whatever. Here, the sender could explicitly specify what service to use. I don't see how this works if you use the phone number as a name in the DNS. Wouldn't choosing a different carrier require changes to the DNS? Or do you intend separate domains for each paging service? Or did I completely misunderstand this whole thing? -- Steve Dorner, Qualcomm Inc.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12993; 13 Sep 93 11:35 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12989; 13 Sep 93 11:35 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa22210; 13 Sep 93 11:35 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA05560; Mon, 13 Sep 93 11:14:02 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA05556; Mon, 13 Sep 93 11:14:01 EDT Received: from guppylake.noname (guppylake.bellcore.com) by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Mon, 13 Sep 93 11:13:51 EDT Received: by guppylake.noname (4.1/SMI-4.1) id AA18302; Mon, 13 Sep 93 11:14:28 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.guppylake.noname.sun4.41 via MS.5.6.guppylake.noname.sun4_41; Mon, 13 Sep 1993 11:14:26 -0400 (EDT) Message-Id: Date: Mon, 13 Sep 1993 11:14:26 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ietf-822@dimacs.rutgers.edu, Steve Dorner Subject: Re: Hypothetically speaking... In-Reply-To: <199309131318.AA07514@dorner.slip.uiuc.edu> References: <199309131318.AA07514@dorner.slip.uiuc.edu> I think we have two totally different models operating here. The question is, who assigns pager numbers? If pager numbers are, like fax numbers, part of the telephone numbering system (NANP in North America), then the DNS system works, and the choice of vendor is address-transparent (as has recently become the case with 800 service in the US, for example). If pager numbers are to be assigned in a proprietary fashion, then addresses are FUNDAMENTALLY vendor-specific, and the pager+number@vendor.com system is the only one that makes sense to me. Or maybe *I* am the one who is missing something....   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03967; 13 Sep 93 14:51 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ah03901; 13 Sep 93 14:51 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa05309; 13 Sep 93 13:02 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA05470; Mon, 13 Sep 93 11:00:36 EDT Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA05466; Mon, 13 Sep 93 11:00:34 EDT Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA06576; Mon, 13 Sep 93 08:00:31 -0700 Message-Id: <9309131500.AA06576@Mordor.Stanford.EDU> To: Steve Dorner Cc: ietf-822@dimacs.rutgers.edu Subject: Re: Hypothetically speaking... Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 13 Sep 93 08:18:23 -0500. <199309131318.AA07514@dorner.slip.uiuc.edu> Date: Mon, 13 Sep 93 08:00:31 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Crocker X-Mts: smtp Steve, It is unlikely that a page recipient will have more than one service provider, so I'd guess that the kind of question you are raising won't be a real problem for paging. But there certainly may/will be other uses for tpc.int (e.g., the original fax printing) in which multiple providers will be available. (In fact, there already are.) The current scheme has the major benefit of not requiring that the sender know anything special about any given recipient, other than the standard core piece of information, namely the telephone number. You raise the concern that this very approach PREVENTS the sender from making a choice, if they want to. I did some checking and it turns out that the assumption isn't correct. The DNS returns the list of ALL providers. If you don't care, choose the first. If you do care, look deeper at the list. Dave   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19432; 16 Sep 93 22:38 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19428; 16 Sep 93 22:38 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa10773; 16 Sep 93 22:38 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA10044; Thu, 16 Sep 93 21:54:27 EDT Received: from THUD.CS.UTK.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA10040; Thu, 16 Sep 93 21:54:26 EDT Received: by thud.cs.utk.edu (5.61+IDA+UTK-930125/2.7c-UTK) id AA25724; Thu, 16 Sep 93 21:54:23 -0400 Date: Thu, 16 Sep 93 21:54:23 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: moore@cs.utk.edu Message-Id: <9309170154.AA25724@thud.cs.utk.edu> To: ietf-822@dimacs.rutgers.edu Subject: internet draft for delivery status notifications I have just submitted an Internet Draft entitled MIME Content-Type for Delivery Status Notifications which describes a well-defined format for delivery reports, and non-delivery reports. (there is also a draft describing an SMTP extension to request such reports). For the time being, these can also be had via anonymous ftp to cs.utk.edu, directory pub/moore, files: draft-moore-mime-delivery-00.txt (mime content-type) draft-moore-smtp-drpt-00.txt (smtp extension) (note that the Internet Drafts people may assign different filenames.) Keith Moore   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09310; 17 Sep 93 14:46 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09306; 17 Sep 93 14:46 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa01140; 17 Sep 93 14:46 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA20224; Fri, 17 Sep 93 14:01:00 EDT Received: from netcom5.netcom.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA20220; Fri, 17 Sep 93 14:00:58 EDT Received: by netcom5.netcom.com (5.65/SMI-4.1/Netcom) id AA29156; Fri, 17 Sep 93 11:01:20 -0700 Message-Id: <9309171801.AA29156@netcom5.netcom.com> X-Org: The Tigon Corporation X-Phone: (214) 733-2722 To: ietf-822@dimacs.rutgers.edu Cc: dcrocker@sgi.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Greg Vaudreuil Subject: Comments and extensions to STIF Date: Fri, 17 Sep 93 11:01:15 -0700 X-Orig-Sender: gvaudre@netcom.com Dave, I have reviewed the STIF document and have a number of comments. At a high level I agree that this is a needed piece of technology and the general approach is reasonable. I have several applications for which this is almost adequate and would like to challenge STIF to meet these needs within the established technology of RFC 822/MIME. One assumption I need to challenge is that exchanged information will be of a consistent type (text) and a consistent character within a header set. I can see an immediate need to exchange information in multiple character sets, although only with only one character set per header line, and items which are not text, such as X-Face (X.500 portrait) and Spoken Name. While these non-text examples can be encoded into a text form, the necessary specification of format and encoding is unfortunately outside the scope of the current STIF document. An alternate approach to make these assumptions apply to a header line rather than to the header as a whole. This gives the flexibility to include items of multiple character sets in the same header without inventing new protocol. This approach solves the multiple character sets and multiple encodings needs, but does not solve the mixed media. The encoded word assumes data is of type text/plain and provides the one parameter to the text/plain as a separate field for the specification of the character set. It would be useful to extend this to allow for short segment of any arbitrary content-type. To do this I propose an extension to the encoded word for STIF use. I would expect that the line length limitations of the encoded word would be preserved. The most obvious extension is to add an additional parameter to the encoded word to represent the content-type, either using a shortened version of the content-type name or by using the corresponding MIME branch OID used for the MIME/MHS mapping. (I assume it is reasonable to use an implicit OID branch to avoid the long number string) The character set parameter slot can be used for any necessary parameter information for a given content- type. This approach has two limitations. First it is not compatible with current encoded word parsers, and second, it adds to the already large overhead of the encoded word further reducing the amount of data in a single word. I prefer another approach however which is backward compatible with the encoded word. That is, use the corresponding MIME content-type OID (or some other short content-type alias) in the character set parameter when the content-type is not text/plain. A reserved token, such as the letters OID, can be used if necessary to indicate that this is not a character set This approach will work only for simple content-types which have no use of parameters. I do not believe this is a limitation for the short simple objects envisioned for inclusion in STIF headers. Example: Name: Gregory M. Vaudreuil Face: =?OID-GIF?B?LKJDFOsdfJLKLIreJLtyuJLSDtyuIJLKtutututuJOIJSFIJK?= Best Friend: =?iso-8859-8?b?7eXs+SDv4SDp7Oj08A==?= Phone: +1 214 733 2722 (Work) / +1 214 733 8666 (Fax) Greg Vaudreuil   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04422; 18 Sep 93 18:35 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04417; 18 Sep 93 18:35 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa27903; 18 Sep 93 18:35 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02942; Sat, 18 Sep 93 18:10:27 EDT Received: from domen.uninett.no by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02938; Sat, 18 Sep 93 18:10:25 EDT Message-Id: <9309182210.AA02938@dimacs.rutgers.edu> Received: from localhost by domen.uninett.no with SMTP (PP) id <21250-0@domen.uninett.no>; Sun, 19 Sep 1993 00:10:06 +0200 To: Greg Vaudreuil Cc: ietf-822@dimacs.rutgers.edu, dcrocker@sgi.com Subject: Re: Comments and extensions to STIF In-Reply-To: Your message of "Fri, 17 Sep 1993 11:01:15 PDT." <9309171801.AA29156@netcom5.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 19 Sep 1993 00:10:04 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Harald T. Alvestrand" Greg, Dave: I have unfortunately not had the time to look closely at STIF (perhaps hoping that the relative quiet meant that it had died....) I dislike the basic assumption made in STIF: That it is appropriate to define an international format that: - Is intended to be "nearly human readable" - Imposes special syntax on Norwegian dat fields ([]), which means that you have to know when you start typing a line whether or not you need to put Norwegian characters in there - Does not allow at all the use of Norwegian in tag names. (for instance, the Norwegian word for "birth" contains an O-slash). I would much rather prefer to see an approach that either went all the way towards being machine parseable (my preference: SGML....), or went all the way towards being "special-looking text", such as the Tab-separated-format that, I believe, supports a "charset" parameter. Harald Tveit Alvestrand   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04780; 18 Sep 93 19:50 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04776; 18 Sep 93 19:50 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa00326; 18 Sep 93 19:50 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03332; Sat, 18 Sep 93 19:21:51 EDT Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03328; Sat, 18 Sep 93 19:21:50 EDT Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA15878; Sat, 18 Sep 93 16:21:42 -0700 Message-Id: <9309182321.AA15878@Mordor.Stanford.EDU> To: "Harald T. Alvestrand" Cc: ietf-822@dimacs.rutgers.edu Subject: Re: Comments and extensions to STIF Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Sun, 19 Sep 93 00:10:04 +0200. <9309182210.AA02938@dimacs.rutgers.edu> Date: Sat, 18 Sep 93 16:21:42 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Crocker X-Mts: smtp Harald, ---- Included message: - Does not allow at all the use of Norwegian in tag names. (for instance, the Norwegian word for "birth" contains an O-slash). The concern for use of international character sets in name strings was a moderately hot topic during the Mime discussions and it has been mentioned a number of times about STIF. We have no quarrel about the general need to support international character sets and languages, so the only question is when and how. One model could be: Always. Any string may be in any character set. Another model could be: All "values" may be in any character set, but the "tags" for the values are more restricted. Other forms for the model are possible, of course, but I find myself favoring this second framework. Standardizing a framework for doing attribute/value exchanges requires that there be some common base. For the Internet, that base must work for the whole Internet, in my opinion. To the extent that some information is special to a certain community, I believe we MUST allow that community a means of expressing the information. To the extent that the exchange is intended for the entire Internet, then it MUST be universal. STIF is intended for exchanges on the Internet. It is attempting to provide a base for standardizing sets of attributes. This MUST include the NAMES of those attributes, since that is the only way to refer to them. Allowing variation in charactersets for that part of the specifications will, I believe, introduce optional behavior that only adds to complexity and does not faciliate interoperability. This is one point of view. I'd be interested in hearing counter-views. Dave   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15429; 19 Sep 93 13:43 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15425; 19 Sep 93 13:43 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa02406; 19 Sep 93 13:43 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12097; Sun, 19 Sep 93 13:28:19 EDT Received: from umail.umd.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12093; Sun, 19 Sep 93 13:28:17 EDT Received: by umail.UMD.EDU (5.57/Ultrix3.0-C) id AA25786; Sun, 19 Sep 93 13:28:15 -0400 Date: Sun, 19 Sep 93 13:28:15 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dana S Emery To: ietf-822@dimacs.rutgers.edu Subject: Re: Comments and extensions to STIF Message-Id: In-Reply-To: Your message <9309182321.AA15878@Mordor.Stanford.EDU> of Sat, 18 Sep 93 16:21:42 -0700 Content-Type: TEXT/plain; charset=US-ASCII > STIF is intended for exchanges on the Internet. It is > attempting to provide a base for standardizing sets of > attributes. This MUST include the NAMES of those > attributes, since that is the only way to refer to > them. Concur. A well designed GUI can sheild the user from ever having to see the standardized tags, it would present translations of those tags to the user, but would transmit the standardized ascii. Consider the parrallelism: binary/ascii ascii_tags/unified_display_code -- dana s emery   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07759; 20 Sep 93 15:13 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07755; 20 Sep 93 15:13 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa08110; 20 Sep 93 15:12 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12917; Mon, 20 Sep 93 14:54:48 EDT Received: from VAXL1.DANAVICTOR.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12913; Mon, 20 Sep 93 14:54:46 EDT Message-Id: <9309201854.AA12913@dimacs.rutgers.edu> Date: Mon, 20 Sep 1993 13:54 CdT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "WARREN SMITH - VICTOR PRODUCTS - LISLE IL." To: IETF-822@dimacs.rutgers.edu Cc: WSMITH@vaxl1.danavictor.com Subject: ADD SUBSCRIPTION ADD SUBSCRIPTION   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03947; 22 Sep 93 7:33 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03943; 22 Sep 93 7:33 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa08568; 22 Sep 93 7:33 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03403; Wed, 22 Sep 93 07:16:01 EDT Received: from othello.admin.kth.se by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03399; Wed, 22 Sep 93 07:15:59 EDT Received: from mercutio.admin.kth.se by othello.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0b) id AA26397; Wed, 22 Sep 93 13:15:49 +0200 Received: by mercutio.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0) id AA25241; Wed, 22 Sep 93 13:15:12 +0200 Date: Wed, 22 Sep 93 13:15:12 +0200 Message-Id: <9309221115.AA25241@mercutio.admin.kth.se> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Olle Jarnefors To: ietf-822@dimacs.rutgers.edu Cc: Dave Crocker , Olle Jarnefors In-Reply-To: <9309182321.AA15878@Mordor.Stanford.EDU> (Sat, 18 Sep 93 16:21:42 -0700; From: Dave Crocker ) Subject: Re: Comments and extensions to STIF > This is one point of view. I'd be interested in hearing counter-views. I gave some comments on STIF a couple of months ago but got no reactions. Obviously I sent them to the wrong mailing list, ;-) So, once more: ----- Date: Thu, 15 Jul 93 19:13:23 +0200 Message-Id: <9307151713.AA18392@othello.admin.kth.se> From: Olle Jarnefors To: Dave Crocker Cc: , Peter Svanberg , Olle Jarnefors Subject: Comments on STIF I'm unfortunately not able to attend the STIF BOF (RARE WG-CHAR meeting at the same time), but here are some preliminary comments on draft 00: I think STIF is really needed. I generally like the ideas but they can be both extended and simplified. 1) The treatment of "alternate character sets" I regard as the least satisfying part of the specification: a) The BNF excludes characters represented by octets > 127 in ! b) Characters outside the US-ASII repertoire can't be used in s. But for example some Japanese concepts can't be expressed adequately in English (nor Latin). c) Everything in s using characters outside US-ASCII must be put between square brackets. This makes STIF data awkward to read and difficult to input for most users. d) STIF data using an alternate character set is in reality a _dual_ coded character set thing. This is unnecessary since all US-ASCII characters are included in almost all alternate character sets. In addition, this makes the use of a MIME charset parameter indicating _one_ character set improper. I have a better and simpler solution, which I intend to present on the mailing list. 2) STIF follows "typical RFC822 rules for wrapping of field data" (section 2.6, paragraph 3). I suppose that this doesn't mean that continuation lines of a has to start with linear white space. That would be unnecessary due to the semicolon delimiters. It's however much more reader-friendly to start each named field on a new line, so advice to that effect should be included in the document. 3) I'm not sure that the STIF specification need to specify the internal syntax of s (as is done now with and and LWSP). It should be sufficient to exclude "\", ">" and "/" from the s. 4) I think that "," would be a better separator in s than "/", because it would be more natural and easy to understand as such for ordinary users. 5) I feel that ordinary parentheses are used frequently enough in data that is to be expressed in s to motivate that another construction for comments should be used. I suggest that "!!" leads into a comment which ends with the following CRLF (or EOF). 6) My final suggestion is that STIF is extended to allow representation of a file of STIF-structured records. These could be separated by blank lines and should not have to be named like . (If record names are needed in a particular case a special record name field can be included in all records.) -- Olle Jarnefors, Royal Institute of Technology, Sweden   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02546; 24 Sep 93 6:47 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02542; 24 Sep 93 6:47 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa06284; 24 Sep 93 6:47 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA20346; Fri, 24 Sep 93 06:07:37 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA20342; Fri, 24 Sep 93 06:07:36 EDT Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Fri, 24 Sep 93 06:07:31 EDT Received: by greenbush.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Fri, 24 Sep 93 06:07:30 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.greenbush.galaxy.sun4.41 via MS.5.6.greenbush.galaxy.sun4_41; Fri, 24 Sep 1993 06:07:29 -0400 (EDT) Message-Id: <8gcgPVi0M2YtE74d83@thumper.bellcore.com> Date: Fri, 24 Sep 1993 06:07:29 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Nathaniel Borenstein Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: info-mime@thumper.bellcore.com, ietf-822@dimacs.rutgers.edu Subject: Lost mail I just managed to misconfigure things very badly, and I think I've lost a day or two's worth of info-mime and ietf-822 mail. If you're waiting for an answer from me on anything that you said on the mailing list in the last day or two, please let me know. -- Nathaniel