Subject: No OPES WG Meeting in PAris

From: Markus Hofmann <[email-masked]>
Date: Tue, 12 Jul 2005 20:09:17 -0400

Folks,

you might have noticed that we didn't ask for an OPES meeting slot at 
the IETF 63 in Paris. Reasons being that neither of the draft authors 
will be available to present in Paris and that we didn't make progress 
on the rules language.

In case you feel there's an urgent need to meet, let Tony and me know, 
there might be an option to have a quick ad-hoc meeting.

Thanks,
   Markus

---

From: jfcm <[email-masked]>
Date: Wed, 13 Jul 2005 07:06:22 +0200

On 02:09 13/07/2005, Markus Hofmann said:
>Folks,
>you might have noticed that we didn't ask for an OPES meeting slot at the 
>IETF 63 in Paris. Reasons being that neither of the draft authors will be 
>available to present in Paris and that we didn't make progress on the 
>rules language.
>

I am not sure I am here all the session. I will not attend the IETF (no 
worth $500 for me). There is a social event on August 2nd. We will guest 
ISOC people on the 4th evening. But we could organise a drink or something 
on 3rd or at another time, some where. If there are other people as well?
jfc

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Wed, 13 Jul 2005 11:22:54 -0600

I'm sorry that I'm not going to Paris, and sorry that the rules language
is going so slowly.  I'd hoped to have a draft done on Monday, but it is
looking as though several more days will pass before it's ready.

I have several issues.  

1. Should the language be able to store metadata about message and/or
   connection state?  Should it be able to accept such information
   from the callout protocol?

2. Should the rules be able to load data from files?  For example, long
  lists of IP addresses?  So that instead of writing a rules for
  each IP address, one could write 
    (if address.ip.src member-of (file-data("ip-addresses")) ...
  or
    initializiation:
     file-to-array("ip-addresses", ip-address-array)
    ...
     rules:
   (if address.ip.src member-of ip-address-array ...

3. Is there any reason not to include full regexp matching?

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 13 Jul 2005 14:19:35 -0400

----- Original Message -----
From: "The Purple Streak, Hilarie Orman" <[email-masked]>

>    from the callout protocol?

I would say so.

> 2. Should the rules be able to load data from files?

Of course. But that may be independent of the client.

> 3. Is there any reason not to include full regexp matching?

That's an language implementation issue.

Lets take a step back a little.

Did I personally miss the Interface Requirements between heterogeneous
processes?  Or does this not apply?

If this is going to work, I can only see this be done as a black box where
some OPES service is exposed to the world, maybe as a WEB SERVICE for
example in the backend.   The issues I need to know is how to pass it the
information it needs and how to get a result as I expect it.

From a SMTP standpoint for example, there are five (5) process entities:

    CIP - Client IP address
    CDN - Client Domain Name
    SRP - Sender Return Path
    RFP - Recipient Forward Path
    DATA - Payload

Plus maybe some server side USER information:

    UAI  - User Authorization Information
    UPA -  User Personal Account

How much more can the SMTP receiver feed a OPES callout service?

I mean, I don't care what the "language" is written in BASIC, APL, LISP,
FORTH, FORTRAN, C++, D++, Z++ or what have you,  I am more interested in the
software engineering interfacing:

        Process <-->  Callout

You need to be able to defined

a) how or what input  is passed?
b) how or what output is returned?
c) will it have synchronous vs. asynchronous behavior?
d) Timeout/Keep Alive issues (very related to C)

Once this is written, the backend language is inconsequential.  They all
must offer the same level of interfacing.  Today, you write this "language."
Tomorrow, someone writes in BASIC maybe just because they believe its makes
it more marketable .  In either case, the interface must be the same.

If I missed any of this in the technical specifications, I would really like
to see it.

Thanks

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Wed, 13 Jul 2005 14:32:48 -0600

Thanks for the dicussion contribution.

What is the interface requirement between heterogeneous processes?

The rules language has the ability to dispatch data streams to many
OPES services, not must SMTP.  It must be able to specify which
messages go to which services.

The rules may be also be invoked on data returning from an OPES service.

Each rule is a condition and an action.  If the condition is met
then the action is invoked.  Your note seems to focus only on
parameters that are part of the action, as if the condition tests
didn't exist.  Or perhaps I'm misunderstanding you.

Hilarie

---

From: jfcm <[email-masked]>
Date: Thu, 14 Jul 2005 00:10:57 +0200

>didn't exist.  Or perhaps I'm misunderstanding you.

I have the same reading. But this might be considered as a small building 
block,simplifying the analysis (RFC 1958)?

I have another totally different need which might also cover an OPES need 
in here. I am better of explaining the need in trying to use OPES wording 
so the similarities may be better viewed. I describe my need however, not 
to try to follow previous work in here so the first question can be "are 
there significant similarities". And if yes to look more into it. And if my 
need could not be in several ways an OPES application.

- I name CRC (common reference center) a clearing house for common 
information to the members of a relation, community, etc.
- I name "shuttle" the one shot transaction which ask the CRC one 
information identified by its number, associated to a tag (ex. $list_name/1001)
- I name "spice box" (shuttled private information cache exchange) the 
cache of the data received from the shuttled or processed from them. let 
consider it is an opposite to the cookie (my secret knowledge of the 
external world).

This means that when in a text the filter needs to replace $list_name by 
its value, it will call the 1001 in the spice box which in turn will call 
on the CRC.

I am interested in having the shuttle authenticated.

In most of the case the shuttle transaction will be one datagram. And be 
used to also to carry a command/signal. So UDP seems adequate. But when the 
transported information is longer, OCP could be of interest? Then obviously 
this system is destined in interrelating (on my machine, under my control) 
with the applications such as SMTP.

Obviously the information of the CRC is more static than in OPES (call-out 
servers can be quite dynamic). But CRC will use IPv6 access grids. This 
means that each information will be related to a number which is an 
InterfaceID. So one can call many CRCs to get/prioritised environment 
(something OPES could also do).

I look for experience for specifying a shuttle system (which may exist: it 
is like a one shot ping?).
Also, I think this could be used easily to build permanent e-mail reroutes, 
etc.

I apologize if this is out of context.
Thank you.
jfc

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Wed, 13 Jul 2005 17:18:08 -0600

>  information identified by its number, associated to a tag (ex. $list_name/1001)

It's called on RPC in the literature.

>  consider it is an opposite to the cookie (my secret knowledge of the 

Like a DNS cache, like a proxy server for http, like any number of
other caches for various protocols?

>  its value, it will call the 1001 in the spice box which in turn will call 

Always, or only when the information is stale?

>  I am interested in having the shuttle authenticated.

With respect to what?  The client authenticates the shuttle, the CRC
authenticates the shuttle?  Who authorizes shuttles?

>  transported information is longer, OCP could be of interest? 

Why not use TCP?

>  Then obviously 

What's the architecture?  Does your SMTP server call on the CRC to get
extra information?  Does your SMTP client call on the CRC?  

>  servers can be quite dynamic). 

We hope not.

> But CRC will use IPv6 access grids. This 

Sounds horrible.  Surly you don't want to tie application information to
InterfaceIDs?  Are you talking about using Anycast to collection of
CRC replicas?

If your primary question is, could OPES be used to implement a caching
service for a nearly stateless RPC protocol, I'd say not really.  OPES
would be relevant if you already had such a service and wanted to
provide added value to it with callout servers.

Or, suppose you were using OPES for SMTP enhancements already, and you
wanted to add CRC information.  We had already decided that in such
cases, the callout server would be responsible for retrieving CRC info,
and it would cache it if needed.

I don't see any reason that the same machine that runs OPES couldn't
also run a caching proxy for CRC, though.  

Hilarie

---

From: jfcm <[email-masked]>
Date: Thu, 14 Jul 2005 20:08:19 +0200

>It's called on RPC in the literature.

It may be supported by RCP variant. But the transaction make no difference 
if the CRC is on the same machine or not, or on local network (for example 
qnet)

>other caches for various protocols?

Yes. Except that the information may be processed or deducted. An 
application can be cronned or triggered by some entries. The important 
point is that I can process the information or call for a replacement by 
another value from another source.

>Always, or only when the information is stale?

Always. This is "my" view of that information. A variable.

>authenticates the shuttle?  Who authorizes shuttles?

The shuttling must be secure (I must authenticate the return) and the 
delivery of information may be protected (I authenticate the request). I 
(user) and CRC master authorise shuttles. Possibly under a relation controller.

> >  transported information is longer, OCP could be of interest?

Why not, but seems heavy. Quite comparable to DNS. Timers can be freely 
decided by the application.

>extra information?  Does your SMTP client call on the CRC?

Any architecture can be thought of.  Let think about the spice box as a 
dynamic extended locale.

> >  servers can be quite dynamic).

Why? This is the interest of an OPES vs a middle-box?

>InterfaceIDs?

Sure we do. We do not relate "application information" but "protocol 
information". The Grid is part of the Protocol. Like ports could be in RPC.

>Are you talking about using Anycast to collection of CRC replicas?

Nothing opposes if the replicas are identical (ex. distribution of IANA). 
But the interest is that the spice boxes can be fed with prioritized 
information from different servers. So, I can get context information from 
a given CRC and referent information from another one and default from a 
locale like source.

>and it would cache it if needed.

I just mentioned it to help my thinking on the issue and as an example of 
the architecture some cases could work with. The OPES concept is that it 
runs on a proxy and the callout server is distant. The spice box is on the 
user machine and dynamically build its vision of the world. One application 
can actually change that vision from an SMTP input. For example, if an OPES 
tells a call-out server the origin of mails, that server can call an 
application running on the spice box, the information is used and an 
information in the spice box changed that can be sent to the all-out server 
to permit a response to the OPES.

This can permit me for example to tell my machine where to send a mail, 
depending in the time it comes in, of its sequence and where I am, while 
all these informations are randomly feed.

I am very interested if you have advises on the RPC tools (center of 
expertise, specialists, ...) I will spend my vacations on RCP, ISO 11179, 
ASN1. etc. :-)

jfc