Jfc,
- who are the "we" when you say "we won't do that as a humman command
interface" ?
From our charter:
> In a next step, the WG will specify one or more OCP profiles that
> will support OPES services operating on SMTP
OCP has no human command interface! That is why I said "we"
- what is the purpose of this OPES work? Is it just to carry
some research
or to design operational network building blocks?
Again the charter:
> In a next step, the WG will specify one or more OCP profiles that
> will support OPES services operating on SMTP. In particular, the
> profile to be specified will enable an SMTP server (the OPES
> processor) to encapsulate and forward SMTP data and metadata to a
> callout server for additional processing.
This is what we are trying here. And to prepare this we are discussing
the specific use cases, activation points and callout modes needed for
OCP.
- the language being used "OCP server/client" and an "MTA
becoming an OPES
processor" and a "callout server" does not make ANY sense to
me.
Sorry jfc. We discussed and defined them over and over again while
working on our previous charter and also for the SMTP work.
These terms are also used in our current charter.
This is a
middlebox language where the middlebox protocols are
affected/enhanced by
an external feature. This is not a server based Service
language. IMHO this
confusion does not help.
I will not further discuss this topic.
Regards
Martin