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