[standards-jig] Re: LAST CALL: Service Discovery (JEP-0030)
jean-louis.seguineau at antepo.com
Wed Dec 4 19:14:58 UTC 2002
I don't recall anywhere saying that JID should take a particular form.
Adding logic inside the JID, is bound to lead to scalability issues soon. It
will also loose any attempt at universality of the protocol.
As Alexey rightly pointed out, it only works because your specific server do
not use this resources in another cases. But who ever dictate that JID
resource must be used in a specific way ? Who ever imposed that service JID
do not hold a node name and only a domain name. This is just because short
cuts have been taken by certain developper. Once again, we are facing the
interpretation of the protocol for a specific server implementation.
IMHO one proper way to tackle this kind of issue would be to use parameters,
which are valid for JID, in the query part of the JID (you know what is
after the ? mark). As a reference, this is what SIP is using in many cases,
and I tend to believe this is one good way to extend the JID capabilities
without being bound to a particular implementation or interpretation.
----- Original Message -----
> Message: 2
> Date: Wed, 4 Dec 2002 09:39:20 +1100
> From: Robert Norris <rob at cataclysm.cx>
> To: standards-jig at jabber.org
> Subject: Re: [standards-jig] LAST CALL: Service Discovery (JEP-0030)
> Reply-To: standards-jig at jabber.org
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> > One more example: jabberd1.4 in browse reply to one of the admins of
> > server inserts "Online Users" item with jid=3D'servername/admin'. But
> is is
> > again JID overloading, and works only because this JID not used
> > me looks better if server sends this in disco reply like
> > <item jid=3D'servername' id=3D'online users'/>.
> I disagree - servername/admin (or servername/users and
> servername/sessions, as my plan is for j2) is entirely appropriate - its
> a different JID, so different results can be expected.
More information about the Standards