Re: [Standards] Status of XEP-0364

Hi, Am 26. April 2019 um 19:29 Uhr + schrieb Daniel Gultsch: > the XEP describes a comparatively sane approach for implementing OTR > over XMPP (including message hints, tearing the session down on > reconnect) To my knowledge the few clients that implemented those > 'best practices' have

[Standards] Status of XEP-0364

Hi, XEP-0364 describes the current use of OTR encryption. It has been deferred after inactivity. As it is an informational XEP that (to my knowledge) correctly describes how OTR is currently used, can it be moved by Council to Active? Marvin -- Blog: https://mg.guelker.eu

Re: [Standards] XEP-0283 Moved - Security and Usability

Am 09. März 2018 um 11:16 Uhr -0600 schrieb Sam Whited: > On Fri, Mar 9, 2018, at 10:53, Georg Lukas wrote: > > as part of Easy XMPP I wanted to have a way to completely migrate from > > one account to another, or to be able to move a subset of your contacts > > to another (local) JID. > > What

[Standards] Feedback (was: Proposal: Server selection for user-registration)

Am 09. Januar 2018 um 07:39 Uhr +0100 schrieb Daniel Gultsch: > It's more important to > have the tools than to bikeshed about how to use them. Thanks. First hammer the nail in, and then think where it should have gone. Nice idea. To return from personal argumenting to more useful one, the

Re: [Standards] Proposed XMPP Extension: Message Markup

This is an interesting approach. Specifying the markup completely externally would not have occured to me, but is a really cool idea. Some notes: §4.1 has: > The start and end attributes define the range at which the span is > applied. They are in units of unicode code points in the character >

Re: [Standards] Proposed XMPP Extension: Styling

Am 06. November 2017 um 21:19 Uhr +0100 schrieb Daniel Gultsch : > It's probably more helpful if people comment on the actual XEP in > regards to specific rules or wording in the XEP. Read my message again. I have done that (commenting on wording with regard to terminal

Re: [Standards] Proposed XMPP Extension: Styling

Am 06. November 2017 um 15:29 Uhr -0600 schrieb Sam Whited : > > Not using something XML-based in a XEP's format > > also creates a precedence case from which we don't know where else it > > will come back at us when other XEPs are made. > > I didn't understand this, sorry,

Re: [Standards] Proposed XMPP Extension: Styling

The XEP defines requirements like "MUST be displayed in italics" (§6.5) or "MUST be displayed with a horizontal line through the middle (strike through)" (§6.6) that immediately map to the user interface and are not possible to implement in a terminal client on most terminal emulators. I don't see

Re: [Standards] Formatting Use Cases

Am 29. October 2017 um 12:59 Uhr + schrieb Sam Whited : > In retrospect my example was poor. I need to know *why* this is helpful. What > do you do with the formatting? How is it helpful? Now, that depends on what is actually explained. If for example there's some kind of

Re: [Standards] Formatting Use Cases

Am 28. October 2017 um 13:25 Uhr -0500 schrieb Sam Whited : > To carry forward the formatting discussion, I'd like to collect some use > cases from the community. When I explain complex things to people, it's occasionally helpful to colourise parts of the message differently;

Re: [Standards] Broken XEP PDFs on xmpp.org/extensions (no ToC)

On Sat, Feb 25, 2017 at 09:42:10AM +0100, Marvin Gülker wrote: > However, it appears there's a number of XEPs on xmpp.org/extensions > whose PDF files have no Table of Contents, albeit the HTML versions > have. I looked into this problem a little more, and it appears that the Makefile

[Standards] Broken XEP PDFs on xmpp.org/extensions (no ToC)

Hi, I am sort of a paper person and thus usually prefer the PDF variant of the XEPs over the HTML one. However, it appears there's a number of XEPs on xmpp.org/extensions whose PDF files have no Table of Contents, albeit the HTML versions have. Examples are: * XEP-0124 * XEP-0131 * XEP-0136 *

[Standards] XEP-0115 (caps): Validation string processing incomplete?

Hi, XEP-0115 (Entity Capabilities), §5.4 says this: > When an entity receives a value of the 'ver' attribute that appears to > be a verification string generated in accordance with the generation > method defined in this specification, it MUST process the 'ver' > according to the following

Re: [Standards] RFC 6120 vs. XEP

Hi, On Mon, Feb 06, 2017 at 04:46:58PM -0700, Peter Saint-Andre wrote: > RFC 6120 author here. :-) Great! :-) > Note that the order of features matters. In the Bind2 proposal, the order is > this: I have to disagree. RFC 6120, section 4.3.2 says this, though it is marked as an Implementation

Re: [Standards] RFC 6120 vs. XEP (was: CSI and Carbons state after SM resumption)

On Mon, Feb 06, 2017 at 06:09:50PM +0300, Evgeny Khramtsov wrote: > 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

Re: [Standards] RFC 6120 vs. Bind2 XEP (was: CSI and Carbons state after SM resumption)

On Mon, Feb 06, 2017 at 03:25:15PM +0300, Evgeny Khramtsov wrote: > I guess that's your opinion? Or where is it stated in the RFC? xmlns='urn:ietf:params:xml:ns:xmpp-bind'/> is a mandatory-to-negotiate > feature (at least if included), thus, clients MUST NOT ignore it. I tend to agree with this.

Re: [Standards] [Members] 33C3 talk on Signal and current XMPP issue in providing a similar UX

On Fri, Dec 30, 2016 at 02:22:11PM +0100, Tobias Markmann wrote: > > We need to aggressively address the spam problem. > > Indeed. Proposed solutions I've heard about so far are mostly requiring > captcha on first contact or reputation systems. I think end-to-end captchas > could result in a very