[standards-jig] LAST CALL: Service Discovery (JEP-0030)

Robert Norris rob at cataclysm.cx
Wed Dec 4 22:26:51 UTC 2002

>  RN> I disagree - servername/admin (or servername/users and
>  RN> servername/sessions, as my plan is for j2) is entirely appropriate - its a
>  RN> different JID, so different results can be expected.
> It works only because server not use this resources in another cases.  If I
> want to do somethng similar with client (or with service that connected as
> client) that already have resource, then I'll have troubles with using resource
> for this.

I'm a little confused by this. I'm talking about using the server JID,
not a user JID. The jabberd2 session manager does this:

 - A disco#items get sent to "server.com" returns the services
   (transports/agents/etc) that the SM knows about.

 - A disco#items get sent to "server.com/users" returns the users that
   are currently connected (users only, no resources).
 - A disco#items get sent to "user at server.com" is handled by the SM
   (since IQs without a resource aren't routed to clients), and returns
   the active sessions that the user has.

(The last two will be protected by suitable access controls).

I don't see why any of this is a problem. All that disco#items is
intended to do is return a list of JIDs that are "related" to the
queried JID. The actual JIDs in use is left to the implementation, and
rightly so - its impossible to predict every possible type of JID list
that a component might want to return, and we can't require clients to
know what types are possible.

> 1) JID is restricted in length.  Of course in practice this must be deep
> hierarchy, but who know what we will have in future.
> 2) It stops to work if we have another JID logged in with partially matched
> resource (I mean e.g. with "/u" appended, then all packets with "/u" will
> routed to him instead of first JID).  Currently all JIDs have 3 levels of
> hierarchy: server, node, resource.  If we really want to use JID with more
> levels, then need to e.g. explicitly define meaning of "/" symbol in resource
> identifiers and deny of login JID with resource that are child of another
> already logged resource.  (Sorry for my english)

Resource hierarchies are defined by the application. The length
restriction is simply something that application designers need to take
into account. Resource partial matching is intended to assist the
application in creating such hierarchies, but it is certainly not the
job of the session manager to enforce any particular semantics on a
resource hierarchy.

I'm not entirely sure what this has to do with disco, either.


Robert Norris                                       GPG: 1024D/FC18E6C2
Email+Jabber: rob at cataclysm.cx                Web: http://cataclysm.cx/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20021205/fda95d23/attachment.sig>

More information about the Standards mailing list