[Standards] [jdev] RFC 3921 message to RFC 5322 message conversion

Dave Cridland dave at cridland.net
Tue Jan 5 15:05:22 UTC 2010

On Tue Jan  5 13:14:14 2010, Tomasz Sterna wrote:
> Dnia 2010-01-05, wto o godzinie 12:30 +0000, Dave Cridland pisze:
> > > 1. How do i store 'from' and 'to' fields of the XMPP message?
> > >
> > 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.
> Well... I _do_ have an e-mail<->jabber gateway, so I could convert  
> to
> the gateway compatible form: user%email.srv at email.jabber.srv
> It has the advantage that replying to such message using MUA would  
> work.
> But I am also thinking about the case when MUA gets XMPP support
> eventually, and would be able to:
> a) answer the message directly over XMPP
> b) show the 'from' contact status (if subscribed)
> These use-cases would suggest another header fields for the e-mail
> message to make this information available easily.
Right - my scenario was to allow the IMAP SEARCH, SORT, and THREAD  
commands to be used to provide online access and search facilities,  
like a XEP-0136, but with a "real" message store doing the heavy  

So I'm seeing the case of an XMPP client that gets IMAP support,  

> > > 3. <thread/> converts directly to References:
> > 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.
> Right. I misunderstood RFC 5322 on this.
> This makes building IMAP THREAD hard. :-(

You could make it easier, I think, by making the first message id of  
a given thread equal to the <thread/>. Then you can  just count the  
numbers of matching messages with:

<tag> SEARCH RETURN (COUNT) HEADER References <thread value>

And then assign each new message in the thread a <thread/>-<count>  
style mid.

Obviously these would all have a domain.

> > > 4. Should I generate Message-ID header? If so, how? Maybe it  
> would
> >
> > 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.
> What makes it even trickier, is that it gets lost on the SMTP/XMPP
> boundary. So I'm beginning to doubt it's worth synthesizing.

Certainly does, if you're attempting gatewaying, but again, I don't  
think it matters. Message-ID is a SHOULD, and if you want threading  
to work at all, it's really a MUST in all but name.

> > 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
> Good idea. I like it very much. :-)

Mind you, PSA pointed out that the media type already exists, plus  
the address transform. Should make the specification a bit easier. :-)

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list