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

Alexey Shchepin alexey at sevcom.net
Sat Dec 7 10:46:56 UTC 2002

Hello, Joe!

On Fri, 6 Dec 2002 13:33:38 -0700, you said:

 JH> Alexy:
 >> E.g. clients can't send replies from any JID except user at server/resource.
 >> So if we want to make such hierarchy, then this will look strange that
 >> replies comes not from JID they sended to...

 JH> Ah!  Now that makes sense to me.  I didn't quite see what the fuss was
 JH> until now.

 JH> I think this is actually an addressing problem, and not necessarily (yet)
 JH> a disco problem.

 JH> Imagine a Jabber client that is also providing non-IM services (like
 JH> xmlrpc endpoints, etc).

 JH> There must be a way to sub-address those services.  Yes, it is possible to
 JH> rely on implementations to route foo at bar/baz/bar to a connection that
 JH> authed with foo at bar/baz, but that is limiting in a variety of ways.

I agreed that each jabber entity (I mean service, client, server, conference
room participant, etc...) must have its own JID.

 JH> Once there is a way to address those services, *then* there needs to be a
 JH> way to discover them, and their children.

 JH> I guess the question is, do we need to pause disco development while we
 JH> solve the addressing issue?

Lets consider this two questions:

1) How to make JID hierarchy?  This is really haven't direct relation to disco.

2) If *one* JID can return many <item/>'s in disco reply, what way we must use
to structure them?  Personally I dislike making of additional JIDs for this
which is not used in other ways.

More information about the Standards mailing list