On 5/11/06, Wendell Turner <[EMAIL PROTECTED]> wrote: > On Thu, May 11, 2006 at 12:08:19AM +0200, Norman Rasmussen wrote: > > > What's you config file's <host> set to? Is it a valid public IP or dns > > entry? > > Yes, the <host> entry is the valid (outside) IP address of the > PyMSNt machine. The <jid> is the same hostname with 'msn.' in > front of it, which is not dns-resolvable. That name doesn't > need to be resolvable, does it?
Only if you want people on _other_ servers to be able to use it. Even then, they can force the dns at there end if they really want to access the transport. Lack of dns isn't a safe way to 'secure' your transports from external users with their own servers. -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/ From [EMAIL PROTECTED] Thu May 11 10:11:25 2006 From: [EMAIL PROTECTED] (Alexey Nezhdanov) Date: Thu May 11 10:11:36 2006 Subject: [py-transports] TNs in pyMSN-t Message-ID: <[EMAIL PROTECTED]> Hello. I noticed this small bug in pyMSN-t: TN works for first message only if user of Native MSN client continuously sends several messages to jabber user. I think that it is happens because of that in MSN "TN on" state are terminated only with "TN off" packet whereas in jabber it is reset also by usual message. So the scheme is: 1. User starts typing in native MSN client. both MSN and jabber switches to "TN on" state 2. User sends message and continues with typing second message. MSN stays in "TN on" state whereas jabber already reset to "TN off" since message received. 3. Case (2) repeated several times 4. User stops typing, some time passes, MSN client sends "TN off" packet. MSN is reset to "TN off" state, jabber client ignores. 5. go to 1 If the problem really this - then it should be fixed by sending additional "TN on" packet right after message packet if TN was "on" before this message. -- Respectfully Alexey Nezhdanov
