IMHO all this come from the perspective we are mudded into. The initial
analysis makes (IMHO) the wrong end of the OCP link the core center. To
clarify this I will note ONES (Open Network Extended Services/Server)
architecture in which (a network of) servers interoperate services to user
relations, through shims inserted on the relational paths. What in OPES
words would mean many OPES calling out the same server.
1. OPES act as a indepedent middle box calling out on external systems.
2. ONES operates services on the user's demand where the user demands it
(and have located a shim).
OPES are new (similar) logics/RFC every time there is a new applications.
And have no control/knowledge of the way the callout servers may work.
ONES have a global strategy. They should have a single framework/RFC with
each application having to provide consistent I/O, and powerful specific
application management extensions.
OPES cannot permit to deploy a dynamic SMTP strategy depending on a mail
situation (triggering mail, overload, DoS, etc.). This is a specific
capability of ONES. What Hilarie describes is typically what a ONES is for
(with all the versatility to also adapt the filtering strategy to the
situation). P, Sieve, etc. are different OPES concepts, they are just
complementary and possibly interactive/complementary shim tools of an ONES.
This is why I ask if we should not document both architectures and report
to IESG/IAB for further guidance. I think there is room for both, and that
clarification can only help both.
jfc
On 01:05 25/04/2005, The Purple Streak, Hilarie Orman said:
Alex's analysis was orthogonal to what I thought the criteria would
be. I'd thought Sieve had some advantages in being able to support
SMTP directly; if it does, I can't tell from his comments. And his
bottom line, about a partially defined language seeming more
attractive than a fully defined language, is a cogent observation.
For me, the requirements are powerful expressions for matching,
easy-to-use variables, and support for parsing network headers.
Also the ability to dispatch to the OPES callout server quickly
and to get replies.
I'd like a narrowly scoped, limited language, because I want to
make it very fast for the OPES matching and dispatching functions.
It has to have a good interface to the underlying OS network
functions.
Failing that, I'll take a general purpose pre-existing language!
So, I'm not thrilled with Sieve, but am willing to work with it, based
on my reading of the drafts last year. P still seems vague and
undistinguished.
Hilarie