[standards-jig] LAST CALL: Service Discovery (JEP-0030)
alexey at sevcom.net
Sat Dec 7 10:46:56 UTC 2002
On Fri, 6 Dec 2002 13:33:38 -0700, you said:
>> 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