Subject: RE: OPES protocol, pre-draft

From: "Abbie Barbir" <[email-masked]>
Date: Mon, 24 Feb 2003 10:27:22 -0500

hi,

see inside
abbie

> -----Original Message-----
> From: jfcm [mailto:[email-masked]] 
> Sent: Sunday, February 23, 2003 4:15 AM
> To: [email-masked]
> Subject: RE: OPES protocol, pre-draft
> 
> 
> 
> On 19:59 21/02/03, Alex Rousskov said:
> >On Fri, 21 Feb 2003, jfcm wrote:
> ><offtopic>blame your mail agent instead, for not 
> auto-filling both TO 
> >and

SNIP

> You ask two things.
> 
> - technical considerations: discussion about SOAP/noSOAP,
>    redirecting or not. ICAP.2 etc. One vision is continuity with
>    existing solutions, the other is a new vision related to a
>    global optimisation..
> 
> - applications examples:
>    - SMTP/FTP etc. support not HTTP to start with
>    - redirects with request of agreement by the user
>    - redirects/duplication upon thrid party decision (ex. 
> write tapping)
>     and all the interactions ONES/user/hosts/third parties.
>     whicha re not from what I understand part of OPES.
> jfc

very good point. The example protocol in the architecture document is HTTP.
So our first scenarios must be based on HTTP.

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!!

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.

Abbie

---

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

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.

> 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.