Subject: Re: Status Update

From: Markus Hofmann <[email-masked]>
Date: Wed, 01 Dec 2004 10:44:48 -0500

jfcm wrote:
> Sorry for this. (a) but better to ask: where can one find the most 
> appropriate definition of sieve? 

http://ietf.org/html.charters/sieve-charter.html for the sieve WG, but 
it doesn't have a link to the latest sieve definition.

> (b) should we not first stabilize the 
> list of applications?

We'll do that in parallel, Martin and Abbie are getting started and 
will have something to share soon.

> Also, I know that we are not supposed to discuss architecture, but I see 
> an increasing documented debate over NATs and all the functions actually 
> located at "NATs." - in my wording I name them "corebox" when they are 
> the actual core of the users vision of the networks. This seems one of 
> the natural location for OPES and additional services. So, without 
> discussing architecture, I suggest that we adopt the most open mind 
> toward applications/protocol and we enlarge to 
> _mail/structured_signals_, not only on SMTP?

The charter is claer - it's SMTP. This does *not* prevent us from 
keeping the larger picture in mind when designing solutions (jus as we 
did with the HTTP work), but the deliverables ask for SMTP only and 
that's our focus.

-Markus

---

From: jfcm <[email-masked]>
Date: Wed, 15 Dec 2004 10:16:00 +0100

I will list a few other applications I do not know if I quoted them:

- filtering on language tag basis - tags are presently discussed for a 
revision of the RFC 3066.

- filtering for externet confinement. Externet is a notion I work on as 
part of the probable (old) future of the nets: it is the virtual network of 
my vision of a part of the network (the extenal IPs, names, tags, etc. I 
accept to relate with).

- semantic web support. I can use external information to amalgamate them 
with the mail content. This is a general OPES capacity I think we should 
discuss with the W3C, since OPES and OCP could be the core of an automated 
underlaying semantic web. Obviously this is more a ONES architecture (my 
old open network extended services) as it has to initiate the process, or 
if triggered by a cron it is not an end to end action. But we could fake an 
OPES for the IAB. Let conceive the following architecture:

   1. I have a web site made of structured pages of information I want to 
update in using a semantic web approach.
   2. I send _myself_ mails, each mails being the content of the site pages.
   3. on the mail path the "SMTP/OPES" (whatever it may mean) works on the 
mails to update them from all the related semantic web sites.
   4. I receive the mails and once all of them are updated I use their 
content to update the site.

   The advantage of SMTP over HTTP and a Webservice is that everything is 
quite built-in (I can write a perl script to send and receive in less than 
an hour), that the it is asynchronous (so it may accept delays, machine 
being downs, store all the data before the last mail triggers the rebuild 
process, etc.), that it has a built-in duplication solution (so I may 
maintain many sites one shot), that with additional OPES features I can 
trace the process, I can charge for it, etc.

- in the same vein using a similar "send myself a question for it to come 
back with an answer" I can easily build information services, with 
broadcasts to everyone concerned. For example, in a working group, I have a 
question of common interest: I can send the group a question, the SMTP/OPES 
will exfilter, respond from semantic web or a database, fill into the mail. 
So the group receives the reply to my query.

- multilingual/anonymized mails. The mail header is modified so the origin, 
destinees, etc. can be written in a scripting and received in another 
scripting.

- incrementing counters to charge for mails (mail toll or stamp.s) at 
gateways, etc. There is only a small filter interacting with the OPES 
server, so the cost can be very low.

- triggering alarms. When a mail I am waiting for is delivered, I receive 
an SMS.

- third party notarization. A recent FCC case shows the need. They fined a 
network for an indecent show (if I am correct a singer had an incident 
[pretented on purpose] and shown her breasts). It said it had received 129 
e-mail complaints. An audit shown it had received only 23 including 20 
copies of the same 3 mails. An "SMPT/OPES" could be easily devised to 
report on the number of really different mails received by an authority. 
The interest of the OPES is that the content can be verified on a secure 
server.

- mail tapping. Obviously this is the same as mail tapping by police. The 
ISP may be easily asked by a Judge to tapp the mails of a customer just in 
turning on/off an OPES.

- I suppose I quoted it before, but an SMTP/OPES can provide encryption of 
regular mails and scrambling (for example setting up an "ISP rotation" it 
may send crypted bits of mails through several ISP/mails and rebuild tghe 
mail on arrival)

etc.