Subject: RE: Response modification

From: "Martin Stecher" <[email-masked]>
Date: Sat, 22 Jan 2005 21:09:22 +0100

> 
> 
> OPES is supposed to enable new services.

Absolutely.

> 
> The call-forward wouldn't have been a hack if it had been done as
> part of an OPES service, using the same architectural model that
> we used for HTTP. 

I fully agree.

> Further, we rule out a large number of useful
> identity-based services by eliminating the ability to do
> response modification.  

Here I disagree.

Tonny describes again a use case that we've listed already last year.
See sample 2-2 on http://www.martin-stecher.de/opes/smtpusecases.html
No doubt that it is a very important one.
This and other examples of group 2 are the "useful identity-based services"
you are referring to, aren't they?
And these are all request satisfaction examples, not response modification.

Again: Response modification is only useful if the callout service makes
use of the original response data, which in SMTP is the SMTP reply.

The only service I can think of, that does this, is a logging service.
Is that one strong enough to have response modification in the SMTP deployment?
Or can you please describe another important service that makes use of
the response and modifies it?

Regards
Martin

---

From: jfcm <[email-masked]>
Date: Sun, 23 Jan 2005 00:58:18 +0100

I am sorry, I really have a problem following all this discussion and I 
feel I have no idea of what is really discussed.

My understanding was that:

- we make a list of cases. 
http://www.martin-stecher.de/opes/smtpusecases.html and keep adding to it 
each case we would indentify as not covered
- we would discuss the best OPES architecture able to address them
- in testing the propositions against each of these cases.

I expected that in this process we would discover new services we could 
enable this way, and at the same time to simplify the architecture to be used.

Today I feel (but I may be wrong) that we are sorting and filtering case 
concepts (not real cases) along sorting and filtering concept corresponding 
to a solution approach. I do not object that this may not be right and 
brillant, but I am lost and cannot commit.

Now, I must confess that I am not interested in SMTP as such. I am 
interested in real store and forward cases serviced by OPES over real life 
MTAs, SMTP being part of their support, may be this is why I am 
lost?  Also, I am definitly interested in operational, legal local 
constraints, as something a solution must support (and may be should we 
list them all, as Hector is probably not the only one having some needs in 
that area ? I listed at least one myself [to make sure mail would never 
cross machines of a given domain/country]. But this should not be used to 
limitate the architectural specifications.

If I am out of context, I apologize.
jfc

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Sun, 23 Jan 2005 00:01:43 -0700

>  the response and modifies it?

When the response comes back indicating that there's a problem with
the recipient name, the OPES processor sends that to the callout
server, and at that time, the callout server can pick an alternative
method for finding the recipient.  This seems obvious to me ...
I'm not sure why it seems obscure to others.  I wrote a white paper
for Novell several years ago about "global identities" that used this
method for resolving delivery addresses.

Hilarie