HDTenEightyP/NetNews huggingface dataset:
From: nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein)
Newsgroups: comp.mail.multi-media
Subject: Re: MIME (RFC1341) Charset question
Date: 8 Oct 92 22:06:24 GMT
Distribution: inet
Organization: The Internet

Excerpts from internet.mmm-people: 8-Oct-92 MIME (RFC1341) Charset
ques.. Martin Wendel@bloom-beac (1301)

> I see a problem, though, when a message is originally created with
> characters that doesn't fit into one of the 8859 charsets but could 
> be squeezed into two or more. Is it the intent that such a message 
> should be of content type multipart/mixed? 

For now, yes.  Eventually, I expect that 10646/Unicode will be
registered as a MIME character set, and then you can send
mixed-character-set text within a single MIME object that way.

> Then, what about characters not in any one of the 8859's?

They just have to be registered.  Japanese users are well on their way
to having iso-2022-jp registered as the official MIME name for the
current Japanese usage.  Similar efforts are ongoing for Korean and
Vietnamese, and today I got my first inquiry about how to go about
registering a name for the existing Farsi character set usage in Iran.

> Finally, why not use mnemonics? That would eliminate the need for
> the quoted-printable content-transfer-encoding.

There was a great deal of discussion about this on the MIME list. 
Eventually, what it came down to was a belief that MIME should
essentially be descriptive rather than prescriptive -- that is, MIME
should provide a way of defining & registering character set names to
correspond to existing usage, and to new usage as it is adopted (e.g.
unicode/10646), but not that MIME should push a new agenda for the world
of character sets.  The Mnemonic encoding is very appealing, but until
it is widely adopted it is not suitable as the primary MIME character
set mechanism.

> BTW what charsets aside from US-ASCII and ISO8859-[1-9] have been
> accepted as standard MIME charsets?

Those are the only ones in the base MIME document.  A spec for
iso-2022-jp has been published as an Internet Draft, but I don't know if
it has turned into an RFC and/or received any official standard status
yet.  I think that other efforts are even less far along in the process.

Hope that helps.  -- Nathaniel
From: RCB@SPSUP-1.NAVY.MIL (CHRIS R BARTRAM)
Newsgroups: comp.mail.multi-media
Subject: discussion group direction and ietf-822
Date: 8 Oct 92 19:15:08 GMT
Distribution: inet
Organization: The Internet


We're working on developing a MIME implementation and are interested
in issues dealing with the development and implementation of such a
package, as well as keeping current with any new developments in the
standards processes.

I hadn't seen the ietf-822 discussion group listed on the list of
listserv lists -- if that list is public, how do we subscribe?

                                                Chris Bartram
                                                 3k Associates
                                                 RCB@3k.com
From: MRC@CAC.WASHINGTON.EDU (Mark Crispin)
Newsgroups: comp.mail.multi-media
Subject: Re: Mass market MIME based e-mail question
Date: 14 Oct 92 02:51:19 GMT
Distribution: inet
Organization: The Internet

On 13 Oct 92 11:34:31 GMT, Alasdair Grant wrote:
> IMAP2bis is pretty
> new and even now they seem to be talking about replacing it with something
> from Carnegie-Mellon.

This is not correct.  The Mail Management Protocol effort at CMU is not a
replacement for IMAP2bis; rather, it is an extension in the areas of mail
management.

Specifically, IMAP2bis adds some rather basic management capabilities (among
others) to IMAP2.  These are not intended to be anything other than basic
management capabilities for simple configurations.  More complex
configurations require a more general management facility.  Putting these in
IMAP2 would make it unnecessarily complex, and it is folly to do so when there
are environments where it is not needed.

This is where the Mail Management Protocol steps in.  It expands on (and
replaces) the basic management facilities in IMAP2bis.  On the other hand, it
does not have access facilities; that's what IMAP2 is for.

This is a planned design, in the name of `separation of concerns,' and it is
also a division of labor between the University of Washington and CMU.

The reason that mail management capabilities are added to IMAP2bis at all is
to provide a springboard for the Mail Management Protocol and to make a
simpler configuration possible for smaller organizations.

-- Mark --

Newsgroups: comp.mail.multi-media
From: s0468754@let.rug.nl (M. Wassenaar)
Subject: Re: Rearranging lists & newsgroups
Organization: Faculteit der Letteren, Rijksuniversiteit Groningen, NL
Distribution: inet
Date: Wed, 14 Oct 1992 08:21:47 GMT

In article <wep6j2K0M2YtRoD48X@thumper.bellcore.com> nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) writes:
>From: nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein)
>Subject: Rearranging lists & newsgroups
>Date: 8 Oct 92 17:11:30 GMT
>Attention, readers of the "comp.mail.multimedia" newsgroup and the
>"mmm-people" internet mailing list:
>
>As many of you know, the recent publication of MIME, the proposed
>standard for multimedia Internet mail, has generated a great deal of
>renewed interest in multimedia mail in general.  Earlier today, I
>proposed to readers of the MIME mailing list and the mailing list for
>metamail (my public-domain MIME implementation) that we look into
>creating new newsgroups for discussions of MIME and metamail.
>
>Several people have suggested, in response, that the existing
>comp.mail.multimedia newsgroup and mmm-people mailing list (which are
>mutually gatewayed) are suitable for this purpose.  What I would like to
>know is this:  do you think it would be reasonable to have general
>discussions about MIME on mmm-people and comp.mail.multimedia?   Or
>would it be better to have aseparate newsgroup for this purpose?  How
>about specific MIME implementations such as metamail?  
>
>For information purposes, info-metamail routinely carries one or two
>dozen messages a week at this point.  The MIME dicussion list, ietf-822,
>carries a much more variable amount of traffic, depending on the current
>state of the standards process, but not all of this discussion would be
>appropriate to move to mmm-people/comp.mail.multimedia anyway.  In
>particular, the mail oriented to new drafts of the MIME standard would
>undoubtedly stay on ietf-822, while general "how does MIME do X?"
>discussion would probably migrate to the newsgroup.
>
>What is being suggested, at bottom, is a renewed and expanded charter
>for this longstanding low-volume newsgroup.  Alternately, we could
>create new subgroups such as "comp.mail.multimedia.mime" and
>"comp.mail.multimedia.metamail", thus not significantly increasing the
>traffic on the base newsgroup.  A hybrid strategy would be to start out
>by just routing all such traffic to comp.mail.multimedia, and later
>deciding if new groups are needed.
>
>For myself, I have no strong opinions about which is the right solution;
>I'm just trying to reduce the burden that is involved in administering
>info-metamail, which has gotten to be a fairly large mailing list with
>all the normal pains involved in such lists.  A newsgroup seems like a
>reasonable idea, but I don't much care whether we create a new one or
>re-use an old one.
>
>I suspect that it is better to debate this question publicly on the
>list/newsgroup rather than via private mail to me, since I'm trying to
>open a public discussion here rather than simply get person-to-person
>advice.
>
>Thanks for your patience & advice.  -- Nathaniel
Newsgroups: comp.mail.multi-media
From: ptrubey@netcom.com (Phil Trubey)
Subject: Re: Mass market MIME based e-mail question
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Tue, 13 Oct 1992 17:01:25 GMT

In article <1992Oct13.113431.7685@infodev.cam.ac.uk> ag129@cus.cam.ac.uk (Alasdair Grant) writes:
>In article <1992Oct13.054709.22181@netcom.com> ptrubey@netcom.com (Phil Trubey) writes:
>>Am I missing something here?  Why is it that I seem to be the only person
>>who thinks that MIME based e-mail packages can take on the very profitable,
>>yet proprietary mass market e-mail packages like Microsoft Mail (aka Network
>>Courier), Lotus cc:Mail, Da Vinci E-Mail, etc?
>
>MIME is just a content encoding. The mail packages you mention are all 
>transport mechanisms as well. So you would have to run MIME over something,
>like POP2/POP3/IMAP2/IMAP3/..., and these protocols are not stable enough
>to be attractive to many commercial vendors, I suspect. IMAP2bis is pretty
>new and even now they seem to be talking about replacing it with something
>from Carnegie-Mellon. 

Yeah, I was thinking of using something like POP3 or IMAP - or both.

>Of course, each of these protocols is IP-based, which
>has its own problems in the PC/Mac environment, such as requirements for
>packet/NDIS/ODI drivers (and IP/IPX multiplexers if necessary, etc. etc.),
>and RARP/BOOTP servers etc. And isn't MacTCP a commercial product?

Yep, this is a problem.  One way you could get around it would be to use
POP3/IMAP over IPX, NetBios, ASDP - of course, you might lose something
in terms of interoperability.

Yes, MacTCP is commercial, but it is also licensable and that's what most
TCP/IP based applications do in the Mac world (license it).

>What might be interesting is a PC-based MUA talking P7 and using MIME as
>a content-encoding.

What is P7?
-- 

Phil Trubey                   | Internet: ptrubey@netcom.com
Systemhouse Inc.              | Voice:    415-327-8337
                              | Fax:      415-243-0471
From: ag129@cus.cam.ac.uk (Alasdair Grant)
Newsgroups: comp.mail.multi-media
Subject: Re: Mass market MIME based e-mail question
Date: 14 Oct 92 11:34:17 GMT
Organization: U of Cambridge, England

In article <Ieqk6Fi00WBwRl1i8C@andrew.cmu.edu> John Gardiner Myers <jgm+@CMU.EDU> writes:
>Um, no.  Carnegie Mellon is starting to do work with IMAP2bis and is
>talking about augmenting it (not replacing it) with a Mail Management
>protocol.

Augmenting in what sense? Multiplexing functions over port 143 (IMAP2) by
using an additional command set? The copy of "Andrew II Functional 
Requirements" you posted to imap-request says nothing about IMAP; could
you reveal some details about the new system will be implemented?
(We are downsizing from MVS; my interest is as a potential user, not as
a theorist!)
From: ag129@cus.cam.ac.uk (Alasdair Grant)
Newsgroups: comp.mail.multi-media
Subject: Re: Mass market MIME based e-mail question
Date: 13 Oct 92 18:14:30 GMT
Organization: U of Cambridge, England

In article <Bw2E9L.9Kx@mtholyoke.edu> jbotz@mtholyoke.edu (Jurgen Botz) writes:
>In article <1992Oct13.113431.7685@infodev.cam.ac.uk> ag129@cus.cam.ac.uk (Alasdair Grant) writes:
>>like POP2/POP3/IMAP2/IMAP3/..., and these protocols are not stable enough
>
>I don't buy this argument.  What do you mean by "not stable enough"..?  Do
>you think that these vendors never change their protocols?  A lot of them
>won't even bother maintaining backward compatibility when they do!  (They
>have less need to do so since customers can usually upgrader their whole
>site if they choose to upgrade).  Internet protocols are far more concerned
>with interoperability and are generally "stable" for much longer stretches
>of time than proprietary vendor protocols.

But MS, Lotus or whoever will sell the client and server as a package.
The _whole point_ of POP and IMAP is that they provide interworking 
between different vendors' clients and servers; in particular the server
is usually public-domain (no fancy user-interface stuff). So if a vendor
wants to have control over the protocol, they would have to sell both
client and server.

Yes, Internet protocols are generally stable, but remote-mail-management
is an exception! Just look at the IMAP2 vs. IMAP3 controversy for example.
It does look as if IMAP2bis is settling down, but there are a number of
unanswered problems (authentication in the absence of Kerberos, quota 
management, manual and automatic forwarding, interface to the Directory)
and I get the feeling some people are waiting for CMU's Andrew II messaging
system to take a more coherent approach. (IMAP2's specialisation on the
'Retrieval' function is in line with Internet no-redundancy policy, but
has pitfalls in practice. To me, redundancy means having five competing
mail-retrieval protocols!)
Organization: Systems Group 97, Carnegie Mellon, Pittsburgh, PA
Newsgroups: comp.mail.multi-media
Date: Tue, 13 Oct 1992 13:04:17 -0400 
From: John Gardiner Myers <jgm+@CMU.EDU>
Subject: Re: Mass market MIME based e-mail question
	<1992Oct13.113431.7685@infodev.cam.ac.uk>

ag129@cus.cam.ac.uk (Alasdair Grant) writes:
> to be attractive to many commercial vendors, I suspect. IMAP2bis is pretty
> new and even now they seem to be talking about replacing it with something
> from Carnegie-Mellon.

Um, no.  Carnegie Mellon is starting to do work with IMAP2bis and is
talking about augmenting it (not replacing it) with a Mail Management
protocol.

-- 
_.John G. Myers		Internet: jgm+@CMU.EDU
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up


Newsgroups: comp.mail.multi-media
From: ptrubey@netcom.com (Phil Trubey)
Subject: Mass market MIME based e-mail question
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Tue, 13 Oct 1992 05:47:09 GMT

Am I missing something here?  Why is it that I seem to be the only person
who thinks that MIME based e-mail packages can take on the very profitable,
yet proprietary mass market e-mail packages like Microsoft Mail (aka Network
Courier), Lotus cc:Mail, Da Vinci E-Mail, etc?
  
The basic architecture that I would see working is as follows:

- MIME based user agent running on Microsoft Windows and Macintosh.
- Uses POP3 over TCP/IP as transport between user agent and server.
- POP3 compliant servers for Unix, Novell NLM, Univel platforms.
- SMTP protocol used for server to server communications.

Nice features of this architecture:

- because TCP/IP is used as a transport for both client/server and server/server
  communications, you can use other off the shelf components for things like
  providing remote dial in support:  ie use SLIP/PPP communications servers
  for this task.
- again, since TCP/IP is used as the transport, you can take advantage of the
  standard TCP/IP APIs that exist on Windows (Windows Socket API) and 
  Macintosh (MacTCP).
- same user interface whether you run the user agent remotely over dialup or 
  locally from a LAN (assuming you use SLIP/PPP for dialup communications)
- interoperates seemlessly, without the need for gateways, to other SMTP
  based servers and MIME based user agents.
  
This a broad architecture and there are many details to be worked out, such
as user directories, directory synchronization, IP address assignment, etc.

My question to the Net is:  am I missing something obvious, or is there a
tremendous opportunity to make buckets of money constructing and selling 
such a system?
-- 

Phil Trubey                   | Internet: ptrubey@netcom.com
Systemhouse Inc.              | Voice:    415-327-8337
                              | Fax:      415-243-0471
From: nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein)
Newsgroups: comp.mail.multi-media
Subject: Re: MultiMedia Mailtool
Date: 8 Oct 92 14:07:54 GMT
Distribution: inet
Organization: The Internet

Excerpts from internet.mmm-people: 5-Oct-92 Re: MultiMedia Mailtool
Dominic Richens@ucbvax.B (1581)

> Firstly, you would want to look up RFC-934, RFC-1049, and RFC-1342 to find
> which standards are already out there for "Content-type" headers in e-mail
> messages.

Actually, I think you want 1341 more than 1342, although both are
relevant.  So, for that matter, is 1343.  -- Nathaniel
From: postel@ISI.EDU (Jon Postel)
Newsgroups: comp.mail.multi-media
Subject: Re: MIME (RFC1341) Charset question
Date: 9 Oct 92 01:06:42 GMT
Article-I.D.: zephyr.199210090106.AA28791
Distribution: inet
Organization: The Internet



Hi.

I'd like to see a move to unify MIME charactersets with those listed in
RFC-1345.

--jon.
From: schmitz@scd.hp.com (John Schmitz)
Newsgroups: comp.mail.multi-media
Subject: Re: mime support under hp-ux hp 9000/8xx machine with elm
Date: 15 Oct 1992 23:04:05 GMT
Organization: Hewlett-Packard Santa Clara Division
Distribution: inet
NNTP-Posting-Host: hpsceo.scd.hp.com

I have used the metamail package on hpux 8.0 systems and have used
it with the public domain elm2.4 (not hp's elm).  I haven't tried
too much, but the basics seem to work fine.
From: RCB@SPSUP-1.NAVY.MIL (CHRIS R BARTRAM)
Newsgroups: comp.mail.multi-media
Subject: Re: mime support under hp-ux hp 9000/8xx machine with elm
Date: 15 Oct 92 21:12:02 GMT
Distribution: inet
Organization: The Internet


> Has anyone any experience implementing MIME or the metamail package
> from Bellcore under a HP-UX version 8.0 platform on a HP 9000/8xx
> machine in conjunction with the ELM mail reader? Does anyone know
> if ELM 2.3 or ELM 2.4 supports MIME and if so where may it be obtained?
>
> Thank you,
>
> Lee

  I obtained the MM package from HP's ftp server in the UK via the
Internet but have yet to install it. It had instructions for Elm
but I don't remember if it said anything about HP-UX's implementation
in specific. I'm not a unix-guru myself, but would like to hear about
anyone that has installed it (we also run an HP9000/8xx on HPUX 8.0).
                                    -Chris


************************************************************************
Chris Bartram                         Internet: RCB@UII.COM
Manager of Computer Operations
Unified Industries, Inc.              Phone:  (703)922-9800x245/922-6358
6551 Loisdale Ct, Suite 400           Fax:    (703)971-5892
Springfield, VA  22150-1854  USA      Hours:  09:00-18:00 Est
Newsgroups: comp.mail.multi-media
From: jbotz@mtholyoke.edu (Jurgen Botz)
Subject: Re: Mass market MIME based e-mail question
Organization: Mount Holyoke College
Date: Tue, 13 Oct 1992 14:44:08 GMT

In article <1992Oct13.113431.7685@infodev.cam.ac.uk> ag129@cus.cam.ac.uk (Alasdair Grant) writes:
>MIME is just a content encoding. The mail packages you mention are all 
>transport mechanisms as well. So you would have to run MIME over something,
>like POP2/POP3/IMAP2/IMAP3/..., and these protocols are not stable enough
>to be attractive to many commercial vendors, I suspect. 

I don't buy this argument.  What do you mean by "not stable enough"..?  Do
you think that these vendors never change their protocols?  A lot of them
won't even bother maintaining backward compatibility when they do!  (They
have less need to do so since customers can usually upgrader their whole
site if they choose to upgrade).  Internet protocols are far more concerned
with interoperability and are generally "stable" for much longer stretches
of time than proprietary vendor protocols.
--
Jurgen Botz                  |   Internet: JBotz@mtholyoke.edu
Academic Systems Consultant  |     Bitnet: JBotz@mhc.bitnet
Mount Holyoke College        |      Voice: (US) 413-538-2375 (daytime)
South Hadley, MA, USA        | Snail Mail: J. Botz, 01075-0629
From: ckd@eff.org (Christopher Davis)
Subject: Re: Mass market MIME based e-mail question
Organization: Electronic Frontier Foundation Tech Central
Date: Thu, 15 Oct 1992 17:31:43 GMT

AG> == Alasdair Grant <A.Grant@ucs.cam.ac.uk> 

 AG> Because P7 is built on top of, among other things, the OSI Reliable
 AG> Transfer Service (RTS). Imagine a situation where you are trying to
 AG> retrieve a 100Mb MIME message over a cellular phone link that goes
 AG> down every time you go under a bridge. Potentially, you have a
 AG> better chance of eventually transferring the message with P7 than
 AG> with SMTP, since SMTP requires a TCP connection to be maintained
 AG> throughout the transfer of the message.

With a proper implementation of TCP/IP over the cellular link, you'd be
fine (yeah, it'd be slow, but I bet RTS would be slow too).  After all,
it was developed for battlefield implementation ("The router's what?
Down?  It took a 105mm?  Oh.")

I still don't see this as a necessary advantage of P7.
--
Christopher K. Davis      |       NET.INSIGHTS INTO ARTISTIC CRITICISM:
<ckd@eff.org>   EFF #14   | ``[Y]ou don't cure bad art by locking it all up
System Administrator, EFF | in one museum, you cure it by throwing tomatoes
+1 617 864 0665  [CKD1]   | at bad artists.'' --Barry Shein <bzs@world.std.com>
Newsgroups: comp.mail.elm
From: tkoppel@cassandra.cair.du.edu (Ted Koppel)
Subject: Undigestifier
Organization: CARL Systems Inc, Denver, Colo.
Date: Wed, 14 Oct 92 18:00:16 GMT

Now that the various PC/MSDOS new software announcements are meing
mailed out in a digest by Keith and the folks at Simtel-20, I'm
getting a 600-line message once a day full of filenames.  That's
great;  I am not complaining.

I understand that some mail programs are smart enough, when
instructed, to break the bunches of messages in a Digest into
individual mail messages, which can then be manipulated (or deleted,
or saved) in the same way that a 'real' mail message is.

Does Elm have such an 'undigestifier'?  How do I invoke it?

Thanks.
--
-------------------------------------------------------------------------
     Ted Koppel  --  ted@carl.org  or   tkoppel@cassandra.cair.du.edu
Newsgroups: comp.mail.elm
From: syd@DSI.COM (Syd Weinstein)
Subject: Re: Elm and POP
Organization: Datacomp Systems, Inc., Huntingdon Valley, PA
Date: Wed, 7 Oct 1992 15:22:03 GMT

In article <1992Oct7.134247.3542@cs.hw.ac.uk> sfleming@cs.hw.ac.uk writes:
>I must admit to being a total novice as regards Elm.
>However, I'm looking at reconfiguring a mail network to use
>Post Office Protocol (POP) and I would like to find out how
>Elm could be integrated with such a service.
Elm 2.4 cannot, that is one of the issues on the Elm 3.0 rewrite.
-- 
========================================================================
Sydney S. Weinstein, CDP, CCP          Elm Coordinator - Current 2.4PL00
Datacomp Systems, Inc.                 Projected 3.0 Release: ??? ?,1994
syd@DSI.COM or dsinc!syd      Voice: (215) 947-9900, FAX: (215) 938-0235
Newsgroups: comp.mail.elm
From: n029gg@tamuts.tamu.edu (Adam Roach)
Subject: Re: How to include file in letter
Organization: Texas A&M University, College Station
Date: Sun, 11 Oct 1992 17:56:57 GMT

In article <1992Oct11.132342.25604@panix.com> kgs@panix.com (Karen Schneider) writes:
>I've looked through the documentation and STILL can't figure it out;
>how do I send a file from another directory as a piece of mail?  Elm
>keeps chirping that it can't open these other directories (and even
>if it could, I still don't "get it").
>
>For example, I have a file I uploaded, eval.txt, and I want to send
>it to a friend.  In the funky old mail program, I could easily
>use a tilde command (tilde r, for example) to include it within the
>mail as part of my correspondence.  Or there is another command (I
>forget which one) that just sent the file as a piece of mail _in toto_.
>But in elm I feel confused by "folders" and all that.  (I understand
>how to forward pieces of mail; it's the files that make 
>me run back to the dollar prompt to use the old mail program.)

It depends on which editor you use to send out your mail. Personally, I
use vi; to include a file in that, you type :r filename, and it reads it
right in where the cursor is. (:r ~/eval.txt would be the command you're
looking for.) There's an equivlent command for emacs, but I don't know what
it is (It probably involves some 17 contortions of control keystrokes, like
ctrl-f ctrl-s qn compose ctrl-shift-~N ctrl-meta-WQ or something totally non-
mneumonic like that...).


				-Adam Roach

P.S. If that really _is_ an Emacs command, I DON'T want to know about it.
Newsgroups: comp.mail.elm