Alex Rousskov wrote:
It does not. The problem is with the specific deliverables that seem
to mention just one language specification/document rather that a core
language plus modules approach:
DATE Initial document on OPES rules language
DATE Submit document on OPES rules language to
IESG for Proposed Standard
Should we rephrase so that multiple documents are allowed?
What about:
SEP04 Initial document(s) on OPES rules language
MAY05 Submit document(s) on OPES rules language to
IESG for Proposed Standard
Sounds like it excludes other protocols from being considered when
designing the core language. How about:
Define a rules language to control OPES processor selection
and execution of OPES services, including HTTP and SMTP
adaptation services.
Let's committ to producing a solution that at least supports HTTP and
SMTP, but not more.
We aim to define a language that is open to support others as well,
but we don't get into trouble if it turns out to be too complex.
That's exactly what we did with the protocol in the current charter -
we were chartered to define a solution for HTTP. but we were able to
come up with an elegent solution that is flexible enough to support
other protocols as well.
So I'd suggest to stick with "Define a rules language to control the
selection and invocation of HTTP-based or SMTP-based OPES services."
-Markus
PS: I'll go through the reamining comments and will send out an update
charter once I got through.