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

Alexey Shchepin alexey at sevcom.net
Wed Feb 19 12:15:02 UTC 2003


Hello, Matthew!

On 18 Feb 2003 14:37:45 -0800, you said:

 MAM> Hola, First, the use of x:data you have is not "as spec". x:data
 MAM> is not meant to "stand alone" in the form you are using it.
 >>  Where in spec writen that I can't do this? :)
 MAM> jabber:x:data does not have the element <query/>, let alone with
 MAM> the attribute "node", as detailed in Section 8.1.  That alone
 MAM> can be considered "not as spec".

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

This is bad, because x:data can be used without context (i.e. show
form and submit it).  Note that in first message in this thread I say
that one of purposes of this way is to make interface to services more
generic.  And Tkabber knows nothing about ejabberd, but I have admin
interface with it.  This is what i mean by "generic".  If we define
that "x:data must be in namespace to give context", then I need to
define one new namespace (as you done with x:commands) which contain
"node" attribute (and again is useless, and not give specific context
as sayed above).  Or to give context I need to define many namespaces
(e.g. http://jabber.org/protocol/ejabberd#config#acls), and add
support for it in Tkabber (not generic way).

And don't forget that x:data is only one namespace that use node.
Stats also use it, and i don't know how and why i can use x-commands
for storing another namespaces.

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

Yes, but better with adding of "query" then denying it.

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

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

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

 MAM> As for making "node" part of the globally addressing system, I
 MAM> don't 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> Unless I'm completely misreading, you are arguing that "node" be
 MAM> considered an attribute of <iq/>, <message/>, and <presence/>
 MAM> for the purpose of addressing.

For purpose of addressing inside entity.

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

JID contain addressing only for jabber entity, it not address what
part of entity is packet to.

 MAM> If you find the need to address a "node" globally, it would be
 MAM> better to make it an addressible entity (use only the JID)
 >>  Any good ideas how to make this?
 MAM> As I said, I think x-commands is a "perfect" fit to what you're
 MAM> trying to accomplish for ejabberd.  That is my suggestion in
 MAM> your case.  Different problems often have different solutions.

But I can't use x-commands for another namespace, or for <message/>.

 MAM> and leave the use of "node" for items that should not be
 MAM> directly communicated with.
 >>  Why we need node to which we can't communicate? :)
 MAM> I cannot answer this question globally. I can, however, answer
 MAM> it for x-commands: A command is not a directly addressible
 MAM> entity.  It makes no sense to subscribe to its presence, or to
 MAM> send it messages.  The only sensible usage is within the
 MAM> province of IQ, as detailed in the specification.

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

Here you can see discussion when "node" attribute have been added and
reasons for this.
Start of discussion:
http://mailman.jabber.org/pipermail/standards-jig/2002-December/thread.html#2243
End of discussion:
http://mailman.jabber.org/pipermail/standards-jig/2002-December/002279.html




More information about the Standards mailing list