Re: New SCMP Discussion List

[Tom Arnold <toma@xxxxxxxxxxxxxxx>]

Gunther,

Let me respond by making a quick comment and then a repost on the subject of how and why SCMP exists.... (I'm sorry for the length of this message).

Let me open by stating that SCMP was sent in as a result of separate operating implementations in both the US and Denmark, handling a variety of transaction payloads. There is no IETF working group. Jason, the other authors, and myself posted the first draft over two years ago as the specification was being developed and implemented. At that time, the issue for the IETF, was there did not appear to be a single WG that this work seemed to fit. 

As the implementations were finished, and the protocol began working under production stress, we decided to present it to the applications area directors, and the IESG as an independent RFC. We received several comments and this list was born. We are currently planning to release this draft as an informational RFC (once a few more small bugs are worked out) and then prepare another draft to move up the standards track. 

We currently are active working within the TRADE, SMIME, and PKIX working groups and would be glad to work with the EDIINT team. But as of yet, the SCMP work is still independent. 

--------------  Begin past repost on where SCMP fits in

X-Sender: dptom@xxxxxxxxxxxxxxxxxxxx
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 26 May 1999 22:26:25 -0700
To: "'ietf-scmp@xxxxxxx'" <ietf-scmp@xxxxxxx>
From: Tom Arnold <toma@xxxxxxxxxxxxxxx>
Subject: Re: Where this fits in
Sender: owner-ietf-scmp@xxxxxxx
List-Archive: <http://www.imc.org/ietf-scmp/mail-archive/>
List-Unsubscribe: <mailto:ietf-scmp-request@xxxxxxx?body=unsubscribe>

Yes. There are several. Of the ones listed, I'm most familiar with the Rosetta, OBI, and IOTP. ...

First off: SCMP was designed to be a "request and reply" protocol. In essence, a single message is sent from a sender to a server. Given the assumption that the sender and receiver have previously established a trusted relationship, the receiver of the SCMP request authenticates the message, examines the payload, performs the functions requeste, formats a reply, and sends the reply back to the request. 

Second: There is no description of payload, requirements on the server for payload handling, implications on business processing, or requirements for the server to hold state. In several of the other protocols, there are fields described, there a functions and processes that must be performed on the fields, and there are implied trading relationships. Let me state that these are all necessary things, but they involve how a business might be run and require some agreement between both trading partners. 

Our view of the world is that SCMP could be used to move many of these messages around. For instance, it would be perfectly reasonable for two entities to agree to use ANSI-X12/EDI. In this case, the "SCMP-message-type:" might be set to "ANSI-X12/EDI/Ver5036/Doc850" or something. The receiver of this message would know to hand the payload off to the EDI translater and respond with some form of acknowledgement message.... (this is an over simplification as the application doing the payload processing would have to do a bit more, but I think you get the drift).

Our plan in this area was to have people thinking of SCMP as a general method for moving commerce messages. The next step is to follow this up with an Informational document that describes specific payloads related to the other protocols.

Does this help position what SCMP is?



[snip]

-------------------  End repost

At 02:15 PM 6/28/99 -0500, Gunther Schadow wrote:
>Hi,
>
>I just browsed over the SCMP draft
>
>http://www.ietf.org/internet-drafts/draft-arnold-scmp-03.txt
>
>and I think it does contain some good ideas. However, I have a few
>questions and I am unsatisfied by the lack of coordination that is
>apparent in IETF working groups.
>
>First the questions: I wonder how specific this SCMP protocol is for
>the PKCS security protocol suite. I could not find the convincing
>argument for such a dependency, nor could I see the dependency itself.
>
>Second, and probably more important, this draft seems to be not the
>entire picture of the protocol. How do the client and server connect?
>Is this a direct TCP connection such as with SMTP or HTTP, or are the
>SCMP messages sent as RFC822 messages amd through SMTP (or HTTP)? How
>are the error messages returned? Did I miss something or could I not
>implement the SCMP protocol with only what I see in the draft?
>
>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?
>
>I assume that the SCMP authors have done their duty to research the
>field and have studied EDIINT specifications (though they don't
>reference them in their draft.) I can see that the SCMP authors might
>have missed some points in the current set of EDIINT specifications
>(so did I for a long time.) And I can also see that the low activity
>and delay in release of drafts to RFCs is a bad vital sign for the
>EDIINT group. However, rather than quickly creating just another
>protocol to do basically the same thing (with basically the same
>means,) I would have found it more appropriate for the SCMP authors to
>stir up some discussions in EDIINT about the missing features (e.g.,
>the Time-To-Live real time feature.)
>
>I believe that the world in general and the IETF in particular suffers
>from today's popularity of standards. It seems as if standards have
>become such prestige objects, that whoever believes he is a smart guy
>writes a standard like he would write scientific papers.  This defeats
>the purpose of standardization (required joke: "The nice thing about
>standards is that there are so many to choose from!") If IETF
>leadership does not step up and do some active coordination, Internet
>standardization will become a farce.  The area chairs of IETF or the
>IAB, if they see a potential overlap should:
>
>(1) Force people to join another WG rather than opening up a new WG.
>(2) Force existing WG and its chairs to listen to and appreciate the
>    new ideas.
>(3) Facilitate a resolution of disagreements and incompatibilities.
>
>If IETF and IAB does not take on such a steering role, standardization
>will no longer decided by IETF processes but by sheer marketing
>power. Whatever Microsoft/RSADSI/u-name-it will choose will be the
>standard.
>
>As for SCMP, I'd like to see an open discussion on EDIINT WG list to
>make us aware about the missing features in RFC1767 and associated
>specs.  It makes much more sense to relaunch RFC1767 to include time
>to life and secure message id, sequencing and referencing, than to
>have yet another incompatible protocol.
>
>regards
>-Gunther
>
>DISCLAIMER: I have no personal or material interest in the existing
>EDIINT standards or in pushing aside SCMP. But please, let's be sane!
>
>Gunther Schadow ----------------------------------- http://aurora.rg.iupui.edu
>Regenstrief Institute for Health Care
>1001 W 10th Street RG5, Indianapolis IN 46202, Phone: (317) 630 7960
>schadow@xxxxxxxxxxxxxxxxxxx ---------------------- #include <usual/disclaimer>
>
>



Thomas A. Arnold                              CyberSource Corporation
Vice President                                550 S. Winchester Bl.  #301
Chief Technical Officer                       San Jose, CA 95128
toma@xxxxxxxxxxxxxxx                          Direct: 1.408.260.6010
http://www.cybersource.com/                   Main: 1.408.556.9100
---------------------------------------------------------------------------
This Email and any attached files are confidential and may also be privileged.  It is intended only for the individual or entity to whom it is addressed.  If you are not the recipient or an authorized agent of the recipient, y  ou are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited.  If you have received this message in error, please contact CyberSource Corporation immediately at (408) 556-9100.  
Thank you.