OPES Working Group
Chairs: Tony Hansen and Markus Hofmann
Meeting started at 19:00, November 8, 2005.
Agenda overview. No issues.
Review of existing RFCs. The internet draft smtp-use-cases draft has been
updated to address required revisions and will be resubmitted.
Milestones review. Because it has languished with no one willing to work
on it, the rules language milestones are being removed from the charter.
This has been submitted to the IESG. The IESG has not approved this yet,
but this will be on the agenda of the next telechat.
Paul Knight did a presentation entitled "SMTP adaptation with OPES",
authored by Martin Stecher and Clemenss Perz, about the draft authored
by the same people. This started with a quick review of OPES services
and how this work relates to the charter of the working group. He
explained that the HTTP profile and the OCP core are completed RFCs,
and that the SMTP profile is the area now being focused on.
Tracing and bypass were called out as issues that need to be addressed
in the SMTP profile. Paul showed a diagram showing a typical message
path, with an MUA --> MSA --> MTA --> MTA --> MTA --> MDA --> MUA. The
diagram indicated that the OCP/SMTP callout to a callout server would
happen at the MTA points in the message path. Blake Ramsdell pointed
out that the other points in the chain could be reasonable places to
use the OCP/SMTP callout also. John Leslie pointed out that the MSA
operates on SMTP, so logically it seems that OCP/SMTP would be reasonable
to apply at that point, and that the MDA to MUA protocol is not SMTP,
so it is not likely to be useful. The WG chairs concurred. [N.B. The
MSA will use either SMTP, Submit (which is a restricted SMTP), or a
non-SMTP-based protocol. The first two could be subject to OCP/SMTP.]
John Leslie pointed out that the example OPES-* headers in the example
provided by Paul were not before the Received header for the MTA.
Philip Guenther pointed out that one of the OPES-System simply needed
to be reordered before the bottom Received header. The relevance of
this is that the ordering of the headers is important in order to show
which MTA applied the headers, which seems to be an issue that needs
to be understood. The WG chairs pointed out that doing this also
requires that the definition of "Trace headers" as defined by 2821/2822
be expanded to include the OPES-* trace headers.
Paul covered tracing and notifications to "the sender", and John pointed
out that the "sender of the message" is somewhat ambiguous (MAIL FROM,
Sender, Reply-To, etc. etc.) The WG chairs indicated that the WG needs
to explore the meaning following the spirit of the IAB considerations.
Ted Hardie pointed out that the semantic of sender is "TBD", but that
following the spirit of the IAB considersions it should most likely be
interpreted as "the creator of content" (just as in the HTTP case, for
which the IAB considerations were written). Barry Leiba pointed out that
Joe-jobs are another potential concern.
The WG charis pointed out a concern that "bypass" in the context of SMTP
is problematic. The essence is that "bypass" means that the sender and
recipient have the ability to opt-out. So how should this be enforced?
Paul pointed out that you do not have an option to bypass virus scanning
services, for instance. The WG chairs indicated that the WG needs to
determine how the IAB considerations apply to the SMTP case and that early
dialog with the authors of the IAB considerations would be helpful to
ensure the WG is on the right track.
Paul continued speaking about bypass issues, as there is some ambiguity
as to what the "sender" or "recipient" in the context of SMTP. Is an MTA
communicating with the next downstream MTA considered to be a "sender"?
Paul indicated that these concerns are already spelled out in the existing
Philip Guenther pointed out that the IAB considerations might not have
considered SMTP as a protocol when coming up with their list of requirements
for OPES, and that push vs. pull models. He suggested that really pushing
the IAB to reconsider their recommendations to consider SMTP-specific
issues might be useful. The WG chair indicated that the original
considerations were written mostly with HTTP in mind, but that a dialog
with the IAB about SMTP could very well be helpful. Philip pointed out
that the tracing is meant to provide a mechanism to indicate "blame" so
you know what intermediate OPES agent to be angry at.
The general way that this is going to proceed is that issues with bypass
and tracing that are hard to deal with between the SMTP profile and the
IAB considerations would be discussed informally with the IAB members.
The theory is that in IESG last call, the IAB will review the document
and there should be no surprises.
The WG chair pointed out that the working group progress on the drafts
needs to have more participation from the SMTP community. If there is no
discussion, then there isn't any real reason to keep the working group
active, and there could be the risk of simply shutting it down.
The mailing list address is email@example.com.
The meeting adjourned at 19:45.