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