🚀 go-pugleaf

(Obtw,  Louis gave a very good tutorial on DNS and BIND.  I recommend it
to anyone who doesn't understand the insides of how a internet hostname
gets resolved.)


In article <1d43e1INNqua@ni.umd.edu> louie@sayshell.umd.edu (Louis A. Mamakos)  
writes:
> In article <1992Nov2.185708.2641@bmw.mayo.edu> brunkhorst@mayo.edu writes:
> 
> >MIME is not overly impressive, at least compared to NeXTmail in  
presentation.
> >Like a lot of standards, MIME will hamper "neat" UIs, as a lot of  
> >works-in-progress seemed to think that MIME attachments cannot and should  
not  
> >reflect any sort of integration (attachments 'fall' out of the document, in  
no 
> >real order of interrelationships to the other attachments).

> This just isn't true.  MIME is not a user interface, but a
> specification for multipart mail.

I'll eat crow.  The statement above is not based on the spec, but on 
the represented implementors of mailers based on the specification

>  The fact that existing MIME user
> interfaces don't look as spiffy as NeXTmail doesn't mean that there's
> a problem with MIME; it means an opportunity for NeXT to produce a
> really wonderful MIME product.

Will a MIME UI purchased from Z-mail be able to make heads or
tail of the a NeXT-MIME document?  See below.

> Attachments can be included in any order, imbedded within other body
> parts.  You are seeing an artifact of a primitive MIME user interface,
> not a deficiency in the MIME protocol itself.  At least that's my
> opinion, having closely watched and participated in the working group
> defining the spec.

Since I am coming from a confused consumer perspective, I will defer to Louis
as to the details of the spec.   Anyway,  I'm not faulting the spec (my choice  
of wording was vague at best)... I AM faulting the implementors, and how  
because of the spec's existence the implementors get wrapped up in the spec  
minutia, and not in loftier pursuits, like enabling electronic mail to be  
something better than what it is today.

Every implementer that was 'selling' a MIME mailer (either as a work in  
progress or a nearly done product), was admittedly unsure when I asked them  
about implementing sub-body-parts, pictures/graphics in the body of text, being  
able to put attachments "in context", etc.  In fact, the person in the IBM  
booth quickly pointed out that I was "talking about MultiMedia and Compound  
documents...  MIME was never meant to solve those problems."  This sort of  
vagueness in the implementation goals (From what I have read, the MIME spec is  
quite compleat), or lack of one vendor pushing the specification with a really  
good reference platform (okay, NeXT isn't pushing it either) is where I feel it  
will hamper the neater implementations.

I have seen this in other 'standards' (the CGM ANSI standard, in particular),
where the least common subset becomes the de facto standard, since no one will  
support the truly enabling stuff, because that would stretch the development  
teams.  Also, driven by customers or marketing, a lot of 'features'  will be  
'value-added' as non-MIME extensions, which by nature will not comply with the  
published specification.  

I do agree that NeXT could "lead the way" with a truly neat UI for MIME, but I  
would be a bit depressed if all it would buy me is more incongruence ("Oh, we  
don't support the part that NeXT is exploiting to do that neat stuff with...").   
And it seemed, at least to me, the two or three MIME implementors I talked to  
in detail were flat out missing the point, as they were amazed that ANY mailer  
did what NeXTmail did.  I never thought NeXTmail as being beyond MIME, and  
certainly never thought that NeXTmail was a CDA or an all-inclusive multimedia 
application.

> But NeXT will let this pass them by as they have other stuff since its
> not part of the true NeXT religion.  Also, they are too small a
> company, busy doing other essential things like rearranging C include
> files.

Who am I to defend NeXT?
 
> The other neat stuff to see at InterOp is the audio (and coming,
> video) conferencing over the network.  The past two IETF meetings had
> audio teleconferencing across the Internet on a world-wide scope
> (North Americal, Europe, Australia/NZ).

The video conferencing was interesting.  A lot of people were showing 
this off.  Since few were selling product, I didn't take a lot of notice, and
others (Northern Telecom) were not linking in via IP, but by alternate
telephone circuitry.  But there were at least 10 booths doing demos passing
live video over the net.  Most were point-to-point, but the demos were
impressive.

> The NeXT would be an ideal plaform for this work, having a DSP to do
> audio compression, etc.  Except for lack of IP multicasting support in
> the kernel.  This would take all of 4 or 5 hours to install by someone
> who knows what they're doing.  You can FTP the code from Stanford.
> But right now, if you want to experiment with this stuff over the
> Internet, you better have a Sun.  They are missing another golden
> opportunity.  This apparently is not mission-critical enough.

Well, without hardware or software mpeg (or hardware jpeg), I felt NeXT was  
hurting to do a "best of breed" implementation in house rsn.  They really  
didn't do the AppleTalk stuff right, so why make them do something that didn't  
have a couple million potential installed conversants;-). Maybe the question of  
being a hardware, a software, or an interoperable company is currently the most  
mission critcial issue for them?

> louie
-geoff
---------------------------------------------------------------
Geoffrey Brunkhorst, RCF                    brunkhorst@Mayo.edu
Guggenheim 10                                    (507) 284-1805
Mayo Foundation, Rochester MN, 55905 USA     fax (507) 284-5231