Re: [Standards] Fwd: RFC 7081 on CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP)

Mon, 02 Dec 2013 13:53:46 -0700 Peter Saint-Andre stpe...@stpeter.im wrote: This document suggests some strategies for the combined use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) both in user-oriented clients and in deployed servers. Do

Re: [Standards] Fwd: RFC 7081 on CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP)

Mon, 02 Dec 2013 17:03:55 -0800 Graham King gra...@gkgk.org wrote: We're a team of six, currently building a SIP and XMPP server in Go. Yeah, I would say a team of six is a bare minimum to build a SIP server :)

Re: [Standards] [Operators] Future of XMPP Re: The Google issue

Wed, 4 Dec 2013 14:44:36 + Dave Cridland d...@cridland.net wrote: XMPP is *not* a hard-schema protocol for the most part - we can and do cheerfully sling extra elements and attributes in all over the shop. Only the core is hard - that is, the stanzas and stream - the rest should be

Re: [Standards] [Operators] Future of XMPP Re: The Google issue

Thu, 05 Dec 2013 01:05:50 +0100 Alexander Holler hol...@ahsoftware.de wrote: Yes, they don't care, but a XMPP-server has to care about, as the server should refuse not-wellformed stanzas. So feeding it with the initial stream:stream might result in a problem (not hard to avoid, but still

Re: [Standards] server IP check (XEP-0279)

Wed, 16 Apr 2014 17:56:07 -0600 Peter Saint-Andre stpe...@stpeter.im wrote: XEP-0279 defines a simple XMPP extension that enables a client to discover its external IP address from its server. This feature can help a client discover if it's behind a NAT and thus trigger things like STUN

Re: [Standards] server IP check (XEP-0279)

Sat, 19 Apr 2014 02:14:19 -0400 Genghis Khan genghisk...@gmx.ca wrote: On Sat, 19 Apr 2014 09:19:36 +0400 Evgeny Khramtsov xramt...@gmail.com wrote: There is trivial mod_sic module in ejabberd. However, I still vote to Reject the XEP for the reason I did that years ago. May you post

Re: [Standards] server IP check (XEP-0279)

Sat, 19 Apr 2014 11:54:12 +0200 Genghis Khan genghisk...@gmx.ca wrote: Then write it down, again, if you may. I might incline to your opinion. We should use ICE.

Re: [Standards] Proposed XMPP Extension: Recipient Server Side Notifications Filtering

Mon, 23 Jun 2014 12:01:21 +0200 Philipp Hancke fi...@goodadvice.pages.de wrote: Am 23.06.2014 09:41, schrieb Sergey Dobrov: So guys, what are the exact concern around the XEP-0033 None of us has ever seen 0033 deliver on reducing the amount of s2s traffic. Even the authors of 0033 agreed

Re: [Standards] Proposed XMPP Extension: Recipient Server Side Notifications Filtering

Mon, 23 Jun 2014 12:11:35 +0100 Dave Cridland d...@cridland.net wrote: On 23 June 2014 11:44, Evgeny Khramtsov xramt...@gmail.com wrote: 1) servers hold too much state What state do you think they hold that they should not? CAPs cache for example. 2) clients receive too much data

Re: [Standards] Proposed XMPP Extension: Recipient Server Side Notifications Filtering

Mon, 23 Jun 2014 15:23:40 +0200 Kim Alvefur z...@zash.se wrote: When does this happen? Other clients should check with disco#info and caps if the client supports things before sending them. This happens when a server doesn't cache caps. Presence de-duplication would be very interesting to

Re: [Standards] Proposed XMPP Extension: Client State Indication

Tue, 19 Aug 2014 11:30:18 +0100 Matthew Wild mwi...@gmail.com wrote: There are so many different approaches and optimisations (as you just demonstrated in your message!). I don't feel this XEP is the right place to document them, I think there is a lot of room for experimentation. I want to

Re: [Standards] Proposed XMPP Extension: Client State Indication

Tue, 19 Aug 2014 10:21:42 -0700 Kurt Zeilenga kurt.zeile...@isode.com wrote: On Aug 19, 2014, at 10:05 AM, Matthew Wild mwi...@gmail.com wrote: On 19 August 2014 17:21, Evgeny Khramtsov xramt...@gmail.com wrote: Tue, 19 Aug 2014 11:30:18 +0100 Matthew Wild mwi...@gmail.com wrote

Re: [Standards] Cleaning the Wiki

Mon, 1 Sep 2014 19:08:22 +0200 Christian Schudt christian.sch...@gmx.de wrote: Hi, I appreciate the idea to introduce an issue tracker for XEPs (like Jira). It would be way much easier to move XEPs to github and use the corresponding github's bug tracker.

Re: [Standards] Cleaning the Wiki

Mon, 01 Sep 2014 21:57:42 +0200 Florian Schmaus f...@geekplace.eu wrote: On 01.09.2014 19:25, Evgeny Khramtsov wrote: Mon, 1 Sep 2014 19:08:22 +0200 Christian Schudt christian.sch...@gmx.de wrote: Hi, I appreciate the idea to introduce an issue tracker for XEPs (like Jira

Re: [Standards] Cleaning the Wiki

Mon, 1 Sep 2014 19:03:49 +0100 Steven Lloyd Watkin ll...@evilprofessor.co.uk wrote: Whilst I agree with you entirely (we could also use Travis to test patches are valid and publish / updated the website) I believe there are some potential legal issues that have come up previously. I *think*

Re: [Standards] Cleaning the Wiki

Mon, 1 Sep 2014 20:43:57 +0100 Dave Cridland d...@cridland.net wrote: Not all our contributors currently will use github. Who will not? And why?

Re: [Standards] Cleaning the Wiki

Mon, 1 Sep 2014 22:03:43 +0100 Dave Cridland d...@cridland.net wrote: See Kurt's comment as to one possible reason why. I use it for both work and pleasure; I'm more in the camp of wanting to avoid a proprietary outsourced lockin for a core concern. I don't mind a mirror on github, but then

Re: [Standards] Cleaning the Wiki

Tue, 2 Sep 2014 09:17:05 +0100 Kevin Smith ke...@kismith.co.uk wrote: On the issue tracker front: Having an issue tracker is sensible, if people (both the submitters and the people who need to handle the issues) want one. We set one up years ago, and it fell into disuse so it's no longer

Re: [Standards] Cleaning the Wiki

Tue, 2 Sep 2014 09:17:05 +0100 Kevin Smith ke...@kismith.co.uk wrote: On Tue, Sep 2, 2014 at 7:54 AM, Cramer, E.R. (Eelco) eelco.cra...@tno.nl wrote: So it is very well possible to host a service with the same features people love at github. There's an assumption running through a lot of

Re: [Standards] Cleaning the Wiki

Tue, 2 Sep 2014 10:57:44 +0100 Dave Cridland d...@cridland.net wrote: Just because you disagree with the argument does not make it invalid. Even though it's valid it doesn't mean it outweighs other arguments. I do follow the concept that a decentralized open protocol using a centralized

Re: [Standards] Cleaning the Wiki

Tue, 2 Sep 2014 10:58:38 +0100 Dave Cridland d...@cridland.net wrote: So your argument is that if the procedure doesn't fit the tool, we should change the procedure? Sure, why not.

Re: [Standards] Which server do you prefer mostly ?

Tue, 23 Sep 2014 14:43:07 +0100 kwaye kant gabrielkw...@gmail.com wrote: I am installing the ejabberd and it seems not to be easy to configure. What exactly do you have problems with?

Re: [Standards] Fwd: [Council] Minutes 2014-11-26

Thu, 27 Nov 2014 11:57:58 + Kevin Smith kevin.sm...@isode.com wrote: Kev proposes using Trello for Agenda planning, with a board prepared at https://trello.com/b/ww7zWMlI/xmpp-council-agenda, and all agree. Kev asks for Council to let him know their Trello accounts so he can add them to

Re: [Standards] Proposed XMPP Extension: HTTP File Upload

Sat, 1 Aug 2015 14:51:19 -0500 Sam Whited s...@samwhited.com wrote: If Content-MD5 were to be supported in particular it would probably have to be something that clients supported, eg. header name=Content-MD5 / Another issue is how to pass this data to the file recipient. While it

Re: [Standards] Proposed XMPP Extension: HTTP File Upload

Thu, 30 Jul 2015 12:06:18 +0200 Goffi go...@goffi.org wrote: why wouldn't file transfer work offline or with MUC ? We just need a way to request a file with an uri. We definitely need to transfer files with MUCs (think of lolcats in chats). Regarding offline: sometimes I want to send a lolcat

Re: [Standards] Proposed XMPP Extension: HTTP File Upload

Thu, 30 Jul 2015 11:07:28 +0200 Goffi go...@goffi.org wrote: My point is that HTTP transfer is nothing more than a P2P transfer between server and requester(s) (and why would you not store the file ?), and while trying to make life easier it will result in either developers implementing

Re: [Standards] MAM and MUC archives

Mon, 27 Jul 2015 12:32:48 +0100 Kevin Smith kevin.sm...@isode.com wrote: To the room. Will it be defined in the spec? Because it's not very obvious.

Re: [Standards] File Transfer Roadmap

Mon, 27 Jul 2015 10:33:15 +0200 Christian Schudt christian.sch...@gmx.de wrote: 1) How to do offline file transfer? (see HTTP Upload-XEP) 2) How to send a file in a MUC room to all occupants/members? I think before moving JFT to Draft, the above two questions should be discussed. HTTP

Re: [Standards] MAM and MUC archives

Mon, 27 Jul 2015 14:05:34 +0100 Kevin Smith kevin.sm...@isode.com wrote: Yes, “”” 3.2 MUC archives A MUC service allowing MAM queries for a room MUST expose the MAM archive on the room's bare JID “”” This is still unclear. It's only said that a service allows MAM queries for a room, but

Re: [Standards] Proposed XMPP Extension: HTTP File Upload

Mon, 27 Jul 2015 17:03:25 +0200 Rick van Rein r...@openfortress.nl wrote: I would like to point you to an alternative, namely MSRP MSRP is scary as an atomic war :)

Re: [Standards] Proposed XMPP Extension: HTTP File Upload

Mon, 27 Jul 2015 17:20:16 +0200 Rick van Rein r...@openfortress.nl wrote: For my understanding, could you rephrase that in technical terms please? Technically, you can count letters in the MSRP RFC and in HTTP-Upload XEP :) And to be serious, how do you see MSRP implemented in XMPP clients?

Re: [Standards] Proposed XMPP Extension: HTTP File Upload

Mon, 27 Jul 2015 11:01:58 -0500 Sam Whited s...@samwhited.com wrote: 2) Easily match signed requests; I did an example implementation where the server delegated storage to Amazon S3. The server would generate a pre-signed upload URL with a limited TTL, then the client would make a PUT to this

Re: [Standards] Deprecating Privacy Lists

Thu, 8 Oct 2015 14:05:04 +0200 Ralph Meijer wrote: > Can you explain why people wanting to implement some feature couldn't > (begin to) write a XEP? I have some ideas why they don't do this. I know a lot of developers from different projects who is unwilling to write XEPs. So my

Re: [Standards] Deprecating Privacy Lists

Mon, 12 Oct 2015 09:51:28 -0300 Ben Langfeld wrote: > What else would you call it? You can stop bugtracker for your project then. There are only trolls. > Someone has to do this. So XSF created a standardization process and now tells us: someone has to do this. > XMPP is

Re: [Standards] Deprecating Privacy Lists

Mon, 12 Oct 2015 09:48:07 -0300 Ben Langfeld wrote: > I'm afraid they'd be mistaken in this belief. Developers are bad, mmmkay. So what do you suggest? Teaching them to be better? I bet that's not the goal of XSF. I think the solution is to accept the fact developers do not

Re: [Standards] Deprecating Privacy Lists

Mon, 12 Oct 2015 13:03:52 -0300 Ben Langfeld wrote: > I'm happy with people reporting bugs against my open source projects. > When they come back and ask "is it done yet?", then I get mad. Your feelings are very interesting to know, but how this relates to the original problem

Re: [Standards] Deprecating Privacy Lists

Mon, 12 Oct 2015 08:45:29 -0300 Ben Langfeld wrote: > If no-one is prepared to say why they won't do this but continues to > complain about the absence of XEPs then the assumption has to be that > they are trolling. So, if I complain there is no feature X in software Y and I'm

Re: [Standards] Deprecating Privacy Lists

Mon, 12 Oct 2015 13:58:21 -0300 Ben Langfeld wrote: > My point is this: > > 1. What appears to be a majority of the XSF does not believe that > Privacy Lists should be promoted as the correct way to achieve the > functionality it intended to provide. > 2. The XSF has a tool to

Re: [Standards] Deprecating Privacy Lists

Mon, 12 Oct 2015 13:48:34 -0300 Ben Langfeld wrote: > What is your suggested solution to making XMPP easier to contribute > to? This is a very funny question from you. Because whatever one says can be opposed with "you're not a customer" argument.

Re: [Standards] Deprecating Privacy Lists

Mon, 12 Oct 2015 15:39:38 -0300 Ben Langfeld <b...@langfeld.me> wrote: > On 12 October 2015 at 14:28, Evgeny Khramtsov <xramt...@gmail.com> > wrote: > > > Mon, 12 Oct 2015 13:48:34 -0300 > > Ben Langfeld <b...@langfeld.me> wrote: > > > > >

Re: [Standards] Deprecating Privacy Lists

Mon, 12 Oct 2015 16:04:43 -0300 Ben Langfeld wrote: > "We want to deprecate Privacy Lists because we think it's a bad spec." > "You'll have to write a good spec first!" > "A good spec would be nice. Do you (or anyone else in the community) > fancy helping write one?" > "No! You

Re: [Standards] Deprecating Privacy Lists

Mon, 12 Oct 2015 22:21:38 +0200 Ralph Meijer wrote: Technical arguments, finally :) > One of the major problems on the client side, is that implementing a > proper user interface for this protocol is a challenge and unlikely to > be very intuitive. Have a look at Gajim's

Re: [Standards] Proposed XMPP Extension: Jingle HTTP Transport Method

Wed, 26 Aug 2015 16:48:41 +0200 Kim Alvefur z...@zash.se wrote: Didn't Jingle File Transfer support transfer of multiple files? OK, probably it does. But it's still unclear how this will interact with thumbnails. As I understand several files will be rejected at the first step (only thumbnails

Re: [Standards] XMPP Myths

Thu, 27 Aug 2015 17:13:14 +0100 Dave Cridland d...@cridland.net wrote: The rest of these comments, though, I largely agree with - there's been talk of putting together both a new profile XEP, listing the things any modern messaging app should support, and also putting together a bunch of

Re: [Standards] Proposed XMPP Extension: Jingle HTTP Transport Method

Wed, 19 Aug 2015 15:44:30 + (UTC) XMPP Extensions Editor edi...@xmpp.org wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Jingle HTTP Transport Method Abstract: This specification defines two Jingle transport methods for establishing HTTP connections for

Re: [Standards] Proposed XMPP Extension: Jingle HTTP Transport Method

Wed, 26 Aug 2015 19:38:35 -0700 Lance Stout lancest...@gmail.com wrote: To that end, I submitted an update to XEP-0264 today to get it out of the Deferred state, allow it to use other URI types, and expand its scope to more than just file transfer thumbnails (for example, attaching a

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

Thu, 3 Sep 2015 14:11:32 +0300 Evgeny Khramtsov <xramt...@gmail.com> wrote: > It would be great if the protocol supports image thumbnails > (optionally). A server could generate thumbnails during upload so a > client don't need to convert image locally. This will reduce >

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

Thu, 27 Aug 2015 16:10:18 + (UTC) XMPP Extensions Editor wrote: > Version 0.1 of XEP-0363 (HTTP File Upload) has been released. > > Abstract: This specification defines a protocol to request > permissions from another entity to upload a file to a specific path > on an HTTP

Re: [Standards] Extending the XHTML-IM profile

Tue, 25 Aug 2015 22:03:14 +0200 Emmanuel Gil Peyrot linkma...@linkmauve.fr wrote: Their current way is pretty terrible, they just put the URL in the body of the message, and the receiving client will download and display it if there is no other text than the URL. This terrible way is easy to

Re: [Standards] XEP Review

Thu, 17 Sep 2015 13:51:41 +0100 Kevin Smith wrote: > Hi folks, > > Council had a chat yesterday about how much review XEPs generally get > outside those last-minute reviews required by Council at advancement > points, and we generally agree that what happens is often >

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

Thu, 17 Sep 2015 21:49:04 +0200 Daniel Gultsch wrote: > Hi, > > a couple of reason that speak against using the HTTP upload to create > thumbnails. (In no particular order) > > - the service should be agnostic towards the files. I assume you are > proposing to create

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)

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)

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)

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 extension implementations among different libraries, servers and > applications.

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

Mon, 21 Sep 2015 16:06:13 + (UTC) XMPP Extensions Editor wrote: > Version 0.4 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

Re: [Standards] Deprecating Privacy Lists

Tue, 6 Oct 2015 12:43:06 +0100 Kevin Smith wrote: > On 5 Oct 2015, at 14:42, Matthew Wild wrote: > > XEP-0191 is simple and efficient. It does one job, which is the one > > that most users need and expect - blocking someone they not longer > > want

Re: [Standards] Deprecating Privacy Lists

Tue, 6 Oct 2015 11:35:58 -0500 Sam Whited wrote: > and I doubt that > anyone's going to try and come up with a new thing *unless* the old > one is deprecated The thing is nobody will come up even in the case the XEP is deprecated. There were several attempts to write SPIM

Re: [Standards] XMPP client certificates for SASL EXTERNAL

Wed, 6 Jan 2016 13:28:54 -0500 "Emil Romascanu" wrote: > Hello, > > Could anybody send me a few X.509v3 certificates of XMPP clients that > can be used for SASL authentication. I am looking for certs that > satisfy the cases presented in XEP-0178, page 3:

Re: [Standards] XMPP client certificates for SASL EXTERNAL

Wed, 6 Jan 2016 14:14:27 -0500 "Emil Romascanu" wrote: > Could you change the '.pem' extension of the file to '.bin' to allow > the download? Probably the browser is trying to import the .pem file > and because it's not being a CA cert from a trusted CA it prevents > its

Re: [Standards] Images in chat

Fri, 11 Mar 2016 09:24:17 -0600 Sam Whited wrote: > On Fri, Mar 11, 2016 at 8:33 AM, Peter Waher > wrote: > > What is the preferred way of sending an image in chat today? > > XHTML-IM can be used to send smaller images using the data URI > > scheme. >

Re: [Standards] A MIX Tape of suggestions.

Mon, 23 May 2016 12:28:11 +0100 Dave Cridland wrote: > I'd really like to avoid the overhead of '60 syntax where this makes > sense. But in this case you cannot re-use existing pubsub framework at least server-wise (not sure about clients).

Re: [Standards] Proposed XMPP Extension: Spam Reporting

Sat, 21 May 2016 23:44:44 + (UTC) XMPP Extensions Editor wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Spam Reporting > > Abstract: > This document specifies a mechanism by which users can report > spam and other abuse to a

Re: [Standards] MIX progress

Tue, 5 Jul 2016 09:55:53 +0200 Florian Schmaus wrote: > I'd also welcome if XEP development, especially for such an important > one like MIX, would be more open. For the record, we already have github XSF repo for that. We can keep development there and tag stable version.

[Standards] MIX progress

Hello, Is anyone working on the MIX (XEP-0369) spec? Can I look at a preliminary updated version? I'm playing with MIX-MUC interaction code and it seems like ACL and config interaction is the most challenging part, which we sadly don't have currently defined in the published version.

Re: [Standards] MIX progress

Tue, 5 Jul 2016 08:10:13 +0100 Kevin Smith wrote: > Yes, Steve’s done a pass of significant changes - he just wants me to > run a quick review over it before submitting the next version. Hi, Kevin. Is it possible to publish this raw version somewhere? I don't care about

Re: [Standards] MIX progress

Tue, 5 Jul 2016 10:10:28 +0100 Kevin Smith wrote: > On 5 Jul 2016, at 09:51, Florian Schmaus wrote: > > XEP development behind closed doors is not desirable. > > To be fair, that isn’t what’s happening here, it’s just that Steve > wants to

Re: [Standards] CSI and Carbons state after SM resumption

Mon, 6 Feb 2017 12:03:15 + Kevin Smith wrote: > Nothing stops further specs from changing the core rules by > negotiation. This is not a violation, it’s agreeing to do something > different. I guess that's your opinion? Or where is it stated in the RFC? is a

Re: [Standards] CSI and Carbons state after SM resumption

Mon, 6 Feb 2017 12:44:49 +0100 Florian Schmaus wrote: > Maybe I don't understand the question, but Bind2 still does resource > binding. Yes, but in a different way. While RFC6120 tells how to *exactly* bind a resource: > the client MUST bind a resource to the stream as

Re: [Standards] RFC 6120 vs. XEP

Mon, 6 Feb 2017 16:46:58 -0700 Peter Saint-Andre wrote: > tl;dr Let's do the best we can on Bind2 and then cross the IETF > bridge when we come to it. If the issue is to be addressed, it's fine by me. ___ Standards mailing list

Re: [Standards] Easy XMPP

Sun, 5 Feb 2017 08:31:45 +0300 ValdikSS wrote: > You want to know why? For many years XMPP was a protocol not suited > for modern mobile devices with unstable network connection. Messages > could be easily lost (and you had to ask for receiving > acknowledgement yourself in

Re: [Standards] RFC 6120 vs. XEP

Tue, 7 Feb 2017 09:57:07 -0600 Sam Whited wrote: > The rules for required stream features say that if multiple required > features are listed, the client picks between them. In this case, > clients that support it would simply pick the new bind mechanism and > 6120 is

Re: [Standards] RFC 6120 vs. XEP

Tue, 7 Feb 2017 14:04:59 +0100 Ralph Meijer wrote: > A client that understands Bind2 can simply see the feature appearing > next to the RFC 6120 one, and choose to negotiate it instead of that. The problem is, formally speaking, it cannot ignore RFC's binding, because there are

Re: [Standards] Proposed XMPP Extension: Extensible SASL Profile

Thu, 9 Feb 2017 02:05:35 + (UTC) XMPP Extensions Editor wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Extensible SASL Profile > > Abstract: This document describes a replacement for the SASL profile > documented in RFC 6120 which

Re: [Standards] CSI and Carbons state after SM resumption

Mon, 6 Feb 2017 14:57:10 + Kevin Smith wrote: > Not really, that’s just how extensions work. I disagree. Extensions should extend, not replace, the RFC. Replacing RFCs by XEPs is some new phenomenon introduced in recent years.

Re: [Standards] RFC 6120 vs. XEP

Wed, 8 Feb 2017 08:19:17 + Dave Cridland wrote: > Right, I understand, and largely agree. I might scribble a draft to > address this, by clarifying what we really meant here. I see also two issues here ;) 1. RFC6120, section 7.1 says: > After a client authenticates with

Re: [Standards] RFC 6120 vs. XEP

Tue, 7 Feb 2017 21:22:17 + Dave Cridland <d...@cridland.net> wrote: > On 7 February 2017 at 16:29, Evgeny Khramtsov <xramt...@gmail.com> > wrote: > > Tue, 7 Feb 2017 19:18:39 +0300 > > Evgeny Khramtsov <xramt...@gmail.com> wrote: > >> Indeed (se

Re: [Standards] CSI and Carbons state after SM resumption

Mon, 6 Feb 2017 09:22:22 +0100 Dave Cridland wrote: > A combination of bind 2 and SASL 2 will sort this out. I'm wondering how all this new shiny stuff deals with RFC6120 where, for example, resource binding is a MUST? ___ Standards

Re: [Standards] CSI and Carbons state after SM resumption

Mon, 6 Feb 2017 03:14:54 -0600 Sam Whited wrote: > Not at all; the nonzas are semantically correct here because it > doesn't make sense to have the CSI enable/disable "commands" be > routable. What does that "routable" mean? Are roster queries "routable"?

Re: [Standards] CSI and Carbons state after SM resumption

Mon, 6 Feb 2017 10:32:22 +0100 Kim Alvefur wrote: > ... you can have a roster with another entity, for example a transport > to another IM network. And do I have privacy list with another entity? Private XML storage? In more general, why couldn't an external component maintain my

Re: [Standards] MIX use of type=groupchat?

Sun, 22 Jan 2017 19:31:38 + Stephen Paul Weber wrote: > I have a question about > > > Doesn't using defeat the purpose of > building on / re-using PubSub? Absolutely. Pubsub doesn't fit well, and,

Re: [Standards] MIX use of type=groupchat?

Mon, 23 Jan 2017 07:12:17 - "Steve Kille" wrote: > I don't think this is right. And what about you previous statement: > There would be a definite elegance in "using PubSub" everywhere, and > an early MIX version was written this way So you failed to build "elegant"

Re: [Standards] MIX use of type=groupchat?

Mon, 23 Jan 2017 08:14:55 - "Steve Kille" wrote: > I think what we are doing with MIX is also elegant. And ad-hoc access model is very elegant for sure. Why is it needed by the way? Because pubsub's access model is not elegant enough? :) > I think that a MIX goal is

Re: [Standards] MIX use of type=groupchat?

Mon, 23 Jan 2017 09:37:44 + Dave Cridland wrote: > If by a generic relay you mean "reflects traffic as-is too all > subscribers", isn't that what MIX/MUC are providing? It is hard to call it "generic", because it introduces very specific stuff like "subject" node for

Re: [Standards] MIX use of type=groupchat?

Mon, 23 Jan 2017 11:32:54 + Dave Cridland wrote: > MIX introduces a proxy JID simply because without one, you'd have to > have metadata in the message to indicate the publisher Why not? MIX server already parses node's items data, so why bother?

Re: [Standards] LAST CALL: XEP-0368 (SRV records for XMPP over TLS)

Sat, 28 Jan 2017 17:26:00 + (UTC) XMPP Extensions Editor wrote: > 5. Is the specification accurate and clearly written? I think the sentence: > ALPN (RFC 7301) requires registration of the new Protocol IDs, > 'xmpp-client' and 'xmpp-server', specified in this document is

Re: [Standards] Proposed XMPP Extension: Bind 2.0

Wed, 25 Jan 2017 12:11:12 + Dave Cridland wrote: > Not that I believe XMPP can't scale any more than you, but clustering > is about more than scale (or should be). I know that. But every customer we have/had wanted a scalable fault-tolerant clustering. Also, in other

Re: [Standards] Proposed XMPP Extension: Bind 2.0

Wed, 25 Jan 2017 10:59:19 + Kevin Smith wrote: > Mostly because I don’t want to make 198 resumption mandatory for > servers, where it’s somewhere between fairly difficult and > impossible, depending on architecture (unless a server doesn’t > support clustering, in

Re: [Standards] Advance XEP-0368 to Proposed

Thu, 19 Jan 2017 15:19:12 -0500 Travis Burtrum wrote: > Hi all, > > I am proposing advancing XEP-0368 from Experimental to Proposed, and > the XSF MUC said to do this by sending an email to the standards list. > > https://xmpp.org/extensions/xep-0368.html > > It's been a

Re: [Standards] Example Resources in XEPs (XEP-0369)

Mon, 20 Feb 2017 10:36:07 +0100 Georg Lukas wrote: > I think that we need readable examples in the XEPs over anything else. > My suggestion would be to use human-readable, short resource > identifiers, both in the client case and in the auto-generated proxy > case. It is possible

Re: [Standards] Proposed XMPP Extension: Extensible In-Band Registration

Mon, 13 Feb 2017 11:24:32 -0600 Sam Whited wrote: > Maybe I'm misunderstanding what you want to use ad-hoc commands for; > the server just sends the user "challenges" (which might be a data > form, a POW function, an out-of-band link to click, etc.) and the user > replies

Re: [Standards] Proposed XMPP Extension: Extensible In-Band Registration

Mon, 13 Feb 2017 20:56:33 +0100 Florian Schmaus wrote: > It might makes sense to define generic request/response Nonzas for > such cases. Just like IQs, but only between two directly connected > endpoints. After all, a server can just send stream errors. Because, typically,

Re: [Standards] Proposed XMPP Extension: Extensible In-Band Registration

Mon, 13 Feb 2017 13:58:14 -0600 Sam Whited wrote: > I'm still not sure what you're expecting the ad hoc commands to do; > can you send me a listing of some example adhoc commands? I think > there might be a misunderstanding about how this spec works; the > client does not

Re: [Standards] LAST CALL: XEP-0368 (SRV records for XMPP over TLS)

Tue, 14 Feb 2017 09:25:17 -0500 Travis Burtrum wrote: > It's basically got 3 maybe 4 use cases, share ports with other TLS > services, enable connectivity from places with dumb firewall policies > (airports, coffee shops etc), save roundtrips. And this is the maybe, > most

Re: [Standards] Proposed XMPP Extension: Extensible In-Band Registration

Mon, 13 Feb 2017 15:14:15 -0600 Sam Whited wrote: > So you're suggesting we have a "register or recover" feature, and > that feature gives you "commands" for "register" and "recover"? No, I suggest something like: http://jabber.org/protocol/commands'> register

Re: [Standards] Proposed XMPP Extension: Extensible In-Band Registration

Mon, 13 Feb 2017 15:26:59 -0600 Sam Whited wrote: > I don't see all those things fitting into this XEP, so we go back to > my original position: this seems like a neat idea, but rewriting the > XMPP handshake (or creating a new feature that just acts as a slightly > different

Re: [Standards] Proposed XMPP Extension: Extensible SASL Profile

Thu, 9 Feb 2017 08:40:49 + Dave Cridland wrote: > 3) I still do not understand, what's the point in sending =? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe:

Re: [Standards] Proposed XMPP Extension: Extensible SASL Profile

Thu, 9 Feb 2017 09:41:43 + Dave Cridland wrote: > Because the server has to send an empty string, not the absence of a > challenge. When does it make a difference (i.e. empty string vs its absence)? ___ Standards mailing list

Re: [Standards] NEW: XEP-0387 (XMPP Compliance Suites 2017)

Fri, 10 Feb 2017 12:58:31 +0100 Georg Lukas wrote: > - Removal of 'User Avatars' from IM-Core, making it IM-Advanced only. Yeah, IM client without avatars in 2017. XMPP Underground :) ___ Standards mailing list Info:

Re: [Standards] LAST CALL: XEP-0368 (SRV records for XMPP over TLS)

Wed, 15 Feb 2017 08:21:39 +0100 "Ruslan N. Marchenko" wrote: > So the use case described above is - how to build loadbalancer with > ssl offload for xmpp from components which don't speak xmpp. Which > from my understanding is again a corner-case. Well, high-load is always a

  1   2   3   >