Subject: RE: Last Call: draft-ietf-opes-smtp-security (Integrity, privacy and security in OPES for SMTP) to Informational RFC

From: "Stecher,Martin" <[email-masked]>
Date: Thu, 11 Jan 2007 15:20:03 +0100

> 
> I never got the OPES idea.  Of course folks can do their A/V 
> and SIEVE and SIQ (I-D.irtf-asrg-iar-howe-siq-03) businesss 
> on a separate box, they can even outsource it, but they do 
> this already without OPES.
> So what's the technical point of OPES wrt mail ?
> 

OPES' technical point is to have an application agnostic core
call-out protocol (OCP) that is being enhanced by protocol specific
adaptations (OCP profiles).
Other profiles could be defined that describe how to work with
certain data files (such as a MIME file) without any specific protocol.

This will allow to create such a separate filter box that you mentioned
but have it negotiate with different proxies and gateways what kind of
protocol/data it can handle.
Today a protocol such as ICAP is hacked and misued to work with other
protocols than HTTP.

Martin

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Dave Crocker <[email-masked]>
Date: Thu, 11 Jan 2007 13:57:10 -0800

Stechter,

Thanks for the followup.

> protocol/data it can handle.

Given what you say at the end of this sentence, I assume this is for the purpose 
of adaptation, for example to permit data to travel through proxies and gateways 
that can support the correct set.

As has been clear for some time, the OPES topic is both important and difficult. 
  That sort of combination always makes want to look for some history of 
exerience with ways to solve the current problem.

In the case of OPES, I do not know of a qualifying history, nor do I see the 
effort to build something based on such experience.

In any event, I am still not understanding how something like this SMTP draft 
can say much that is of use, absent a meaningful OPES architecture specification 
and, preferably, protocol specifications.

If the current document is intended as a case analysis for a particular 
application -- namely email -- to serve as *input* to the design of the OPES 
architecture and protocols, then I do not see how the current document achieves 
that.

> Today a protocol such as ICAP is hacked and misued to work with other

As you decsribe it, this sounds more like the challenge of adapting a protocol 
at one layer to different types of transport at the layer below.  How is that an 
OPES task?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Tony Finch <[email-masked]>
Date: Fri, 12 Jan 2007 00:53:52 +0000

On Thu, 11 Jan 2007, Dave Crocker wrote:
>
> As has been clear for some time, the OPES topic is both important and
> difficult.  That sort of combination always makes want to look for some
> history of exerience with ways to solve the current problem. In the case
> of OPES, I do not know of a qualifying history, nor do I see the effort
> to build something based on such experience.

The closest history I can think of is the sendmail milter interface, and
the clamav and spamassasin interfaces. All of these are implementation-
specific: the Milter interface is exported as an API, not a protocol, and
the other two are essentially application-internal interfaces. Milters are
closest to what OPES is trying to do, but AFIK not quite as ambitious:
geared for content *filtering* not *adaptation*. So I agree that OPES
doesn't seem to be based on any well-developed experience.

> architecture and protocols, then I do not see how the current document
> achieves that.

I believe it's intended to fit the existing OPES architecture to SMTP.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FAEROES: WESTERLY BECOMING CYCLONIC 7 TO SEVERE GALE 9, PERHAPS STORM 10
LATER. VERY HIGH. RAIN OR SHOWERS. MODERATE OR GOOD.

---

From: Markus Hofmann <[email-masked]>
Date: Thu, 11 Jan 2007 21:01:49 -0500

> I believe it's intended to fit the existing OPES architecture to SMTP.

The original charter of OPES focused on services operating on HTTP 
messages. OPES was then re-chartered to add support for services 
operating on SMTP.

In a first step, the WG discussed how the SMTP work would have to 
address the IAB considerations for OPES [RFC 3238]. The draft 
(draft-ietf-opes-smtp-security) summarizes the results of these discussions.

Since there's a lack of interest (i.e. not a sufficient number of active 
contributors) we decided *not* to move forward with the SMTP work and to 
dissolve the WG.

The intend of publishing this document before dissolving the WG is to 
have the discussion on how the IAB considerations apply to OPES/SMTP 
written down, in case individual contributors might pick-up the 
OPES/SMTP work later on (although we don't have indication this might 
happen).

Thanks,
   Markus

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 12 Jan 2007 03:32:06 +0100

> OPES/SMTP work later on (although we don't have indication this might

Thanks for info, I didn't know that.  For that purpose the I-D is fine.

Frank

---

From: Dave Crocker <[email-masked]>
Date: Sat, 13 Jan 2007 11:30:34 -0800

> OPES/SMTP work later on (although we don't have indication this might 

Markus,

Thank you.  This is extremely helpful.

I suggest that the document have something like your above text added to the 
Introduction.

d/
-- 

   Dave Crocker

---

From: Markus Hofmann <[email-masked]>
Date: Sat, 13 Jan 2007 16:23:32 -0500

Dave,

> I suggest that the document have something like your above text added to 
> the Introduction.

Agreed, good suggestion. We'll add some words in.

Thanks,
   Markus