Re: WG Last Call: draft-ietf-opes-smtp-use-cases-02.txt

On 7/6/05, Markus Hofmann <[email protected]> wrote:
> Tony already provided (editorial) comments and will provide more small
> nits in separate email, which can be addresses without having to go
> through another WGLC. The suggestion is for Martin to incorporate
> Tony's comments in an updated version. Unless there are other
> comments, we'll then submit this updated version to IESG after WGLC
> closes.

>>
   SMTP is a store and forward protocol.  Current email filtering
   systems either operate at SMTP time or they operate on messages after
   reception either on the MTA's queue or by being handed from the MTA
   to a mail filter and back again.
<<

I'm not sure I understand the "handed from the MTA to a mail filter
and back again" message filters might take place at a variety of times
after reception by the MTA, and not all of them require being "handed
back again"

I suggest rewording as:

...either operate during the SMTP exchange or on messages that have
already been received, after the SMTP connection has been closed (for
example, in an MTA's queue).

>>

--
Most of section [3] seems like it could be removed and replaced with a
reference to draft-crocker-email-arch, which has put a lot of care
into addressing these issues.

Instead, this document should focus on just where OPES would be
inserted into the existing architechure
--

Section 1 states:

>>
   This work focuses on SMTP based services that want to modify command
   values and those that want to block commands by defining an error
   response that the MTA should send in response to the response it
   received.  OPES MTA will be involved in SMTP command modification and
   command satisfaction, analog to request modification and request
   satisfaction from HTTP [9].
<<

However, (and I'm probably missing it) I don't see anywhere that SMTP
commands are modified in any of the use cases (unless you mean the
payload of a DATA command).  What I do see (in terms of results of the
exchange) are:

a) Modification of the DATA payload
b) Returning an appropriate *response* to a command.
c) Returning metadata (e.g. directory information -- use case 4.7)
d) No return value (e.g. logging only)

Am I missing the case where actual commands are modified?  If not,
then we should reword this paragraph to indicate that these use cases
are only interested in modifying the DATA payload.

-Rob

-- 
Rob Siemborski        |     PGP:0x5CE32FCC    |     [email protected]
Software Engineer     |                       |            650-623-6925