Re: New SCMP Discussion List

I wrote:
>Now my wining.  I think that the emerge of this SCMP draft is a sign
>of a bad coordination that goes on in the IETF.  There is a working
>group called EDI-Internet Integration (EDIINT) that addresses EDI/EC
>messaging over the internet for quite a few years now. I want to know
>why there is a completely new and seemingly unrelated protocol "SCMP"
>now?

and I received some responses that, in part, help clear up the
situation. The important point that I did not know was the the SCMP
draft revision 00 was out 2 years ago. That's a long time.  Tom Arnold
said that, at that time, no WG was to be found in the application area
that SCMP would fit in. That was probably about the time when EDIINT
WG came into existence, but I am not positve. The fundamental EDIINT
RFC, however, was out a looong time ago (in March 1995), that was RFC
1767 D. Crocker "MIME encapsulation of EDI objects." 

RFC 1767 is the standards track protocol for sending all kinds of
EDI/EC messages in MIME payloads. It is transport neutral in the same
sense as MIME is transport neutral, meaning that it's home is RFC822
e-mail, but it is used heavily via HTTP and there is nothing that
prevents you from sending MIME messages over some direct TCP, UDP, or
even RS232 serial link :-)

RFC 1767 was not secure in itself, but RFC 1847 and 1848 Galvin and
S.Crocker et al. "MIME security multiparts" and "MIME object security"
was all you needed for using RFC 1767 securely.  Those items were out
in October 1995.

Now count in a considerable pre-life as an Internet draft, and I am
back with my wining about SCMP's existence.  The SCMP authors should
have been able to find an RFC item by searching the 1995 summary of
RFCs for the keyword "EDI" which is quite obvious when you deal with
"Electronic Commerce."  Have they tried?  May be, it's not always
easy, and I don't want to single out the SCMP authors here.  What
about the application area directors? Have they been asked? And if so,
have they hinted to existing IETF work and RFCs?  I don't know, I only
know that something went wrong.

Now, what are we going to do with this?  SCMP is a protocol that's
implemented and used. Fine. SCMP draft heads up for informational RFC
status. That's appropriate for a protocol that is used.  But then I
read that the SCMP authors want to climb up on the standards track?
Why? I think at that point my wining about the lack of coordination
becomes quite relevant.

Not everyone has to rush for standards track just because the protocol
is neat.  Take Sun's ONC RPC, XDR, and NFS as an example. Those are
neat protocols, used on millions of computers all over the world. Good
designs. Numerous implementations. What else would you want for a
standards track protocol? And yet, RPC et al. were informational for a
long, long time 1988--1995.

In our case, as EDI is not as ubiquitous as NFS, I think we should
cooperate. I see no reason why a brand new protocol (though 2 years
since draft version 0) is needed given that RFC 1767 et al. are in
place (since 1995).  That SCMP is implemented somewhere does not make
it eligible to simply override or compete with EDIINT stuff. EDIINT
specs are implemented too, including a number of larger EDI vendors.

Again, I am only marginally involved in the EDIINT work and it is not
my intention to push SCMP aside.  I want that there is a cooperation
and eventually a merger.  In my opinion there is no place in the IETF
for alternative protocols to achieve the same goal with about the same
means. This S/MIME vs. PGP, and SPKI vs. PKIX fuzz is already more
than any sane mind can take.

So, the question is, who yields where? I don't know.  I think there is
enough evidence collected over the past, that a revisit of RFC 1767 is
in order. This could be the time to bring in every good idea of SCMP
that is missing yet. For logistic reasons, it makes sense to first
(and finally!) flush the EDIINT drafts REQ, AS#1, and AS#2 into RFCs
so that we can all step back and do the right next step.

Since EDIINT has a WG status and SCMP does not and since EDIINT stuff
is out for a longer time, and since EDIINT has probably the wider
implementation base, those are many reasons that SCMP needs to do some
homework, iff it wants to go for standards track.  This is, revising
EDIINT specs and point the finger on the deficiencies, and then
explain why the SCMP approach is so fundamentally different that a
merger would be impossible. I think that's appropriate.  For EDIINT it
is appropriate to also read SCMP and appreciate SCMP's new
ideas. EDIINT should be gracious towards whatever SCMP has to say and
EDIINT should not be defensive when it comes to details.

In the rest of this I am commenting on Graham Klynes remarks

> I am just an interested party, and not a principal in the SCMP
> proposal, but I would like to toss in a couple of reasons why I find
> SCMP useful in ways that EDIINT is not:

This is precisely what I'd like to see very clearly presented in a
comparison. What exactly is the difference between the SCMP approach
and the EDIINT approach, what the benefit of SCMP, what the deficiency
of EDIINT. I really appreciate that there may be deficits in EDIINT
specs, I am not at all defensive. But these issues need to be made
very clear and objective.

> (a) SCMP is quite specific that it is intended to be payload- and
> service- neutral.

This sentence is a contradiction in itself. "X-neutrality" is a
quality that people claim for their work and X-neutrality is often
taken synonymous with "open."  But if you look more closely,
X-neutrality means that you don't standardize with respect to X. (The
most "open" and "all-neutral" standard is a blank sheet of paper.)
You can not be specific and neutral at the same time and topic.

So, a standard that has options must be very clear on how the
optionality is managed.

I don't see how SCMP standardizes things like "SCMP-sender-name" or
"SCMP-message-type".  There are no suggestions on what the message
type names for the more common message types like X12 or EDIFACT
purchase order messages are. Nor is there any infrastructure to
support the message type name assigment.

Conversely EDIINT RFC 1767 (since 1995) just uses MIME types for that
application/edi-x12 and application/edifact to be specific while
remaining flexible based on the established and industry-accepted
infrastructure of MIME type assignment.  Application/edi-consent is
there as a catch-all, that gives you the "X-neutrality".  There are
issues with that, and a message type *parameter* or the
application/edi-* header could be a way to go.

Same with SCMP-sender-name. RFC822 have ubiquitous fields for
originator and routing and return addresses, that are meaningful on
the Internet and not just arbitrary strings.  If the only thing that
SCMP does with a sender name is to reject requests based on the sender
name, then, the same can be done based on a standard RFC 822 "From"
header.

<Error number> is another such example of things that are simply left
blank and up to the implementer. Nice, but not interoperable.

I just don't see the big advantage about SCMP.

Furthemore, I still wonder how precisely SCMP is used? Is it RFC822
and SMTP e-mail?  Makes sense to me, it is just not specified in SCMP.

> I think future developments of this specification might form a
> useful basis for a range of applications that require non-repudiable
> message delivery over a variety of message transports.

No, no, not SCMP in the future will be a useful basis, but MIME *is*
such a useful basis already today.  Going for SCMP to be everything
for everyone, and more than just Commerce, isn't going to help
pursuing. Sure, you can send personal messages through SCMP, sure you
can deliver cooking recipees through SCMP, but so what? All that I can
already do with simple and standard MIME using Netscape mail or your
favorite commercial or free mail user agent.

> (b) The SCMP specification is simple, and very easy to read.  This
> is in stark contrast to the EDIINT specifications (and I am on
> record as having made comments to this effect on the EDIINT
> discussion list).

Yes, easy to read is nice and every serious writer knows that he
always could do better and shorter. But first things first.  A
specification that specifies:

(1) use MIME
(2) use S/MIME
(3) use 5 headers
(4) do useful things with them

can afford to be short and easy to read. Conversely, a work 
- that appreciates the heritage of current Internet standards,
- that carefully tries to lay out the issues with using EDI over
  the Internet (REQ),
- that tries to be specific in managing optionality with 
- - EDI protocols (RFC 1767) and 
- - with security protocols (RFC 1847),
- that tries to tie all this together to a concrete spec from which
  one can implement wityhout oral tradition,
- that tackles most ambiguities.
- that tell you exacly how to ship the nice MIME messages from me to
  you and back,
- - over e-mail AS#1, and 
- - over HTTP AS#2
- that uses standard message disposition notifications, 

etc., etc., yes, such a specification that tackles more issues will be
more pages to read, and it will have more chances to be clumbsy here
and there.  But such a specification is much more specific and has
more normative power than a light and nice-sounding SCMP draft.

> I think that the simplicity and directness of the SCMP specification
> is in the spirit of other classical and succesful IETF protocols.

I disagree for reasons shown above. If you can read an understand the
"classical" Internet specs IP, TCP, UDP, TELNET, RFC and FTP, RFC822,
and SMTP, you should be able to read and understand MIME, RFC1767, and
EDIINT REQ, AS#1, and AS#2 easily.

regards
-Gunther

Gunther Schadow ----------------------------------- http://aurora.rg.iupui.edu
Regenstrief Institute for Health Care
1001 W 10th Street RG5, Indianapolis IN 46202, Phone: (317) 630 7960
[email protected] ---------------------- #include <usual/disclaimer>