The whole point of using the hash is it's a global fingerprint of the file. If one user used sha1 and another user used xyz, then they might generate the same hash for seperate files. What's the client supposed to do then? Store one image per roster item?
What happens if a bunch of users use the same image, in different clients. The sha1 hashes of all the images are identical, but each user's client sends a different key because they calcuate it differently. This means you download the same image more than once which is bad. The simple and easy fix is that all new implementions use the raw image data. PyMSNt's changing of the image format is so that the legacy network clients can display the data correctly. Although I have seen an MSN contact with an animated gif, obviously PyMSNt breaks that image :-(. PyMSNt probably shouldn't change the image type, it should make the client do that. (keeps code simple too) On 12/6/05, Pedro Melo <[EMAIL PROTECTED]> wrote: > Hello, > > On Dec 5, 2005, at 6:15 PM, Norman Rasmussen wrote: > > > and when the hash changes, and you get the vcard, you have to 'assume' > > that the presence hash matches the hash of the image data, because > > other users _might_ send the same presence. > > And this is bad why? > > > FYI: JEP-0153 is a Historical JEP, i.e. it attempts to provide > > documentation of a protocol that is already in use within the > > Jabber/XMPP community. i.e. When in doubt refer to clients that > > implemeted the protocol before the JEP was written. > > Correct, yet what I'm suggesting will make your client work no matter > what other clients do. > > And is still valid. > > > in this case a _tiny_ change to gajim, or we change all of: > > JEP-0153/Psi/Kopete/iChat/PyMSNt/etc/etc. > > I all for clarification. We should SHA1 the binary representation of > the image always. But I still think that even then you should use the > hash blindly. > > For ex: pyMSNt changes the image format from whatever you send to a > PNG. If some other server does the same, you might get it wrong. > > Best regards, > > > > On 12/5/05, Pedro Melo <[EMAIL PROTECTED]> wrote: > >> But is included in the presence. > >> > >> If the hash is absent from the presence, you should not use the photo > >> as avatar, per jep 0153 spec. At least that's my reading of items 1 > >> and 2 of section 4.1. > >> > >> Best regards, > >> > >> On Dec 5, 2005, at 5:32 PM, Norman Rasmussen wrote: > >> > >>> Except that the hash is not included in the vCard. > >>> > >>> On 12/5/05, Pedro Melo <[EMAIL PROTECTED]> wrote: > >>>> Hi > >>>> > >>>> Another solution for this, would be to treat the hash as an opaque > >>>> value. > >>>> > >>>> That means that the client should store the image and the hash that > >>>> was used. > >>>> > >>>> This way, it doesn't matter how the hash was generated. > >>>> > >>>> Best regards, > >>>> > >>>> On Dec 5, 2005, at 2:59 PM, Norman Rasmussen wrote: > >>>> > >>>>> On 12/5/05, Jeff Licquia <[EMAIL PROTECTED]> wrote: > >>>>>> > >>>>>> Iris (Psi, Kopete) doesn't seem to use the hash at all. I was > >>>>>> unable to > >>>>>> find other examples of avatar handling in client source. > >>>>> > >>>>> The Pedrito build of Psi _does_ cache images, you would have to > >>>>> check > >>>>> the patches applied there to make sure. > >>>>> > >>>>>> The JEP should probably be clearer on this point. > >>>>> > >>>>> I have a bone to pick with 'base64' encoding. Some > >>>>> implementations > >>>>> create a newline after every 64 characters, others don't. Across > >>>>> different platforms, these newlines will differ: \n (*nix) vs \r\n > >>>>> (win32) vs \r (mac). As an absolute minimum _if_ the hash is > >>>>> computed > >>>>> using the base64 encoded data, the newlines must be removed. > >>>>> > >>>>> All this confusion is removed if the hash is computed on the raw > >>>>> image > >>>>> data. Also it's far simpler to compute the hash on the raw data > >>>>> using > >>>>> _any_ tool. (i.e. openssl, sha1sum, etc) > >>>>> > >>>>> -- > >>>>> - Norman Rasmussen > >>>>> - Email: [EMAIL PROTECTED] > >>>>> - Home page: http://norman.rasmussen.co.za/ > >>>>> _______________________________________________ > >>>>> py-transports mailing list > >>>>> py-transports@blathersource.org > >>>>> http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports > >>>> > >>>> -- > >>>> HIId: Pedro Melo > >>>> SMTP: [EMAIL PROTECTED] > >>>> XMPP: [EMAIL PROTECTED] > >>>> > >>>> _______________________________________________ > >>>> py-transports mailing list > >>>> py-transports@blathersource.org > >>>> http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports > >>>> > >>> > >>> > >>> -- > >>> - Norman Rasmussen > >>> - Email: [EMAIL PROTECTED] > >>> - Home page: http://norman.rasmussen.co.za/ > >>> _______________________________________________ > >>> py-transports mailing list > >>> py-transports@blathersource.org > >>> http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports > >> > >> -- > >> HIId: Pedro Melo > >> SMTP: [EMAIL PROTECTED] > >> XMPP: [EMAIL PROTECTED] > >> > >> _______________________________________________ > >> py-transports mailing list > >> py-transports@blathersource.org > >> http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports > >> > > > > > > -- > > - Norman Rasmussen > > - Email: [EMAIL PROTECTED] > > - Home page: http://norman.rasmussen.co.za/ > > _______________________________________________ > > py-transports mailing list > > py-transports@blathersource.org > > http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports > > -- > HIId: Pedro Melo > SMTP: [EMAIL PROTECTED] > XMPP: [EMAIL PROTECTED] > > _______________________________________________ > py-transports mailing list > py-transports@blathersource.org > http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports > -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/ From [EMAIL PROTECTED] Tue Dec 6 18:24:49 2005 From: [EMAIL PROTECTED] (Eric Langheinrich) Date: Tue Dec 6 18:24:58 2005 Subject: [py-transports] Installing PyAIM with Jabber2 In-Reply-To: <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Tcpdump shows traffic that looks okay. I'm not writing out a separate jabber-router.log file, but maybe that's something I'll change today. Right now everything is going to syslog. Output looks like Dec 6 11:11:20 mail jabberd/c2s[5935]: [8] [X.X.X.X, port=2298] connect Dec 6 11:11:22 mail jabberd/c2s[5935]: [8] SASL authentication succeeded: mechanism=DIGEST-MD5; [EMAIL PROTECTED] Dec 6 11:11:22 mail jabberd/c2s[5935]: [8] bound: [EMAIL PROTECTED]/Exodus Dec 6 11:11:22 mail jabberd/c2s[5935]: [8] requesting session: [EMAIL PROTECTED]/Exodus Dec 6 11:11:22 mail jabberd/sm[5933]: session started: [EMAIL PROTECTED]/Exodus Dec 6 11:12:07 mail jabberd/resolver[5932]: [aim.mydomain.org] resolved to [X.X.X.X:5269] (86400 seconds to live) Dec 6 11:13:17 mail jabberd/c2s[5935]: [8] [X.X.X.X, port=2298] disconnect Dec 6 11:13:17 mail jabberd/sm[5933]: session ended: [EMAIL PROTECTED]/Exodus I'm a little confused about the aim gateway being resolved. But that could just be my ignorance. Do I need to make any changes to the jabber xml files aside from adding the following to the router.xml file? <!-- These users can bind names other than their username --> <acl type='bind'> <user>pyaimt_user</user> </acl> Thank you, -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Norman Rasmussen Sent: Tuesday, December 06, 2005 2:51 AM To: PyAIM-t/PyICQ-t/PyMSN-t Discussion Subject: Re: [py-transports] Installing PyAIM with Jabber2 odd, what's in the jabberd-router.log file? if you run a tcpdump/tcpflow, is there any data being sent back and forth?
