[Standards-JIG] Re: Syntax for forwarding messages
thoutbeckers at splendo.com
Thu Jan 20 19:17:01 UTC 2005
On Thu, 20 Jan 2005 19:50:47 +0200, Stephen Marquard <scm at marquard.net>
> Looks reasonable. I have 2 questions:
> 1. Where JEP-0131 says:
> "3.1 Protocol Support. In order to discover whether another entity
> supports this protocol, an entity MUST use Service Discovery ."
> does that mean that it's mandatory to discovery whether another entity
> supports the protocol before using, or just that should one wish to
> discover whether another entity supports the protocol, one must use
> service discovery to do so?
Well, that's what it would mean. I don't know why it's in there really.
You're just attaching some meta data really. I wouldn't even disco at all
for it, if it was just some simple tagging (like X-No-Archive). If you
want to prevent forwarding loops, it could be benifical to check if the
entity support it, but even if it doesn't you could still just attach the
SHIM headers. (Any decent jabber based forwarding mechanism would forward
the entire message, including all attachted stanzas).
Dunno for what reason it was choosen to include this rule in the JEP, but
I think changing it to MAY or SHOULD won't raise much objections. In
contrast, for working correctly with JEP-0033, it's almost a MUST to disco
if you want to work properly in the first place.
I use both JEPs in my project to integrate James (the SMTP server of the
apache project: http://james.apache.org), I which I replace the SMTP
backend with an XMPP backend. Depending on how you configure this, it's
optional, the server can Disco the address to see if it exists in the
Jabber world and fall back on SMTP (you could also put info on that in
your disco profile, for example messages with attachments use SMTP, other
XMPP, use an alternate XMPP address, etc). Since I disco some stuff
already I also look for JEP-0033 to decide how to multicast the messages.
I don't look at SHIM even if it's there, I think it's important to send
the meta data even if the client doesn't support it.
Previously I was thinking of stuff like archiving for which this could be
benificial, but it's good for this too.
> If a server is going to forward a message on to another user on another
> server, it doesn't seem reasonable to have to decide whether the other
> entity supports the protocol before adding forwarding info.
> 2. For a header that's mentioned in JEP-0131 and defined by RFC 2822, is
> it understood that the value is an email address or can a JID be used ?
> Should a prefix be specified, e.g. xmpp:user at server/resource ?
Well, I doubt the RFC "allows" that, but I just map them 1 to 1. I don't
use any prefixes. I should probably strip the resource part though, and
there are problems with characters that are allowed in a JID but not in an
email address. It's stuff like this that keeps me from releasing any code
But I think we shouldn't use prefixes, as long as it's on the XMPP
network, XMPP rules will apply. When it goes onto the SMTP network some
translation might be done, but it should be transparant for your
forwarding mechanism if the address originated from XMPP, SMTP, SIP,
whatever. (Of course you might still have different forwarding rules based
on other tags or other stanzas)
> So if A sends a message to B, who has an autoforward to C, who has an
> autoforward to D, then the message as it arrives at D could look like:
> <message from='c at server3'
> to='d at server4'>
> <body>A well-travelled message</body>
> <headers xmlns='http://jabber.org/protocol/shim'>
> <header name='resent-from'>b at server2</header>
> <header name='resent-date'>Thu, 20 Jan 2005 17:42:49 +0200</header>
> <header name='resent-from'>a at server1</header>
> <header name='resent-date'>Thu, 20 Jan 2005 17:42:47 +0200</header>
> <header name='reply-to'>a at server1</header>
If you receive a message with a reply-to set, it's likely that it will use
JEP-0033. (So you'll just forward that as well). In my component I also
map these email headers (to, from, cc, bcc, reply-to etc) to JEP-33. If
you add these yourself in your forwarding mechanism, you should probably
also use JEP-003.
For the rest, there's the timestamp issue, for Jabber we have
http://www.jabber.org/jeps/jep-0082.html. Since we're not following RFC
2822 exactly anyway (using JIDs instead of email addresses for example) it
might be acceptable to just use Jabber Timestamps instead. (Any gateway
would be responsible for translating them). I wouldn't mind hearing
other's opinions on this one though..
More information about the Standards