Subject: RE: SMTP Use Cases

From: "Martin Stecher" <[email-masked]>
Date: Fri, 22 Oct 2004 16:28:38 +0200

jfc,

> I do not see any of these examples (which are much needed) 
> being an OPES. 
> They are middlebox (RFC 3234) services. None of them are on the fly 
> protocol add-on functions in a store and foreward system.

RFC 3234 lists in the catalogue of middleboxes in section 2.10
for example the Application Layer Firewall which an SMTP
client/server pair or a Web proxy agent.

I think this example can help us to find the way from our
recent HTTP work to the SMTP work now.

The SMTP client/server in the Application Layer Firewall is
the OPES processor in the OPES context that talks to a callout
server as before.

While RFC 3234 lists protocol checks and other features that
ensure the validity of the application. Exactly what we expect
all the time from the OPES processor; that part is responsible
for sending valid SMTP (or HTTP) to its peer.

Content adaptation is being done in the callout server in
an OPES scenario.

If you disagree, what kind of SMTP use cases do you see for OPES?

Regards
Martin

---

From: jfcm <[email-masked]>
Date: Fri, 22 Oct 2004 17:21:51 +0200

>If you disagree, what kind of SMTP use cases do you see for OPES?

None.

 From the very begining I disagree with the scope of OPES which is very 
confuse to me. But this is an architecture problem (RFC 2775 says that in 
fact everything can be changed if needed ). The reason why is that I 
consider that what is named "edge" (in a Host centric network) is actually 
the "core" (in a user centric system) and that actually the functions 
performed by OPES are ONES functions (Open Network Extended Services). This 
may appear futile, but you then better understand that the performed 
services are Network Services (what is not possible in a dumb network - but 
reread RFC 2775 about this. This is why I refered to middleboxes which 
actually offer network embedded functions - but usually not (yet) 
coordinated). How can you otherwise consider MTA as an "edge" (UA OK, not MTA)?

You also better understand that the OPES are real edge services (interface 
between the network and the application) and are to be services which adds 
to the protcol not to the exchange. In the case of HTTP we are in a direct 
relation so the confusion is less harming. In the mail store and forward 
exchange what you propose can be performed on the "store" part, while OPES 
should act on the protocol "forward" part.

But then the problems are quite complex because when http is direct 
one-to-one SMPT is one-to-many over upto 5 days.

jfc