Re: [Standards] presence priority -1 issues
Pavel Simerda wrote: On Tue, 05 Aug 2008 09:16:45 -0600 Peter Saint-Andre <[EMAIL PROTECTED]> wrote: IMHO you'd get account/* from a bare JID and client/* from a full JID. /psa But then account/* should never send presence, no? Right, account/* is service discovery only, not presence. I was just being thorough about what is an "IM" entity and what is not. For entities that generate presence, only the client/* rule would apply. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] presence priority -1 issues
On Tue, 05 Aug 2008 09:16:45 -0600 Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > Maciek Niedzielski wrote: > > Peter Saint-Andre wrote: > >>> I like the part that only client/* should be interpreted as > >>> IM-capable resources, but I don't know if that is too strict. > >> > >> That's probably too strict. At the least I think we'd say that the > >> following identities are IM-capable: > >> > >> account/* > >> client/* > > > > I always thought these two are independent - account/* defines... > > account, client/* describes particular connection. > > So for example, [EMAIL PROTECTED] is account/registered, > > [EMAIL PROTECTED]/calendar is automation/bot and [EMAIL PROTECTED]/chat > > is client/pc (yes, I know resources ids are supposed to be opaque, > > but it was easier to explain this way). > > IMHO you'd get account/* from a bare JID and client/* from a full JID. > > /psa > But then account/* should never send presence, no? -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] presence priority -1 issues
Maciek Niedzielski wrote: Peter Saint-Andre wrote: I like the part that only client/* should be interpreted as IM-capable resources, but I don't know if that is too strict. That's probably too strict. At the least I think we'd say that the following identities are IM-capable: account/* client/* I always thought these two are independent - account/* defines... account, client/* describes particular connection. So for example, [EMAIL PROTECTED] is account/registered, [EMAIL PROTECTED]/calendar is automation/bot and [EMAIL PROTECTED]/chat is client/pc (yes, I know resources ids are supposed to be opaque, but it was easier to explain this way). IMHO you'd get account/* from a bare JID and client/* from a full JID. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] presence priority -1 issues
Peter Saint-Andre wrote: I like the part that only client/* should be interpreted as IM-capable resources, but I don't know if that is too strict. That's probably too strict. At the least I think we'd say that the following identities are IM-capable: account/* client/* I always thought these two are independent - account/* defines... account, client/* describes particular connection. So for example, [EMAIL PROTECTED] is account/registered, [EMAIL PROTECTED]/calendar is automation/bot and [EMAIL PROTECTED]/chat is client/pc (yes, I know resources ids are supposed to be opaque, but it was easier to explain this way). -- Maciek xmpp:[EMAIL PROTECTED]
Re: [Standards] presence priority -1 issues
Pedro Melo wrote: On Aug 5, 2008, at 12:01 AM, Peter Saint-Andre wrote: Pedro Melo wrote: On Jul 31, 2008, at 5:21 PM, Dave Cridland wrote: On Thu Jul 31 17:17:40 2008, Pedro Melo wrote: Moving forward, this would allow clever clients to observe that it wasn't a IM client capable of handling calendaring requests, but a dumb calendaring bot working on behalf of the user. Not following. Clients could have an integrated calendaring app, allowing both chat and calendaring traffic to happen to the same full jid. Alternately, it may only do one or the other. Yes, but then you would only need to publish the proper . What makes a automated system try a certain protocol is the feature, not the identity. The identity automation/calender (per Peter example) is only needed to mark a resource as a non-IM resource. So a clever Calendar application that also allows chat would probably still announce itself with a client/pc but would also set to support cal-dav-over-xmpp, or whatever. Then do we need a feature for "IM" (as in, "sorry, this calendaring resource doesn't do that instant messaging stuff")? I've re-read this thread quickly. I think dwd doesn't like negative features, and I tend to agree with him (although guilty of implementing such a beast in the past). But the need to mark resources as non-im is still there and it's real. It seems that using an in the automation class could be enough to signal non-IM interface. Or put it in another way, maybe we should say that only clients/* should be interpreted as IM-capable resources. I like the part that only client/* should be interpreted as IM-capable resources, but I don't know if that is too strict. That's probably too strict. At the least I think we'd say that the following identities are IM-capable: account/* client/* I'm not 100% sure about client/bot but that seems OK (it's a bot you can chat with). We might want to define automation/bot for other sorts of entities (e.g., bots that handle ad-hoc commands rather than chats). /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] presence priority -1 issues
On Aug 5, 2008, at 12:01 AM, Peter Saint-Andre wrote: Pedro Melo wrote: On Jul 31, 2008, at 5:21 PM, Dave Cridland wrote: On Thu Jul 31 17:17:40 2008, Pedro Melo wrote: Moving forward, this would allow clever clients to observe that it wasn't a IM client capable of handling calendaring requests, but a dumb calendaring bot working on behalf of the user. Not following. Clients could have an integrated calendaring app, allowing both chat and calendaring traffic to happen to the same full jid. Alternately, it may only do one or the other. Yes, but then you would only need to publish the proper . What makes a automated system try a certain protocol is the feature, not the identity. The identity automation/calender (per Peter example) is only needed to mark a resource as a non-IM resource. So a clever Calendar application that also allows chat would probably still announce itself with a client/pc but would also set to support cal-dav-over-xmpp, or whatever. Then do we need a feature for "IM" (as in, "sorry, this calendaring resource doesn't do that instant messaging stuff")? I've re-read this thread quickly. I think dwd doesn't like negative features, and I tend to agree with him (although guilty of implementing such a beast in the past). But the need to mark resources as non-im is still there and it's real. It seems that using an in the automation class could be enough to signal non-IM interface. Or put it in another way, maybe we should say that only clients/* should be interpreted as IM-capable resources. I like the part that only client/* should be interpreted as IM- capable resources, but I don't know if that is too strict. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] presence priority -1 issues
Pedro Melo wrote: On Jul 31, 2008, at 5:21 PM, Dave Cridland wrote: On Thu Jul 31 17:17:40 2008, Pedro Melo wrote: Moving forward, this would allow clever clients to observe that it wasn't a IM client capable of handling calendaring requests, but a dumb calendaring bot working on behalf of the user. Not following. Clients could have an integrated calendaring app, allowing both chat and calendaring traffic to happen to the same full jid. Alternately, it may only do one or the other. Yes, but then you would only need to publish the proper . What makes a automated system try a certain protocol is the feature, not the identity. The identity automation/calender (per Peter example) is only needed to mark a resource as a non-IM resource. So a clever Calendar application that also allows chat would probably still announce itself with a client/pc but would also set to support cal-dav-over-xmpp, or whatever. Then do we need a feature for "IM" (as in, "sorry, this calendaring resource doesn't do that instant messaging stuff")? /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] presence priority -1 issues
On Thu, 31 Jul 2008 20:47:25 +0100 Dave Cridland <[EMAIL PROTECTED]> wrote: > On Thu Jul 31 17:54:32 2008, Pedro Melo wrote: > > > > On Jul 31, 2008, at 5:21 PM, Dave Cridland wrote: > > > >> On Thu Jul 31 17:17:40 2008, Pedro Melo wrote: > Moving forward, this would allow clever clients to observe > that it wasn't a IM client capable of handling calendaring > requests, but a dumb calendaring bot working on behalf of the > user. > >>> Not following. > >> > >> Clients could have an integrated calendaring app, allowing both > >> chat and calendaring traffic to happen to the same full jid. > >> > >> Alternately, it may only do one or the other. > > > > Yes, but then you would only need to publish the proper . > > > > What makes a automated system try a certain protocol is the > > feature, not the identity. The identity automation/calender (per > > Peter example) is only needed to mark a resource as a non-IM > > resource. > > > > > Right, except in the case of IM, features are advertised. But to > advertise a lack of IM, we need to change the identity, since we > don't have an IM feature. > > Of course, it'd really be automation/application, or > automation/daemon, since what kinds of protocols it's an automaton > for is, as you say, down to the features advertised. Protocols/features and the purpose of the application may be different. IMHO it depends on how much you want to distinguish. > > So a clever Calendar application that also allows chat would > > probably still announce itself with a client/pc but would also > > set to support cal-dav-over-xmpp, or whatever. > > Of course - but I'm somewhat against a negative feature, if there's > any alternative. +1 > Dave. Pavel -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] presence priority -1 issues
On Thu Jul 31 17:54:32 2008, Pedro Melo wrote: On Jul 31, 2008, at 5:21 PM, Dave Cridland wrote: On Thu Jul 31 17:17:40 2008, Pedro Melo wrote: Moving forward, this would allow clever clients to observe that it wasn't a IM client capable of handling calendaring requests, but a dumb calendaring bot working on behalf of the user. Not following. Clients could have an integrated calendaring app, allowing both chat and calendaring traffic to happen to the same full jid. Alternately, it may only do one or the other. Yes, but then you would only need to publish the proper . What makes a automated system try a certain protocol is the feature, not the identity. The identity automation/calender (per Peter example) is only needed to mark a resource as a non-IM resource. Right, except in the case of IM, features are advertised. But to advertise a lack of IM, we need to change the identity, since we don't have an IM feature. Of course, it'd really be automation/application, or automation/daemon, since what kinds of protocols it's an automaton for is, as you say, down to the features advertised. So a clever Calendar application that also allows chat would probably still announce itself with a client/pc but would also set to support cal-dav-over-xmpp, or whatever. Of course - but I'm somewhat against a negative feature, if there's any alternative. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] presence priority -1 issues
On Jul 31, 2008, at 5:21 PM, Dave Cridland wrote: On Thu Jul 31 17:17:40 2008, Pedro Melo wrote: Moving forward, this would allow clever clients to observe that it wasn't a IM client capable of handling calendaring requests, but a dumb calendaring bot working on behalf of the user. Not following. Clients could have an integrated calendaring app, allowing both chat and calendaring traffic to happen to the same full jid. Alternately, it may only do one or the other. Yes, but then you would only need to publish the proper . What makes a automated system try a certain protocol is the feature, not the identity. The identity automation/calender (per Peter example) is only needed to mark a resource as a non-IM resource. So a clever Calendar application that also allows chat would probably still announce itself with a client/pc but would also set to support cal-dav-over-xmpp, or whatever. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] presence priority -1 issues
On Jul 31, 2008, at 5:21 PM, Dave Cridland wrote: On Thu Jul 31 17:17:40 2008, Pedro Melo wrote: Moving forward, this would allow clever clients to observe that it wasn't a IM client capable of handling calendaring requests, but a dumb calendaring bot working on behalf of the user. Not following. Clients could have an integrated calendaring app, allowing both chat and calendaring traffic to happen to the same full jid. Alternately, it may only do one or the other. Yes, but then you would only need to publish the proper . What makes a automated system try a certain protocol is the feature, not the identity. The identity automation/calender (per Peter example) is only needed to mark a resource as a non-IM resource. So a clever Calendar application that also allows chat would probably still announce itself with a client/pc but would also set to support cal-dav-over-xmpp, or whatever. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] presence priority -1 issues
On Thu Jul 31 17:17:40 2008, Pedro Melo wrote: Moving forward, this would allow clever clients to observe that it wasn't a IM client capable of handling calendaring requests, but a dumb calendaring bot working on behalf of the user. Not following. Clients could have an integrated calendaring app, allowing both chat and calendaring traffic to happen to the same full jid. Alternately, it may only do one or the other. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] presence priority -1 issues
On Jul 30, 2008, at 8:40 PM, Peter Saint-Andre wrote: Dave Cridland wrote: On Wed Jul 30 13:55:56 2008, Pedro Melo wrote: The most important part of -1 resources are their caps. For example, I can have a calendar app logged in with my own jid, accepting some namespace for calendar updates or meeting requests. Are you suggesting a sort of negative disco feature which indicates that the XMPP entity is not an IM resource at all? Could this be done with a suitable category/type? Moving forward, this would allow clever clients to observe that it wasn't a IM client capable of handling calendaring requests, but a dumb calendaring bot working on behalf of the user. If you're not suggesting this, can I suggest it? :-) I think he's suggesting that the disco identity of your calendar would be something like this: Exactly. But you would need to complement this with to specify the protocol that the agent uses to receive calendar requests/updates. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] presence priority -1 issues
On Jul 30, 2008, at 7:25 PM, Dave Cridland wrote: On Wed Jul 30 13:55:56 2008, Pedro Melo wrote: The most important part of -1 resources are their caps. For example, I can have a calendar app logged in with my own jid, accepting some namespace for calendar updates or meeting requests. Are you suggesting a sort of negative disco feature which indicates that the XMPP entity is not an IM resource at all? Yes, I suggested that in the past. Could this be done with a suitable category/type? Probably. Maybe a new type under automation? See http://www.xmpp.org/registrar/disco-categories.html#automation Moving forward, this would allow clever clients to observe that it wasn't a IM client capable of handling calendaring requests, but a dumb calendaring bot working on behalf of the user. Not following. If you're not suggesting this, can I suggest it? :-) Go crazy :) At SAPO, we used sapo:no-chat as a disco feature for SMS contacts. It would signal compliant clients not to use their presence as an indication of online in a multi-contact setup. This allowed us to have a multi-contact, with IM and SMS Jids, but only using the presence information of the IM contacts. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] presence priority -1 issues
On Wed Jul 30 20:40:13 2008, Peter Saint-Andre wrote: Dave Cridland wrote: On Wed Jul 30 13:55:56 2008, Pedro Melo wrote: The most important part of -1 resources are their caps. For example, I can have a calendar app logged in with my own jid, accepting some namespace for calendar updates or meeting requests. Are you suggesting a sort of negative disco feature which indicates that the XMPP entity is not an IM resource at all? Could this be done with a suitable category/type? Moving forward, this would allow clever clients to observe that it wasn't a IM client capable of handling calendaring requests, but a dumb calendaring bot working on behalf of the user. If you're not suggesting this, can I suggest it? :-) I think he's suggesting that the disco identity of your calendar would be something like this: So you know that it's not something like this: That's what I was hoping he was suggesting. Since if you see it's not a client, but an automaton, then you know not to strike up a conversation with it. Whereas a client/* presumably might have a human on the other end, and so is reasonable to talk to under some circumstances. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] presence priority -1 issues
Dave Cridland wrote: On Wed Jul 30 13:55:56 2008, Pedro Melo wrote: The most important part of -1 resources are their caps. For example, I can have a calendar app logged in with my own jid, accepting some namespace for calendar updates or meeting requests. Are you suggesting a sort of negative disco feature which indicates that the XMPP entity is not an IM resource at all? Could this be done with a suitable category/type? Moving forward, this would allow clever clients to observe that it wasn't a IM client capable of handling calendaring requests, but a dumb calendaring bot working on behalf of the user. If you're not suggesting this, can I suggest it? :-) I think he's suggesting that the disco identity of your calendar would be something like this: So you know that it's not something like this: Peter smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] presence priority -1 issues
On Wed Jul 30 13:55:56 2008, Pedro Melo wrote: The most important part of -1 resources are their caps. For example, I can have a calendar app logged in with my own jid, accepting some namespace for calendar updates or meeting requests. Are you suggesting a sort of negative disco feature which indicates that the XMPP entity is not an IM resource at all? Could this be done with a suitable category/type? Moving forward, this would allow clever clients to observe that it wasn't a IM client capable of handling calendaring requests, but a dumb calendaring bot working on behalf of the user. If you're not suggesting this, can I suggest it? :-) Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] presence priority -1 issues
Hi, (sorry to be late at the discussion) :) On Jul 27, 2008, at 8:26 PM, Kevin Smith wrote: It's possible this is just a UI problem. I remember chatting to Pedro Melo about this back in February, and I believe our conclusion back then was just that clients will start showing -1 as a non-chat resource, or somesuch, depending on how general usage pans out +1. The most important part of -1 resources are their caps. For example, I can have a calendar app logged in with my own jid, accepting some namespace for calendar updates or meeting requests. That would show up on "regular clients" at most with a small calendar icon. But it should not represent a "online" resource, of course. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] presence priority -1 issues
Jack Moffitt wrote: 1. stanzas to the bare JID should not be send to this client because no user will read it. Use message storage or whatever a server may do with such a message. Agreed, and this required by RFC 3921. (Section 11.1 Rule 4.1). 2. stanzas to the full JID should be send to this client. There is a reason why the sender used the full JID for that message. It could be an IBB using message for two non-chat applications exchanging data. Also required by RFC 3921. (section 11.1 Rule 1). 3. should be send to all clients or two non-chat clients will never find each other to send messages to the full JID. Also required by RFC 3921. (Section 11.1 Rule 4.2). OK good, we all agree on the proper behavior and the spec seems to be consistent with those expectations. Now it's just a question of getting implementations to do the right thing. :) /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] presence priority -1 issues
> 1. stanzas to the bare JID should not be send to this client > because no user will read it. Use message storage or whatever a > server may do with such a message. Agreed, and this required by RFC 3921. (Section 11.1 Rule 4.1). > 2. stanzas to the full JID should be send to this client. > There is a reason why the sender used the full JID for that > message. It could be an IBB using message for two non-chat > applications exchanging data. Also required by RFC 3921. (section 11.1 Rule 1). > 3. should be send to all clients or two non-chat clients > will never find each other to send messages to the full JID. Also required by RFC 3921. (Section 11.1 Rule 4.2). Clearly Jabberd2 and Google Talk are not compliant in this respect and need to be fixed. I'm preparing a detailed bug report for both, but if those guys are listening, please fix this asap pretty please... with sugar on top? jack.
Re: [Standards] presence priority -1 issues
"Jack Moffitt" wrote: >>> It's possible this is just a UI problem. >> >> I remember chatting to Pedro Melo about this back in February, and I >> believe our conclusion back then was just that clients will start >> showing -1 as a non-chat resource, or somesuch, depending on how >> general usage pans out > > Ok, fair enough, but there are other problems. > > Jabberd2 and Google Talk both refuse to send presence to resources at > priority -1. IMHO that is wrong compared to the statement above. I agree that -1 means non-chat resource. This can either be a chat client without a user or an application doing something completly different with XMPP. For a -1 priority I would propose: 1. stanzas to the bare JID should not be send to this client because no user will read it. Use message storage or whatever a server may do with such a message. 2. stanzas to the full JID should be send to this client. There is a reason why the sender used the full JID for that message. It could be an IBB using message for two non-chat applications exchanging data. 3. should be send to all clients or two non-chat clients will never find each other to send messages to the full JID. My point is that "non-chat resource" doesn't mean it is an idle chat client, it can be something very much alive but not for chatting. Dirk -- Life is complex, it has a real part and an imaginary part.
Re: [Standards] presence priority -1 issues
On Mon, Jul 28, 2008 at 5:53 AM, Jack Moffitt <[EMAIL PROTECTED]> wrote: > Jabberd2 and Google Talk both refuse to send presence to resources at > priority -1. This is fatal for us with Speeqe since this means you > will never receive muc presence from the room. I haven't tested this > yet with Palaver, but this is the case with ejabberd 2.x muc component > when using either jabberd2 or google talk accounts to access them. That sounds like a bug, to me, but if the spec isn't clear, perhaps it can be modified. /K
Re: [Standards] presence priority -1 issues
>> It's possible this is just a UI problem. > > I remember chatting to Pedro Melo about this back in February, and I > believe our conclusion back then was just that clients will start > showing -1 as a non-chat resource, or somesuch, depending on how > general usage pans out Ok, fair enough, but there are other problems. Jabberd2 and Google Talk both refuse to send presence to resources at priority -1. This is fatal for us with Speeqe since this means you will never receive muc presence from the room. I haven't tested this yet with Palaver, but this is the case with ejabberd 2.x muc component when using either jabberd2 or google talk accounts to access them. I hope that I am just missing something. jack.
Re: [Standards] presence priority -1 issues
> It's possible this is just a UI problem. I remember chatting to Pedro Melo about this back in February, and I believe our conclusion back then was just that clients will start showing -1 as a non-chat resource, or somesuch, depending on how general usage pans out /K
Re: [Standards] presence priority -1 issues
It's possible this is just a UI problem. http://blog.jabber.com/filaments/2008/03/11/priority-1-presence/ -1 resources should be included in the probe response. On Jul 24, 2008, at 11:57 AM, Jack Moffitt wrote: At XMPP Summit 5 this past week it became clear that lots of people are using or are planning to use presence priorities of -1 to allow specialized clients access to various XMPP resources. At Speeqe we do this so that our MUC client doesn't steal private messages. I believe that Fritzy at Seesmic said that Twhirl would soon start doing this now that they have XMPP support there for Identi.ca. This has lead me to discover some small usability problems. It looks like the spec requires that users with presence priority -1 be shown as available, but I'm not sure if I'm missing something in the spec or if it is just underspecced. http://www.xmpp.org/rfcs/rfc3921.html#presence-resp-probes says that the server must reply from all "available" resources, but it does not say how this interacts with negative presence priorities. The unwelcome side-effect of this is that if you are online only in negative priority mode you show as available to all your contacts, but you cannot receive any messages to the bare jid. This is pretty confusing for people trying to talk to you. Is this a nuisance we have to live with? Can a clarification be made here? Can the different server authors tell us what they have done in this edge case? Thoughts? jack.
[Standards] presence priority -1 issues
At XMPP Summit 5 this past week it became clear that lots of people are using or are planning to use presence priorities of -1 to allow specialized clients access to various XMPP resources. At Speeqe we do this so that our MUC client doesn't steal private messages. I believe that Fritzy at Seesmic said that Twhirl would soon start doing this now that they have XMPP support there for Identi.ca. This has lead me to discover some small usability problems. It looks like the spec requires that users with presence priority -1 be shown as available, but I'm not sure if I'm missing something in the spec or if it is just underspecced. http://www.xmpp.org/rfcs/rfc3921.html#presence-resp-probes says that the server must reply from all "available" resources, but it does not say how this interacts with negative presence priorities. The unwelcome side-effect of this is that if you are online only in negative priority mode you show as available to all your contacts, but you cannot receive any messages to the bare jid. This is pretty confusing for people trying to talk to you. Is this a nuisance we have to live with? Can a clarification be made here? Can the different server authors tell us what they have done in this edge case? Thoughts? jack.
