Re: [Standards] XEP-0124: which error if sid invalid?

Hi Mridul, Am Mittwoch, den 15.08.2007, 19:11 +0530 schrieb Mridul Muralidharan: Intermediaries wont send a 404, which is what (i recall) the xep asks httpbind to send back in case of unknown/invalid sid. So we dont need to know the ver in this case (since httpbind assigns sid not client,

Re: [Standards] storage:* namespaces

Am Freitag, den 17.08.2007, 09:50 -0600 schrieb Peter Saint-Andre: The following specs use storage:* namespaces: [...] XEP-0145: Annotations http://www.xmpp.org/extensions/xep-0145.html state: Historical / Active [...] I propose that we write new specs to replace XEP-0048

[Standards] XMPP over Websocket vs XEP-0198

Hi, within Section 3.5[1] XMPP over Websocket states that the closing party MUST close the XMPP stream if it has been established. With hindsight of page transitions within legacy web apps this might not be wanted by the client as it might wish to resume the stream by use (abuse?) of XEP-0198

Re: [Standards] Fwd: [Summit] BOSH actions

JSJaC doesn't either. And at least the old implementation of ejabberd's mod_http_bind didn't as well. .Steve Am 04.02.2013 um 22:39 schrieb Steffen Larsen zoo...@gmail.com: Just checked strophe, and it does not use it. I'll check some more implementations that uses BOSH for transport. Maybe

[Standards] BOSH and legacy auth

Hi folks, regarding the issue listed at http://wiki.xmpp.org/web/BoshIssues#Stream_Creation:_missing_.3Cstream:features.2F.3E I'd propose sth the lines of %== If no stream:features/ element is included in the connection manager's session creation response, then the client SHOULD

Re: [Standards] Proposal for Secure Distributed Discovery of JIDs

Wouldn't it be an option to not only publish one's JID on behalf of such a lookup service but also other information meant to be publicly available like a associated buddycloud node e.g.? Am 07.02.2013 um 01:13 schrieb Tobias Markmann tmarkm...@googlemail.com: Hi, We have been working on a

Re: [Standards] BOSH and legacy auth

Hi, On 07.02.2013, at 13:12, Winfried Tilanus winfr...@tilanus.com wrote: On 02/06/2013 05:05 PM, Stefan Strigler wrote: regarding the issue listed at http://wiki.xmpp.org/web/BoshIssues#Stream_Creation:_missing_.3Cstream:features.2F.3E Is it correct you are addressing an issue

Re: [Standards] BOSH and legacy auth

Matt, in short words: On 07.02.2013, at 13:54, Matthew Miller linuxw...@outer-planes.net wrote: If I recall correctly, this issue is about what to do when, after authentication, the client sends a restart=true, but the server does not support that (since there is no way to discover the

Re: [Standards] BOSH and Multiple Streams

Hi, Am 08.02.2013 um 23:55 schrieb Matt Miller linuxw...@outer-planes.net: In working on the patch to address HTTP pipelining, I cascaded into section 16: Multiple Streams. Multiple Streams seems to require support for HTTP pipelining, but feels as if it runs afoul of even the basic

Re: [Standards] BOSH and legacy auth - do we have to be backwards compatible?

OK! Am 15.02.2013 um 13:14 schrieb Winfried Tilanus winfr...@tilanus.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/08/2013 06:28 PM, Peter Saint-Andre wrote: Hi, I think we can remove the XEP-0078 references. It has been obsolete since 2008. Steve, there seem to be no

Re: [Standards] BOSH and legacy auth - do we have to be backwards compatible?

trip times). .Steve On 08.02.2013, at 18:28, Peter Saint-Andre stpe...@stpeter.im wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/8/13 2:37 AM, Winfried Tilanus wrote: On 02/07/2013 01:50 PM, Stefan Strigler wrote: Hi, Stream features are only provided by non legacy servers

Re: [Standards] XMPP meetup July 27 in Berlin?

Me too!! :) Am 17.05.2013 um 22:00 schrieb Alexander Gnauck gna...@ag-software.de: Anyone interested? absolutely!!! Alex

Re: [Standards] New feature proposal for XEP-0313: result limiting per JID

2014-08-27 12:41 GMT+02:00 Kevin Smith ke...@kismith.co.uk: On Wed, Aug 27, 2014 at 10:33 AM, Piotr Nosek piotr.no...@erlang-solutions.com wrote: Me and colleagues had a discussion on this issue and we think XEP-0313 could use a new parameter for queries, that will tell the server to

[Standards] XEP-0313 v0.2 vs v0.3

Hi everbody! Can someone please enlighten me why the section on archiving messages esp the requirement to have archived by='jul...@capulet.lit' id='28482-98726-73623' / added to the message got removed at v0.3? I have a use case where this would be very useful to know... Thanks, Stefan

Re: [Standards] OTR

2014-11-07 13:02 GMT+01:00 Winfried Tilanus winfr...@tilanus.com: On 11/07/2014 10:55 AM, Dave Cridland wrote: Is anyone willing to help work on a XEP to explain how to run OTR over XMPP, and catalogue limitations etc? Though I am quite flooded with work right now, I am willing to help

Re: [Standards] OTR

I see, we're having a fruitful discussion. This was part of the master plan. ;) 2014-11-17 13:52 GMT+01:00 Winfried Tilanus winfr...@tilanus.com: On 11/14/2014 10:25 PM, Genghis Khan wrote: Hi, Bobs Suicide Letter has a typo an horrible. Well, if that is the only typo / strange thing in

[Standards] script running amok?

Hey there! Found these in hundreds this morning in editors inbox: From: standards@xmpp.org on Fri Feb 6 09:20:15 2015 Subject: There where errors during the run of /home/xsf/editor-auto-test/xsf-tools/testscript.py on 2015-02-06 09:20:14 Cause: The message headers matched a filter rule

Re: [Standards] off-server archives with MAM

Sounds like a really nice hack. A recombination of presence, disco and MAM to gain a totally different user experience. +1 for the idea :) Not sure where to put this though. How about XEP-1337 Hacks :D 2015-04-18 5:24 GMT+02:00 Kurt Zeilenga kurt.zeile...@isode.com: On Apr 17, 2015, at

Re: [Standards] off-server archives with MAM

Oh, my list is missing the carbons of course. 2015-04-18 10:58 GMT+02:00 Stefan Strigler stefan.strig...@gmail.com: Sounds like a really nice hack. A recombination of presence, disco and MAM to gain a totally different user experience. +1 for the idea :) Not sure where to put this though

[Standards] XEP-0060: be more consistent with reply #106

Hey there, when implementing parts of XEP-0060 I came across a maybe inconsistency when it's about unsubscribing from a Node (Section 6.2.2 - http://xmpp.org/extensions/xep-0060.html#subscriber-unsubscribe). If we'd allow to also have a the resulting subscription element in the response, the

Re: [Standards] XEP-0313 purge draft

Maybe just contact Valerian directly? 2015-09-21 12:11 GMT+02:00 Michael Uvarov : > Hi, > > The link > https://demo.frenchtouch.pro/valerian.saliou/xmpp/extensions/xep-0313.html > is dead. > > Does anyone has a copy of this draft? It's the MAM with purge extension > that was

Re: [Standards] XEP-0060: be more consistent with reply #106

-10-05 10:48, Stefan Strigler wrote: > > Hey there, > > > > when implementing parts of XEP-0060 I came across a maybe inconsistency > > when it's about unsubscribing from a Node (Section 6.2.2 > > - http://xmpp.org/extensions/xep-0060.html#subscriber-unsubscri

Re: [Standards] Proposed XMPP Extension: Multi-User Chat Light

2015-12-14 16:16 GMT+00:00 Dave Cridland : > > > No, you cannot have an arbitrary XEP-0045 service also presented over this > protocol; it has to be a cut-down, especially written service. The result > is that existing '45 features are lost entirely. > The service identifies

Re: [Standards] Proposed XMPP Extension: Multi-User Chat Light

Hi, 2015-12-14 17:06 GMT+00:00 Tobias M <tmarkm...@googlemail.com>: > > On 14.12.2015, at 17:56, Stefan Strigler <stefan.strig...@gmail.com> > wrote: > > if you want to do IQ with members of a room in the context of MUC Light > you would do so by

Re: [Standards] Proposed XMPP Extension: Multi-User Chat Light

Tobias, if you want to do IQ with members of a room in the context of MUC Light you would do so by addressing them directly since there is no concept of anonymous or semi-anonymous rooms. Cheers, Stefan 2015-12-14 16:39 GMT+00:00 Tobias M : > > On 14.12.2015, at

Re: [Standards] [Council] 2016-07-20 Council Meeting

Some random thoughts on this discussion from an observer: From a purely technical point of view I was like "never make this part of 0045, please". But I think this is what we always got wrong. Not seeing XMPP also as a whole thing. We know what it is in reality but from a theoretical point of view

Re: [Standards] PubSub Item Publisher

bin...@jrudevels.org> wrote: > It still does not answer how to determine from client if pubsub server > is going to send them. I.e. if I rely on this feature, I want to know in > advance if a particular service is suitable? > > > On 26/10/2016 14:58, Stefan Strigler wrote: > >

[Standards] PubSub Item Publisher

Hidey ho, XEP-0060 states at http://www.xmpp.org/extensions/xep-0060.html#publisher-publish-success-publisher that "If configured to do so, the service can include the publisher of the item" as in "" but nothing more about this throughout the document. I assume it's meant as a per service

Re: [Standards] Proposed XMPP Extension: Spoiler messages

Like and then etc... Greets, Stefan On Wed, Nov 2, 2016 at 8:40 AM Stefan Strigler <stefan.strig...@gmail.com> wrote: > Couldn't we also support trigger warnings within this context in the same > way? > > On Wed, Nov 2, 2016 at 3:33 AM Lance Stout <lances

Re: [Standards] PubSub Item Publisher

Created a pull request https://github.com/xsf/xeps/pull/267 On Fri, Oct 14, 2016 at 6:09 PM Stefan Strigler <stefan.strig...@gmail.com> wrote: > Also I assume that when this feature is enabled retrieving items as > described at > > https://xmpp.org/extensions/xep-0060.html#s

Re: [Standards] Proposed XMPP Extension: Spoiler messages

Couldn't we also support trigger warnings within this context in the same way? On Wed, Nov 2, 2016 at 3:33 AM Lance Stout wrote: > The element can be used to display human readable text via > the `hint` attribute, so it should be noted that multiple > elements could be

Re: [Standards] PubSub Item Publisher

On Fri, Oct 14, 2016 at 2:47 PM Stefan Strigler <stefan.strig...@gmail.com> wrote: > Hidey ho, > > XEP-0060 states at > http://www.xmpp.org/extensions/xep-0060.html#publisher-publish-success-publisher > that > > "If configured to do so, the service can inc