Response#1 RFC1154 Encoding Hdr

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

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05128; 17 Mar 93 11:57 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05124; 17 Mar 93 11:57 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12888; 17 Mar 93 11:57 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05099; 17 Mar 93 11:57 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05093; 17 Mar 93 11:57 EST
Received: from TURBO.Kean.EDU by CNRI.Reston.VA.US id aa12879; 17 Mar 93 11:57 EST
Received: (from user AL) by TURBO.Kean.EDU; 17 Mar 93 11:59:08 EST
To: mrose@dbc.mtview.ca.us
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#1 RFC1154 Encoding Hdr
Date: Wed, 17 Mar 1993 11:59:08 -0500
Message-ID: <9303171157.aa12879@CNRI.Reston.VA.US>

Hello,

Let me take a moment to respond to your post.

   >In the Internet community, there is a well-established mechanism for
   >developing and standardizing technology.  In fact, there is something
   >called the "standards track", which each "standard" document traverses.
   >A quality which often distinguishes the Internet standardization process
   >from other processes is the tight-loop of specification, implementation,
   >and deployment.  This often results in technology which is both
   >technically-capable, reasonably-implementable, and market-useful.
   >
   >In the Internet community, there is also a mechanism for developing and
   >fielding experimental technology, which is distinct from standardized
   >technology.  As might be imagined, the mechanisms for developing these
   >two styles of technology have widely varying metrics with respect to
   >engineering and process.
   >
Your right so far! I agree...

   >Because experimental technologies do not receive the same level of
   >outside scrutiny with respect to either engineering or process, it is
   >often difficult to objectively compare standard technologies to
   >experimental technologies.
   >

I would say you are dead wrong here.  The only scrutiny missing between
something that is Experimental vs. on Standards Track is the political BS
involved and the scrunity that comes from the IETF __ITSELF__!!!

Something that is Experimental may work as well or better than something
that is a standard.

   >For example, MIME is a proposed standard.  It has received extensive
   >review both in terms of engineering and process.  It solves a number of
   >problems for the Internet community as a whole.  For further
   >elaboration, I refer you to the multi-MB archives of the RFC822
   >extensions working group.  More importantly, vendors of Internet mail
   >technology may rely on the stability and quality of MIME when they
   >develop products.
   >

Excuse me? Did you use the word stability????

What Stability??? The people who have supported RFC1154 have ALWAYS pointed
out structual problems with MIME.  I do not need to prove this point, all
you have to do is look at the IETF MIME WG Agenda for Ohio!!!  MIME looks
like it has some problems...

   >The mechanism defined in RFC 1154 is an experimental technology.  It is
   >not a standard.  Vendors are certainly free to use this technology in
   >their products, but they must not claim that their product is
   >Internet-standard conformant.  Further, they have no guarantees as to
   >the stability or quality of RFC 1154, nor the applicability of this
   >technology for their particular applications.
   >

What are you talking about.  The quality of an RFC has nothing to do with
it being standard vs. experimental...

What stability are you comparing RFC1154 to??? Surely NOT MIME's!!  If MIME
was so structuraly sound there would not be any problem incorporating
PEM into it...  Noooo, MIME's solution is to just keep adding headers...

   >As much as I would enjoy engaging in some serious 1154-bashing (and
   >believe me, this is a target-rich environment), I will refrain.
   >

I feel this statement you have made is rather political.  I doubt there is
any technical problem with 1154 that you could 'bash'.  Please feel free to
bash it off line to me.  I'll accept input on any concern you may have.

   >Instead, I will simply remind everyone reading this list that there are
   >differences between standard and experimental technologies, and that
   >these differences are often reflected in marketing literature, marketing
   >decisions, product deployment, etc.
   >
   >/mtr
   >
   >ps: Please direct technical issues to the ietf-rfc822@dimacs.rutgers.edu list.
   >I'm sure everyone on that list would absolutely love to re-live the
   >tedious 1154 debate...

I have no love to debate this issue because I know 1154 __IS__ the answer
and I do not feel I have to prove it to people that have closed minds.

I will however respond to any post and defend 1154.

Regards,

Al Costanzo