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