Re: Which SMTP element?

At 16:46 14/07/04, Markus Hofmann wrote:
>Martin Stecher wrote:
>>>Moreover, could we try to simplify the charter by removing all other
>>>SMTP agents from it? Can we just hope that OCP/SMTP profile with a
>>>focus on MTAs will be applicable enough to MSAs and MDAs? We can
>>>always add MSA- or MDA-specific features later, right?
>>
>>I second that.
>
>While I agree, where' then back to having a single - albeit more focused - 
>SMTP milestone. Ted's original suggestion was that a singel milestone 
>seems a bit monolithicand that it might be worthwhile to split the SMTP 
>work into multiple milestones.
>Now, with the more focused and narrow SMTP milestone, that might be ok, 
>but if anyone has any suggestions...

I am sorry but IMHO this is not the problem. Could we not take the question 
with some simple logic?

1. We have addressed HTTP, which is a protocol to access and retrieve 
existing unique texts.
2. We know consider SMTP, which is a simple protocol to push mails to a 
group of destinees.

Everyone can deduce from this that there is only one thing in common 
between HTTP and SMTP - it is that both are protocols.
- so the novelty is not with the services of a protocol
- but with their difference : push vs. retrieve, unique vs. multiple, text 
vs mail, access vs send.

For example:

- push vs. retrieve implies different routing and priorities. DNS will only 
provide one IP address to HTTP. Several of them can be used by SMPT with 
priorities. Delays of validity will be substantially different. Also, if I 
call a text and do not retrieve it I notice it. If I send a mail and the 
other do not receive it I do not know it. Also, when I call a text, the 
call will go to the right document and I get it. When I receive a mail 
nothing proves me it was sent by the said origin.

- text vs mail there is a main difference : there are no metada in a mail. 
A text is a permanent document. A mail can be a command.

- unique vs. multiple calls for a very clear definition of what are the end 
participants to an application. What are their privileges. Who the OPES 
must report to. etc. Just a question : what about the location of the OPES. 
What can be changed at a given position not to conflict with the other 
copies. If I send a mail in English to A,B,C. If an OPES changes the 
text/addresses for ABC in Russian is quite different from the case of an 
OPES changing the text/addresses in Russian for B only at the gateway of a 
Russian ISP and C in French at my ISP gateway.

Now, about the protocol.

In both cases there is a protocol and several payloads (header, cookies and 
text in HTTP, header, mail and attachement in SMPT). Is that enough to 
consider the same? I doubt it because an OPES will have less impact

IMHO but as long as these issues have not be taken into account,
- we will be objected that we did not do our home work
- we may conflict with other projects
- we will meet major difficulties in understanding what we will discuss....

Again sorry, I may be totally wrong, but the current charter just does not 
make sense to me in a network environment (it is clearer as a charter for a 
front-end OPES for one single application. This means the OPES is related 
to one edge of the network, and works by receiving/sending end to end pair 
- ex. Markus' analysis that sending a mail to a list is the same as sending 
one mail to each member of the list).

I know end-to-end is the Internet paradigm and Reed/Engelbart/Cerf etc. 
etc. thinking. But OPES are opposing that. OPES are precisely that 
connections are NOT end to end. Content and destination may change. This is 
what I call ONES. HTTP permitted to partly avoid the problem in focusing on 
the way it is used (call, retrieve and applications). SMTP (push, broadcast 
and interapplications) does not permit to avoid the analysis.

jfc