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 protected]
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
lifting.
So I'm seeing the case of an XMPP client that gets IMAP support,
really.
> > 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.
--
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
