[Standards] XEP-0249 v1.2rc1 (was: Fwd: Re: [MUC] XEP-0249 and "continue")

2011-08-16 Thread Peter Saint-Andre
FYI. Original Message Subject: Re: [MUC] XEP-0249 and "continue" Date: Tue, 16 Aug 2011 15:27:21 -0600 From: Peter Saint-Andre Reply-To: Multi-User Chat over XMPP To: ke...@kismith.co.uk, Multi-User Chat over XMPP On 8/16/11 1:40 PM, Kevin Smith wrote: > On Tue, Aug 16, 2011

Re: [Standards] Remarks on XEP-0114

2011-08-16 Thread Jehan Pagès
Hi, On Wed, Aug 17, 2011 at 1:10 AM, Kevin Smith wrote: > 2011/8/16 Jehan Pagès : >> The use case is a wordpress plugin I wrote which implements XEP-0070. >> Basically the first implementation was with a bot > >> Now I implemented a component alternative (component.shakespeare.lit). > >> Right

Re: [Standards] Remarks on XEP-0114

2011-08-16 Thread Kevin Smith
2011/8/16 Jehan Pagès : > The use case is a wordpress plugin I wrote which implements XEP-0070. > Basically the first implementation was with a bot > Now I implemented a component alternative (component.shakespeare.lit). > Right now, only the bot version is really reliable. Isn't this just sayin

Re: [Standards] Remarks on XEP-0114

2011-08-16 Thread Jehan Pagès
Hi, On Tue, Aug 16, 2011 at 4:15 PM, Waqas Hussain wrote: > 2011/8/16 Jehan Pagès : >> Hi, >> >> so I have just implemented something with XEP-0114 (client side) and I >> have a few questions. >> >> (1) In my case, the component was locale. And I imagine that's quite >> the most common case. But

Re: [Standards] UPDATED: XEP-0258 (Security Labels in XMPP)

2011-08-16 Thread Peter Saint-Andre
On 8/16/11 2:26 AM, Kevin Smith wrote: > On Mon, Aug 15, 2011 at 8:54 PM, Kurt Zeilenga > wrote: >> I think this document is near ready for advancement to Draft. >> >> I encourage you to now review (or re-review) the document. Please raise any >> technical issue to this list. If you have no te

Re: [Standards] Remarks on XEP-0114

2011-08-16 Thread Peter Saint-Andre
On 8/16/11 1:15 AM, Waqas Hussain wrote: > 2011/8/16 Jehan Pagès : >> Hi, >> >> so I have just implemented something with XEP-0114 (client side) and I >> have a few questions. >> >> (1) In my case, the component was locale. And I imagine that's quite >> the most common case. But that's definitely n

Re: [Standards] Proposed XMPP Extension: Extensible Status Conditions for Multi-User Chat

2011-08-16 Thread Peter Saint-Andre
On 8/16/11 3:35 AM, Dave Cridland wrote: > On Mon Aug 15 22:57:59 2011, Peter Saint-Andre wrote: >> > 1) I don't think the new elements need to have a 1:1 mapping with >> status >> > codes, and the way in which the registrar considerations is phrased >> > implies this to be the case. I think we wan

Re: [Standards] Proposed XMPP Extension: Extensible Status Conditions for Multi-User Chat

2011-08-16 Thread Dave Cridland
On Mon Aug 15 22:57:59 2011, Peter Saint-Andre wrote: > 1) I don't think the new elements need to have a 1:1 mapping with status > codes, and the way in which the registrar considerations is phrased > implies this to be the case. I think we want a new registry, which > includes "related statu

Re: [Standards] UPDATED: XEP-0258 (Security Labels in XMPP)

2011-08-16 Thread Kevin Smith
On Mon, Aug 15, 2011 at 8:54 PM, Kurt Zeilenga wrote: > I think this document is near ready for advancement to Draft. > > I encourage you to now review (or re-review) the document.  Please raise any > technical issue to this list.  If you have no technical issues to raise, > please note so to th

Re: [Standards] Proposed XMPP Extension: Extensible Status Conditions for Multi-User Chat

2011-08-16 Thread Kevin Smith
On Mon, Aug 15, 2011 at 10:57 PM, Peter Saint-Andre wrote: >> 2) We also need to consider that many clients only handle one status >> code. > > Which one do they handle? It varies, some the first they receive, some the last they receive, I think. /K

Re: [Standards] Remarks on XEP-0114

2011-08-16 Thread Waqas Hussain
2011/8/16 Jehan Pagès : > Hi, > > so I have just implemented something with XEP-0114 (client side) and I > have a few questions. > > (1) In my case, the component was locale. And I imagine that's quite > the most common case. But that's definitely not an obligation > (especially as we could imagine