At 16:28 22/10/2004, Martin Stecher wrote:
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?
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