Re: [Standards] XEP-0115 redux

2008-01-17 Thread Kevin Smith
On Jan 15, 2008 8:06 PM, Dave Cridland [EMAIL PROTECTED] wrote: Would it be reasonable to cache iq:version results against node+ver+v of the XEP-115 if the hash attribute exists? It doesn't really work, since the node+ver+v doesn't contain as much info as the iq:version does. There's no

Re: [Standards] XEP-0115 redux

2008-01-17 Thread Kevin Smith
On Jan 17, 2008 6:42 AM, Rachel Blackman [EMAIL PROTECTED] wrote: Seriously, we're talking about breaking a really good protocol for information that is only mildly useful... Sure, but then recognize some people will iq:version flood because they'll feel the need to query an entire contact

Re: [Standards] XEP-0115 redux

2008-01-17 Thread Peter Saint-Andre
Kevin Smith wrote: On Jan 15, 2008 8:06 PM, Dave Cridland [EMAIL PROTECTED] wrote: Would it be reasonable to cache iq:version results against node+ver+v of the XEP-115 if the hash attribute exists? It doesn't really work, since the node+ver+v doesn't contain as much info as the iq:version

Re: [Standards] Authentication via XMPP (Concern over XEP-70)

2008-01-17 Thread Peter Saint-Andre
Maciek Niedzielski wrote: Yet another alternative is to change protocol flow: 1. server sends you auth agent JID (and only this) as realm 2. users asks agent (via XMPP) for one-time-tokenn/password 3. users provides this token as HTTP auth password (leaving username blank) Advantages are: *

Re: [Standards] XEP-0115 redux

2008-01-17 Thread Dave Cridland
On Thu Jan 17 18:08:54 2008, Kevin Smith wrote: I confess that I'm starting to wonder what the difference is between iq version floods and presence floods when you log on. I thought about this, too. Let us suppose a user with N contacts in the roster who are online at the moment the user

Re: [Standards] Client/version Display

2008-01-17 Thread Peter Saint-Andre
Rachel Blackman, ever the voice of reason, wrote: That said, we've probably spent more than enough time on this aspect of the discussion. So if everyone else is fine with just saying 'users want this and iq:version is sufficient, let's just trust the client authors to query in a sane

[Standards] Client/version Display (was: XEP-0115 redux)

2008-01-17 Thread Rachel Blackman
On Jan 17, 2008 6:42 AM, Rachel Blackman [EMAIL PROTECTED] wrote: Seriously, we're talking about breaking a really good protocol for information that is only mildly useful... Sure, but then recognize some people will iq:version flood because they'll feel the need to query an entire contact

Re: [Standards] XEP-0115 redux

2008-01-17 Thread Peter Saint-Andre
Dave Cridland wrote: On Thu Jan 17 18:08:54 2008, Kevin Smith wrote: I confess that I'm starting to wonder what the difference is between iq version floods and presence floods when you log on. I thought about this, too. Let us suppose a user with N contacts in the roster who are online at

Re: [Standards] XEP-0115 redux

2008-01-17 Thread Dave Cridland
On Thu Jan 17 18:15:02 2008, Kevin Smith wrote: On Jan 15, 2008 8:06 PM, Dave Cridland [EMAIL PROTECTED] wrote: Would it be reasonable to cache iq:version results against node+ver+v of the XEP-115 if the hash attribute exists? It doesn't really work, since the node+ver+v doesn't contain as

Re: [Standards] XEP-0115 redux

2008-01-17 Thread Peter Saint-Andre
Peter Saint-Andre wrote: Peter Saint-Andre wrote: Well we're almost there, we could just put everything in caps and be done with it: OK check it out and see what you think: http://www.xmpp.org/extensions/tmp/xep-0115-1.5.html

Re: [Standards] XEP-0115 redux

2008-01-17 Thread Peter Saint-Andre
Peter Saint-Andre wrote: Well we're almost there, we could just put everything in caps and be done with it: OK let's look at the numbers. I log in and send presence with FullCaps: presence from='[EMAIL PROTECTED]/roundabout' c xmlns='http://jabber.org/protocol/caps' hash='sha-1'

Re: [Standards] XEP-0115 redux

2008-01-17 Thread Alexander Gnauck
Peter Saint-Andre schrieb: This puts things in a bit of a different light. I might change presence 8+ times during a presence session, but I'd bet that most users don't do change presence that often. Therefore it seems to me that plunking n+os+v in caps is not evil from the perspective of

Re: [Standards] XEP-0115 redux

2008-01-17 Thread Rachel Blackman
This puts things in a bit of a different light. I might change presence 8+ times during a presence session, but I'd bet that most users don't do change presence that often. Therefore it seems to me that plunking n+os+v in caps is not evil from the perspective of bandwidth usage. +1

Re: [Standards] XEP-0115 redux

2008-01-17 Thread Kevin Smith
On Jan 17, 2008 9:43 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote: We'll run it up the flagpole and see who salutes. :) I'll drink to that. Per Dave's comment: I don't see an attack. What one could do, with the previously suggested method (not the current xep proposal) is to claim to be Psi

Re: [Standards] XEP-0115 redux

2008-01-17 Thread Pedro Melo
Hi, On Jan 17, 2008, at 8:45 PM, Peter Saint-Andre wrote: So each time I send presence I generate another 16,000 bytes. Therefore I would need to change presence 8.5 times during the life of my presence session to equal the iq:version request+response interaction that I would have

Re: [Standards] XEP-0115 redux

2008-01-17 Thread Peter Saint-Andre
Pedro Melo wrote: Hi, On Jan 17, 2008, at 8:45 PM, Peter Saint-Andre wrote: So each time I send presence I generate another 16,000 bytes. Therefore I would need to change presence 8.5 times during the life of my presence session to equal the iq:version request+response interaction that I

[Standards] XEP-0174 v. 1.1pre3

2008-01-17 Thread Peter Saint-Andre
Thanks to feedback from Justin Karneges, I have clarified and corrected a few points in the provisional version 1.1 of XEP-0174 (Link-Local Communications): http://www.xmpp.org/extensions/tmp/xep-0174-1.1.html http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0174.xml?r1=1555r2=1588