Subject: draft-ietf-opes-smtp-use-cases-01

From: "Martin Stecher" <[email-masked]>
Date: Sat, 18 Jun 2005 23:09:27 +0200

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

---

From: jfcm <[email-masked]>
Date: Sun, 19 Jun 2005 23:44:57 +0200

On 23:09 18/06/2005, Martin Stecher said:
>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.

Thank you for carrying the work!
Sorry to be the unhappy one, but I feel we contributed with many more cases?
I see no content massaging applications?
I am not sure at all this has no security implication? Where to you address 
the end to end issue: if rerouting is not accepted by both end there is an 
obvious security leak?

All the best.
jfc

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 20 Jun 2005 11:00:54 -0400

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

---

From: Markus Hofmann <[email-masked]>
Date: Wed, 29 Jun 2005 22:18:53 -0400

Folks,

there were a few comments on this draft on the list. Martin will take 
these comments into account and publish a new version of the draft by 
next week. As soon as this new version is out, we'll issue WG Last 
Call on the draft, assuming it'll go through smoothly as there don't 
seem to be more comments.

In case you've more comments, please provide them by Friday, 7/1/2005 
on this mailing list, so that Martin could incorporate them in the new 
version. Otherwise we expect to get through WG Last Call quickly.

Thanks,
   Markus