Re: New SCMP Discussion List

[Jason Eaton <jeaton@xxxxxxxxxxxxxxx>]

Gunther, my comments are below. I have responded to the issues and questions
that pertain to the SCMP draft.

As a general comment, using the term "e-commerce" is dangerous. Word
smithing this
draft as an e-comerce solution opens up a lot of issues because of work
happening in 
other areas in the name of "e-commerce".

In it's purist form SCMP is actually "real time S/MIME". If we had word
smithed the draft
in this way I doubt that this exchange would be taking place. After
analyzing our particular
needs for "e-comerce" we realized that much of our requirements were
satisfied by other
standards. This is why SCMP is an application of S/MIME.

If in your opinion EDIINT can fulfill our requirements and in our opinion
S/MIME can fulfill our
requirements, does that mean that EDIINT is redundantly implementing S/MIME? ;)

You should ask yourself if you have issues with the SCMP draft only because
its a proposed
solution for "e-commerce". That is if the draft were proposed as "real time
S/MIME" would you 
still have the same issues concerning EDIINT?

At 12:51 PM 6/30/99, Gunther Schadow wrote
>
>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.

RFC 1767 specifies EDI messages as the MIME payload. SCMP does not
specify the payload format.

>
>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?  

We did consider EDI, ( in one of it's various forms ) as a possible solution.
As a matter of fact we use EDI to communicate to physical fulfillment parties
or distributors. Again we do not want to specify our payload.

>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.

Relevance does not come from wining. We are willing to coordinate with
any relevant group.

>Not everyone has to rush for standards track just because the protocol
>is neat.

I agree, this is not a good idea. Five years in the making of SCMP is hardly 
"rushed". Our driving force was to allow our ideas to be shared among 
the community. 

>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.

I agree. We should coordinate with the EDIINT group to see if our requirements
can be answered with their work. However there may be two totaly seperate
areas of work going on here. ( don't get hung up on the e-commerce term ).

>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.

I still am concerned that the problem space is fundamentally different.

I don't think a yielding is yet in order. We need to do some more research on 
EDIINT and a meaningful exchange with the group. We will be in Oslo and 
would love to get some time from some members of the working group.

Any volunteers? 

Thanks.


Jason Eaton			CyberSource Corporation
Phone 408.260.6044		Security Engineering Manager
jeaton@xxxxxxxxxxxxxxx	http://www.cybersource.com