Le jeudi 30 août 2007, Rachel Blackman a écrit :
> >>> Personally I think the client version information should be
> >>> carried in the disco#info using XEP-0128 using a new special
> >>> FORM_TYPE (maybe even reusing using jabber:iq:version and using
> >>> its elements as the xdata field names).
>
Personally I think the client version information should be
carried in the disco#info using XEP-0128 using a new special
FORM_TYPE (maybe even reusing using jabber:iq:version and using
its elements as the xdata field names).
Or it could be split out as a separate attribute.
Where the
On Aug 30, 2007, at 10:01 AM, Richard Dobson wrote:
Personally I think the client version information should be
carried in the disco#info using XEP-0128 using a new special
FORM_TYPE (maybe even reusing using jabber:iq:version and using
its elements as the xdata field names).
Or it could
And why should we put the version number in the node ?
If it is to substitute the XEP-0092, I think it's the wrong way. (Because it
break compatibility with xep-0115 1.3 (if the capabilities doesn't change
between versions 1.3.4b to 1.3.4c)
Personally I think the client version informati
Le jeudi 30 août 2007, Sergei Golovan a écrit :
> I think that it's not a good idea to send disco#info query to a
> specific node (concatenated node and ver attributes). Instead, queries
> should be sent to peer's JID without any node (as it is specified in
> version 1.4 of the XEP).
I fully agree
Hi!
It seems to me that new version 1.5pre5 of XEP-0115 (Entity
capabilities) contains unnecessary complications (in comparison with
more clear 1.4).
I think that it's not a good idea to send disco#info query to a
specific node (concatenated node and ver attributes). Instead, queries
should be se
