Re: [Standards] inconsistency between section 7.2 - 10.2 in XEP-0136 ?
On 4/7/09 3:44 PM, Peter Saint-Andre wrote: > On 4/7/09 3:32 PM, Alexander Tsvyashchenko wrote: >> Peter, >> >> On Tue, 07 Apr 2009 10:31:20 -0600, Peter Saint-Andre >> wrote: >> >>> On 4/6/09 12:28 AM, Alexander Tsvyashchenko wrote: >>> I see two possible solutions: 1) Keep things like they were before, so that "retrieve" may return messages from one collection only. Requires rollback of the last change to XEP and removing "exactmatch" support by "retrieve" from 10.1 and from XML Schema. >>> I now think that is the right approach. >>> >>> Alexander, what do you think? >> I think that would be both the best and the easiest solution (the rare case >> when these qualities do not interfere ;-) > > OK, good. I will update XEP-0136 accordingly Done: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0136.xml?%40diffMode=u&%40diffWrap=s&r1=2993&r2=3008&u=3&ignore=&k= Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] inconsistency between section 7.2 - 10.2 in XEP-0136 ?
On 4/7/09 3:32 PM, Alexander Tsvyashchenko wrote: > Peter, > > On Tue, 07 Apr 2009 10:31:20 -0600, Peter Saint-Andre > wrote: > >> On 4/6/09 12:28 AM, Alexander Tsvyashchenko wrote: >> >>> I see two possible solutions: >>> >>> 1) Keep things like they were before, so that "retrieve" may return >>> messages from one collection only. Requires rollback of the last change >>> to >>> XEP and removing "exactmatch" support by "retrieve" from 10.1 and from >>> XML >>> Schema. >> I now think that is the right approach. >> >> Alexander, what do you think? > > I think that would be both the best and the easiest solution (the rare case > when these qualities do not interfere ;-) OK, good. I will update XEP-0136 accordingly and then the Council can decide whether to approve the changes. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] inconsistency between section 7.2 - 10. 2 in XEP-0136 ?
Peter, On Tue, 07 Apr 2009 10:31:20 -0600, Peter Saint-Andre wrote: > On 4/6/09 12:28 AM, Alexander Tsvyashchenko wrote: > >> I see two possible solutions: >> >> 1) Keep things like they were before, so that "retrieve" may return >> messages from one collection only. Requires rollback of the last change >> to >> XEP and removing "exactmatch" support by "retrieve" from 10.1 and from >> XML >> Schema. > > I now think that is the right approach. > > Alexander, what do you think? I think that would be both the best and the easiest solution (the rare case when these qualities do not interfere ;-) -- Good luck! Alexander
Re: [Standards] XMPP example site - www.LiveBaseballChat.com
On 4/7/09 3:00 PM, Dean Collins wrote: > I'm not sure if this is crossing the lines and if it is feel free to > delete this email. Nope, it's always good to hear about applications. Usually we learn of such things through blog posts, microblogging mentions, or posts to the j...@jabber.org list. It's all a bit informal. :) > But we are always talking about XMPP on this mailing list but I rarely > see anyone talking about sites that have implemented solutions and apart > from the well known public IM facing sites and sites like Chesspark etc > I couldn't name more than 4 or 5 I've seen mentioned. > > Anyway so I thought I would let you know about a small site we just > launched this week called www.LiveBaseballChat.com > > Basically it is an ajax/xmpp site with 2430 chat rooms set up over the > next 6 months for people to talk about specific Baseball games. Sweet. And just in time for baseball season! :) /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XMPP example site - www.LiveBaseballChat.com
I'm not sure if this is crossing the lines and if it is feel free to delete this email. But we are always talking about XMPP on this mailing list but I rarely see anyone talking about sites that have implemented solutions and apart from the well known public IM facing sites and sites like Chesspark etc I couldn't name more than 4 or 5 I've seen mentioned. Anyway so I thought I would let you know about a small site we just launched this week called www.LiveBaseballChat.com Basically it is an ajax/xmpp site with 2430 chat rooms set up over the next 6 months for people to talk about specific Baseball games. It has Facebook, twitter and email integration. There are still a number of tweaks to implement over the next few days but thought it might interest some of you to go and check it out (obviously best in the USA afternoon when games are on so you can see how it works fully). Like I said not sure if this is breaching etiquette if it is feel free to delete. Regards, Dean Collins Live Chat Concepts Inc d...@livechatconcepts.com +1-212-203-4357 New York +61-2-9016-5642 (Sydney in-dial). +44-20-3129-6001 (London in-dial).
Re: [Standards] inconsistency between section 7.2 - 10.2 in XEP-0136 ?
On 4/6/09 12:28 AM, Alexander Tsvyashchenko wrote: > I see two possible solutions: > > 1) Keep things like they were before, so that "retrieve" may return > messages from one collection only. Requires rollback of the last change to > XEP and removing "exactmatch" support by "retrieve" from 10.1 and from XML > Schema. I now think that is the right approach. Alexander, what do you think? Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] UPDATED: XEP-0198 (Stream Management)
On 4/7/09 12:03 AM, Fabio Forno wrote: > On Tue, Apr 7, 2009 at 3:05 AM, Peter Saint-Andre wrote: > >>> S: >>> >>> It isn't perfect but it can work for most of the cases. >> Agreed. But what is the purpose of max="n" here? > > It could be used to adjust the number of maximun number of outstanding > packets (When throttling it makes sense to reduce it) Ah, I think that needs to be a 'stanzas' attribute. The 'max' attribute specifies the longest allowable time period for session resumption and the 'stanzas' attribute indicates the server's preferred maximum number of received stanzas between acks. So: Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0136 - Message Archiving Preferences doubt
Hello Sachin, On Tue, 7 Apr 2009 11:50:04 +0530, Sachin Khandelwal wrote: > Only in case of otr ssn negotiation, its fine that its clients > responsibility > to make sure that server acts according to the agreement that clients > reached. > > But say if any client has not set the proper preference of user and contact > in > case of otr as I mentioned in the previous earlier then what is expected > from > server when both users are having auto=true but otr as require and forbid. ... and if client records messages locally contrary to what OTR/preferences suggest, should the server brute-force user's PC account and, if successful, scan HDD and remove all messages recorded not in accordance to preferences stored on server? ;-) Talking seriously, server does not take any part nor in OTR negotiation, neither in analysis of OTR preferences stored on server. These preferences are for client only: it takes it as starting values and based on that starts OTR negotiation. When OTR negotiation finishes, client may need to configure its server accordingly to the agreement achieved - such as enable auto-archiving for current stream, if OTR negotiation resulted in "allow archive" agreement and client prefers auto-archiving rather than manual one, or adjust it...@save] attribute to 'false' value for particular JID if OTR negotiation resulted in "do not archive" agreement but client still wants to keep auto-archive enabled for all other conversations, or whatever. Once again: the server is just "storage back-end", and it does only what client told it to do. If client told the server "enable auto-archiving" - so be it, it's client responsibility to ensure that this command didn't violate OTR negotiation results or whatever else part of XEP-136. There's no point in server knowing about OTR and trying to enforce it when clients may easily violate it by local messages recording. 2Peter: in fact XEP-136 might be slightly confusing in its current form regarding preferences interpretation in auto-archiving mode - probably, it might be a good idea to list explicitly which preferences server takes into account when auto-archiving is enabled. I believe these are "auto" (per stream), "defau...@expire, @save]" and "it...@expire, @jid, @save]" in "normal" auto-archiving mode and no preferences are taken into account in "forced" auto-archiving mode. It also might be useful to explicitly state that all other preferences are for clients interpretation only. -- Good luck! Alexander
