Subject: agenda?

From: jfcm <[email-masked]>
Date: Tue, 30 Nov 2004 01:09:30 +0100

Is there a break or did I lose connectivity?
All the best.
jfc

---

From: Markus Hofmann <[email-masked]>
Date: Mon, 29 Nov 2004 21:44:55 -0500

> Is there a break or did I lose connectivity?

The former.

Martin and Abbie are getting started on the SMTP Use Cases draft and 
will share first results soon. (In parallel, we're trying to find some 
shared collaboration space for our documents). This is a DECEMBER 
deliverable, so we really need to get this going!

Our new charter also lists "Revised document on OPES rules language" 
as a November deliverable. (Funny that charter approvals their time, 
but deadliens are never adjusted accordingly...). Alex - does it make 
sense to submit an updated document on "P" to IESG and use this as a 
starting point?

Tony suggested that we take another close look at 'sieve', now that 
there's a WG looking at sieve extensions. Maybe there's an opportunity 
to worj tjrough sieve extensions?

-Markus

---

From: "Alex Rousskov" <[email-masked]>
Date: Tue, 30 Nov 2004 09:33:13 -0700

On Mon, 2004/11/29 (MST), <[email-masked]> wrote:

> Our new charter also lists "Revised document on OPES rules language" as  
> a November deliverable. (Funny that charter approvals their time, but  
> deadliens are never adjusted accordingly...). Alex - does it make sense  
> to submit an updated document on "P" to IESG and use this as a starting  
> point?
>

My understanding is that my "Sieve versus P comparison" resulted in a  
consensus that we cannot use Sieve "as is", but have to learn their  
lessons (including trying to be no more complex than Sieve).  
Unfortunately, the comparison missed a couple of important extensions such  
as Sieve variables. Those extensions may now get into Sieve Core (also a  
lesson for us -- variables are needed as a core primitive).

I am not sure what to do at this point: I can post P draft and start  
working on fixing known issues, with others help. It will take a few  
iterations before P Core can be submitted to IESG, IMO. Alternatively, we  
can re-open the discussion on whether we can extend Sieve enough so that  
it accomodates OPES needs for HTTP and SMTP adaptations, at least. I am  
happy to work on P, but I need an "official" go-ahead from the WG to avoid  
wasting time on a new language the group is not interested in.

How do we proceed?

Thanks,

Alex.

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Tue, 30 Nov 2004 13:41:36 -0700

I thought the sieve extensions were promising, and I couldn't
see any obvious reason not to adopt them.  Perhaps our use
cases will help us decide?

Hilarie

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 30 Nov 2004 17:17:27 -0500

Alex Rousskov wrote:

> iterations before P Core can be submitted to IESG, IMO. Alternatively, 
> we  can re-open the discussion on whether we can extend Sieve enough so 
> that  it accomodates OPES needs for HTTP and SMTP adaptations, at least. 
> I am  happy to work on P, but I need an "official" go-ahead from the WG 
> to avoid  wasting time on a new language the group is not interested in.
> 
> How do we proceed?

Given that several voices suggested that sieve extensions are 
promising and could meet OPES needs, we should consider again whether 
this is the case or not. This will take additional time, but seems 
important.

I suggest that anyone with an opinion on this topic posts to the list 
either (a) an example of what can *not* easily be done with sieve 
extensions, or (b) describes how sieve extensions would be used to 
meet OPES needs.

-Markus

---

From: jfcm <[email-masked]>
Date: Wed, 01 Dec 2004 01:50:51 +0100

Sorry for this. (a) but better to ask: where can one find the most 
appropriate definition of sieve? (b) should we not first stabilize the list 
of applications?

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?
jfc

At 23:17 30/11/2004, Markus Hofmann wrote:

>Given that several voices suggested that sieve extensions are promising 
>and could meet OPES needs, we should consider again whether this is the 
>case or not. This will take additional time, but seems important.
>
>extensions, or (b) describes how sieve extensions would be used to meet 
>OPES needs.
>
>-Markus
>
>
>