On Tue Jan 5 10:02:42 2010, Tomasz Sterna wrote:
Hello.
I am working on accessing jabber message archive with IMAP and a
normal
MUA with IMAP backend.
Excellent. I know that Alexey Melnikov is interested in that, as am I.
This begs a question: How do I convert RFC 3921 message, to RFC 5322
message to store in IMAP store. (But it may also be useful for
Jabber/E-Mail gateway.)
I had some thoughts on this. The trickiest part is that the form of
an XMPP address differs radically from that of an email address,
although superficially both look identical.
1. How do i store 'from' and 'to' fields of the XMPP message?
RFC 5322 defines From: as mailbox-list and To: as address-list
which in
turn reduces to addr-spec which does not include schema and is
assumed
to be in SMTP domain. ":" is used to delimiter group names so we
cannot
use XMPP URI there.
- Should I add X- header for preserving XMPP 'from' field? What
exact?
- Should I fill From: and To: fields to maka maile readers usable?
I'd opt for a simple tranformation of the address into an email
compatible form. Alexey may have some good advice here, as he's been
heavily involved in EAI. Pete Resnick, who edited RFC 5322, may also
have some good ideas, and he's familiar with XMPP, having co-chaired
the original XMPP WG.
2. Subject: header is straightforward
Mostly - it needs encoding, obviously.
3. <thread/> converts directly to References:
- what if there is no <thread/>? Should I supplement it? How?
I'm not sure thread *does* convert, given that thread is a single
string for all messages within a thread, whereas References is a list
of message ids. If you want things to look sane with, say, the IMAP
THREAD extension, you'll need to refer to other messages here in the
right order.
4. Should I generate Message-ID header? If so, how? Maybe it would
be
useful to base it on some of the message characteristics?
You could synthesize it, yes - which'd also solve the <thread/>
issue. I'm not even sure it needs to be consistently synthesized -
that is, given the same input, different implementations could
generate different mids.
For preservation of the original, I'd be inclined to use
multipart/alternative, with text/plain, possibly text/html (for
XHTML-IM), and a new application/xmpp-msg+xml type to contain the
original message stanza in full. It's much, much simpler than trying
to encode it elsewhere.
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
