RE: EDI over http?

[Rik Drummond <drummond@xxxxxxxxxx>]

I seems to me that we have three options at this time: 1) do the http/post, 2) do a real-time smtp or 3) keep looking.
What us everyone's take. http sounds fine to me, but last year during the discussion some believed that http just would not work well large file transfers. Chuch questioned this in an earlier message. Is this true? Is there a problem with using http/post for large file transfers?

Does anyone know?

Later, Rik

-----Original Message-----
From:	Matthew James Gering [SMTP:mgering@xxxxxxxxxxxx]
Sent:	Monday, June 23, 1997 10:17 PM
To:	'ietf-ediint@xxxxxxx'
Subject:	Re: EDI over http?

> Using HTTP POST over SLL does require client to server authentication,
> but there is no reason why the client side can't actually be a server -
> we therefore have server-to-server authentication using SSL.  Am I
> missing somethnig here??

No, I don't think so. For SSL, one side initiates the session, but the once
established it is symmetrical, no client/server distinguishment. I thought
the original poster did not realize that SSL support X.509 certificates on
either end -- although I'm not sure if the below handshake shows that.

Although that says nothing about the protocol underneath SSL. HTTP is most
definitely client/server -- but yes, a /server/ per say could act as a
client. Also, SSL is not tied to HTTP, there have been attempts to use SSL
as a secure channel for other protocols.

Hopefully I am not bastardizing the specs, but that is my understanding
anyway.

	Matt

> >-----Original Message-----
> >From:	chucks@xxxxxxxxxxxxx [SMTP:chucks@xxxxxxxxxxxxx]
> >Sent:	Monday, June 23, 1997 12:24 AM
> >To:	Matthew James Gering
> >Cc:	ietf-ediint@xxxxxxx
> >Subject:	Re: EDI over http?
> >
> >Matt,
> >
> >I'm looking over the SSL3 protocol spec and there definitely is
> >something client side and server side about it. For instance this is the
> >possible message flow defined for the SSL handshake:
> >
> >
> >CLIENT                     SERVER
> >
> >ClientHello --------------> ServerHello
> >                            Certificate
> >                            CertificateRequest
> >                            ServerKeyExchange
> >            <--------------
> >
> >Certificate
> >ClientKeyExchange
> >CertificateVerify
> >change cipher spec
> >Finished------------------->change cipher spec
> >    |                        Finished
> >    |                            |
> >    |                            |
> >    |                            |
> >    |                            |
> >    |                            |
> >    V                            V
> >
> >   application <-------------> application 
> >      data                       data 
> >
> >
> >Matthew James Gering wrote:
> >> 
> >> SSL is end-to-end session encryption -- there is nothing client-side
or
> >> server-side about it.
> >> 
> >> If you are referring to the X.509 certificate on the server used for
server
> >> identity verification, X.509 certificates are also supported on the
client
> >> for client identity verification and security login by most web
servers.
> >> 
> >>         Matt
> >> 
> >> > Since EDI is generally server to server, doesn't adopting a http/SSL
> >> > transport also imply that the client side http/SSL implementation be
> >> > done on the server side as well?
> >> >
> >> > For instance, the browser will implement the client side SSL
functions
> >> > such as server certificate authentication, etc. In the situation
where
> >> > there is no browser, and a server needs to send the EDI file to
another
> >> > server, doesn't the sending server need to implement the http/SSL
client
> >> > side dialogues?
> >> >
> >> > Does this mean that companies would need to go to the expense of
> >> > creating a "customised" http/SSL server to support client side
> >> > functionality?