[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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