[Standards-JIG] Recommended additions to JEP-130 (Waiting Lists)

Craig Kaes CKaes at jabber.com
Thu Sep 2 19:00:13 UTC 2004

Overall, I believe that JEP-130 is straightfoward and quite functional.  I
see two deficiencies in JEP 130 that ought to be addressed.

First, there is no way to store a human readable identifier in the waitlist
item so that when viewed in a client other the client originating the
addition, there may be insufficient context to know what the entry
represents.  For example, I may add somebody to the waitlist by phone # on
my cell phone.  Two months later, I retrieve the waitlist on my desktop
client and can't remember who (524) 332 - 9243 is.  I recommend adding this
identifier to the item within the query child.   Below, I give an example
but I'm certainly not married to the exact syntax.

Currently, the client sends the following to add a waitlist item:
<iq type='set'
  <query xmlns='http://jabber.org/protocol/waitinglist'>
      <uri scheme='tel'>contact-number</uri>

Recommended change:
<iq type='set'
  <query xmlns='http://jabber.org/protocol/waitinglist'>
      <uri scheme='tel'>contact-number</uri>
      <name>Mr. Morton</name>

Notde the addition of the name element that is now a child of item.
Further, we should agree on a limit to the length of the text to allow for
efficient database storage.  Shall we allow, say, 1K of normalized cdata?

Secondly, there is no mechanism in the current protocol for the service to
inform the user that it has asked all the interop partners it knows of and
none of them handle that uri.  For example, let's say a user adds an item
with uri of 555-555-5555.  The request is valid and so the service
acknowledges receipt of the request and subsequently forwards the request on
to a number of interop partners.  These partners, in turn, all eventually
respond that they do not handle that uri.  There is no way for the service
to then tell the client that and further waiting by the client is in vain.

There are three approaches that I see.

First, the service can hold on to the iq result for the original iq set
until all interop partners have responded.  The service could then return a
remote server error as suggested in example 14.  I find this solution
unpalatable because the delay in responses from the interop partners
probably necessitates persisted state at the service and a long delay in
responding to the client -- possibly on the order of days.

Second, the service can silently remove the waitlist item so that the next
time the client retrieves the waitlist, it simply doesn't have that item
anymore.  I believe this would be surprising to the user and just doesn't
seem right.

Lastly, the service can send a notification similar to the successful
notification (i.e. in a message) that the URI cannot be located.  Something

    to='user at service-provider.com'>
  <body>This message contains a waiting list item.</body>
  <waitlist xmlns='http://jabber.org/protocol/waitinglist'>
    <item id='12345' type='error'>
      <uri scheme='tel'>contact-number</uri>
    <error code='500' type='cancel'>

Other nits -- the error codes need updating and I think recommending a
type='headline' on the notifications is a big mistake.  I've said that I
want to be notified when this user is added; why wouldn't I want
notification if I'm offline when the user finally joins?  Seems strange.


More information about the Standards mailing list