Re: [Standards] NEW: XEP-0363 (HTTP File Upload)

Am 29.09.2015 um 02:02 schrieb Evgeny Khramtsov : > Thu, 24 Sep 2015 13:10:44 +0300 > PG Stath wrote: > >> In general I think that XMPP might be missing developers not because >> features are missing but because of non compatible extensions lists >> and

Re: [Standards] NEW: XEP-0363 (HTTP File Upload)

On Tue, Sep 29, 2015 at 8:45 AM, Dave Cridland wrote: > > > On 29 September 2015 at 08:12, Christian Schudt > wrote: > >> >> XEP-0256 vs. XEP-0319 (Idle/Last active time, clients now need to append >> both extensions) >> > > Can we do server

Re: [Standards] NEW: XEP-0363 (HTTP File Upload)

On 29 September 2015 at 08:12, Christian Schudt wrote: > > Am 29.09.2015 um 02:02 schrieb Evgeny Khramtsov : > > > Thu, 24 Sep 2015 13:10:44 +0300 > > PG Stath wrote: > > > >> In general I think that XMPP might be missing

Re: [Standards] NEW: XEP-0363 (HTTP File Upload)

> On 29.09.2015, at 10:10, Evgeny Khramtsov > wrote: > >> >> File transfer, on the other hand, could very usefully be done via >> protocol translation. Converting SI to Jingle and back again - or >> even terminating Jingle in the server and

Re: [Standards] NEW: XEP-0363 (HTTP File Upload)

Tue, 29 Sep 2015 10:17:12 +0100 Tobias M wrote: > Not ready in what capacity? It’s implemented by Conversations, Gajim, > Swift and web clients (maybe, don’t remember for sure). Pidgin does > not support it currently, there was a dev branch once but it’s likely >

Re: [Standards] NEW: XEP-0363 (HTTP File Upload)

> On 29.09.2015, at 10:10, Evgeny Khramtsov wrote: > >> >> File transfer, on the other hand, could very usefully be done via >> protocol translation. Converting SI to Jingle and back again - or >> even terminating Jingle in the server and translating to HTTP - >> really

Re: [Standards] NEW: XEP-0363 (HTTP File Upload)

Tue, 29 Sep 2015 10:49:35 +0100 Dave Cridland wrote: > Writing up use-cases for these things would be really interesting, by > the way. In fact, writing up use-cases in general, and how to > implement them with existing XEPs, would be interesting generally, I > think. Maybe

Re: [Standards] NEW: XEP-0363 (HTTP File Upload)

> Seems like I'm constantly repeating on the list... > Do those implementation resolve the following problems: > 1) MUC friendly > 2) Offline support > > From what I know Jingle FT specs don't provide a solution for those > problems. Funny, I've brought up exactly these two problems, too:

Re: [Standards] NEW: XEP-0363 (HTTP File Upload)

Tue, 29 Sep 2015 08:28:45 +0100 Dave Cridland wrote: > File transfer, on the other hand, could very usefully be done via > protocol translation. Converting SI to Jingle and back again - or > even terminating Jingle in the server and translating to HTTP - > really feels like it

Re: [Standards] NEW: XEP-0363 (HTTP File Upload)

On 29 September 2015 at 10:43, Evgeny Khramtsov wrote: > Tue, 29 Sep 2015 10:17:12 +0100 > Tobias M wrote: > > > Not ready in what capacity? It’s implemented by Conversations, Gajim, > > Swift and web clients (maybe, don’t remember for sure). Pidgin

Re: [Standards] XEP-0280: vs.

On 17.09.2015 13:31, Christian Schudt wrote: > Hi, > > >> I get your point. But it feels wrong to define nearly identical >> extension elements in two XEPs. The author of xep334, Matthew Wild, >> already expressed his willingness to change xep334 so that it can be >> re-used in xep280. Therefore

Re: [Standards] XEP-0280: vs.

On 29 September 2015 at 16:02, Florian Schmaus wrote: > On 17.09.2015 13:31, Christian Schudt wrote: > > Hi, > > > > > >> I get your point. But it feels wrong to define nearly identical > >> extension elements in two XEPs. The author of xep334, Matthew Wild, > >> already

[Standards] UPDATED: XEP-0313 (Message Archive Management)

Version 0.4.1 of XEP-0313 (Message Archive Management) has been released. Abstract: This document defines a protocol to query and control an archive of messages stored on a server. Changelog: [See revision history] (XEP Editor (mam)) Diff:

Re: [Standards] XEP-0301 Annual review (In-Band Real Time Text)

On Tue, Sep 29, 2015 at 3:44 PM, Mark Rejhon wrote: > If we fix the schema, would this force namespace to increment: > i.e. urn:xmpp:rtt:1 instead of urn:xmpp:rtt:0 > > My commentary: All developers have complied with the assumed latter schema, > since it was obvious from the

Re: [Standards] Deprecating Privacy Lists

On 2015-09-29 22:02, Sam Whited wrote: > I've brought up reconciling privacy lists and the blocking command in > the past [1], but the discussion faltered and it never went before the > council. It was brought up as part of a recent discussion again [2], > and I'd like to formally propose that it

[Standards] Blocking a MUC participant

Hi, With Privacy lists and Blocking command being brought up, I'd like to raise an issue they both have: blocking a MUC participant. Both XEP-0016 and XEP-0191 states that when someone who has been blocked attempts to communicate with the the user: > For message stanzas, the server SHOULD

[Standards] XEP-0301 Annual review (In-Band Real Time Text)

Re: http://www.xmpp.org/extensions/xep-0301.html Infopage: http://www.realjabber.org I am doing an annual review of XEP-0301 adoption status. Last year, no change was deemed necessary. However, one developer submitted an errata, which I am now confirming with XSF. New implementations: -

Re: [Standards] XEP-0301 Annual review (In-Band Real Time Text)

On 29.09.2015 22:44, Mark Rejhon wrote: > There is this pending cosmetic errata, that we wish to confirm with > XSF members: > > Christian Schudt (of Babbler) says of XEP-0301: > >>2. The XML Schema might be wrong, but I am not sure. >> >> >> >> >> >> >> >> I

[Standards] Deprecating Privacy Lists

I've brought up reconciling privacy lists and the blocking command in the past [1], but the discussion faltered and it never went before the council. It was brought up as part of a recent discussion again [2], and I'd like to formally propose that it be deprecated. I have made a pull request

Re: [Standards] Deprecating Privacy Lists

On 09/29/2015 10:02 PM, Sam Whited wrote: > I've brought up reconciling privacy lists and the blocking command in > the past [1], but the discussion faltered and it never went before the > council. It was brought up as part of a recent discussion again [2], > and I'd like to formally propose that