[standards-jig] UPDATED: Message Delivery Semantics (JEP-0079)

Matthew A. Miller linuxwolf at outer-planes.no-ip.COM
Thu Jun 26 23:03:54 UTC 2003


I think I now see where you are heading.  Unfortunately, I don't think
you're not going to like the answer.

First, JEP-0079 is designed for use by the sending entity and servers en
route, not recipients.  In other words, a recipient of a
semantics-governed message should never receive the <semantics/>
element(s) (and I realize I need to update to explicitly state this).

Secondly, the server-initiated replies should be going back to the
sending entity (based on the full JID), so it is unlikely the reply
would be misunderstood.  Is it possible that the returning entity will
not understand the semantics?  Yes, and there are some allowances within
the XMPP drafts for this (such as the optional <text/> element).  This
situation is also unlikely (not impossible, and not rare, but
unlikely).  Implementations are free to set this (and, in the case of
"alert" and "notify", the <subject/> and <body/>) to whatever they feel
is appropriate.  But this is, in my opinion, an implementation issue.

Thirdly, a server SHOULD only perform notifications on those (matching)
rules the sending entity specifies in the first place, and MUST not
accept semantics it does not understand (which I now realize is not
clearly specified).  Given my earlier example, I would only receive the
<rule condition='match-resource'/> if I had specified it in the first
place.  Also, if it had been there, this message should not have
progressed further if the gateway did not understand the conditions and
actions applied.

I will update JEP-0079 to account for the discrepancies you have brought
to light.  However, many of the issues you have explicitly stated are
implementation-specific issues.  If you have suggestions for better
handling some of these in a standardized manner, please provide them. 
I'm not a omniscient after all (-:


-  LW

On Thu, 2003-06-26 at 15:18, Barry Latimer wrote:
> Hi,
> 
> sorry didn't fully explain myself here. The functionality I was talking about was providing more information about delivery errors to Xmpp.
> 
> Using the gateway example
> 
> FROM: Sender at email.com
> TO : Gateway at jabber.com
> Subject: Delivery Failed Invalid Mailbox
> [Message Desposition Headers]
> 
> Unable to delivery your message to 'user at email.com' as this mailbox does not exist.
> 
> Convert this into 
> 
> <message from='email.com'
> to='sender%somewhere.com at email-gateway.jabber.com' type='error'>
>   <body>Unable to delivery your message to 'user at email.com' as this mailbox does not exist.</body>
>   <semantics xmlns='http://jabber.org/protocol/msg-delivery'
> status='error'>
>     <rule action='error' condition='match-resource' value='exact'/>
>   </semantics>
>   <error code='500' type='cancel'>
>     <internal-server-error xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
>     <condition-error xmlns='http://jabber.org/protocol/msg-delivery'>
>       <rule action='error' condition='match-resource' value='exact'/>
>     </condition>
>   </error>
> </message>
> 
> Now the email message is not only telling me that the message delivery failed but why it failed, what I was commenting on is that I could not see in your proposal anywhere to add a reason for a delivery failure. Which can be useful to report back to the user so that they can decide if they should resend the message or not. 
> 
> So in essence converting from Xmpp to Email/Sms not a problem just when converting back from Email/Sms we are losing information.
> 
> The second point about the 'human' readable text included in the body is to allow for clients who do not implement JEP-0079 to still display a useful message. The internationalisation issues I would handle the same as email who ever generated the message decides upon a language, because this is provide as a courtesy to clients who do not understand JEP-0079
> 
> Barry
> 
> 
> 
> 
> -----Original Message-----
> From: Matthew A. Miller [mailto:linuxwolf at outer-planes.no-ip.com]
> Sent: Friday, 27 June 2003 2:09 AM
> To: standards-jig at jabber.org
> Subject: RE: [standards-jig] UPDATED: Message Delivery Semantics
> (JEP-0079)
> 
> 
> I believe that JEP-0079 already does provide this additional
> information.  When an "alert","error", or "notify" action, the reply
> coming back specifies the <rule/> that triggered it.  In the case of
> "error", this is doubly repeated (until XMPP is standard and widely
> supported).
> 
> In the case of gateways (such as e-mail or SMS), you are already
> translating between Jabber/XMPP and that other system.  So you can quite
> easily translate this:
> 
> <message from='example.com'
> to='sender%somewhere.com at email-gateway.example.com' type='error'>
>   <body>We need to talk</body>
>   <semantics xmlns='http://jabber.org/protocol/msg-delivery'
> status='error'>
>     <rule action='error' condition='expire-in' value='100'/>
>   </semantics>
>   <error code='500' type='cancel'>
>     <internal-server-error xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
>     <condition-error xmlns='http://jabber.org/protocol/msg-delivery'>
>       <rule action='error' condition='expire-in' value='100'/>
>     </condition>
>   </error>
> </message>
> 
> to this:
> 
> FROM: notification at jabber.somewhere.com
> TO:   sender at somewhere.com
> SUBJECT:  FAILED Delivery Notification
> 
> The message sent to 'receiver%example.com at email-gateway.example.com'
> failed to be delivered within 100 milliseconds.
> ...
> 
> 
> If you can provide more details, including how you intend to handle
> internationalization issues, I'm more than happy to consider and discuss
> them.
> 
> 
> -  LW
> 
> On Wed, 2003-06-25 at 17:26, Barry Latimer wrote:
> > In both JEP-0079 and JEP-0022 the notification of message delivery is limited to a simple success or failure option, we are using Xmpp to communicate to an Sms gateway which returns different types of delivery failures.
> > 
> > I think the delivery semantics need to be expanded to include the reason the delivery failed or succeed as part of the returned condition. 
> > 
> > Also in email an body is returned detailing why the message is being sent to allow 'humans' to easily understand the message such as 'Your message to xxxx was delivered in time' should this be added to returned message.
> > 
> > 
> > 
> > 
> > -----Original Message-----
> > From: Peter Saint-Andre [mailto:stpeter at jabber.org]
> > Sent: Wednesday, 25 June 2003 1:17 AM
> > To: standards-jig at jabber.org
> > Subject: [standards-jig] UPDATED: Message Delivery Semantics (JEP-0079)
> > 
> > 
> > Matt Miller has submitted an updated version of JEP-0079 (Message
> > Delivery Semantics). The changelog is:
> > 
> >   Completely rewritten to better account for various suggested usage
> >   details and requirements; Completely reorganized to better codify 
> >   the protocol(s) and their possible uses; Added more conditions; 
> >   Added more actions; Added common usage scenarios (lw)
> > 
> > http://www.jabber.org/jeps/jep-0079.html
> > 
> > Peter
-- 

Matt "linuxwolf" Miller
JID:	linuxwolf at outer-planes.net
E-MAIL:	linuxwolf at outer-planes.net

- Got "JABBER"? (http://www.jabber.org/)




More information about the Standards mailing list