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".
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 draft.
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 ietf-openproxy(_at_)imc(_dot_)org(_dot_)
The meeting adjourned at 19:45.