Joe Hildebrand wrote:
>
> 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 ex
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 receiv
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 disco#info
request at a node you don't know about, you should reply as if t
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 ma
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
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
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 st
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 a
Rachel Blackman wrote:
>>>node='http://code.google.com/p/exodus/'
v='0.9.1'
ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
AND...
Then do you display the following?
Software: Exodus 0.9.1 0.9.1
>>>
>>> "If the name string contains
AND...
Then do you display the following?
Software: Exodus 0.9.1 0.9.1
"If the name string contains the version string..."
strcasestr(clientname,version) == 1
But how do you know what a version string is? Just lots of fancy
regexes?
name='Exodus 0.9.1'
v='0.9.1'
strcasestr("Exodu
Rachel Blackman wrote:
>>> ...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?
>>
>>
>> > node='http://code.
...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?
AND...
Then do you display the following?
Software: Exodus
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 d
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
-- or
whatever -- and handled accordingly. (And yes
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;
Le vendredi 9 novembre 2007, Joe Hildebrand a écrit :
> > 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.
And are you supposed to know a client named "FooBar2000" is a
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 id
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 tags in the disco#info
response? If you want this info, you
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
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
Le vendredi 9 novembre 2007, Joe Hildebrand a écrit :
> On Nov 8, 2007, at 3:52 PM, Olivier Goffart wrote:
> > I even think we should specify a fixed value for the node attribute.
> > such as node="jabber.org/caps-x"
> > So client that support the 1.3 version of the XEP still works.
>
> That's an
On Thursday 08 November 2007 3:18 pm, 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 a
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 t
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 poten
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 '#' c
On Nov 8, 2007, at 3:52 PM, Olivier Goffart wrote:
I even think we should specify a fixed value for the node attribute.
such as node="jabber.org/caps-x"
So client that support the 1.3 version of the XEP still works.
That's an interesting idea, but one of the use cases in the XEP is
still im
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
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 all,
specially if the ve
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=1194&r2=1362
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
http://mail.jabber.org/
30 matches
Mail list logo
