ietf-openproxy
[Top] [All Lists]

RE: OPES protocol, pre-draft

2003-02-24 10:54:12
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:rousskov(_at_)measurement-factory(_dot_)com] 
Sent: Monday, February 24, 2003 12:12 PM
To: ietf-openproxy(_at_)imc(_dot_)org
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.

<Prev in Thread] Current Thread [Next in Thread>