Re: [Standards] Deprecating Privacy Lists (again)

One nice feature we also don't have with blocking command is blocking a while group. -- Yann Le 22/03/2017 à 20:08, Sam Whited a écrit : > TL;DR — Privacy lists don't give us anything that we actually want to > have that the blocking command doesn't give us already, and they're > too

Re: [Standards] UPDATED: XEP-0070 (Verifying HTTP Requests via XMPP)

On 12/09/2016 05:20 PM, XMPP Extensions Editor wrote: > Version 1.0.1 of XEP-0070 (Verifying HTTP Requests via XMPP) has been > released. > > Abstract: This specification defines an XMPP protocol extension that enables > verification of an HTTP request via XMPP. > > Changelog: [See revision

Re: [Standards] UPDATED: XEP-0045 (Multi-User Chat)

Le 2016-05-16 22:33, XMPP Extensions Editor a écrit : Version 1.26 of XEP-0045 (Multi-User Chat) has been released. Abstract: This specification defines an XMPP protocol extension for multi-user text chat, whereby multiple XMPP users can exchange messages in the context of a room or channel,

Re: [Standards] Current OTR Info

Le 2016-05-09 03:37, Brian Cully a écrit : On 8-May-2016, at 15:08, Yann Leboulanger <aste...@lagaule.org> wrote: All that is not specific to OTR. All encryption mechanisms are concerned (GPG for example). Currently, one can send a GPG encrypted message with a bad key, and neve

Re: [Standards] Current OTR Info

On 05/08/2016 07:17 PM, Sam Whited wrote: > On Sun, May 8, 2016 at 12:05 PM, Sam Whited wrote: >> On Wed, Apr 27, 2016 at 3:48 PM, Chris Ballinger >> wrote: >>> A quick fix would be to only send delivery receipts if the message could be >>> successfully

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

[Standards] XEP 313 versions

Hi, I have 2 questions about XEP-313 versions: - Is it normal that V0.3 is not available here: http://xmpp.org/extensions/attic/ - Is it normal that the xmlns urn:xmpp:mam:0 is not updated from version to version? If a client support V0.3 and server implement V0.4, they think they can

Re: [Standards] XEP 313 versions

On 09/16/2015 08:59 PM, Kevin Smith wrote: > On 16 Sep 2015, at 19:32, Yann Leboulanger <aste...@lagaule.org> wrote: >> - Is it normal that the xmlns urn:xmpp:mam:0 is not updated from >> version to version? If a client support V0.3 and server implement V0.4, >> they

Re: [Standards] XEP 313 versions

On 09/16/2015 09:38 PM, Kevin Smith wrote: > On 16 Sep 2015, at 20:08, Yann Leboulanger <aste...@lagaule.org> wrote: >> On 09/16/2015 08:59 PM, Kevin Smith wrote: >>> On 16 Sep 2015, at 19:32, Yann Leboulanger <aste...@lagaule.org> wrote: >>>> -

Re: [Standards] XEP-0234 Jingle File Transfer 0.16

On 06/21/2015 03:56 PM, Tobias Markmann wrote: On Sat, Jun 20, 2015 at 2:08 PM, Yann Leboulanger aste...@lagaule.org mailto:aste...@lagaule.org wrote: I just read the version 0.16 of Jingle File Transfer XEP, and saw that you removed the request flow. Just to mention

Re: [Standards] XEP-0234 Jingle File Transfer 0.16

On 07/13/2015 09:37 PM, Tobias Markmann wrote: On Mon, Jul 13, 2015 at 9:30 PM, Yann Leboulanger aste...@lagaule.org mailto:aste...@lagaule.org wrote: As there is no other answer, I guess nobody is interested in this topic. Sad but I'll stay with :3 then. Well.. there is http

[Standards] XEP-0234 Jingle File Transfer 0.16

Hi all, I just read the version 0.16 of Jingle File Transfer XEP, and saw that you removed the request flow. Just to mention that it is used in Gajim to re-request the file at the end of a tranfer when hash was wrong. I don't think it's a good thing to removed a feature without a replacement,

Re: [Standards] XEP-0234 Jingle File Transfer 0.16

On 06/20/2015 09:41 PM, Daniel Gultsch wrote: out of curiosity does this mean you are working on implementing jingle file transfer 0.16 in gajim? I was looking at it, but this would cause a regression in 2 of our features: ability to re-request a file in hash is wrong and our file sharing

Re: [Standards] Blocking command and Privacy Lists

Le 22/12/2014 16:21, Dave Cridland a écrit : On 22 December 2014 at 13:51, Sam Whited s...@samwhited.com mailto:s...@samwhited.com wrote: On 12/22/2014 04:19 AM, Dave Cridland wrote: Slightly confused by this. XEP-0191 is server-side enforced, so the behaviour will be

Re: [Standards] Whiteboarding with XMPP

On 09/22/2014 04:10 PM, Christian Schudt wrote: Hi, I am looking to implement whiteboard functionality in an XMPP client. All I've found about it (protocol-wise) is this: http://xmpp.org/extensions/inbox/whiteboard.html http://xmpp.org/extensions/inbox/whiteboard2.html

[Standards] forwarding message

Hi all, while reading some XEP here and there, I found something strange in XEP-0146. To forward messages it uses XEP-0033 with type='ofrom', which doesn't exist in this XEP. -- Yann

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

On 06/11/2013 10:38 PM, XMPP Extensions Editor wrote: Version 0.2 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: Document the ability to page through results by

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

On 07/24/2013 07:50 PM, Matthew Wild wrote: On 24 July 2013 18:48, Kim Alvefurz...@zash.se wrote: On 2013-07-24 19:23, Matthew Wild wrote: On 24 July 2013 17:46, Yann Leboulangeraste...@lagaule.org wrote: On 06/11/2013 10:38 PM, XMPP Extensions Editor wrote: There sould be a way to retrieve

Re: [Standards] XEP-0191

On 03/31/2013 11:33 AM, Kevin Smith wrote: On Sat, Mar 30, 2013 at 1:08 PM, Yann Leboulangeraste...@lagaule.org wrote: While starting to implement XEP-0191, I realized that there is a regression in the feature Gajim offers if I don't use privacy lists: The ability to block a group by its name.

Re: [Standards] XEP-0191

On 03/31/2013 11:29 PM, Peter Saint-Andre wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/31/13 3:33 AM, Kevin Smith wrote: On Sat, Mar 30, 2013 at 1:08 PM, Yann Leboulanger aste...@lagaule.org wrote: While starting to implement XEP-0191, I realized that there is a regression

[Standards] XEP-0191

Hi all, While starting to implement XEP-0191, I realized that there is a regression in the feature Gajim offers if I don't use privacy lists: The ability to block a group by its name. What about adding the ability to block a group in this XEP with something like: item group='co-workers'/

Re: [Standards] XEP-296 problem?

On 08/15/2012 06:18 PM, Kevin Smith wrote: On Wed, Aug 15, 2012 at 5:11 PM, Yann Leboulangeraste...@lagaule.org wrote: On 08/15/2012 05:59 PM, Kevin Smith wrote: On Wed, Aug 15, 2012 at 4:50 PM, Yann Leboulangery...@leboulanger.org wrote: On 08/15/2012 05:48 PM, Kevin Smith wrote: On

[Standards] XEP-296 problem?

Hi, I was wonder what should I do in this situation: user A and B are connected with resource r1. They that, so messages go from A/r1 to B/r1. user B connects a second client with resource r2 with a higher priority. Where should go next message of user A? Someone pointed me to XEP-0296

Re: [Standards] XEP-296 problem?

On 08/15/2012 05:48 PM, Kevin Smith wrote: On Wed, Aug 15, 2012 at 4:45 PM, Yann Leboulangeraste...@lagaule.org wrote: Hi, I was wonder what should I do in this situation: user A and B are connected with resource r1. They that, so messages go from A/r1 to B/r1. user B connects a second

Re: [Standards] XEP-296 problem?

On 08/15/2012 05:59 PM, Kevin Smith wrote: On Wed, Aug 15, 2012 at 4:50 PM, Yann Leboulangery...@leboulanger.org wrote: On 08/15/2012 05:48 PM, Kevin Smith wrote: On Wed, Aug 15, 2012 at 4:45 PM, Yann Leboulangeraste...@lagaule.org wrote: Hi, I was wonder what should I do in this

Re: [Standards] XEP-296 problem?

On 08/15/2012 05:59 PM, Kevin Smith wrote: On Wed, Aug 15, 2012 at 4:50 PM, Yann Leboulangery...@leboulanger.org wrote: On 08/15/2012 05:48 PM, Kevin Smith wrote: On Wed, Aug 15, 2012 at 4:45 PM, Yann Leboulangeraste...@lagaule.org wrote: Hi, I was wonder what should I do in this

Re: [Standards] XEP-296 problem?

On 08/15/2012 06:17 PM, Matthew Miller wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 15, 2012, at 09:45, Yann Leboulanger wrote: Hi, I was wonder what should I do in this situation: user A and B are connected with resource r1. They that, so messages go from A/r1 to B/r1

[Standards] error in RFC 6120

Hi, I think there is a small error in RFC6120, in section 4.9.3.19, at the end of the section: (b) the receiving entity MAY have a policy of following redirects only if it has authenticated the receiving entity I think it should be (b) the *initiating* entity MAY have a policy of

Re: [Standards] jingle file transfer with proxies

On 10/31/2011 10:16 PM, Yann Leboulanger wrote: Hi, I'm trying to make jingle FT working in a special case: sender sends no cadidate, receiver propose a proxy only. so sender connects to proxy, then send a candidate-used to receiver. Then receiver connects to proxy, activates it, and here

[Standards] jingle file transfer with proxies

Hi, I'm trying to make jingle FT working in a special case: sender sends no cadidate, receiver propose a proxy only. so sender connects to proxy, then send a candidate-used to receiver. Then receiver connects to proxy, activates it, and here is the problem, all the proxy I tested returns an

Re: [Standards] Proposed XMPP Extension: Whitespace Keepalive Negotiation

On 07/19/2011 10:19 PM, XMPP Extensions Editor wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Whitespace Keepalive Negotiation Abstract: This specification defines a method for negotiating how to send keepalives in XMPP. URL:

Re: [Standards] RFC vs privacy lists

Le 28/04/2011 00:24, Florian Zeitz a écrit : Am 27.04.2011 23:43, schrieb Florian Zeitz: Am 27.04.2011 23:28, schrieb Yann Leboulanger: No, the outgoing iq is not blocked, but the reply is. So a client sends an iq, but nver get an answer, which is against the RFC. As you pointed out yourself

Re: [Standards] RFC vs privacy lists

Le 28/04/2011 10:31, Dave Cridland a écrit : The easiest way to fix this (IMHO) is probably to send the user a type error IQ whenever he is trying to send a type get/set one to a JID that is blocked from answering. That does not fix your problem however and I maintain that the solution to that

Re: [Standards] RFC vs privacy lists

Le 28/04/2011 14:12, Remko Tronçon a écrit : I thought we had established incoming means incoming from the client's POV. Right, i actually meant the whole chain, up to and including the server part (up to the stanza router). It doesn't make sense to filter out stanzas from your own server (not

Re: [Standards] RFC vs privacy lists

Le 28/04/2011 15:20, Matthew Wild a écrit : On 28 April 2011 14:16, Yann Leboulangeraste...@lagaule.org wrote: Le 28/04/2011 14:12, Remko Tronçon a écrit : I thought we had established incoming means incoming from the client's POV. Right, i actually meant the whole chain, up to and

[Standards] RFC vs privacy lists

Hi, I have a problem with privacy list on an ejabberd server, and developers are right to say there is a problem in the standards: Let's say I configure a list to block all IQ for jid with subscription=none (nice anti-spam rule). Now I don't get any iq answer to, let's say, disco#info on my

Re: [Standards] RFC vs privacy lists

On 04/27/2011 08:02 PM, Remko Tronçon wrote: That's normal because RFC [1] says that Privacy lists MUST be the first delivery rule applied by a server, superseding ... XEP 16 (copied from the RFC), section 2.14 says that the server should return service-unavailable. Really? I See the case

Re: [Standards] RFC vs privacy lists

On 04/27/2011 09:04 PM, Kim Alvefur wrote: Let's say I configure a list to block all IQ for jid with subscription=none (nice anti-spam rule). Now I don't get any iq answer to, let's say, disco#info on my server. That's normal because RFC [1] says that Privacy lists MUST be the first delivery

Re: [Standards] RFC vs privacy lists

On 04/27/2011 10:00 PM, Remko Tronçon wrote: If a user setup this rule it's because he doesn't want spam. And if server don't block result|error, user can be spammed of iq result for ex According to xep-0016: The allowable child elements are: message/ -- blocks incoming message stanzas iq/

Re: [Standards] RFC vs privacy lists

On 04/27/2011 10:42 PM, Remko Tronçon wrote: So a client is not allowed to send an iq to its server if this anti-spam rule is set? I'm not quite following why it's not ok to send an iq to your own server? The XEP says that privacy lists block *incoming* IQs (that is, 'incoming' from the point

[Standards] XEP-0198: errors in stanza counting?

Hi, I just re-read XEP-0198 (Stream management), and I'm not sure about the way stanza are counted. In example 17, shouldn't client answer with h=1? It already received his roster, so h should be 1. And in example 21, after 5 messages server should reply with h=5 (not 4) as it received 5

Re: [Standards] Which XEP does define the presence information?

On 01/26/2011 12:51 PM, Iñaki Baz Castillo wrote: Hi, I would like to know which XEP(s) defines the exact format of the presence information a client sends to the server. I mean the online/busy/away/etc status, the mod, the text note and so on. Thanks a lot. it's RFC 3921:

Re: [Standards] XEP-0184: received/ vs. displayed/ vs. read/

On 06/19/2010 10:40 AM, Kevin Smith wrote: I think the counterpoint to this is true, but not this, isn't it? received/ helps you know that a message was not lost due to brutal disconnection (etc.) - but the lack of areceived/ doesn't imply that it *was* lost (there's a chunk of text about

Re: [Standards] XEP-0184: received/ vs. displayed/ vs. read/

On 06/18/2010 08:20 PM, Konstantin Kozlov wrote: Waqas Hussain пишет: On Fri, Jun 18, 2010 at 5:00 PM, Konstantin Kozlov yag...@yandex.ru wrote: Well. According to my experience, based on knowledge of my behavior and behavior of my friends, the fact that my message is not new anymore on the

Re: [Standards] XEP-0184: received/ vs. displayed/ vs. read/

On 06/17/2010 03:29 PM, Konstantin Kozlov wrote: Kevin Smith wrote: On Wed, Jun 16, 2010 at 8:10 PM, Konstantin Kozlov yag...@yandex.ru wrote: Yes. Let's sort out what means received, displayed and read to decide which of them are needed and which are not. Yes. So: What's the use case for

Re: [Standards] XEP-0184: received/ vs. displayed/ vs. read/

On 06/16/2010 08:15 PM, Kevin Smith wrote: On Wed, Jun 16, 2010 at 7:04 PM, Peter Saint-Andrestpe...@stpeter.im wrote: I just had an interesting conversation with yagiza about XEP-0184, which he has said I can paste here. The general idea is: do we need something in XEP-0184 to indicate that a

Re: [Standards] XEP-0184: received/ vs. displayed/ vs. read/

On 06/16/2010 08:27 PM, Kevin Smith wrote: On Wed, Jun 16, 2010 at 7:21 PM, Yann Leboulangeraste...@lagaule.org wrote: On 06/16/2010 08:15 PM, Kevin Smith wrote: On Wed, Jun 16, 2010 at 7:04 PM, Peter Saint-Andrestpe...@stpeter.im wrote: I just had an interesting conversation with yagiza

Re: [Standards] XEP-0184: received/ vs. displayed/ vs. read/

On 06/16/2010 08:57 PM, Kevin Smith wrote: Note that 184 is explicit about not using it for triggering re-sends. So you know that your contact didn't received the message but you're not allowed to re-send it? I mean client doesn't re-send it automatically, ok, but user does.

Re: [Standards] XEP-0048 bookmarks

Le 08/03/2010 12:28, Nicolas Vérité a écrit : Hi all, The main difference between versions 1.0 and 1.1 of the bookmarks XEP is the previous use of XEP-0049: Private XML Storage, and the new recommandation of use of XEP-0223: Persistent Storage of Private Data via PubSub. The section 3 even

Re: [Standards] XEP-0136 modifications

Peter Saint-Andre wrote: On 2/2/10 12:59 PM, Yann Leboulanger wrote: The main problem I faced was that it is currently not possible to stop archiving a conversation. The scenario is this one: auto archiving is enabled. I start a conversation with a contact, so it's archived. I start

Re: [Standards] XEP-0136 modifications

Jonathan Schleifer wrote: Am 02.02.2010 um 20:59 schrieb Yann Leboulanger: I start encrypting the conversation (GPG or E2E). While this is true for E2E, it indeed makes sense to store GPG-encrypted message encrypted. Here, the replay attack of GPG becomes useful, as you can still decrypt

Re: [Standards] XEP-0136 modifications

Peter Saint-Andre wrote: Yann, I agree. I'd rather work to reduce complexity in XEP-0136 than to increase complexity. Any suggestions? :) Peter I'm not sure we can reduce complexity. In fact this XEP does 2 things: ability to save logs in server, and ability for clients to store their

Re: [Standards] XEP-0136 modifications

Peter Saint-Andre wrote: On 1/8/10 12:28 PM, Yann Leboulanger wrote: Hi all, Alexander Tsvyashchenko and I discussed changes in XEP-136, and we wrote them in the XEP. Attached is a diff of the xep-0136.xml, and you can see the result here: www.lagaule.org/xep/xep-0136.html What do you

Re: [Standards] XEP-0136 modifications

Yann Leboulanger wrote: Hi all, Alexander Tsvyashchenko and I discussed changes in XEP-136, and we wrote them in the XEP. Attached is a diff of the xep-0136.xml, and you can see the result here: www.lagaule.org/xep/xep-0136.html What do you think about that? Comments are appreciated

[Standards] XEP-0136 modifications

Hi all, Alexander Tsvyashchenko and I discussed changes in XEP-136, and we wrote them in the XEP. Attached is a diff of the xep-0136.xml, and you can see the result here: www.lagaule.org/xep/xep-0136.html What do you think about that? Comments are appreciated! -- Yann diff --git

Re: [Standards] XEP-136 (Message Archiving) clarifications

Alexander Tsvyashchenko wrote: On Fri, 18 Dec 2009 10:20:21 +0100, Yann Leboulanger aste...@lagaule.org wrote: But a solution could be that when we send a request to removing a collection being recorded by the server (example 48) The server should stop recording this session automatically

Re: [Standards] XEP-136 (Message Archiving) clarifications

Le 17/12/2009 23:02, Alexander Tsvyashchenko a écrit : Other resources do know about the changes instantly - see push examples 7, 10, 15. Having said that, I still agree that there might be better ways of doing things here: not sure why it was designed that way, but this XEP is comparably old -

Re: [Standards] XEP-136 (Message Archiving) clarifications

Alexander Tsvyashchenko wrote: Hello Yann, On Thu, 17 Dec 2009 17:28:22 +0100, Yann Le Boulanger aste...@lagaule.org wrote: [skipped] First, the preferences: I don't see the difference between auto save='false'/ and method type='auto' use='forbid'/ in example 3. [skipped] the auto

Re: [Standards] error 503 in MUC

Dave Cridland a écrit : On Mon Oct 12 21:11:00 2009, Yann Leboulanger wrote: Does this mean the room is not joinable (it's what XEP86 says)? Yes. Or does this mean maximum number of participant has been reached (it's ehat XEP45 says)? Maybe that's the reason it's not joinable. I know

[Standards] error 503 in MUC

When we try to join a room and get such an answer: presence from='r...@server/nick' to='jid' type='error' id='816' error code='503' type='cancel' service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/ /error /presence Does this mean the room is not joinable (it's what XEP86 says)? Or

Re: [Standards] Call for Experience: XEP-0199 (XMPP Ping)

Peter Saint-Andre wrote: In its meeting yesterday, the XMPP Council agreed to issue a Call for Experience regarding XEP-0199 (XMPP Ping), in preparation for perhaps advancing this specification from Draft to Final in the XSF's standards process. To help the Council decide whether this XEP is

[Standards] XEP-0145 (Annotations)

Hi, This XEP is maked as historical, why? Is it replaced by something else? Shouldn't it be updated to use pubsub instead of XML storage? -- Yann

Re: [Standards] DEFERRED: XEP-0209 (Metacontacts)

Jonathan Schleifer a écrit : Am 23.01.2009 um 12:32 schrieb Kevin Smith: Brilliant idea - it's almost as if you'd read the XEP. I'm sure the last time I looked at it it didn't. And IIRC, Gajim doesn't use a UUID there either. At least I can't remember having seen one there when I debugged

Re: [Standards] DEFERRED: XEP-0209 (Metacontacts)

Jiří Zárevúcký wrote: 1) Why not use user-specified handle (meta-contact name) instead of some opaque tag? Sure, you could do that too (unlness I overlook something, It's been some time). I'll clarify this. The value of the 'tag' is used as a non-human readable unique identifier for a

Re: [Standards] DEFERRED: XEP-0209 (Metacontacts)

Jiří Zárevúcký a écrit : Another thing to clarify - how to handle groups? That is.. Union? Intersection? Should client synchronize them when merging contacts? Etc.. I think that best approach would be union and synchronizing between all sub-contacts. In gajim we show contact in the groups of

Re: [Standards] [Fwd: [Council] meeting minutes, 2008-10-08]

Eric Will wrote: On Oct 8, 2008, at 4:22 PM, Peter Saint-Andre wrote: 5c. XEP-0091: Delayed Delivery Consensus that we need to determine how widely XEP-0203 is deployed before changing this to Obsolete. Not that I'm important, but I implemented XEP-0203 in synapse. Next Gajim

Re: [Standards] invisibility

Jonathan Schleifer wrote: Many argue that privacy lists are too complex for invisibility or blocking users. For example, the Pidgin developers. They complained that they need to implement privacy lists completely in order to achieve invisibility and blocking. IMO, we could change the XEP to

[Standards] XEP-146 and forwarding unread messages

In XEP-0146, there is a way to forward unread messages from one resource to another. But there is no way to also forward the time at which it was received. I think it would be a nice feature, no? -- Yann

Re: [Standards] XEP-0045: requesting a unique room name

Peter Saint-Andre wrote: Yann Leboulanger wrote: Peter Saint-Andre wrote: Has any MUC implementation coded in support for the unique room name request feature described in Section 10.1.4 of XEP-0045? I think this feature is unnecessary and (in the interest of simplification) I would like

Re: [Standards] XEP-0045: requesting a unique room name

Peter Saint-Andre wrote: Has any MUC implementation coded in support for the unique room name request feature described in Section 10.1.4 of XEP-0045? I think this feature is unnecessary and (in the interest of simplification) I would like to remove it from XEP-0045. In our client (Gajim),

Re: [Standards] Proposed XMPP Extension: XMPP Nodes

XMPP Extensions Editor a écrit : The XMPP Extensions Editor has received a proposal for a new XEP. Title: XMPP Nodes Abstract: This specification more clearly defines the nature of nodes as used in the Service Discovery and Publish-Subscribe extensions to the Extensible Messaging and

Re: [Standards] XHML + GPG

Yann Leboulanger wrote: Hi, XEP 27 (GPG) doesn't say anything on the way to encrypt XHML messages. Are those 2 features orthogonal? should XEP 27 be completed to encrypt XHTML messages ? So a client should disable XHTML when encrypting with GPG? -- Yann

[Standards] XHML + GPG

Hi, XEP 27 (GPG) doesn't say anything on the way to encrypt XHML messages. Are those 2 features orthogonal? should XEP 27 be completed to encrypt XHTML messages ? -- Yann