ietf-openproxy
[Top] [All Lists]

Re: Status Update

2004-11-30 17:51:10

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





<Prev in Thread] Current Thread [Next in Thread>