Re: New SCMP Discussion List

It should also be noted that SCMP is a working protocol that has been in
production since 1994. The specification was written to describe a working
production message protocol. We are currently accepting approximately 2 million
messages a month with this protocol.

Thanks.

At 09:31 PM 6/28/99, Tom Arnold wrote: 
>
> 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: [email protected] 
> X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) 
> Date: Wed, 26 May 1999 22:26:25 -0700 
> To: "'[email protected]'" <[email protected]> 
> From: Tom Arnold <[email protected]> 
> Subject: Re: Where this fits in 
> Sender: [email protected] 
> List-Archive:
> <<http://www.imc.org/ietf-scmp/mail-archive/>http://www.imc.org/ietf-scmp/
> mail-archive/> 
> List-Unsubscribe:
> <<mailto:[email protected]?body=unsubscribe>mailto:ietf-scmp-reque
> [email protected]?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>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> 
> > 
> > 
>
>
>
> Thomas A. Arnold                              CyberSource Corporation 
> Vice President                                550 S. Winchester Bl. #301 
> Chief Technical Officer                       San Jose, CA 95128 
> [email protected]                          Direct: 1.408.260.6010 
> <http://www.cybersource.com/>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. 



Jason Eaton			CyberSource Corporation
Phone 408.260.6044		Security Engineering Manager
[email protected]	http://www.cybersource.com