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

Richard Dobson richard at dobson-i.net
Fri Feb 21 15:56:07 UTC 2003


> Hello, Matthew!
>
> On 20 Feb 2003 13:28:53 -0800, you said:
>
>  MAM> I will make changes to JEP-0050 to remove the "extension"
requirement for
>  MAM> command payloads.
>
>  MAM> But adding a node attribute to IQ (and presence, and message) is not
a
>  MAM> simple task.  This would require the approval of the XMPP-WG, which
is
>  MAM> extremely doubtful because of the nature of JIDs.  If you've
followed it
>  MAM> at all, you should know that even "simple tasks" often take
weeks/months
>  MAM> to reach consensus, and are often as not discarded.
>
> I very dislike arguments like "this can take a long time", "jep authors is
> always right", etc...  If this can take months, then we can use temporary
> solution.  This is what I currently use, and it not break XMPP standartds
(it
> breaks DTD for some namespaces, but, if I right understand, this can be
solved
> by calling this attribute e.g. "jabber:node", or something like this).

Im sorry but I dislike implementers who do not follow the set standards and
risk breaking things for others when a simple easy standards compliant
solution has been suggested to them. Also its not your decision to add
things like top level addressing attributes to the protocol just because you
think "it looks better".

>  MAM> But let's put aside the above, and go onto the "spirit" and "intent"
of
>  MAM> things.  The "node" attribute of disco was never intended for
addressing.
>  MAM> It was to report on *NON-ADDRESSIBLE* items.
>
> Non-addressable by JID.  Which we want to address.  Maybe we have
different
> meaning of word "addressing"

Obviously....

> <iq type='get'
>     from='romeo at montague.net/orchard'
>     to='catalog.shakespeare.lit'
>     id='items3'>
>   <query xmlns='http://jabber.org/protocol/disco#items'
>          node='music'/>
> </iq>
>
> we address this query to node "music".  And I want to address to this node
not
> only disco queries.  Compare it with "xml:lang", we not do
>
> <iq type='get'
>     from='romeo at montague.net/orchard'
>     to='catalog.shakespeare.lit'
>     id='items3'>
>   <lang xmlns='http://jabber.org/protocol/lang'
>         lang='ru'>
>     <query xmlns='http://jabber.org/protocol/disco#items'
>            node='music'/>
>   </lang>
> </iq>
>
> or something like this.  Because if we will add new element and namespace
for
> every attribute, then after some time we get something like this:
>
> <iq type='get'
>     from='romeo at montague.net/orchard'
>     to='catalog.shakespeare.lit'
>     id='items3'>
>   <lang xmlns='http://jabber.org/protocol/lang'
>         lang='ru'>
>     <command xmlns='http://jabber.org/protocol/commands'
>              node='music'
>       <...etc...>
>         <query xmlns='http://jabber.org/protocol/disco#items'/>
>       </...etc...>
>     </command>
>   </lang>
> </iq>
>
> instead of
>
> <iq type='get'
>     from='romeo at montague.net/orchard'
>     to='catalog.shakespeare.lit'
>     id='items3'>
>   <query xmlns='http://jabber.org/protocol/disco#items'
>          node='music'
>          xml:lang='ru'/>
> </iq>

Of course we dont use xml:lang that way, because the standard has been set
for xml:lang that it is an attribute of a node you want to add language
information to. How does this relate in anyway to addressing and your
strange ideas about node??????

>  MAM> If you have something you want addressed, you give it a unique JID.
>
> Easy to do if I want ot do this for server or for service which have only
> domain part in JID, but many entities have JID in which all parts already
used.
> Or you see way to make unique JID for any numer of things that entity
wants?
> Then let's remove "node" from disco, because it useless in this case.

It is not useless in disco it is for getting information about
NON-ADDRESSABLE elements when you do not need to address them in any other
way that simply get information about what it is. What exactly are you
trying to do anyway that requires a unique addressable JID?

>  MAM> Even one of the JEP-0030 authors came forward to state exactly this.
>
>  MAM> The true root to your problems is that you have written software
that
>  MAM> does not follow specifications, and want the specs changed to fix
your
>  MAM> broken implementation.
>
> :))
>
> The true root of my problem is that protocol not have good solution for
this
> task, and I don't want to use crutch-like solutions for this to avoid
problems
> in future.  So currently I use simple and logical solution that not break
XMPP.

But again as has been stated it is not your place to add things to a
standardised part of the protocol, you might not have seen it break your
implementation (since you handle it) but it COULD break someone elses
COMPLIANT implementation, you MUST remove this non-compliant addition to the
protocol and use one of the compliant suggestions that have been put to you
to solve your problem.

>  MAM> The issues you have with ejabberd are implementation issues, not
>  MAM> standards issues.
>
> Notice that I have no issue with ejabberd, tkabber, x:data and nodes.  I
have
> working solution, but I want to make it better by moving "node" references
to
> toplevel stanzas, because for me it looks better.

Well it might to you but it DOESNT to us.

Richard





More information about the Standards mailing list