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

Matthew A. Miller linuxwolf at outer-planes.no-ip.COM
Tue Feb 18 22:37:45 UTC 2003


Responses in-line:

On Tue, 2003-02-18 at 12: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? :)

jabber:x:data does not have the element <query/>, let alone with the
attribute "node", as detailed in Section 8.1.  That alone can be
considered "not as spec".

In addition, Section 3.2 of JEP-0004 states that x:data is not useful on
its own, that it needs something to give it context (such as a
containing namespace).  While this does not explicitly state the usage
presented by ejabberd is incorrect, it is implied.

Maybe this is something the council and authors of JEP-0004 need to
address?

> 
>  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).

1)  I can see getting around sessionid, although x-commands requires
that execution include a certain level of statefullness.  status and
action can be useful if someone wants to cancel a change to the server,
without relying on that hideous idea of "timing out".  And to top it all
off, x-commands separates transport-level errors from application-level
errors, which you may or may not find immensely useful.

2)  The protocol for x-commands is still negotiable (-:  LAST CALL (part
deux) for JEP-0050 is going to happen soon, so if you have
questions/concerns with JEP-0050, raise them!

3) Whether or not you like "dummy namespaces" is irrelevant:  This is
how x:data is designed and drafted to be used, not the method you are
attempting (as outlined above).

>  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.

Unless I'm completely misreading, you are arguing that "node" be
considered an attribute of <iq/>, <message/>, and <presence/> for the
purpose of addressing.  I am arguing that the JID is all that is
[usually] necessary, provided that you use it "wisely" (-:

>  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 MUC
> 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.

It can also (IMO, successfully) be argued that the JID already contains
its full addressing.  Where TCP and UDP rely on the combination IP
address/port, Jabber has the three parts of a JID; node, domain, and
resource.  The domain tells where something goes, and the node and
resource (of the JID; those are the terms used in the I-Ds) further
qualify who and what within that domain.

That a JID can have different information for different circumstances is
a result of the information-providing protocol; not necessarily of
Jabber as a whole.

Maybe it would have been better if disco did not try to present non-JID
items.  The designers of disco feel otherwise, and I'll not begrudge
them their decision (since I abuse it oh so well (-: ).

>  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?

As I said, I think x-commands is a "perfect" fit to what you're trying
to accomplish for ejabberd.  That is my suggestion in your case. 
Different problems often have different solutions. 

>  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? :)

I cannot answer this question globally. I can, however, answer it for
x-commands:  A command is not a directly addressible entity.  It makes
no sense to subscribe to its presence, or to send it messages.  The only
sensible usage is within the province of IQ, as detailed in the
specification.

I believe there were more concrete motivations for MUC, although stpeter
can better elaborate on this than I.

> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
-- 

Matt "linuxwolf" Miller
JID:	linuxwolf at outer-planes.net
E-MAIL:	linuxwolf at outer-planes.net

- Got "JABBER"? (http://www.jabber.org/)




More information about the Standards mailing list