Given the latest trends in web services and in particular the work that has
been done in
XML encryption/signature, I would like to suggest to start looking seriously
into adopting SOAP/XML (or OPES compliant SOAP envelop/Schema) for the
callout protocol.
Using SOAP, we can get the flexibility of defining a protocol that is
extensible and flexible. Using SOAP security extension can solve the
security requirements for OPES.
Having the ability of doing incremental signature is an important feature.
Tracing and notification can be provided as a service, that can take
advantage of the incremental siging ability of XML.
I know off hand that performance issues will be used aginst adopting SOAP.
However, keep in mind that performance is only one factor and it can be
argued that with continous improvments in CPU speed and Hardware
acceleration, this will not (or should not) be a major issue.
There is a lot of work that is being done now on SOAP security that can be
very usefull to OPES.
For OPES to be usefull, I think it should be able to interoperate with web
services. At the end of the day, OPES provide a service to the data
provider/consumer application.
I know that SOAP has been looked at before by OPES. As a start, do we have a
pointer on the previous work, if yes can someone please advice where we can
get it.
Thanks
Abbie
-----Original Message-----
From: Markus Hofmann [mailto:markus(_at_)mhof(_dot_)com]
Sent: Wednesday, February 12, 2003 6:52 PM
To: OPES Group
Subject: Start on OPES protocol work
Folks,
with the first two WG drafts being approved by the IESG
(architecture,
protocol requirements), and three others under IESG review
(scenarios,
threats, policy requirements), it's time to get started on the
protocol work!!
As a starting point, I'd suggest everyone to familiarize
herself/himself with the OPES Protocol Requirements Draft
(draft-ietf-opes-protocol-reqs-03). It will provide guidance on
fundamental questions we'll have to answer before trying to
settle/define a protocol, such as
- what type of interactions need to be supported (e.g. pure
request/response, or request with multiple replies, or...)
- what type of data is exchanged in requests and replies
- what are the security requirements
- etc.
We also need to keep performance expectations in mind, which might
impact the decision whether to go binary, text, highly structured
(e.g. XML) etc.
Based on the answers to these questions, we can then discuss and pick
the most suitable protocol. I'm hesitating to list "candidate
protocols" since it would *not* be a good idea to talk about specific
protocols without having discussed the answers to above
questions, but
in the past the following options have been mentioned at some point
(without a specific order!!):
- ICAP
- ICAP "next generation"
- SOAP/XML
- "Something" over BEEP
- Binary protocol
- more...
I would expect that we'll have some lively discussion on the protocol
issue here on the mailing list, and that we continue and
intensify the
discussions at a meeting in San Francisco.
Also consider this a call for agenda items for the next IETF meeting,
and send Marshall and myself agenda requests related to the protocol
issue.
So please, let's get started here on the mailing list, keep your
thoughts and opinions coming.
Thanks,
Markus