Subject: OCP/SMTP, /MAIL, or /MIME profile?

From: Alex Rousskov <[email-masked]>
Date: Mon, 28 Jun 2004 00:17:59 -0600 (MDT)

On Thu, 10 Jun 2004, Markus Hofmann wrote:

> The OCP/SMTP profile item seems pretty clear. Any specific things
> that need to be considered when phrasing a charter item on that?

I am not an SMTP/IMAP/POP/etc expert, unfortunately. Perhaps due to my
lack of in-depth understanding of all these "e-mail" protocols, I
wonder whether a more general "mail" or even MIME profile should be
considered for OCP _instead of_ SMTP profile.

In OCP/HTTP we tried very hard to keep most HTTP-level protocol
interactions away from OCP. For example, OCP/HTTP does not know about
[persistent] HTTP connections. OCP/HTTP works on individual HTTP
messages, leaving the actual HTTP "state" out of scope.

I suspect we can do a similar trick with SMTP. Then, it may be
possible to use the same profile for other protocols that deliver
e-mail or even any MIME messages. Just like OCP/HTTP focuses on an
HTTP message, OCP/MAIL would focus on an e-mail (MIME?) message and
will be applicable to SMTP/IMAP/POP/etc. protocols. We may have to
treat tracing and bypass specially, but that would still be easy.

Are SMTP/IMAP/POP/etc. protocols similar enough from mail adaptation
point of view? Does even more general MIME adaptation make sense?

Note that I am not looking for more work for the WG. I am just trying
do understand whether we can cover more protocols with essentially the
same amount of work if we extend scope from SMTP to other mail
protocols or even to MIME in general.

Thanks,

Alex.

P.S. HTTP messages are almost MIME messages, but there are a few
     important differences that make it difficult to handle an HTTP
     message as just a MIME message. Is that true for SMTP and other
     e-mail protocols? Do they "modify" MIME, each in its own
     special way?

---

From: jfcm <[email-masked]>
Date: Mon, 28 Jun 2004 11:22:45 +0200

Alex,
the work should not only be done for current messaging, but for future 
systems.
There are two things you may want to modify with an OPES:
- the content - and this is protocol transparent
- the addresses. Like changing a name from ascii to chinese.

I am no specialist of SMTP either, but I do not see how you can change the 
address and not resend the mail in a way or another. This is not an OPES 
since the modified data would not come back.

So, apparently you are right, this can only be work on the content.
jfc

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 28 Jun 2004 08:59:54 -0600 (MDT)

> - the addresses. Like changing a name from ascii to chinese.

Agreed. In other words, there is message data (payload/content/etc)
and meta-data (headers/trailers/etc). And, as we have already
established while working on OCP Core, the definition of each and the
boundary between the two are application- and adaptation-specific.
What's content for some may be metadata for others.

> I am no specialist of SMTP either, but I do not see how you can
> change the address and not resend the mail in a way or another. This
> is not an OPES since the modified data would not come back.

Not sure what you mean. My understanding is that an SMTP callout
service can, in theory, change a From: or To: address and everything
will work just fine as long as the corresponding OPES processor (SMTP
server) is capable of handling such a change. Thus, this is still
OPES.

There is a political question of whether this WG can document such
adaptations (they smell like moving towards URI resolution that IAB
does not like), but that's a different question.

> So, apparently you are right, this can only be work on the content.

Things like From/To MIME headers are probably common among all
MIME-based mail protocols. Things like transport connections and
authentication are probably different among those protocols. The
question is whether the common subset is large and autonomous enough to
be adapted without regard to uncommon protocol-specific things.

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Mon, 28 Jun 2004 21:42:50 -0400

> considered for OCP _instead of_ SMTP profile.

Certainly worthwhile to consider, although I'm *not* an email expert 
to tell whether something like that is feasible.

A few folks expressed interest in having support for SMTP - is SMTP 
the only protocol of interest, or is there also a practical need for 
IMAP/POP? Does anyone have specific use cases in mind?

Similar to what we did in the first charter, we can make SMTP the 
prime goal which we'll have to provide a solution for, but we can 
first explore the feasibility of a general "email/MIME" profile (and 
maybe include an explicit charter item for such exploration). Making a 
rash decision now without spending careful thoughts migth backfire.

-Markus

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 29 Jun 2004 08:42:10 -0600 (MDT)

On Mon, 28 Jun 2004, Markus Hofmann wrote:

> maybe include an explicit charter item for such exploration).

The above sounds like the right solution to me.

Thank you,

Alex.