Re: Status Update

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:


>Alex Rousskov wrote:
>
>>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?
>
>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
>
>
>