[Standards-JIG] advertisement and query suggestions for JEP-0128

Ralph Giles giles at onlinegamegroup.com
Thu Sep 8 14:34:40 CDT 2005


Forgive me, but I'm new at this. As I understand it, JEP-0128 pretty
much says, "You can include FORM-TYPE data, defined in relevent other 
JEPs according to JEP-0068, in a response to a disco#info query." 
Paraphrasing, of course.

So, an entity can choose to include data or not, and there's no way to 
know or control what you'll get, a priori.

Taking a popular example, suppose a client wants to display a list of 
public rooms with their subjects, number of occupants and so one. 
JEP-045 defines the muc#roominfo FORM_TYPE (section 14.5.3) which 
provides just this information as an extension. Currently, it seems one 
may say:

<iq type='get' to='chat.example.com' id='rooms_1'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

and the component will return, among other things:

<feature var='http://jabber.org/protocol/disco'/>
<feature var='http://jabber.org/protocol/muc'/>

To show it supports disco (obviously) and the muc protocol. Having 
verified that, one can then say:

<iq type='get' to='chat.example.com' id='rooms_2'>
  <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>

To get a list of public rooms:

<iq type='result' to='client at example.com/foo' id='rooms_2'>
  <query xmlns='http://jabber.org/protocol/disco#items'>
    <item jid='room1 at chat.example.com' name='first room'/>
    <item jid='room2 at chat.example.com' name='second room'/>
	[...]
  </query>
</iq>

Finally, on can go through the list, sending a disco#info to the jid of 
each room, and *if the component is so inclined* it my return the extra
muc#roominfo data form with the metadata the client is interested in.

I'd like to propose for discussion an alternative to this. First, it 
seems reasonable that an entity advertise the FORM-TYPEs it supports as 
additional <feature/> elements in a response. To be useful in this 
example, the muc component itself 'chat.example.com' would have to 
return

  <feature var='http://jabber.org/protocol/muc#roominfo'/>
  
in response to a disco#info. There's some ambiguity here between the 
component and its nodes; I'm not sure what makes the best general case.

Second, it would be nice if one had some control over what the query 
returned. One idea is to make this part of the node mechanism. In our 
example, one could say:

<iq type='get' to='chat.example.com' id='rooms_2'>
  <query xmlns='http://jabber.org/protocol/disco#items'
         node='http://jabber.org/protocol/muc#roominfo' />
</iq>

To have the component return the roominfo FORM_TYPE for
each item.

JEP-0128 tries to maintain a distinction between #info and #items, but 
we don't think this is optimal. Section 2 says:

"An entity MUST NOT supply extended information about associated 
children communicated via the 'http://jabber.org/protocol/disco#items' 
namespace, since a core principle of Service Discovery is that an entity 
must define its own identity only and must not define the identity of 
any children associated with the entity."

But where components and servers are concerned, the distinction 
between a child and an entity isn't always so clean, and becomes
less important to enforce if the querying entity has some control
over what elements are returned. We suggest relaxing the MUST NOT 
to a SHOULD NOT and giving some guidance on when returning extended
information is appropriate. For example, the muc#roominfo data is 
at a similar level to the muc room name, which is always returned
in a disco#items query, but something like the full registration
FORM_TYPE is much more detailed and makes more sense as up to the
individual room entities.

Anyway, I don't feel like I have enough of a handle on all of this
to have a definite opinion, but I'd like to start a discussion on 
whether we can improve on the "maybe you'll get it" nature of the
current JEP-0128 recommendation.

Sincerely,
 -r




More information about the Standards-JIG mailing list