Subject: RE: OPES protocol, pre-draft

From: "Abbie Barbir" <[email-masked]>
Date: Mon, 24 Feb 2003 12:53:52 -0500

Alex,

I would like us to start looking into sporting services (Web Services). 
The example, may require (for broader business/deployment) that an OPES
processor may need to support SOAP.

I really would like us to start looking into that.
So far the Pre-draft discussion developes a protocol that could be easily
implemented as a SOAP one.

we just need few elements, such an an HTTP element (encpasulates HTTP
partial or full), a Responce-Required element etc... Basically, one class of
elements can incoporate all of the features of the pre-draft.

However, we can add elements that allow for
1. Partial/full controlled access to a profile (user)
2. Partial/full access to policy
3. content-trace-route element (this one is optional)

We should look into not requiring close coupling between the Callout Server
service provider and the OPES provider in terms that they are bound to a
spcific OCP protocol that can only be used to sell or provide a service.

IF we look at SOAP, we can in thoery allow for any web service service's
provider to become a Calllout Server. (with the proper OPES framework in
mind, of course)

Abbie

> -----Original Message-----
> From: Alex Rousskov [mailto:[email-masked]] 
> Sent: Monday, February 24, 2003 12:12 PM
> To: [email-masked]
> Subject: RE: OPES protocol, pre-draft
> 
> 
> 
> On Mon, 24 Feb 2003, Abbie Barbir wrote:
> 
> > The example protocol in the architecture document is HTTP. So our 
> > first scenarios must be based on HTTP.
> 
> I do not think the order is important here. Overall 
> application protocol coverage is important.  Yes, we MUST 
> support HTTP. However, we should try to support other popular 
> protocols. There were several SMTP-based usage cases 
> discussed on this list. There are probably other protocols 
> worth keeping in mind (FTP, IM flavors?). It is much easier 
> to support N protocols from the start then to support one and 
> then retrofit support for N-1 later.
> 
> > By the way, it seems to me that the current thinking in the 
> > pre-draft-01 work is that the OPES processor is always 
> fwding messages 
> > to the callout server. This may not be the case!!
> 
> Pre-draft-01 is about OPES callout protocol (for now). What 
> gets forwarded to the callout server is about OPES rules. 
> Thus, the current draft does not talk about forwarding 
> decisions at all. The draft covers what happens _after_ the 
> decision to forward has been made.
> 
> Hilarie Orman may have asked about partial forwarding 
> support. See predraft's TODO list. Partial forwarding is not 
> yet supported because I need Hilarie's clarification on what 
> exactly she is after.
> 
> > I would like us to consider this scenario.
> >
> > 1. Gold, silver and copper services provided by a service 
> provider 2. 
> > Gold package, looks into user prefernces (stored either locally or 
> > thru a URI or whatever) 3. User trust the OPES processor with his 
> > financial/private data, willing to expose some of the 
> preferences to 
> > selected companies. 4. User can log on with multiple devices 
> > (wireless, PC) 5. User requires language translation (or location 
> > based service), that is conditional on the access device
> > 6. user is willing to pay for translation based on various 
> criteria and
> > he/she prefers company X.
> >
> > Now, company X is not willing to implement OCP (OPES Callout 
> > Protocol), but company X provide the translation as a Web Service.
> >
> > How would the predraft protocol would be used here. Is the OPES 
> > provider out of luck. Here the customer can be a 
> Multimillion dollar 
> > company.
> 
> I must be missing something important here. You are saying 
> that "X is not willing to implement OCP" and then asking "how 
> the predraft [OCP] protocol would be used here". If X does 
> not support OCP, predraft will not apply. Apparently, X is 
> using some other protocol to implement language translation. 
> If the customer is willing to pay for that other protocol (or 
> just does not care), then X will serve the customer using 
> that other protocol. If the customer is not willing (perhaps 
> because the other protocol does not provide OPES-grade 
> privacy enforcement), then X will not get customer's 
> business.  Moreover, content provider might want and be able 
> to prohibit non-OPES-translations if client-side software is 
> willing to enforce such restrictions by checking digital 
> signatures and such.
> 
> I am not answering your question though, am I?
> 
> Thanks,
> 
> Alex.
>

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 24 Feb 2003 13:13:45 -0700 (MST)

On Mon, 24 Feb 2003, Abbie Barbir wrote:

> I would like us to start looking into sporting services (Web
> Services).  The example, may require (for broader
> business/deployment) that an OPES processor may need to support
> SOAP.
>
> I really would like us to start looking into that. So far the
> Pre-draft discussion developes a protocol that could be easily
> we just need few elements, such an an HTTP element (encpasulates
> HTTP partial or full), a Responce-Required element etc... Basically,
> one class of elements can incoporate all of the features of the
> pre-draft.
>

It is great that the predraft protocol can be implemented on top of
SOAP. That means our options regarding OPES transport are still wide
open; all transport protocols mentioned on this list can be
supported: BEEP, HTTP, and SOAP.

At some point, we need to decide whether to standardize a single
transport protocol binding (e.g., SOAP) OR allow multiple bindings
(e.g., HTTP or SOAP) with one "OPES binding" spec (RFC?) per supported
transport protocol. The one-binding approach is simpler but the
N-binding approach is more flexible.

> We should look into not requiring close coupling between the Callout
> Server service provider and the OPES provider in terms that they are
> bound to a spcific OCP protocol that can only be used to sell or
> provide a service.
>
> IF we look at SOAP, we can in thoery allow for any web service
> service's provider to become a Calllout Server. (with the proper
> OPES framework in mind, of course)

IETF in general and OPES WG in particular cannot dictate what a
service provider can sell. Clearly, there will be competing protocols
and approaches on the market, and OPES would have to fight its way to
the world dominance.

We have to work in OPES context: a service provider either supports
OPES or it does not. We cannot accommodate service providers that do
not use OPES (e.g., those that use raw SOAP with non-OPES extensions).
We can only try to make OPES attractive enough so that more service
providers support it.

It would be great if current service providers can switch to (or add
support for) OPES without much effort. If you can convincingly
demonstrate that having SOAP binding will make transition to OPES
simple, it would significantly increase chances that SOAP becomes an
OPES binding. To make this case, we have to finish implementing the
core of the protocol, I guess. Before that happens, it is difficult to
discuss transitions from existing approaches since there is nothing to
transition to!

Finally, based on e-mails on this list, I expect some resistance to
SOAP because SOAP is not an IETF standard. I do not know what the
official IETF (IAB?) position is regarding developing IETF standards
that rely on IETF-level but non-IETF standards. Are there historical
precedents (e.g., standard-track RFCs) of IETF specs based on SOAP? If
there is a political problem with SOAP, supporting multiple optional
bindings (including SOAP) may help to avoid a deadly clash with IETF
policies.

Thank you,

Alex.