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