I have a few comments.
1) Consistency comment,
section 3.1.1 says:
(S: means sender, R: means recipient):
I think most RFC examples, if not all, use the "S - server, C: - client"
nomenclature. The current usage makes one think too hard :-)
It also says:
The sender is generating commands and the recipient
is generating replies.
This think it should be rephrased:
The client (C:) is issueing SMTP commands and the
server (S:) is generating responses.
and rephrase the reminding paragraph accordingly.
2) General Comment
While I think it is nice to describe specific 'examples' on how OPES may be
used in SMTP, I think the more important consideration is the interface
considerations.
The sky is the limit on how people will hook into external envelope (2821) and
payload (2822) analyzers, for example, I can cite off hand maybe 3-4
additional usages, but it all apply in the same way.
Generically, from a marketing standpoint, one can simply say that OPES can be
uses for:
- CRM applications
- Help Desk/Support Application
- AVS applications
etc, etc.
But what is common among all, is how the input and output will be done and what
will be other possible technical considerations such as the one we discussed
here in regards to SMTP timeouts. This what would be important to me.
For example, this document can outline and summarized what are the process
environment variables:
CIP - Connection IP address
CDN - Client Domain Name (issued at HELO/EHLO)
RP - Return Path (issued at MAIL FROM)
FP - Forwarding Path (issued at RCPT TO)
PL - Payload (issed at DATA)
Those are the variables for SMTP. So we can model the SMTP OPES usage as as a
function of one or more of these variables:
response = OPES(CIP, CDN, RP, FP, PL)
We have in place a similar model we call EPV (End Point Validation) which are
"hooks" applied at each state:
connect: response = EPV-CONNET(CIP)
EHLO/HELO: response = EPV-HELO(CIP,CDN)
MAIL FROM: response = EPV-MFROM(CIP,CDN,RP)
RCPT TO: response = EPV-RCPT(CIP,CDN,RP,FP)
DATA: response = EPV-DATA(CIP,CDN,RP,FP,PL)
You also have other considerations such as POST SMTP OPES usages. The above can
be considered as dynamic SMTP OPES usages. But we also have the possibility
where OPES can be used in post SMTP operations.
I understand that this might be too detailed for what you were looking for
here, but seeing how it fits from a functional model standpoint will make life
easier for many implementations who will want to see how to apply OPES in SMTP
generically.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
---- Original Message -----
From: "Martin Stecher" <martin(_dot_)stecher(_at_)webwasher(_dot_)com>
To: "OPES WG (E-Mail)" <ietf-openproxy(_at_)imc(_dot_)org>
Sent: Saturday, June 18, 2005 5:09 PM
Subject: draft-ietf-opes-smtp-use-cases-01
Hi,
you have seen that we have published a new version of the use cases draft.
Taking the feedback from the IETF meeting, I stopped classifying the use
cases into groups.
The introduction is still pretty similar to the -00 version. But the main
part is now a collection of some specific use cases with a more detailed
description what they do and what they require.
No more details about how OCP/SMTP could look like.
Please have a look and comment.
I guess we would like to get this milestone done asap. Your feedback is
needed.
If you prefer to read the HTML version of the draft, you'll find one on my
private OPES page.
http://www.martin-stecher.de/opes/
(http://www.martin-stecher.de/opes/smtp-usecases.html)
Regards
Martin