Hilarie,
see remarks inside,
abbie
-----Original Message-----
From: The Purple Streak, Hilarie Orman
[mailto:ho(_at_)alum(_dot_)mit(_dot_)edu]
Sent: Friday, February 14, 2003 3:13 PM
To: Barbir, Abbie [CAR:1A00:EXCH]
Cc: ietf-openproxy(_at_)imc(_dot_)org
Subject: RE: Start on OPES protocol work
I mention that, on Fri, 14 Feb 2003 at 13:01:52 -0500, Abbie
Barbir said:
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've got a book published late last year on XML security, and
it does not mention incremental signatures. What are they,
how would they be useful to OPES?
-------- abbie
what I mean by incremental signature is that different parts of the body can
be signed by mutiple parties, plus different parts can be exposed to
different parties
How can we keep track of this W3C work-in-progress from the
IETF vantage point? I'm not a member of W3C, and I cannot
judge the maturity of their drafts, the likelihood of
standardization of any of the documents. Can you and others
promise to serve as liasons, keeping us apprised of what's
going on? Or perhaps there's already someone who does this
for the XML security work, like Don Eastlake.
I acn do what I can, but a lot of the SOAP security work is done in OASIS
and they have a open process (I beilive), where u can get access to all the
doc.
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.
I'm not objecting to examining performance vs. ease-of-use,
but it is important to keep the whole picture in mind. If a
single CPU with no special hardware enhancements can keep a 2
Gbps line busy, carefully balancing CPU cycles and I/O, then
you have to be very careful about adding extra per packet
processing that multiplies the CPU cycles by a factor of 1000
- this would mean that an organization would need many more
CPU's to do the same job. So let's be very specific when we
discuss performance and acceleration - the numbers are
important because they determine the cost of the deployed systems.
--- abbie
Before u can do that, we need to know what we are comapring SOAP to.
I bet you, that whatever protocol will be developed there will be a need to
define a structured way of invoking RPC, which will involve some form of XML
or metadata.
Even if you ICAP, you still need to know how to find services and how to
invoke them, which means some way must be developed to do that. Otherwise,
you will be binding the OPES architecture to a group of very limitted
services, and you will be forcing the service provider to get hooked on one
the services of one vendor.
There is a lot of work that is being done now on SOAP
security that
can be very usefull to OPES.
How can we know what that very useful work is?
---- abbie
SOAP security involves header extensions that allow for
Authorization/Authentication information to be exchaged (including info for
XML encryption/Sig)
There are also provision for Policy exchange, Privacy exchange, Trust and
routing.
In SOAP, you can use routing information to state which SOAP Actor can be
involved in the data path etc. This help OPES since, since it can define
which callout server can be used and it can also define what policy to use
etc.. (including privacy info...)
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.
Can you tell us what it means to interoperate with web
services? I'm not against it, but I've got only the vaguest
notion of what it might mean for OPES.
---- ABBIE
WHat I mean here, is that the service provider that deploy OPES, should be
able to offer services as they become avilable and as long as they make good
financial sence. Since off hand you do not know what a killer APP is, the
OPES platform should be extendale, meaning, the OPES provider should be able
to offer a service at a minimal cost. SO if SOAP ids the callout protocol,
and the new service ids a web service, implementiung it in OPES is quick and
strighat fwd. Otherwise, u need to customise the service at leat at the OPES
end.
WOrst case secnario, the actual provider of the service need to TALK OPES.
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.
My memory of this is that Lee Rafalow was a strong advocate
of looking at SOAP, but there was no work beyond that
advocacy. Perhaps others have done work since then, but have
not reported it to OPES because we were concentrating only on
the initial documents. We need to spread the word that we
are now in a new WG phase and it is safe to come back to the
mailing list.
Hilarie
I have access to that info, but i thought that there was a talk about
comparing SOAP, ICAP etc.. that was presented in one of the BOFs meetings.
abbie