CDs in the mail
Robert Ullmann <Ariel@relay.prime.com> Fri, 08 March 1991 19:02 UTC
Received: from dimacs.rutgers.edu by NRI.NRI.Reston.VA.US id aa11192; 8 Mar 91 14:02 EST
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA18979; Fri, 8 Mar 91 13:44:29 EST
Received: from RUTGERS.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA18975; Fri, 8 Mar 91 13:44:27 EST
Received: from Relay.Prime.COM by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA28810; Fri, 8 Mar 91 12:43:31 EST
Message-Id: <9103081743.AA28810@rutgers.edu>
Received: (from user ARIEL) by Relay.Prime.COM; 08 Mar 91 12:47:50 EST
To: IETF SMTP list <IETF-SMTP@dimacs.rutgers.edu>
From: Robert Ullmann <Ariel@relay.prime.com>
Subject: CDs in the mail
Date: Fri, 08 Mar 1991 12:47:50 -0500
Hi, I would like to suggest that the members of this group read (or, hopefully, re-read, having read it before :-) section 1 of RFC1140 ("The Standardization Process"). As I understand it, and know from my past experience, Internet protocols (at least the ones that *work*) go through approximately this process: 0: someone gets a Neat Idea <grin> 0.5: (optional) they write it down 1: an initial, experimental, WORKING implementation is constructed. 2: the implementation gets used by some community (the larger and more diverse the better, but usually is within some organization or other group, because everyone is running the same program). 2.5: (optional) return to step 0. <wide grin> 3: an RFC, with status EXPERIMENTAL and ELECTIVE gets published. (RFC1090 had a user base of 3,000 in 22 countries at this point; RFC1154 somthing like 20,000 in 27 countries) (note that RFC1090 says "proposes a standard"; in strict language, this should have been "describes an elective, experimental protocol") 4: other implementations are written and used. 5: IETF WG advances it to Proposed Standard 5.5: two independent implementations MUST exist, 4 months go by 6: IESG advances it to Draft Standard 6.5: (minimum) six months go by 6: IESG./IAB advances it to Internet Standard ___ (phew.) David Robinson and myself have been patiently (more-or-less :-) following through this procedure. We have 3 years of experience with Encoding:, the problems, side effects (ever seen someone mail a 32 megabyte object? Not too unusual when you have, in essence, sender-initated arbitrary file transfer. BITNET has some similar experience.) I have been looking over the proposals in the last few days, and my first strong reaction is: this person really ought to go implement his Neat Idea *first*, see if it works. See if users will use it (even in a comparatively tiny community), *then* propose it. ---- That said: I don't really have any objection to a encoding/content-type keyword of "multipart" with some encapsulation syntax. I _certainly_ have no objections to experimenting with it. (rather, I would demand that the proponents DO the experiments :-) Note that if you define Content-Type: multipart, you implicitly (because RFC1154 says it uses the same set of keywords as C-T) provide for: Encoding: 14 text, multipart This is _not_ silly. Look at it this way: a multi-media "document" structuring (of more or less sophistication, from Andrew or Slate down to RFC934 and similar things), is _not_ the kind of major body parts intended by X.400. There are two different levels here. Consider a multi-<whatever> object I received a few days ago. Not in email, but in the real-world-post. :-) The interesting part of the contents was some music. (good classical music) Combined with some other info in a structured format encoded on the surface of a CD. The box also contained (besides the two CDs) a note, an invoice, and a reply envelope. Consider how this could be done in electronic mail. This is not stretching the analogy. In fact, it isn't an analogy at all. The content of the box of value is in fact data. Bits. Lots of bits ... :-) Andrew (for example) can represent the music. (Does it have a defined syntax for the exact sound-coding used on CD's? One could be defined if not). Each CD is an Andrew object. (Remember, the only connection between them is that they happened to be sold to the same person at the same time.) Also remember that a CD is not just n seconds of sound-coding; there is lots of other stuff. (Did you know that some of the music CDs you have have graphics and text (such as lyrics) on them as well? It is just that your CD player can't "display" them.) So I get a mail message from BMG Music Service. In the header, I see: (using "Andrew" instead of x-be2, assuming it has become one of the standards) Encoding: 27 text (Greetings from BMG), 124 EDI X12 (your bill), 41236 Andrew (Mozart -- the Early Concerti), 51623 Andrew (Dvorzak -- Symphony No 7) It is message 4 in my mailbox. I type: (* is the PDNmail prompt) * file 4.3 ariel>cds>Mozart>early.1 * file 4.4 ariel>cds>Dvorzak>S.7 * !ph play-cd ariel>cds>Dvorzak>S.7 * 4.1 Greetings, Enclosed ... (rest of message) * quit (I'll pay the bill *later* :-) Of course, you might use a whizzy GUI where you pick up the CD icon and drop it in the CD player icon ... If I had enough disk space, and a NFS client in a CD player I could do this today. (i.e. if I had a play-CD command) (Aomeone *really* ought to build that. Yes, you can do it with a SPARC, but that is overkill?) (Is BMG on the commercial Internet?) I also might want to use an Encoding: of "LZJU90 Andrew", or something, to get some compression, if the Andrew sound format doesn't do it already. If not Andrew, I might try using just Encoding: LZJU90 CD-ISO-nnnn or possibly Encoding: uuencode LZW CD-ISO-nnnn ... (I forget the value of nnnn at the moment :-) Best Regards, Robert Ullmann
- CDs in the mail Robert Ullmann
- Re: CDs in the mail Nathaniel Borenstein
- Re: CDs in the mail Timo Lehtinen