Re: [Standards] XEP-0237 Roster Versioning question
On wto, 2009-07-14 at 04:40 +0200, Jiří Zárevúcky wrote: > I agree specs should be strict, but someone not capable of deducing > this actually implementing the spec? That is a ridiculous idea > (considering all the examples). I've seen XMPP implemented by "XML console deduction", so I am expecting the worse. -- Tomasz Sterna Instant Messaging & EDI Consultant Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/
Re: [Standards] XEP-0237 Roster Versioning question
2009/7/14 Tomasz Sterna : > On pon, 2009-07-13 at 15:42 -0600, Peter Saint-Andre wrote: >> Whether or not the roster has been modified since the version >> ID enumerated by the client, the server MUST either return the >> complete roster as described in RFC 3921 (including a 'ver' >> attribute that signals the latest version) or ... > > Peter, > I don't want to be picky, but this raises a question: > - Where should I put the 'ver' attribute? > > This is a technical document after all, so it should be strict and leave > no place for doubt. Even at the cost of over explaining. > > I agree specs should be strict, but someone not capable of deducing this actually implementing the spec? That is a ridiculous idea (considering all the examples).
Re: [Standards] xep-0136 message archiving
On Mon, Jul 13, 2009 at 10:50 AM, Dave Cridland wrote: > The biggest question is really the decision on whether to have the IMAP > message be a conversation or a single message. I'd argue that we should make > formats for both, but do single messages by default. I bet the discussion already started many times, but what do we define as a conversation? -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] xep - 144
On Tue, Jul 14, 2009 at 12:59 AM, Peter Saint-Andre wrote: > Right, but I keep wondering if modifying XEP-0093 to include the second > use case was wrong... An approach could be resurrecting xep-0093 for the first case and use ad hoc commands for the whole second one. We just send an ad hoc command containing the block of roster "commands" that the client should apply, ad we wait for the list of accepted commands as result bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] XEP-0237 Roster Versioning question
On pon, 2009-07-13 at 15:42 -0600, Peter Saint-Andre wrote: >Whether or not the roster has been modified since the version >ID enumerated by the client, the server MUST either return the >complete roster as described in RFC 3921 (including a 'ver' >attribute that signals the latest version) or ... Peter, I don't want to be picky, but this raises a question: - Where should I put the 'ver' attribute? This is a technical document after all, so it should be strict and leave no place for doubt. Even at the cost of over explaining. -- Tomasz Sterna Instant Messaging & EDI Consultant Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/
Re: [Standards] Stream Error; Invalid XML Character
Etienne Philip Pretorius wrote: Peter Saint-Andre wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/13/09 1:33 PM, Etienne Philip Pretorius wrote: Hello List, What stream error would one use to best indicate that there was an invalid xml character in the stream? invalid-xml or bad-format? I think bad-format. The differences are described here: http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-00#section-5.8.3.1 http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-00#section-5.8.3.12 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 iEYEARECAAYFAkpbjKMACgkQNL8k5A2w/vxRwwCfWEDe22V4xX+fhknL390TzjfA O3wAoMbSVF62QHfNp2s8tQhOL1n85ouV =cdQA -END PGP SIGNATURE- Thank you Peter Saint-Andre. Looks like would be even better, since it covers the case most specifically (and choosing the most specific is recommended by the spec). With XML, there is the challenge of weaning ourselves from using the word "invalid" universally toward using the more cumbersome word "well-formedness" for cases such as this where the document isn't even parsable as XML. Validity would only be if the server was validating and the XML was found to violate constraints specified in a schema... best wishes, Brett
Re: [Standards] xep - 144
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/13/09 4:57 PM, Fabio Forno wrote: > On Mon, Jul 13, 2009 at 11:48 PM, Peter Saint-Andre wrote: > >> I like the idea of being able to share roster items, introduce one >> person to another over IM, etc. But I'm not convinced that XEP-0144 >> solves compelling use cases. XEP-0093 was simpler and therefore better, >> IMHO. >> > > We have two use cases: > - exchange of business cards, where xep-0093 was good, since we don't > care if the items are processed > - roster sync with a component (it may be a transport, but also a > component hosting different services), and for that we'd like to see > the result of the operation Right, but I keep wondering if modifying XEP-0093 to include the second use case was wrong... 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 iEYEARECAAYFAkpbvGQACgkQNL8k5A2w/vwchgCfey+WKPauaUcWSwpM0ZLTl7M6 WeQAoJcfLvPVAnsCpP5BYc6gihdtkzcN =BMMW -END PGP SIGNATURE-
Re: [Standards] xep - 144
On Mon, Jul 13, 2009 at 11:48 PM, Peter Saint-Andre wrote: > I like the idea of being able to share roster items, introduce one > person to another over IM, etc. But I'm not convinced that XEP-0144 > solves compelling use cases. XEP-0093 was simpler and therefore better, > IMHO. > We have two use cases: - exchange of business cards, where xep-0093 was good, since we don't care if the items are processed - roster sync with a component (it may be a transport, but also a component hosting different services), and for that we'd like to see the result of the operation bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] xep - 144
On Mon, Jul 13, 2009 at 11:07 PM, Brian Cully wrote: > I am using it in-house with an ad-hoc command interface, and it works > passably. I'm not sure about the points raised here. Regarding lack of > feedback, this might be considered a feature. My understanding of roster > push is that it merely advises the client to make changes to its roster and > is only concerned with the client having accepted the changes (even if it > didn't employ them). If a client decides not to take a change a future > request for a roster push probably shouldn't push out that change again (the > client already reviewed it and said, "no"). Indeed this is the problem we have in absence of feedback: we don't know if the client reject it or it simply didn't process it, and therefore we can't resend additions. The result we observed is that after a while the roster then to be de-synchronized > As for re-synchronizing the roster, as I recall the spec there's no > way to synchronize the roster either. Hence the ad-hoc command interface, > which can be easily extended to do a full push again, if necessary. This is one option we have, however there is no easy way to detect deletions with the present specs (the client can't keep track of who added the contacts, so missing contacts in the resend can't be dedected > That being said, I'm not the biggest fan of XEP-0144, and would be > keen to see any proposed changes although I lack any of my own at this time. Briedly waht we have in mind: - for the first issue we plan to add an id to the addition The client therefore sends a result when it receives the stanza, as it happens now. Then after the user has processed the changes it sends backcontaining the accepted items - for the second issue we would like to send an of type get, specifying a "query" asking for all the contacts of a given group or domain, so that we can compare the result with the contacts we have in the roster and detect deletions too; as you say this can be done with an ad hoc command too, in that case I'd like to write an example in the xep in order to document the practice. bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] xep - 144
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/13/09 3:07 PM, Brian Cully wrote: > That being said, I'm not the biggest fan of XEP-0144, and would be > keen to see any proposed changes although I lack any of my own at this > time. I like the idea of being able to share roster items, introduce one person to another over IM, etc. But I'm not convinced that XEP-0144 solves compelling use cases. XEP-0093 was simpler and therefore better, IMHO. 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 iEYEARECAAYFAkpbq8YACgkQNL8k5A2w/vxxNACeKdPBAdTh11kI1eAQBM1Zxs0Y gooAn02BHq36Igbl4EAqtZHsnPF7FuGm =F19j -END PGP SIGNATURE-
Re: [Standards] XEP-0237 Roster Versioning question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/11/09 1:27 PM, Tomasz Sterna wrote: > On sob, 2009-07-11 at 20:42 +0200, Jiří Zárevúcky wrote: >>> How do I send to the client current roster version when sending >> complete >>> roster? >>> I guess I should add ver attribute to the iq-result query item, but >> that >>> is only a guess. >>> >> A correct one. > > Cool. :-) > So, the code is already in jabberd2 SVN repository. :-) > > >> Seems the example on full result has been left out. >> Maybe it needs a sentence or two about that. > > I think so. I've added the following parenthetical clause: Whether or not the roster has been modified since the version ID enumerated by the client, the server MUST either return the complete roster as described in RFC 3921 (including a 'ver' attribute that signals the latest version) or ... 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 iEYEARECAAYFAkpbqkQACgkQNL8k5A2w/vyPpACg7YZSYrHhrxpbMkqrgFJHrovf MXUAoNNI+9jrkK1KzQV/tw/hTQMpngRE =lPQb -END PGP SIGNATURE-
Re: [Standards] xep - 144
On 13-Jul-2009, at 15:15, Peter Saint-Andre wrote: On 7/13/09 3:44 AM, Fabio Forno wrote: we are trying to use XEP 144 for synchronizing the roster of our mobile client with remote services, but we encountered a number of issues, mainly: - lack of feedback from the client to the service of which modifications of the roster have been accepted - lack of any mechanism for re-synchronizing the roster if something wen wrong Therefore we are thinking to extend the XEP in order to address these issues, the only problem is that we could propose some breaking changes, therefore we'd like to know if anybody is : - using the XEP (we know that psi does, but the implementation is not very usable, I think for the lack of testing since no transport is using it) - planning to use it, in that case any suggestion? There were some implementations of XEP-0093 in the old old days (Gabber, Winjab, etc.), but this has never been the most popular feature. If we want to design yet another approach, that would be fine with me (if it fixes all the issues). I am using it in-house with an ad-hoc command interface, and it works passably. I'm not sure about the points raised here. Regarding lack of feedback, this might be considered a feature. My understanding of roster push is that it merely advises the client to make changes to its roster and is only concerned with the client having accepted the changes (even if it didn't employ them). If a client decides not to take a change a future request for a roster push probably shouldn't push out that change again (the client already reviewed it and said, "no"). As for re-synchronizing the roster, as I recall the spec there's no way to synchronize the roster either. Hence the ad-hoc command interface, which can be easily extended to do a full push again, if necessary. That being said, I'm not the biggest fan of XEP-0144, and would be keen to see any proposed changes although I lack any of my own at this time. -bjc
Re: [Standards] Stream Error; Invalid XML Character
Peter Saint-Andre wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/13/09 1:33 PM, Etienne Philip Pretorius wrote: Hello List, What stream error would one use to best indicate that there was an invalid xml character in the stream? invalid-xml or bad-format? I think bad-format. The differences are described here: http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-00#section-5.8.3.1 http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-00#section-5.8.3.12 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 iEYEARECAAYFAkpbjKMACgkQNL8k5A2w/vxRwwCfWEDe22V4xX+fhknL390TzjfA O3wAoMbSVF62QHfNp2s8tQhOL1n85ouV =cdQA -END PGP SIGNATURE- Thank you Peter Saint-Andre.
Re: [Standards] Stream Error; Invalid XML Character
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/13/09 1:33 PM, Etienne Philip Pretorius wrote: > Hello List, > > What stream error would one use to best indicate that there was an > invalid xml character in the stream? > > invalid-xml or bad-format? I think bad-format. The differences are described here: http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-00#section-5.8.3.1 http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-00#section-5.8.3.12 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 iEYEARECAAYFAkpbjKMACgkQNL8k5A2w/vxRwwCfWEDe22V4xX+fhknL390TzjfA O3wAoMbSVF62QHfNp2s8tQhOL1n85ouV =cdQA -END PGP SIGNATURE-
[Standards] Stream Error; Invalid XML Character
Hello List, What stream error would one use to best indicate that there was an invalid xml character in the stream? invalid-xml or bad-format? Etienne
Re: [Standards] XEP-0051 - Renew that spec?
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Peter Saint-Andre wrote: > Why not use TLS-reconnect + XEP-0198 in that case? This would work as well, of course. I just thought that maybe it would be nice to not need the whole complexity of XEP-0198. But then again, code duplication is evil ;). (Same for spec duplication!) - -- Jonathan -BEGIN PGP SIGNATURE- iQIcBAEBAwAGBQJKW4hJAAoJEMtRg9d5cXHkb1oP/0363MsS2QeJC1lmGSKnIdbr 3MYfsw8A30NXigvP2+gHmWO28R6Z96NQ0fwKV3sx6BIe/x3GWS6AysS1l9/sGDG5 pQuCYnuaRu8xM/w12+7Ce8aKR7ka0i4k0U6h7DCNXuv3+sGX1oSE6qssZsNypBjg fEF4a9+uY0uvGt3KDn4Skhu0SpEclMw28EyKwcAKtuUYaQhHG6XttxQrSgAVBCIP Z1CeCkVR3NILUwg6ugxS+LKlBvT3i3WUZSuzZxJFTqFB2+1zshb2bxmUxWWmxmK7 W+SCSfPDQ//HfZ6el8muJL3u0HPj7ZmOBb5TzUHNneszgnpbLbGzwfFFQvSm94nl 7yQ+WVZIjGUZ6m9eHIkOS0Dw3u65/RH2u2rIJmX1bPsF3lJh2REBZPa2OupZ8DiO mlrNT50rpfybmvsirADdIX7czhV8V+CLuoMAEH8rECqea0TfIEo81pu+fcoDPets 0d38Qhif5+I5yZ/K6irvk4GcBn2GPoSkfdNdcLxuDb/Wm5ptqDzM+O+d5LlGwbTD nmhXN8POXO4uLfU5a1Co/ByEmBApIwKWV17sXQv4vAP2oJ/E9gfK4QKnNfug/rmM OF+5drShzl4AdzVFcKpjgItM028hDQ9lrqVcxS63MPJrjrAlZfOMVbr8Cozm3YLH +FAJT1hT/BkjM+WGcGHA =Jpr+ -END PGP SIGNATURE-
Re: [Standards] xep - 144
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/13/09 3:44 AM, Fabio Forno wrote: > Hi, > we are trying to use XEP 144 for synchronizing the roster of our > mobile client with remote services, but we encountered a number of > issues, mainly: > - lack of feedback from the client to the service of which > modifications of the roster have been accepted > - lack of any mechanism for re-synchronizing the roster if something wen wrong > > Therefore we are thinking to extend the XEP in order to address these > issues, the only problem is that we could propose some breaking > changes, therefore we'd like to know if anybody is : > - using the XEP (we know that psi does, but the implementation is not > very usable, I think for the lack of testing since no transport is > using it) > - planning to use it, in that case any suggestion? There were some implementations of XEP-0093 in the old old days (Gabber, Winjab, etc.), but this has never been the most popular feature. If we want to design yet another approach, that would be fine with me (if it fixes all the issues). 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 iEYEARECAAYFAkpbh+YACgkQNL8k5A2w/vwC9ACgzPU0W0GdOfeZYE9BM9rzDD4w 8xoAoN5J8PlUc8dPFnhnoPNTZCxoK6gb =zFeI -END PGP SIGNATURE-
Re: [Standards] XEP-0051 - Renew that spec?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/13/09 5:12 AM, Jonathan Schleifer wrote: > Reading the current XEP, it sounds like the client should do a normal > reconnect? > > This sounds a bit … disrupting to me. Wouldn't it make more sense to > also give the client a token and if the client reconnects with that > token, the old session is resumed? Something similar to XEP-0198, but > with less overload. The idea is that you get a secret token in the > XEP-0051 stanza and specify it on connection the server you were > redirected to so the new server knows where you come from and thus you > don't have to resend roster etc. Why not use TLS-reconnect + XEP-0198 in that case? 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 iEYEARECAAYFAkpbhwwACgkQNL8k5A2w/vwugACg1cvFKXNB+YB90RuY9gzi7MYF +wAAmwR0rXl0TYz3hu356QSINszGQsgD =8t8i -END PGP SIGNATURE-
Re: [Standards] none + pending in
Me Self wrote: [snip] > Personally I chose an implementation that stores requests separately > from the roster - and not hide roster items added explicitly by the > user. Its not in compliance with spec. The spec needs to be fixed: http://www.ietf.org/mail-archive/web/xmpp/current/msg00047.html Thanks for bringing that up! philipp
Re: [Standards] none + pending in
2009/7/10 Jiří Zárevúcky > 2009/7/10 Me Self : > > Roster always stores the subscription state, which is now "none". How > you store the actual request is up to you. That kind of implementation > details do not reflect in the network, so that is not the kind of > stuff the spec can dictate. > > The only think you need to know is that the item is "hidden" to the > user until the subscription is approved or the item is explicitly > added by the user. That's all you need to know to implement it. How > exactly you do it doesn't matter here. > The example I mentioned about "none + pending in" hiding an item that was previously visible by no action of the roster owner himself shows that the specs assumption of storing requests in the roster shines through all the way to the (bad) user experience. For a newbie like me reading the spec and building a "clean room" implementation of an XMPP server it was very difficult to understand why the spec dictates to hide such a roster item until I got the point that storing requests in the roster was assumed and that this type of implementation cant tell the difference between a roster item added explicitly by the user and a roster item that was added as a sideeffect of receiving a request. All the semantics regarding how the state of pending requests combined with the state of existing roster items affect what the users sees only makes sence if you understand the implementation thats assumed - that why I thought I would be nice if the spec had explained this (not as a requirement but maybe as background knowledge for the somewhat weird requirement to hide items the user put there himself). Personally I chose an implementation that stores requests separately from the roster - and not hide roster items added explicitly by the user. Its not in compliance with spec. I guess I hoped with my initial question that someone would tell me that my interpretation of the spec was wrong and that "none + pending in" should still be visible if the user added the item himself. Kind regards Søren
Re: [Standards] Last Activity in initial presence
Am 02.07.2009 um 00:10 schrieb Peter Saint-Andre: There is such a mechanism in MUC, but AFAIK it's not implemented anywhere. We are using it in Buddycloud for the channels stuff to save traffic (the mobile client only requests new messages since the last time it was online). For the server side, we use palaver, so it seems there is at least one server implementation. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] XEP-0051 - Renew that spec?
Reading the current XEP, it sounds like the client should do a normal reconnect? This sounds a bit … disrupting to me. Wouldn't it make more sense to also give the client a token and if the client reconnects with that token, the old session is resumed? Something similar to XEP-0198, but with less overload. The idea is that you get a secret token in the XEP-0051 stanza and specify it on connection the server you were redirected to so the new server knows where you come from and thus you don't have to resend roster etc. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
[Standards] xep - 144
Hi, we are trying to use XEP 144 for synchronizing the roster of our mobile client with remote services, but we encountered a number of issues, mainly: - lack of feedback from the client to the service of which modifications of the roster have been accepted - lack of any mechanism for re-synchronizing the roster if something wen wrong Therefore we are thinking to extend the XEP in order to address these issues, the only problem is that we could propose some breaking changes, therefore we'd like to know if anybody is : - using the XEP (we know that psi does, but the implementation is not very usable, I think for the lack of testing since no transport is using it) - planning to use it, in that case any suggestion? bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] xep-0136 message archiving
On Sat Jul 11 12:34:26 2009, Bernhard zwischenbrugger wrote: My idea is to make a webchat that handles "normal" messages like emails in a mail program - similar to IMAP. I've long argued that the best way of handling an archive of messages is via IMAP, even if those messages were (or are) XMPP messages. I'd gladly work on a transformation from XMPP to MIME to support this, with a view to allowing XMPP servers to "dump" messages into IMAP. The biggest question is really the decision on whether to have the IMAP message be a conversation or a single message. I'd argue that we should make formats for both, but do single messages by default. Once that's all done, of course, then retrieving the last 20 normal messages is trivial (with base IMAP) - all that side of the work has been done for us, and things like the Lemonade profile, and various common extensions, give us a lot more functionality than we are likely to bother specifying in XEP-0136. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
