Making Progress on OCP/SMTP Work Item

Folks,

as agreed upon in Vancouver, we now must focus on the "tracing" and 
"bypass" issue in order to make progress on the OCP/SMTP work item.

We must get consensus on what "tracing" and "bypass" means in the email 
context. E.g., do the IAB considerations on tracing/bypass apply 
unmodified to email or are there reasons to consider them differently? 
How would one trace/bypass in the email world?

In order to get a discussion going, let me repeat from an earlier email 
from Martin.

===== email from Martin from 10/26/2005 ====

In former drafts we concentrated on classic 
client-sends-request-to-server-which-replies-with-a-response
environments. Here and there, we have indications that other application 
protocols exist, for example: RFC3914: "Moreover, some application 
protocols may not have explicit responses..."

In SMTP tracing information for the email recipient is trivial. But
reliable notifications for the email sender are a problem (a general
problem with SMTP not only for OPES). How does that correspond to the 
IAB considerations? What do you think about DSN (RFC1891) and Message 
Tracking (RFC3885) to build on for OPES/SMTP?

Bypass is the other way arround. OPES bypass is usually client 
controlled. Does that mean email recipient controlled? It is hard to 
check the client's bypass requests in a sender centric OPES system.
What do you think about the bypass section in draft-ietf-opes-smtp-00?
Does that work or do we need an out-of-band solution?


===== end email from Martin =====

Any thoughts? We must make progress on this front, first.

Thanks,
   Markus