[Standards] Proposed XMPP Extension: Discovery and Integration of XMPP Services

Mircea Bardac dev.list at mircea.bardac.net
Wed Mar 28 09:50:31 UTC 2007


On Tuesday 27 March 2007 02:01:08 XMPP Extensions Editor wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Discovery and Integration of XMPP Services
>
> Abstract: This XEP defines a mechanism for Services (in the SOA sense) to
> exist on the XMPP Network. This includes client discovery, load balancing
> and redundancy across multiple instances of the Service.
>
> URL: http://www.xmpp.org/extensions/inbox/dix.html
>
> The XMPP Council will decide within 7 days (or at its next meeting) whether
> to accept this proposal as an official XEP.

1.

-- Quote --
Once a bare JID for a particular service has been established via discovery, 
an Echo message is sent to the bare JID of the Service. To facilitate request 
tracking an id attribute MUST be specified on the message "ping" sent by the 
client and it MUST be echoed in the "pong" response. If multiple "pong" 
responses are received it is up to the client to determine which to further 
query.
-- end quote --

I migth be missing something but.. why is the ping-pong mechanism required 
besides discovering the resource (named "Concrete service" - a bit strange, 
term not found in 2-Glosary).

Also, when would a client receive multiple pongs, if (AFAIK) only one resource 
receives the ping.

2. 

-- Quote --
4.2.3 Verifying the Service
Once a service instance has been found, it's necessary to disco the service to 
verify it supports the correct features:
-- end quote --

I understand this, but what I don't understand why the X-Data form is built-in 
the disco reply. According to the subchapter name and example name, the disco 
only does a verification.

I haven't seen this being done in ad-hoc commands for example. 

From what I've noticed reading this XEP, this XMPP Service should be
* a provider for a subset (=1 command) of Ad-hoc commands
* a generalization of jabber:iq:register

Maybe these concepts could somehow be combined to offer something uniform.


Regards,
Mircea



More information about the Standards mailing list