Re: Current State: An EDIINT Short Status/ Request

[Dave Crocker <dcrocker@xxxxxxxxxxxxxxx>]

At 6:47 PM  -0700 5/3/96, Rik Drummond wrote:
>>2) pick MOSS, S/MIME or PGP/MIME, and

	My reaction, from the EMA conference, is that MSP (the Defense
Messaging System security protocol) is now a contender.  At least two
companies claim to be shipping it.  At the february Workshop, it was the
only one claiming to offer non-repudiation of recipient.

>Note: I just attended a meeting at Electronic Messaging Association (EMA)
>where S/MIME was demo'd on a MS Exchange system, Eudora and Premenos is

	On the other hand, the report I was given, about the RSA press
conference last week, is that it did not go well.  Some/Most of those
recruited to provide S/MIME testimonials instead characterized S/MIME
merely as "one of" the alternatives that would be offered.  I do
acknowledge that this is second-hand information.  I should also note that
the PGP game got a little more interesting, last week, with the
announcement of the formation of PGP, Inc., with Phil Zimmerman as Chair.
Dan Lynch (Interop, Cybercash) is on the board.

>>3) handle the issue of Delivery, read receipts, Nonrepudiation of Delivery
>>and Non repudiation of Receipt. If we solve these three areas we have
>>solved the problem of EDI over Internet in my view.
>
> I am not clear on this one. I personally think we should extend the
>existing RFC functionality and implement a generic NRR of receipt for MIME
>which we can use for EDI. I searched the literature a little, I do not
>think it is a big deal at all.  (What did you find Carl?)

	Delivery Service Notices (DSN) is on the standards track.  A
working group for read receipts is underway.  (I continue to be facinated
by people's expectations for read receipts, since it is an enenforceable
mechanism.  As a cooperative mechanism between communicants, it's fine, but
there is no way to "force" the recipient to send the receipt prior to, or
after, reading.)

>>Carl Hage and I have discussed him investigating and recommending how we
>>do #3 for the Internet Transport -- which means MIME based Status

	not sure if there is functionality that you are seeking which is
different from those already in the MIME email standards pipeline.

>>We must also do a comparison between those in #2 if we are going to make a
>>choice.  Many translator vendors seem to be focusing on the S/MIME.  MOSS

	I agree about MOSS.  I am listing PGP, S/MIME and MSP as the
current contenders.  In the discussion about "vaporware" I suggest merely
noting the differences among installed base, shipping product, and
talk/paper-specifications.

	Old PGP is the only one with installed base.  PGP/MIME does not.
S/MIME does not.  MSP does not.  For that matter, none of them has shipping
product, either, unless I missed something at EMA.  Interoperability
testing has just begun and seems to be going fine, so the lack of shipping
product is a status report, not a criticism.  The PGP/MIME story is less
crisp, although the specification for integrating PGP into MIME is
currently before the IETF in Last Call prior to entering the standards
track.  There have been criticisms of the spec that I will call "political"
but none that I'd count as "technical".  I would be the last person to
predict the behavior of the IESG, but my own perception is that the spec
qualifies for advancement to IETF Proposed standard, since it has support
and doesn't seem to have technical criticisms against it.

d/

--------------------
Dave Crocker                                            +1 408 246 8253
Brandenburg Consulting                             fax: +1 408 249 6205
675 Spruce Dr.                                 dcrocker@brandenburg.com
Sunnyvale CA 94086 USA                       http://www.brandenburg.com

Internet Mail Consortium               http://www.imc.org, info@imc.org