RE: Question regarding draft-ietf-ediint-req-05.txt

["Rik Drummond" <drummond@xxxxxxxxxx>]

How do you wish to extend the rfc1767?  (Remember rfc1767 does not address
security.... the spec's from this work group do.) Please explain in outline
form what you think needs to happen to make thing right.

Gunther, we may be talking about different things here or be having a
semantic problem. When I read your response below... things do not jive with
my understanding of the said technology. So lets start over..... and give us
a succinct outline of what need to be added or addressed.

Stick in there...

Regards, Rik


> -----Original Message-----
> From: Gunther Schadow [mailto:gunther@xxxxxxxxxxxxxxxxxxx]
> Sent: Wednesday, May 06, 1998 8:00 PM
> To: drummond@xxxxxxxxxx
> Subject: RE: Question regarding draft-ietf-ediint-req-05.txt
>
>
> > Gunter, I will say it again. We discussed this two years ago, and
> > decided not to include it because we felt it was a translator issue.
> >
> > Now if you feel different that is ok. Make your case, defend it and
> > we will do a new paper on it.
>
> What I want is that we finally open the case to revise RFC1767. I
> currently see a lot of suggestions by people on this list that are
> essential to secure EDI communication. However, instead of addressing
> these issues generally (i.e. not EDIFACT specific) right at the point
> of origin (the EDI envelope) we hear recommendarions to use a specific
> transport mechanism like HTTP (Rik) or direct SMTP (Carl) or overload
> the outermost RFC822 headers with EDI specific meanings (Carl). Why
> can't we start thinking about a revision of RFC1767?
>
> > The real-time, HTTP exchange, does solve this problem 'completely',
> > because there is not an intermediate third party between the two
> > HTTP servers to mess up the sequencing. Things can't be mis
> > sequenced, unless there is user error at each end -- which is not
> > our problem.
>
> But the beauty of using SMPT (e-mail) for EDI is that it allows for
> intermediary routing, queuing and resending. Even though HTTP might
> work around the problem, this fix is not general. Fixing RFC1767 as I
> described can solve the problem generally, for whatever transport
> mechanisms people want to use. I regard the HTTP deal as a gimmick. As
> Carl pointed out several times, you can have all of this with direct
> SMTP. However, direct SMTP is not flexible enough. EDI messages have
> historically been processed asynchronously and it is a good thing to
> think twice before requiring otherwise.
>
> > So unless the initiating server messes up I fail to see how
> this will not
> > solve the sequencing problem between two trading partners. Am I missing
> > something?
>
> Yes, the point that I just made: the HTTP is a workaround but the core
> of the problem lies in RFC1767 and should be generally solved
> there. Also, your argument would say that if you want *really* secure
> EDI transactions you would have to stick to HTTP. You are effectively
> denying that the sequencing threat can be prevented in asynchronous
> messaging in a general way. I want to do just that. My proposed
> solution is posted a couple of messages back.
>
> -Gunther
>