[standards-jig] disco, x:data, etc...
alexey at sevcom.net
Wed Feb 19 12:15:02 UTC 2003
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:
End of discussion:
More information about the Standards