On Mar 4, 2011, at 01:19 , Eric Cestari wrote:

> Hi everyone,
> 
> I spent some time recently implementing XEP-280 on ejabberd, and I'd like to 
> give you feedback about it.
> The implementation was quite straightforward. It's a module with a hook on 
> filter_message, with a mnesia backend storing jid => enabled resources in a 
> bag.
> 
> However I do have questions, as my code diverged a bit from the XEP – for 
> practical reasons.
> 
> 1.  Enabling Carbons
> <iq type='set' id='enable1'>
>  <carbons var='urn:xmpp:carbons:0' mode='enable'/>
> </iq>
> Wouldn't the 'var' attribute better be an 'xmlns' ?
> I did make the change to xmlns, so that I could leverage the IQ management 
> libraries in ejabberd and in StropheJS
> 

The xmlns "attribute" is necessary; it puts the "carbons" element within the 
"urn:xmpp:carbons"0" namespace.  Otherwise, "carbons" is in the "jabber:client" 
namespace, and would break schema.

> 2. 'to' and 'from'
> The fact that the CC'd messages do not match the true sender and recipient 
> is, indeed, unprecedented. Implementing the XEP in ejabberd will not work 
> unless one modifies the router code. Which I chose not to do for my naive 
> implementation. I did the following modification:
> 
> <message
>    to='[email protected]/orchard'
>    from='[email protected]'
>    type='chat'>
>  <body>Neither, fair saint, if either thee dislike.</body>
>  <thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
>  <sent to='[email protected]/balcony' from='[email protected]/home' 
> xmlns='urn:xmpp:carbons:0'/>
> </message>
> 
> from is bare JID of the user
> to is full JID.
> Original to/from information in the sent element.
> Has this solution been considered ?
> 

That is an interesting approach.  I know I was wondering if the addressing 
rules in the spec might cause problems, and it looks like it is for at least 
one implementation.  I'll think about this some more.

> 3. error messages
> I did not find any mentions in the XEP about messages of type chat with an 
> error element. Should they be CC'd ?
> I decided against that, and my implementation will not copy messages of type 
> chat if they contain a private, error or sent element.

The <error/> element should only be present for <message type='error'/>, and 
not for any other type of <message/>.  If you're finding this, then you should 
file bug reports to those implementations.


- m&m

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to