When I register with PyICQ-t with wrong password, the following
happens:
C: register set
S: register result
S: subscribe
C: subscribed
C: subscribe
S: subscribed
S: message error "Authentication Error! ..."
S: unavailable
This is difficult to understand for automated clients. I suggest
either of the following:
* Registering with wrong password immediately returns an IQ error.
This would be ideal from a UI perspective, but maybe it's not
desirable to log in on registration.
* Return the following kind of presence:
<presence from='icq.example.com' type='error'>
<error type='auth'>
<not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</presence>
Sending a <message/> should probably be kept, for clarity for users.
However, I think it shouldn't be of type "error", as that is meant for
error responses to messages sent by the user (at least, that's how I
read XMPP-CORE[0]). Additionally, it doesn't contain the required
<error/> child.
Magnus
[0] http://www.xmpp.org/specs/rfc3920.html#stanzas-error
From [EMAIL PROTECTED] Sat May 21 16:26:01 2005
From: [EMAIL PROTECTED] (Norman Rasmussen)
Date: Sat May 21 16:26:20 2005
Subject: [py-transports] MSN transport
Message-ID: <[EMAIL PROTECTED]>
For benefit of all, but James in particular:
Small MSN feature request / cosmetic bugs:
- it would be useful to support iq:version for each contact - at the
moment it seems to return a version'less presence from the transport
if a individuals version is queried
- if a client sets a status, and then in a future presence does not
include a status, then the status does not change - this should rather
remove the current status.
I might be able to do this myself, but I figure why not share my ideas :-)
--
- Norman Rasmussen
- Email: [EMAIL PROTECTED]
- Home page: http://norman.rasmussen.org/
From [EMAIL PROTECTED] Sat May 21 23:15:17 2005
From: [EMAIL PROTECTED] (Norman Rasmussen)
Date: Sat May 21 23:15:23 2005
Subject: [py-transports] MSN transport - can't add users properly
Message-ID: <[EMAIL PROTECTED]>
I add someone, and give them auth (eg
[EMAIL PROTECTED]), and then I get auth from the raw
address [EMAIL PROTECTED], instead of
[EMAIL PROTECTED]
Eventually I do get the auth for the correct address though (how weird)
I also saw this error:
05/22/05 - 00:56:42 - Traceback (most recent call last):
05/22/05 - 00:56:42 - File
"/usr/lib/python2.3/site-packages/twisted/internet/default.py", line
526, in doSelect
05/22/05 - 00:56:44 - _logrun(selectable, _drdw, selectable, method, dict)
05/22/05 - 00:56:44 - File
"/usr/lib/python2.3/site-packages/twisted/python/log.py", line 65, in
callWithLogger
05/22/05 - 00:56:44 - callWithContext({"system": lp}, func, *args, **kw)
05/22/05 - 00:56:44 - File
"/usr/lib/python2.3/site-packages/twisted/python/log.py", line 52, in
callWithContext
05/22/05 - 00:56:44 - return context.call({ILogContext: newCtx},
func, *args, **kw)
05/22/05 - 00:56:44 - File
"/usr/lib/python2.3/site-packages/twisted/python/context.py", line 43,
in callWithContext
05/22/05 - 00:56:45 - return func(*args,**kw)
05/22/05 - 00:56:45 - --- <exception caught here> ---
05/22/05 - 00:56:45 - File
"/usr/lib/python2.3/site-packages/twisted/internet/default.py", line
535, in _doReadOrWrite
05/22/05 - 00:56:45 - why = getattr(selectable, method)()
05/22/05 - 00:56:45 - File
"/usr/lib/python2.3/site-packages/twisted/internet/tcp.py", line 255,
in doRead
05/22/05 - 00:56:45 - return self.protocol.dataReceived(data)
05/22/05 - 00:56:45 - File
"/usr/lib/python2.3/site-packages/twisted/protocols/basic.py", line
223, in dataReceived
05/22/05 - 00:56:45 - why = self.lineReceived(line)
05/22/05 - 00:56:45 - File
"/usr/src/cvs/msn-transport/PyMSNt/src/tlib/msn.py", line 665, in
lineReceived
05/22/05 - 00:56:45 - try: handler(params.split())
05/22/05 - 00:56:45 - File
"/usr/src/cvs/msn-transport/PyMSNt/src/tlib/msn.py", line 1028, in
handle_ADC
05/22/05 - 00:56:46 - self.userAddedMe(userGuid, userHandle, screenName)
05/22/05 - 00:56:46 - File
"/usr/src/cvs/msn-transport/PyMSNt/src/legacy/msnw.py", line 535, in
userAddedMe
05/22/05 - 00:56:46 - debug.log("NotificationClient: \"%s\"
userAddedMe(\"%s\", \"%s\")" % (self.factory.userHandle, userHandle))
05/22/05 - 00:56:46 - exceptions.TypeError: not enough arguments for
format string
Not 110% sure they're related but it's a guess.
--
- Norman Rasmussen
- Email: [EMAIL PROTECTED]
- Home page: http://norman.rasmussen.org/
From [EMAIL PROTECTED] Sun May 22 01:17:11 2005
From: [EMAIL PROTECTED] (Chris Carlin)
Date: Sun May 22 01:17:15 2005
Subject: [py-transports] Storing messages on not available?
Message-ID: <[EMAIL PROTECTED]>
Are there any thoughts on storing messages when a user has the status of
"not available" and then passing them on once he's returned to online or
simply away?
Would such behavior be against Jabber policy or The Jabber Way?
Just a thought I had...
~Chris
From [EMAIL PROTECTED] Sun May 22 01:45:58 2005
From: [EMAIL PROTECTED] (James Bunton)
Date: Sun May 22 01:46:19 2005
Subject: [py-transports] Storing messages on not available?
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Not a good idea.
The main problem is in this case.
* User sends message to offline contact and assumes the message will be
seen when contact returns online
* User goes offline (gateway gets disconnected)
* Time passes
* User goes online in another client, sees contact online. Contact
hasn't received message yet.
OR * User goes online again, but contact has already been and gone
without the message being delivered.
The gateways can only deliver messages when the user is online. So
holding them isn't a good idea.
Better to try and convince your friends to get Jabber :)
---
James
On 22/05/2005, at 11:17 AM, Chris Carlin wrote:
> Are there any thoughts on storing messages when a user has the status
> of "not available" and then passing them on once he's returned to
> online or simply away?
>
> Would such behavior be against Jabber policy or The Jabber Way?
>
> Just a thought I had...
>
> ~Chris
> _______________________________________________
> py-transports mailing list
> [email protected]
> http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports
>
