Subject: Re: New SCMP Discussion List

From: Gunther Schadow <[email-masked]>
Date: Mon, 28 Jun 1999 14:15:07 -0500 (EST)

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
[email-masked] ---------------------- #include <usual/disclaimer>

---

From: "Dave Darnell" <[email-masked]>
Date: Mon, 28 Jun 1999 12:40:21 -0700

I would be very interested in hearing a response to this e-mail from the
IETF.

Gunther has some good points here.

-Dave Darnell

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Gunther Schadow
Sent: Monday, June 28, 1999 12:15 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: New SCMP Discussion List

Hi,

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-masked] ---------------------- #include
<usual/disclaimer>

---

From: Jason Eaton <[email-masked]>
Date: Tue, 29 Jun 1999 10:12:35 -0700

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

---

From: Tom Arnold <[email-masked]>
Date: Mon, 28 Jun 1999 21:31:53 -0700

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. 

To: "[email-masked]'" <<[email-masked]>

From: Tom Arnold <<[email-masked]>

List-Archive: <<http://www.imc.org/ietf-scmp/mail-archive/>

List-Unsubscribe: <<mailto:[email-masked]?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.

[snip]

>[email-masked] ---------------------- #include <<usual/disclaimer>

Vice President                                550 S. Winchester Bl. 
#301

http://www.cybersource.com/                   Main: 1.408.556.9100

This Email and any attached files are confidential and may also be
privileged. <bold><italic> </italic></bold>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.