Response#3 RFC1154 Encoding Hdr

Al Costanzo <Al@kean.edu> Wed, 17 March 1993 17:03 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05318; 17 Mar 93 12:03 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05314; 17 Mar 93 12:03 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13089; 17 Mar 93 12:03 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05305; 17 Mar 93 12:03 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05293; 17 Mar 93 12:03 EST
Received: from TURBO.Kean.EDU by CNRI.Reston.VA.US id aa13060; 17 Mar 93 12:03 EST
Received: (from user AL) by TURBO.Kean.EDU; 17 Mar 93 12:04:42 EST
To: mordor.stanford.edu@turbo.kean.edu
Cc: ietf@CNRI.Reston.VA.US, eva@hpindda.cup.hp.com, beckywy@microsoft.com, olle@edvina.se
X-Orig-Sender: ietf-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Al Costanzo <Al@kean.edu>
Organization: Kean College of New Jersey
Security: -- none --
Comment: Sender Phone# (908) 527-2061
Comment: Sender Fax# (908) 527-0391
Subject: Response#3 RFC1154 Encoding Hdr
Date: Wed, 17 Mar 1993 12:04:42 -0500
Message-ID: <9303171203.aa13060@CNRI.Reston.VA.US>

 >Al,
 >
 >I haven't checked the 822ext or SMTPext working group archives, to determine
 >the extent of your participation in their efforts to enhance Internet mail
 >technology, but your note contains some inaccuracies.  Given the strength
 >of the language in your note, this is unfortunate.  (As with Marshall Rose,
 >Ned Freed, and many, many others, I was a participant in those groups.)
 >
 >    ---- Included message:
 >
 >    RFC 1154 _is_ an experimental RFC and is currently being updated.  The fact
 >    that it is experimental and not on a standards tract is really not a concer
 >		  n.
 >
 >I've heard of the effort to upgrade 1154, but think it essential to note that
 >it does not currently represent any formal effort within the IETF working group
 >(and standards) context.  Hence, this appears to be a private effort, at least
 >for now.  To the extent that one distinguishes between private versus public
 >specification efforts, this probably SHOULD be a concern.
 >

Dave,  Why does it matter if it is formal within the IETF?  The important thing
is to make it work and work well.
 >
 >You offer a curious statistical observation, here.  It certainly doesn' match
 >my own interpretation of events.  Certainly the groups started with the belief
 >that they were going to solve some simple problems for supporting international
 >character sets.  It turns out that the issues are not nearly so simple, so
 >the working groups primarily focussed on developing a rich infrastructure
 >for extensions.  I guess I don't see how this constitutes becoming side-tracked.
 >
So Dave what you are saying is that the working group started by working on
a set of problems, instead of focusing on them and looking for solutions they
went off on some strange tangent try to make MIME do all kinds of things that
were never its original purpose, correct?  I would say this is being side-
tracked.

 >In any event, I do concur with your advice.  Please DO look at the Mime
 >working group.  Its results have been spectacular.
 >

See above. This depends on you point of view.  I do not belive you should try
to fix something if its not broke.

 >    The WG WAS suppose to of advance 1154!!
 >
 >Sorry, but that was not its assignment.  Its assignment was to pursue solution
 >of a number of email issues.  As is typical of IETF efforts, careful attention
 >to previous efforts was required.  In this case, the (very and painful)
 >extensive discussions in the working group determined that a different
 >approach was warranted.  In this case, the MIME effort is not upward
 >compatible with RFC 1154 although it is rigorously compatible with RFC822.
 >Extensions to SMTP were able to entirely upward compatibility.
 >
Careful here, you just proved my point.

 > Even though 1154 is experimental, it _IS_ being advanced.  I have been work
 > ing
 > directly with Microsoft, Apple, Lotus and a number of others to make the up
 > date
 > do what people need. I feel this is important.  I do not think abstract upd
 > ates
 > are useful if basic needs are not yet being met.
 >>Our industry has become fond of efforts by private consortia.  Clearly,
 >>these can be useful.  They do not, of course, have anything to do with an
 >>open standards process.  In particular, the effort you describe yourself
 >>pursuing seems to be rather directly at odds with the line of activity
 >>that the IETF standards groups have chosen for the last two years.
 >

Dave,  Please!  Did the IETF define Ethernet or did a group of companies?
Namely Xerox Digital and Intel.

 >As Marshall observes, you are free and welcome to do so, but it ain't got
 >nuthin' to do with Internet standardization.
 >

All due respect.  It sure does.  Look at my Ethernet example. Who developed it
???

 >    I still say MIME is __NOT__ a solution but rather looks like a snowballing
 >    problem.
 >
 >Strong words, of course, but just a tad thin on content?  (And, of course,
 >the ietf mailing list is not the place to pursue the detail, unless there
 >is some aspect to the PROCESS of developing Mime or SMTPext that was/is
 >in question -- but we went through all of this last year.  Those in favor
 >of RFC1154 compatibility were heard and re-heard.  Their concerns were
 >taken very seriously, but the very strong consensus among the working group
 >and among the IETF management was the the Mime path was preferred.)
 >
 >Dave

Please refer to their own posts regarding PEM and look at their agenda.

Regards