On Nov 20, 2007, at 12:38 PM, Rachel Blackman wrote:
I.e., I think this method is kind of a mess, when just adding 'hash'
in separately would've solved the backwards compatibility issue
nicely. However, that ship has probably sailed, so even just
including 'v' will solve the 'users will
I.e., I think this method is kind of a mess, when just adding
'hash' in separately would've solved the backwards compatibility
issue nicely. However, that ship has probably sailed, so even just
including 'v' will solve the 'users will ask for this' concern I
had about displaying version
Well, whatever it is, we should specify it. :)
Joe Hildebrand wrote:
I disagree with this. I think it should return not found. Think about
a pub-sub service, for example...
On Nov 21, 2007, at 11:18 AM, Peter Saint-Andre wrote:
I don't think I agree. That is, I think if you receive a
On Nov 21, 2007, at 10:37 AM, Rachel Blackman wrote:
Now you are supposed to just do a straight out disco query against
the user;http://foo.com/bar#somestring is not guaranteed to actually
be a valid query you can perform, which means old-style clients that
expect to do node#ver queries
Joe Hildebrand wrote:
On Nov 20, 2007, at 12:38 PM, Rachel Blackman wrote:
I.e., I think this method is kind of a mess, when just adding 'hash'
in separately would've solved the backwards compatibility issue
nicely. However, that ship has probably sailed, so even just
including 'v' will
Rachel Blackman wrote:
I.e., I think this method is kind of a mess, when just adding 'hash'
in separately would've solved the backwards compatibility issue
nicely. However, that ship has probably sailed, so even just
including 'v' will solve the 'users will ask for this' concern I had
about
presence from='[EMAIL PROTECTED]/orchard'
c xmlns='http://jabber.org/protocol/caps'
node='http://code.google.com/p/exodus/'
v='0.9.1'
ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/
/presence
AND...
identity category='client' name='Exodus 0.9.1' type='pc'/
Then do you display the following?
OK, I'm still trying to get to closure here... :)
Rachel Blackman wrote:
A version is only interesting if you know the software that it goes with.
Unfortunately all we have is a URI, which means for any sane display I
need a
table of URI-software name mappings, and thus I can only display
...coming back. You cache the name, and add the version.
(Optionally,
if the name string contains the version string, a'la 'Exodus 0.9.1'
and
version '0.9.1' you just use the name unmodified.)
Hmm. What if you have this?
presence from='[EMAIL PROTECTED]/orchard'
c
On August 29 I posted to this list about some provisional changes that
Joe Hildebrand and I made to XEP-0115:
http://mail.jabber.org/pipermail/standards/2007-August/016619.html
Some discussion ensued here:
http://mail.jabber.org/pipermail/standards/2007-August/016655.html
Peter Saint-Andre wrote:
I will post version 1.5pre6 soon
to incorporate the foregoing consensus.
Well soon was rather immediate. :)
http://www.xmpp.org/extensions/tmp/xep-0115-1.5.html
Diff from 1.5pre5:
http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0115.xml?r1=1194r2=1362
Joe Hildebrand wrote:
On Nov 8, 2007, at 4:12 PM, Peter Saint-Andre wrote:
How exactly do 1.3 clients break if in 1.4+ the nodes are things like:
http://code.google.com/p/exodus/#0.9.1
http://psi-im.org/#0.11
Again it's a special URL at the software website. The only potential
problem
On Nov 8, 2007, at 4:24 PM, Peter Saint-Andre wrote:
Yes it seems a bit funny to have a 'v' attribute:
http://mail.jabber.org/pipermail/standards/2007-August/016680.html
As usual, Rachel is the voice of reason. I don't mind her proposal;
however, I still don't think the algorithm needs
On Nov 8, 2007, at 4:12 PM, Peter Saint-Andre wrote:
How exactly do 1.3 clients break if in 1.4+ the nodes are things like:
http://code.google.com/p/exodus/#0.9.1
http://psi-im.org/#0.11
Again it's a special URL at the software website. The only potential
problem is the inclusion of the '#'
A version is only interesting if you know the software that it goes
with.
Unfortunately all we have is a URI, which means for any sane display
I need a
table of URI-software name mappings, and thus I can only display
versions
for software I know about. That seems limiting.
Not really;
However, from an user perspective... what is the interest of
showing different
icon per client.
Imagine that it's a presence-only device, like a phone, for example.
Arguably, this should be a defined value used in the identity element
-- identity category='client' type='presence'
On Thursday 08 November 2007 4:03 pm, Joe Hildebrand wrote:
On Nov 8, 2007, at 4:47 PM, Justin Karneges wrote:
Maybe in addition to Peter's proposed 'v' attribute, we could have
an 'n'
attribute for the name. This should allow for generic display.
Doesn't that come back in the identity
Joe Hildebrand wrote:
On Nov 8, 2007, at 4:24 PM, Peter Saint-Andre wrote:
Yes it seems a bit funny to have a 'v' attribute:
http://mail.jabber.org/pipermail/standards/2007-August/016680.html
As usual, Rachel is the voice of reason.
I know! I tried to convince her to run for XMPP
On Nov 8, 2007, at 4:49 PM, Olivier Goffart wrote:
I think they should not use that XEP for that.
Too late.
There is jabber:iq:version for that.
I hope not. That was the whole reason we wrote this XEP in the first
place!
And if we want to avoid sending a jabber:iq:version to each, we
Olivier Goffart wrote:
Le jeudi 8 novembre 2007, Peter Saint-Andre a écrit :
5. Objections to the Council change in version 1.4 specifying that the
value of the 'node' attribute should be ProductURL#SoftwareVersion.
I think we should not recommend to add the version number in the node at
20 matches
Mail list logo
