ietf-smtp
[Top] [All Lists]

Re: Edited Mail and Resent Headers

2010-05-21 19:32:51

Peter J. Holzer wrote:

On 2010-05-20 16:08:35 -0400, Hector Santos wrote:
The issue is based on the growing or rebirth of FORUMS that are gated by NNTP and exposed as newsgroups and the online software allow uses to correct/alter their mail (at any time), and the implementation does not create a new "message id" that would transforms to a new export by the NNTP gateway.

So I was thinking that maybe it (Resent-*) could be used here. It doesn't since the specs "implies" the old Message-ID remains the same and the Resent-Message-ID get the new one.

The old X.400 "Supersedes" was considered as a possibility to handle it but I am now considering a new proposal that addresses authenticated backend/mua interfacing, less than an IMAP but more than we have now for NNTP/POP3.

I don't know why you throw NNTP and POP3 together. They have rather
different models.


Both use a "Message Index/Number" concept in the listing and both use a GET by number concept.

Anyway, I assume that by "online edited mail" you mean a new version of
a forum/news article which should replace the old version. This is what
the "Supersedes" header is for: The new message gets a new message-ids
(In NNTP message-ids need to be unique - a new message which matches an
existing message-id simply won't be propagated because every newsserver
will assume that it already has the message) and reference the old
message in the Supersedes header. Servers and/or clients are supposed to
remove/hide superseded messages.


Right, keep in mind that the backend is not RFC 5322 ready. So there is a transformation process.

The backend has its own "Message ID" construct and this is currently used for the transformation:

    5322.Message-ID  <--- backend.Message.ID

The backend offer users the ability to "edit" their messages. In this implementation, the backend.Message.ID does not change. Its a simple body context replacement concept. The order is maintained, there is no DELETE OLD/CREATE NEW concept.

In this model, a NNTP gateway will not see this edited message message when it joins the group, i.e. the high mark does not change.

Continue below.


I don't see any relation to the Resent-* message headers.


Right. Nix that suggestion.

The overall issue is what suggestion could there be to allow both models to work well.

Of course, its all a function of the backend implementation to allow for this:

  - Keep a concept of same message online editing

  - Be compliant with RFC based mail reading to reflect the
    change.

What you are saying is the backend needs to able to pass (return) information to the gateway two pieces of information:

   backend.Message.ID
   backend.Message.Previous.ID

and the gateway can see this to perform the transformation:

   5322.Message-ID = backend.Message.ID;
   if (backend.Message.Previous.ID != 0) {
       5322.Supersedes = backend.Message.Previous.ID;
   }

Again, obviously an implementation issue, but the online system will use a persistent backend.Message.ID, so probably it needs:

   backend.Message.ID
   backend.Message.RFC.ID   ; generated for edits only

where backend.Message.RFC.ID is only pertinent for gateways. Now the transformation would be:

   5322.Message-ID = backend.Message.ID;
   if (backend.Message.RFC.ID != 0) {
       5322.Message-ID = backend.Message.RFC.ID;
       5322.Supersedes = backend.Message.ID;
   }

See the difference?

Overall, I am trying to see if there is a general model here that I can put on paper (and I-D) which offers backend vendors a simple way to maintain their desire for online editing of mail and still offer a way to interface with the traditional offline RFC based mail clients.

--
Sincerely

Hector Santos
http://www.santronics.com

<Prev in Thread] Current Thread [Next in Thread>