[Standards] [jdev] RFC 3921 message to RFC 5322 message conversion
dave at cridland.net
Tue Jan 5 12:30:33 UTC 2010
On Tue Jan 5 10:02:42 2010, Tomasz Sterna wrote:
> I am working on accessing jabber message archive with IMAP and a
> 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
> to be in SMTP domain. ":" is used to delimiter group names so we
> use XMPP URI there.
> - Should I add X- header for preserving XMPP 'from' field? What
> - 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
> 4. Should I generate Message-ID header? If so, how? Maybe it would
> 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 Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards