Re: [draft-ietf-opes-smtp-use-cases-01]

Dear Abbie,
I started reading the draft in detail. I am not sure that the organized 
case description includes all the proposed schemes, but it seems to follow 
a good logic (I am not sure however that the contents are so well 
supported? All the more with what Martin says in his last mail - do you 
mean you will pass all the texts to the OPES without filtering them fist?). 
I will try to list all the cases we listed and those I can think of and see 
if they match the cases. But obviously the critical need to trigger the 
routing is not taken care of (I want to prevent mails to cross some MTA 
where the data could be copied) as I am not sure MAIL TO are supported (I 
have not yet tried to read the SMTP RFCs).
Right now I am quite concerned by the wording and the drafts. I read that 
the idea is that the OPES _is_ an MTA? Also there is no interaction between 
MTAs (or I misread the part on "previous" commands, which should be read 
with a wider meaning?).
If I note UA as U, MTA ad M, MSA as S, MDA as D, Filters as F and OPES as 
O, here is the scheme I understand:

                                         O1------O2------O3-----O4     O5 
-------|
                                         |       |       |       |     | 
      |
U1- F --- F - S - F - M - F - D - F ---- F - S - F - M - F - D - F --- F - 
U2    |
    |     |       |       |       | 
|                                            |
    |     |       |       |       | ---- F - S - F - M - F - D - F --- F - 
U3    |
    |     |       |       |       |      |       |       |       |     | 
      |
    O6    O7      O8      O9     O10     O11     O12     O13     O14   O15 
      |
          |<------|-------|-------| 
|-------------------------------|
OPES are following the path starting from where they filtered or modified 
mails are to be resubmitted as for O7-O10 - we can have loops. Also, there 
are certainly some impact of the OPES of an MTA are related (O1-O5) or not 
as (O11-O15). Or making a network (for example O5 and O12) or not.
There are certainly good reasons to reduce that schema?

I also have some concern about the part 6 being quite terse about a huge 
problem of end to end interoperability. If I send a mail to two persons to 
interact based on that mail, if they do not receive the same data, this 
creates many problems of responsibility hence of authority. I feel there is 
a general problem when scaling from end-to-end (we abandon here) to 
brain-to-brains (what counts is what the whole systems manages to convey) 
interinteligibility requires a common authority (authoritative reference).
Let say that American U1 sends a mail telling the other two Us "go to 
Rome". OPES translates on the path to "Nacht Rom" for German U2 and "tire 
du rhum" (fetch some rum) to French U3. There is a mismatch: where is the 
responsibility. Who is authoritative to try to correct the error?
If I compare with the IDNA process. punycode is reversed for verification. 
An IDN is OK if the string transformed in xn-- by punycode and then back 
into ASCII by ToASCII stays the same. Ideally in this case, "fetch some 
rum" not being identical (equal?) to "go to rome", the process  (after an 
acknowledgment using the text) should result in an error being sent to U1 
(this is an usual response) but also to affected collaterals (U2) what is 
not a common behavior?
Also, if a mail is duplicated to another party or not sent to one of the 
destinees, this should be reported. Actually, a feed back with the actual 
delivered text should be returned to the sender (and may be serviced by the 
O6 OPES to collect all the acks and report on the situation as OK or with a 
detail of the actions taken?
In the same line, I suppose we need a WILCO process (authoritative 
acknowledgment) because an OPES may make a mail unreadable to the destinee. 
end to end delivery acknowledgement is not enough. We need a wilco one 
layer above.
Question: such a return traffic would be high. Could we just return patches 
from diffs (OPES I/O differences) when the OPES is trusted?
jfc