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