Subject: Re: Which SMTP element?

From: Markus Hofmann <[email-masked]>
Date: Wed, 14 Jul 2004 10:46:27 -0400

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...

-Markus

---

From: jfcm <[email-masked]>
Date: Wed, 14 Jul 2004 19:54:05 +0200

At 16:46 14/07/04, Markus Hofmann wrote:
>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

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 15 Jul 2004 01:09:20 -0600 (MDT)

On Wed, 14 Jul 2004, Markus Hofmann wrote:

> 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.
>

If several milestones are highly desirable, we can split SMTP work
into "generic MIME" and "SMTP-specific" sections of the same draft and
then base milestones on those sections.

Moreover, we can add "SMTP command adaptation" section/milestone (as
opposed to SMTP MIME message adaptation), if that is in scope. BTW, is
it?

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 15 Jul 2004 02:05:49 -0600 (MDT)

On Wed, 14 Jul 2004, jfcm wrote:

> - but with their difference : push vs. retrieve, unique vs.
>   multiple, text vs mail, access vs send.

I agree that there are many differences between HTTP and SMTP.  I am
sure that future "SMTP adaptation" draft will be different from the
existing "HTTP adaptation" draft. However, I do not see your point.
Why/How those differences affect the charter? Does the charter somehow
imply that HTTP and SMTP adaptations are the same? Does it imply that
we will simply rename "HTTP adaptations" draft into "SMTP adaptations"
draft and ship it? I do not think so.

> For example:
[snip]

> - we will meet major difficulties in understanding what we will discuss....

The differences between HTTP and SMTP should be taken into account, of
course. In fact, our HTTP work is pretty much irrelevant for the SMTP
draft!  Only OCP Core and OPES Communications work is relevant. Why do
you even compare with HTTP?

> make sense to me in a network environment

What exactly does not make sense? The assertion that we can use OCP
Core to facilitate SMTP adaptations? There is not much else in the
current charter, as far as SMTP is concerned!

Are you saying that the charter does not prohibit certain kinds of
SMTP adaptations and it should? If yes, what are those kinds?

Are you saying that the charter does not define certain words related
to SMTP adaptations and it should? If yes, what are those words?

Let's try to drive this debate closer to the charter text. What
exactly is wrong (and how it should be fixed)...

Thank you,

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Thu, 15 Jul 2004 09:27:26 -0400

> then base milestones on those sections.

Given the already narrowed focus, I'd suggest to have a single 
document that fuly describes the SMTP solution, rather than defining a 
generic MIME solution and a seperate document with SMTP specific 
pieces. Let's see what the feedback will be.

> opposed to SMTP MIME message adaptation), if that is in scope. BTW, is

I would consider this part of the SMTP solution. Explicit SMTP use 
cases would help clarifying the scope issue...

-Markus

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 15 Jul 2004 22:47:41 -0600 (MDT)

On Thu, 15 Jul 2004, Markus Hofmann wrote:

> pieces.

I agree. Note that I proposed different sections, not different
documents/drafts.

Alex.