Re: [Standards] XEP-0384: OMEMO Encryption - Feedbacks and proposals

On 09/01/2017 11:24, Dave Cridland wrote: On 6 January 2017 at 08:36, Jaussoin Timothée wrote: Hi, I'm currently in the process of implementing end-to-end encryption in my project. I naturally had a look at the freshly published XEP-0384: OMEMO Encryption and I have some

Re: [Standards] Deferred XEPs Flood

On 1/17/17 7:20 PM, Sam Whited wrote: Appologies for the flood of emails; as you might have guessed, I've just deferred a bunch of XEPs that haven't been touched in a year (or several, in some cases). Some of them may of course still be useful, and I've reached out to the authors of a few to see

[Standards] Deferred XEPs Flood

Appologies for the flood of emails; as you might have guessed, I've just deferred a bunch of XEPs that haven't been touched in a year (or several, in some cases). Some of them may of course still be useful, and I've reached out to the authors of a few to see if they'd be interested in attempting

[Standards] DEFERRED: XEP-0336 (Data Forms - Dynamic Forms)

XEP-0336 (Data Forms - Dynamic Forms) has been Deferred because of inactivity. Abstract: This specification provides extensions to the data forms model defined in previous XEPs that permit enhanced end-user interaction and a better user experience. These extensions

[Standards] DEFERRED: XEP-0335 (JSON Containers)

XEP-0335 (JSON Containers) has been Deferred because of inactivity. Abstract: This specification defines an element to be used for encapsulating JSON data in XMPP. URL: http://xmpp.org/extensions/xep-0335.html If and when a new revision of this XEP is published, its status will be changed

[Standards] DEFERRED: XEP-0330 (Pubsub Subscription)

XEP-0330 (Pubsub Subscription) has been Deferred because of inactivity. Abstract: This specification describe a method that allow a user to share a list of nodes on which it is Pubsub registered URL: http://xmpp.org/extensions/xep-0330.html If and when a new revision of this XEP is published,

[Standards] DEFERRED: XEP-0334 (Message Processing Hints)

XEP-0334 (Message Processing Hints) has been Deferred because of inactivity. Abstract: This document defines a way to include hints to entities routing or receiving a message. URL: http://xmpp.org/extensions/xep-0334.html If and when a new revision of this XEP is published, its status will be

[Standards] DEFERRED: XEP-0331 (Data Forms - Color Field Types)

XEP-0331 (Data Forms - Color Field Types) has been Deferred because of inactivity. Abstract: This specification defines how to publish fields in data forms that take color values. Color values are best edited using a color picker dialog, rather than manual input. URL:

[Standards] DEFERRED: XEP-0333 (Chat Markers)

XEP-0333 (Chat Markers) has been Deferred because of inactivity. Abstract: This specification describes a solution of marking the last received, displayed and acknowledged message in a chat. URL: http://xmpp.org/extensions/xep-0333.html If and when a new revision of this XEP is published, its

[Standards] DEFERRED: XEP-0326 (Internet of Things - Concentrators)

XEP-0326 (Internet of Things - Concentrators) has been Deferred because of inactivity. Abstract: This specification describes how to manage and get information from concentrators of devices over XMPP networks. URL: http://xmpp.org/extensions/xep-0326.html If and when a new revision of this

[Standards] DEFERRED: XEP-0325 (Internet of Things - Control)

XEP-0325 (Internet of Things - Control) has been Deferred because of inactivity. Abstract: This specification describes how to control devices or actuators in an XMPP-based sensor network. URL: http://xmpp.org/extensions/xep-0325.html If and when a new revision of this XEP is published, its

[Standards] DEFERRED: XEP-0323 (Internet of Things - Sensor Data)

XEP-0323 (Internet of Things - Sensor Data) has been Deferred because of inactivity. Abstract: This specification provides the common framework for sensor data interchange over XMPP networks. URL: http://xmpp.org/extensions/xep-0323.html If and when a new revision of this XEP is published,

[Standards] DEFERRED: XEP-0324 (Internet of Things - Provisioning)

XEP-0324 (Internet of Things - Provisioning) has been Deferred because of inactivity. Abstract: This specification describes an architecture for efficient provisioning of services, access rights and user privileges in for the Internet of Things, where communication between

[Standards] DEFERRED: XEP-0320 (Use of DTLS-SRTP in Jingle Sessions)

XEP-0320 (Use of DTLS-SRTP in Jingle Sessions) has been Deferred because of inactivity. Abstract: This specification defines how to use DTLS-SRTP (RFC 5763) in the Jingle application type for the Real-time Transport Protocol (RTP) as a way to negotiate media path key agreement for secure RTP

[Standards] DEFERRED: XEP-0298 (Delivering Conference Information to Jingle Participants (Coin))

XEP-0298 (Delivering Conference Information to Jingle Participants (Coin)) has been Deferred because of inactivity. Abstract: This specification defines an XMPP extension for tightly coupled conference calls. It allows users who participate in multiparty Jingle calls via a focus

[Standards] DEFERRED: XEP-0292 (vCard4 Over XMPP)

XEP-0292 (vCard4 Over XMPP) has been Deferred because of inactivity. Abstract: This document specifies an XMPP extension for use of the vCard4 XML format in XMPP systems, with the intent of obsoleting the vcard-temp format. URL: http://xmpp.org/extensions/xep-0292.html If and when a new

[Standards] DEFERRED: XEP-0215 (External Service Discovery)

XEP-0215 (External Service Discovery) has been Deferred because of inactivity. Abstract: This document specifies an XMPP protocol extension for discovering services external to the XMPP network. URL: http://xmpp.org/extensions/xep-0215.html If and when a new revision of this XEP is published,

[Standards] DEFERRED: XEP-0318 (Best Practices for Client Initiated Presence Probes)

XEP-0318 (Best Practices for Client Initiated Presence Probes) has been Deferred because of inactivity. Abstract: This specification defines a way to determine the time when a XMPP entity has last changed its presence. Using client initiated presence probes the current presence of subscribed

[Standards] DEFERRED: XEP-0264 (Jingle Content Thumbnails)

XEP-0264 (Jingle Content Thumbnails) has been Deferred because of inactivity. Abstract: This specification defines a way for a client to supply a preview image for Jingle content. URL: http://xmpp.org/extensions/xep-0264.html If and when a new revision of this XEP is published, its status will

[Standards] DEFERRED: XEP-0286 (Mobile Considerations)

XEP-0286 (Mobile Considerations) has been Deferred because of inactivity. Abstract: This document provides background information for XMPP implementors concerned with mobile devices operating on an LTE cellular network. URL:

[Standards] DEFERRED: XEP-0233 (XMPP Server Registration for use with Kerberos V5)

XEP-0233 (XMPP Server Registration for use with Kerberos V5) has been Deferred because of inactivity. Abstract: This specification defines the Kerberos principal name of an XMPP server. It also details a method by which a connecting client can determine this Kerberos principal name when

Re: [Standards] Proposed XMPP Extension: Bind 2.0

Tue, 17 Jan 2017 23:09:52 +0100 Florian Schmaus wrote: > How do clients know which version of carbons got enabled? I guess the bind2 spec itself should define what versions of carbons/mam/etc it should support. For example, for urn:xmpp:bind2:0 - it's urn:xmpp:mam:3 and

Re: [Standards] Proposed XMPP Extension: Bind 2.0

On 17.01.2017 21:30, Michal Piotrowski wrote: >> Note: this gets rid of manual resource binding altogether. For > discussion on standards@ > > This maybe tricky. On one hand I think it'd be better if only the server > could assign resource, on the other hand I worked with some > installations

Re: [Standards] Proposed XMPP Extension: Bind 2.0

On 17.01.2017 16:23, XMPP Extensions Editor wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Bind 2.0 > > Abstract: This specification provides a single-request replacement for > several activities an XMPP client needs to do at startup. > > URL:

Re: [Standards] Proposed XMPP Extension: Bind 2.0

On Tue, Jan 17, 2017 at 2:30 PM, Michal Piotrowski wrote: > This maybe tricky. On one hand I think it'd be better if only the server > could assign resource, on the other hand I worked with some installations > (closed ones) where the resource where well

Re: [Standards] Proposed XMPP Extension: Bind 2.0

Hi, Thanks for the protoXEP, this is step in a good direction! The part which I find the most important is the information about unread messages. Here are my questions regarding this: 1. How messages should be marked as read? Is this subject of another XEP or maybe XEP-0333: Chat Markers could be

Re: [Standards] bind2

On 13 Jan 2017, at 12:22, Michal Piotrowski wrote: > I'm really interested in seeing the changes in bind2. Even if they are just > notes. And they’re out :) /K > > > Best regards > Michal Piotrowski > michal.piotrow...@erlang-solutions.com > > On 13

Re: [Standards] Easy XMPP

On 17 January 2017 at 15:31, Sam Whited wrote: > On Mon, Jan 16, 2017 at 10:05 PM, Peter Saint-Andre > wrote: >>> And if your business plan doesn't involve federation, why bother with >>> the additional overhead and complexity? > > I don't have a good

Re: [Standards] XEP-0300 and a future without reading tea leaves

> On 17 Jan 2017, at 15:33, Goffi wrote: > > Le mardi 17 janvier 2017, 14:08:54 CET Tobias Markmann a écrit : >> On Fri, Jan 13, 2017 at 11:59 AM, Kevin Smith wrote: >>> It sounds like a sensible enough approach to me, unless we think Gajim is >>> the

Re: [Standards] Easy XMPP

Tue, 17 Jan 2017 09:29:09 -0600 Sam Whited wrote: > Of note: security didn't really enter into it from her perspective Exactly. Regular users aren't concerned about security and encryption. They don't even know if Whatsapp has any sort of encryption. Yet, every third

Re: [Standards] XEP-0300 and a future without reading tea leaves

Le mardi 17 janvier 2017, 14:08:54 CET Tobias Markmann a écrit : > On Fri, Jan 13, 2017 at 11:59 AM, Kevin Smith wrote: > > It sounds like a sensible enough approach to me, unless we think Gajim is > > the only deployment using hex. > > To my current knowledge, after

Re: [Standards] Easy XMPP

On Mon, Jan 16, 2017 at 10:05 PM, Peter Saint-Andre wrote: >> And if your business plan doesn't involve federation, why bother with >> the additional overhead and complexity? I don't have a good answer for this, but it's worth asking why most email and phone / SMS providers

Re: [Standards] Easy XMPP

On Tue, Jan 17, 2017 at 6:29 AM, Holger Weiß wrote: > * Peter Saint-Andre [2017-01-16 09:28]: >> If someone like Sam's friend told me they wanted to find a secure messaging >> service, I'd tell them to just use Signal. > > I wouldn't, because Sam's

[Standards] Proposed XMPP Extension: Bind 2.0

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Bind 2.0 Abstract: This specification provides a single-request replacement for several activities an XMPP client needs to do at startup. URL: http://xmpp.org/extensions/inbox/bind2.0.html The council will decide in the

Re: [Standards] Easy XMPP

On 17 January 2017 at 14:34, Holger Weiß wrote: > * Vitaly Takmazov [2017-01-17 17:10]: >> 2017-01-17 15:11 GMT+03:00 Holger Weiß : >> > I don't want to install >> > I don't want to be >> > I want to >> >> XMPP will

Re: [Standards] Easy XMPP

* Vitaly Takmazov [2017-01-17 17:10]: > 2017-01-17 15:11 GMT+03:00 Holger Weiß : > > I don't want to install > > I don't want to be > > I want to > > XMPP will never have successful project until community members will > not think what *user* wants

Re: [Standards] XEP-0300 and a future without reading tea leaves

On 17 Jan 2017, at 13:08, Tobias Markmann wrote: > > > On Fri, Jan 13, 2017 at 11:59 AM, Kevin Smith wrote: > It sounds like a sensible enough approach to me, unless we think Gajim is the > only deployment using hex. > > To my current

Re: [Standards] XEP-0300 and a future without reading tea leaves

On Fri, Jan 13, 2017 at 11:59 AM, Kevin Smith wrote: > It sounds like a sensible enough approach to me, unless we think Gajim is > the only deployment using hex. > To my current knowledge, after checking back in the Gajim MUC the current situation is: * Conversations does

Re: [Standards] Easy XMPP

* Peter Saint-Andre [2017-01-16 09:28]: > If someone like Sam's friend told me they wanted to find a secure messaging > service, I'd tell them to just use Signal. I wouldn't, because Sam's friend would likely end up with an empty roster. Why? Because IM vendors don't

Re: [Standards] Easy XMPP

* Peter Saint-Andre [2017-01-16 21:05]: > Although I like federation, I'm no longer convinced that it is necessary for > most people. For example, in services like Slack and Hipchat everything is > room-based, and that fits well with MUC/MIX. Yes, Slack and HipChat probably

[Standards] Why XMPP (and XSF)

The "Easy XMPP" thread seems to have shifted topics and I wanted to share some thoughts. I am passionate about open standards. It seems to me that real time messaging and presence need an open standard.XMPP is the winner in my view. Federation is central to an open IM standard.Need to

Re: [Standards] Easy XMPP

On 17 January 2017 at 04:05, Peter Saint-Andre wrote: > The world I work in has mostly migrated away from on-premises software, to > cloud services that are public or semi-private. I recognize that some > organizations simply can't go there - they have regulatory reasons or >