[Standards-JIG] Re: Syntax for forwarding messages

Tijl Houtbeckers 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 [8]."
> 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  
for now..

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>
>    </headers>
> </message>

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 mailing list