Re: [Standards] What should be the behavior if used sends element to the server ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/14/09 2:56 AM, Sand T wrote: > Hi, Hi. If you could, please preface your messages with "XEP-0136". That makes it easier to track the issues. > Following statement is mentioned in XEP 0136: > > In order to remove all preferences for a contact, the client shall send > an element to the server. > > Example 11. Client Removes Preferences for a Contact > > Kindly explain, what should be the server behavior if tag > is sent by the user? What do you mean by "user"? The client is a client controlled by the user, so I don't see a difference here. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoSEV8ACgkQNL8k5A2w/vxdEACfZdTaHMnXM5SOYff2zQ6fAHNp 8cAAoKij6UV7O208dQNAh3flJOAWwfam =lg8u -END PGP SIGNATURE-
Re: [Standards] XEP-0136 - Setting archiving preferences for a domain
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/17/09 10:58 PM, Sandip Nemade wrote: > Hi, >The xep-0136 has not given any example of setting an archiving > preferences for a domain. How exactly setting archiving preferences for > a domain needs to be handled? Isn't that defined here? http://xmpp.org/extensions/xep-0136.html#pref-archive Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoSEK8ACgkQNL8k5A2w/vzsKACg1qIo1IP0tXESN5a1P897Qfhf lV8Anj+3HJDIVSS8xM/HBsG7w5j9MYI9 =K90Q -END PGP SIGNATURE-
[Standards] XEP-0256 use cases
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
XEP-0256 (Last Activity in Presence) illustrates one use case for
including Last Activity (XEP-0012) information in a presence stanza,
namely auto-away ("when my client sent this auto-away notice I was away
for X seconds").
Today Joe Hildebrand and I got to talking about another use case: when
sending initial presence, include a Last Activity notation to indicate
when you were last active before logging in this time. This usage could
be used by the recipient to do Smart Things related to notifications.
For example, a pubsub service could send you all the published items you
missed while you were offline, thus enabling you to sync up with regard
to news, market information, PEP notifications, etc.
Peter
- --
Peter Saint-Andre
https://stpeter.im/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkoSCdQACgkQNL8k5A2w/vyaWgCdHepVyi6nhEVMv23MOa3Qy6dR
IYwAn3u8GRaDe2SLpxQMgPw1v5p/fK4Z
=mCxd
-END PGP SIGNATURE-
[Standards] interop testing effort
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nathan Fritz has been pushing for a kick-ass interoperability testing effort, kind of a real-time analogue to http://validator.w3.org/ but for XMPP. See this post and follow-ups: http://mail.jabber.org/pipermail/members/2009-May/005084.html We will hold a meeting about this on Thursday, May 21 at 18:00 UTC in the xmpp:foundat...@conference.jabber.org room. See you then! Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoR4W4ACgkQNL8k5A2w/vxvMgCgtrzmFN5o8eYPix73ZNMPdRwJ O6QAoJ7evWtWvOGlMc697Up20C+D1Nkq =NMoX -END PGP SIGNATURE-
Re: [Standards] SIFT
2009/5/18 Jiří Zárevúcky : > Well, until now I believed that "unavailable" presence doesn't mean > "show me offline", but "make me unavailable for presence exchange and > messaging". But you're right, it doesn't really matter. > > Anyway, if SIFT capable client went invisible mid-session, it could do > so by sending unavailable presence. But possibly without any prior > SIFT command. So I think it should be noted that either supporting > client must use sift to initiate it's "SIFT based session" prior to > using such invisibility, or the server must not terminate the > communication availability even when there was no explicit SIFT. If > it is not specified, the first possibility should be implicit for the > client developer to avoid problems, but I'm afraid not everyone would > realize that. Agree. The default is not to sift, and we may not have captured that adequately in the draft yet. We also need to make it explicit that you can change your sift rules at any time. There is still a use case for priority -1 presence; I'm a presence publisher that doesn't want to receive messages. The -1 here is a hint to the sender that they shouldn't expect me to get this message if they send it right now. We probably need to add text like this: If a client requests message sifting, but sends presence, it SHOULD send priority -1 as a hint to subscribers. -- Joe Hildebrand
Re: [Standards] SIFT
2009/5/18 Peter Saint-Andre : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 5/16/09 6:45 AM, Jiří Zárevúcky wrote: >> Hello. The filtering/intercepting functionality seems nice for IQ >> stanzas, but I have doubts about some of the use cases. >> >> "Invisibility" as defined by this spec would certainly ease it's >> handling by both client and server, > > Simplification is a good thing, no? (Aside from the fact that > invisibility is stupid, if we're going to support it then we might as > well support it in the simplest way possible.) > Sure. >> but is changes the meaning of >> available and unavailable presence stanzas. > > How so? > > still means "tell my contacts that I'm online". > > still means "tell my contacts that I'm > offline". > >> That means servers that >> support SIFT will understand them differently than servers that do >> not. > > Yes, SIFT separates presence probing and inbound presence delivery from > the sending of outbound presence notifications. I don't yet see any > major problems with that, because the client will discover whether the > server supports SIFT before it starts sending presence. > Well, until now I believed that "unavailable" presence doesn't mean "show me offline", but "make me unavailable for presence exchange and messaging". But you're right, it doesn't really matter. Anyway, if SIFT capable client went invisible mid-session, it could do so by sending unavailable presence. But possibly without any prior SIFT command. So I think it should be noted that either supporting client must use sift to initiate it's "SIFT based session" prior to using such invisibility, or the server must not terminate the communication availability even when there was no explicit SIFT. If it is not specified, the first possibility should be implicit for the client developer to avoid problems, but I'm afraid not everyone would realize that. >> Also, if I understand it correctly, the empty sift query means >> "don't filter anything" and not "send me all now". If you use it as an >> "on" switch, you are overloading it's functionality. > > How so? > > 1. I log in. > > 2. I discover that my server supports SIFT. > > 3. I send empty . > > 4. Server sends me offline messages and probes my contacts. > > Why does empty need to mean either "don't filter anything" or > "sync me up" but not both? > It's actually not said that the request also means "start sending everything that's not to be intercepted". It's only implied by the business rules. I think it should be added to the definition. >> The second (possible) problem is that when you use it to filter >> messages (which you can do by negative priority), your contacts >> wouldn't know it. If you have negative priority, everyone sees you >> can't receive messages. That is not the case here. I think the spec >> should at least define an error response to notify sender the entity >> can't receive messages. > > The intent is that SIFT removes the need for negative priorities. Why is > it necessary to advertise the fact that the client doesn't want to > receive messages addressed to the bare JID? And what would a contact do > wtih that information? In general we recommend that you send a message > to the bare JID when you want to initiate a chat, not send to the full > JID of a particular resource. I don't see a big (or even any) problem here. > Oh, sorry. I thought the rule applies to any message, even specifically addressed. I have to read more carefully next time. >> And to be complete, I'd appreciate an example of "excepting" multiple >> payload types for IQ's. Thanks :) > > Done in 0.0.4. > > Peter > You've forgotten to update human language "translation". :)
Re: [Standards] SIFT
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/16/09 6:45 AM, Jiří Zárevúcky wrote: > Hello. The filtering/intercepting functionality seems nice for IQ > stanzas, but I have doubts about some of the use cases. > > "Invisibility" as defined by this spec would certainly ease it's > handling by both client and server, Simplification is a good thing, no? (Aside from the fact that invisibility is stupid, if we're going to support it then we might as well support it in the simplest way possible.) > but is changes the meaning of > available and unavailable presence stanzas. How so? still means "tell my contacts that I'm online". still means "tell my contacts that I'm offline". > That means servers that > support SIFT will understand them differently than servers that do > not. Yes, SIFT separates presence probing and inbound presence delivery from the sending of outbound presence notifications. I don't yet see any major problems with that, because the client will discover whether the server supports SIFT before it starts sending presence. > Also, if I understand it correctly, the empty sift query means > "don't filter anything" and not "send me all now". If you use it as an > "on" switch, you are overloading it's functionality. How so? 1. I log in. 2. I discover that my server supports SIFT. 3. I send empty . 4. Server sends me offline messages and probes my contacts. Why does empty need to mean either "don't filter anything" or "sync me up" but not both? > The second (possible) problem is that when you use it to filter > messages (which you can do by negative priority), your contacts > wouldn't know it. If you have negative priority, everyone sees you > can't receive messages. That is not the case here. I think the spec > should at least define an error response to notify sender the entity > can't receive messages. The intent is that SIFT removes the need for negative priorities. Why is it necessary to advertise the fact that the client doesn't want to receive messages addressed to the bare JID? And what would a contact do wtih that information? In general we recommend that you send a message to the bare JID when you want to initiate a chat, not send to the full JID of a particular resource. I don't see a big (or even any) problem here. > And to be complete, I'd appreciate an example of "excepting" multiple > payload types for IQ's. Thanks :) Done in 0.0.4. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoRh6gACgkQNL8k5A2w/vxLgACfbQ4ZbyvFvbod0NNNnLrLTsh8 QzoAoO8dFXC/oEU6JAo/FjXciM5tc2V7 =DQKt -END PGP SIGNATURE-
