[standards-jig] disco, x:data, etc...

Nick nick at devzero.homelinux.com
Tue Feb 18 23:42:28 UTC 2003

Just to make a note: I don't think node semantics were ever to "help" 
in addressing JID addressable "items". "node" was put into place to 
make it possible to discover non-JID addressable items.

Lets say you have a custom jabber server that also provides built in 
webclients, LDAP, blah blah, etc. None of those items are addressable 
but you would like to dissemanate that information to all who ask about 
it. That's would node would be for.

Beyond that, the jep does not define semantics on how node can be used 
or whether or not it should mean anything. I currently implement it as 
a hierarchy following the example given in the jep with custom 
categories and types (like containers: to let the entity know that the 
item has children items and you can even disco#info the container and 
it will tell you that it can #info and #items :). Others have mentioned 
they do it as a string to address that non-jid item (maybe it contains 
ip address to those services which don't have a jid, or path to a file 
on the local machine, or some sort of URL, whatever).

So, no, node should not be a global thing. We already have an 
addressing system in place to reach those entities that speak jabber. 
Node is to provide for those that are too selfish to have a jid so the 
(jabber)world can speak to them.


Nicholas Perez
Email: 	nick at devzero.homelinux.com
Jabber:	nickperez at jabber.org
Home:	303.759.0574

On 2003.02.18 13:25 Alexey Shchepin wrote:
> Hello, Matthew!
> On Sun, 16 Feb 2003 13:49:32 -0800, you said:
>  MAM> Hola, First, the use of x:data you have is not "as spec". x:data
> is not
>  MAM> meant to "stand alone" in the form you are using it.
> Where in spec writen that I can't do this? :)
>  MAM> Rather, this usage is exactly what x-commands (JEP-0050) was
> designed
>  MAM> for.  You should look into using x-commands where you have
> stand-alone
>  MAM> x:data forms.
> X-commands only adds session id and status, which I not need in this
> situation.
> And I don't like to use dummy namespaces like iq:register to include
> x:data
> inside it (in case when using only x:data this namespace is really
> dummy).
>  MAM> As for making "node" part of the globally addressing system, I
> don't
>  MAM> think it necessary.
> Yes it not necessary, but many not necessary things make life better
> :)  Using
> XML in Jabber protocol is also have not been necessary, but this make
> protocol
> much better than e.g. when using IRC-like string-packets with strange
> format.
>  MAM> "node" was not intended as part of the global addressing.  It
> was
>  MAM> intended as a way to report non-addressible items via disco.
> Look to JID and "node" as to IP and port in tcp/ip addressing schema.
> Each
> router looks only to IP (s/router/not advanced router/ :) and when
> packet
> transferred to tcp/ip entity, OS on this entity looks to port and
> sends packet
> to program inside it.  Same with Jabber: servers route packets by JID
> to jabber
> entity, and this entity can contain some subservices, to which packet
> is routed
> by node.  Without "node" Jabber enity can't separate information that
> returned
> e.g. by disco or by stats.  This is why "node" appears in disco -- in
> exists too many things to be returned by discovery, so we need way too
> separate
> it in logical groups.  And this is reason why I add support of node in
> stats
> namespace (I mean in ejabberd and Tkabber) -- because this statistics
> is getted
> from diferent parts of ejabberd, and it better looks when it is
> separated in
> the same way.
>  MAM> I made each command a disco node because they are not directly
>  MAM> addressible, but wanted to make better use of disco for
> discovery and
>  MAM> reporting.  You address the entity, not the command.  To
> explicitly
>  MAM> synchronize with disco, x-commands uses "node" to identify the
> specific
>  MAM> command.
>  MAM> If you find the need to address a "node" globally, it would be
> better to
>  MAM> make it an addressible entity (use only the JID)
> Any good ideas how to make this?
>  MAM> and leave the use of "node" for items that should not be
> directly
>  MAM> communicated with.
> Why we need node to which we can't communicate? :)
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig

More information about the Standards mailing list