Re: [Standards] OMEMO Key Agreement (v2)

On Wed, May 31, 2017 at 3:27 PM, Ignat Gavrilov wrote: > 1. Does this even work? I think the Signatures made using Ed25519 on your >"non-libsignal" side (which not necessarily includes all non-libsignal >implementations) will not be verifiable on the

Re: [Standards] OMEMO Key Agreement

On Wed, May 31, 2017 at 2:59 PM, Dave Cridland wrote: > But you did copy, amongst possibly other things, a constant-time > conditional-swap routine, along with the comments, from the > "additional" directory of a GPL library, so I can only assume that > copyright law works an

Re: [Standards] OMEMO Key Agreement

On Wed, May 31, 2017 at 2:35 PM, Dave Cridland wrote: > I call bullshit. > > He copy and pasted some code (and the comments!). > > The fact he did this then submitted it to another project without > attribution and flouting the licensing is actually besides the point - > I have

Re: [Standards] OMEMO Key Agreement

mple 3DH), but maybe that's a > price we're willing to pay? > > Remko > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > -- Sam

Re: [Standards] OMEMO and Olm

On Sun, May 28, 2017 at 10:40 AM, Remko Tronçon wrote: >> You'll notice that most (all?) of OWS's ed25519 code was >> copied from here, > > AFAICT, everything under additions/ is either new or modified ref10 code > (_modified.*), > hence only available under a GPL license. This

Re: [Standards] OMEMO and Olm

On Sun, May 28, 2017 at 9:53 AM, Sam Whited <s...@samwhited.com> wrote: > If you're curious, feel free to ping me out of band > (s...@samwhited.com, email or JID) and I can send you the code it > generates; there are definitely no jumps there, and it's actually > quite interesti

Re: [Standards] OMEMO and Olm

On Sun, May 28, 2017 at 1:15 AM, Remko Tronçon wrote: > Is this really true? You can do *a lot* of branches+memcpys for 3 loops over > all data as far as I know. I would have guessed this was a measure against > timing attacks. Where is this CMov coming from? In this case I

Re: [Standards] OMEMO and Olm

On Sun, May 28, 2017 at 9:37 AM, Sam Whited <s...@samwhited.com> wrote: > That's correct, it is almost identical, just as their version is > almost (exactly?) identical to the ed25519 reference implementation. Sorry, left off the link, the public domain reference implementation

Re: [Standards] OMEMO and Olm

On Sun, May 28, 2017 at 5:31 AM, Dave Cridland wrote: > The comments are identical, and the variable names and code structures > are identical. > > My conclusion would be that the Go version is a clear-cut derivation > of the libsignal code, and thus a derived work (in

Re: [Standards] OMEMO and Olm

On Sat, May 27, 2017 at 3:41 PM, Remko Tronçon wrote: > And you got all this just by looking at the XEdDSA spec? Maybe to you this > is trivial, but I don't understand how parts of the pseudocode in the spec map > to the code you wrote (e.g. the ScCMove bit is pure magic to me,

Re: [Standards] OMEMO and Olm

On Fri, May 26, 2017 at 7:27 PM, Remko Tronçon wrote: > - We change the XEP to use XEdDsa, and someone gets an implementation into > an (peer reviewed and preferably established) crypto library, *independent* > of libolm. In its most basic form XEdDSA just requires being able

Re: [Standards] OMEMO and Olm

On Fri, May 26, 2017 at 12:15 PM, Remko Tronçon wrote: >> crypto is subtle, and it can be very easy to make mistakes that have >> catastrophic consequences. >> >> ... >> I haven't finished or tested it yet > > > This doesn't really give me much more confidence to be honest.

Re: [Standards] OMEMO and Olm

> Yes, it's true that there's currently no such thing [a permissively licensed > implementation] for XEdDSA … > implementing this yourself really isn't > that complex. You can re-use existing EdDSA code, all you need to do is > write the key conversion code yourself, for which there is

Re: [Standards] [Council] 2017-05-17 Council Meeting Minutes

On Fri, May 26, 2017 at 9:43 AM, Kevin Smith wrote: > In the meantime, I’ve set up mail on the host and confirmed it can send to > XSF lists as edi...@xmpp.org. Thanks, that seems to be working; hardhats on for incoming mail flood please! —Sam

Re: [Standards] [Council] 2017-05-17 Council Meeting Minutes

On Fri, May 26, 2017 at 9:10 AM, Kevin Smith wrote: > I’ve now given the editors the ability to deploy a new docker image with the > aforementioned script. Thank you; one down. > email is an issue of Editor tooling, rather than iteam, and we can resolve > that there.

Re: [Standards] [Council] 2017-05-17 Council Meeting Minutes

>> Sam and Dave think it still involves manual steps. > > It does, as it has always done. Those manual steps have never involved being dependent on another team though, which is the actual problem. On Fri, May 26, 2017 at 3:31 AM, Kevin Smith wrote: > I did say that the

Re: [Standards] Council Minutes 2017-05-24

On Wed, May 24, 2017 at 11:54 AM, Dave Cridland wrote: > I see it as a requirement for the role in Council. Otherwise how can > one judge whether there are outstanding problems? I think it's not terribly difficult to keep an eye on the community and what's going on without

Re: [Standards] Council Minutes 2017-05-24

On Wed, May 24, 2017 at 11:36 AM, Daniel Gultsch wrote: > Side note: We also have *a lot* of XEPs which are inactive for way > more than 6 month where there is no activity whatsoever. No questions, > no discussions, no implementations. Are we just going to defer them? > Or is

Re: [Standards] Council Minutes 2017-05-24

On Wed, May 24, 2017 at 11:04 AM, Dave Cridland wrote: > Firstly, section 6 of XEP-0001 clearly states that the Author's job is > to gather and incorporate feedback from the community during the > lifetime of the XEP. It also clearly states that the XEP author should > be

Re: [Standards] Privacy Rules and MAM interaction

On Sat, May 20, 2017 at 10:45 AM, Evgeny Khramtsov wrote: > Which doesn't mean everyone should delete the corresponding code. I agree, which is why I said no such thing. >> I would avoid making more code dependent on it. > > I'm not sure what this means and how it's relevant

Re: [Standards] Privacy Rules and MAM interaction

On Sat, May 20, 2017 at 10:21 AM, Evgeny Khramtsov wrote: > I wonder what privacy list should be consulted before storing a message > in MAM archive: default or active? I think this should be the default > list, but I'd like to clarify. Privacy lists have been deprecated by

Re: [Standards] Proto-XEP: Pre-Authenticated Roster Subscription

On Thu, May 11, 2017 at 2:34 AM, Georg Lukas wrote: > Sam, could you imagine elaborating a bit more of your potential business > use case and how you see it conflict with HMAC-tokens? I'm not sure that there's much more to say; I don't have a specific use case in mind other than

Re: [Standards] Proto-XEP: Pre-Authenticated Roster Subscription

On Wed, May 10, 2017 at 3:08 PM, Sam Whited <s...@samwhited.com> wrote: > can be flexible but not introduce unnecessary complexity, which I > think this does, it seems like a good idea to me. which I DON'T think this does, that is. D'oh. To be clear, I think the server approach is

Re: [Standards] Proto-XEP: Pre-Authenticated Roster Subscription

On Wed, May 10, 2017 at 2:29 PM, Daniel Gultsch wrote: > IMHO the hypothetical service operators who maintain their own service which > are self-branded are very welcome to step forward now and try to get their > use case covered but keeping them in mind without knowing who

Re: [Standards] Proto-XEP: Pre-Authenticated Roster Subscription

On Wed, May 10, 2017 at 1:41 PM, Daniel Gultsch wrote: > The business logic consists of a definition on how to convert a timestamp > into a sequence of bytes and hmacing that with a secret key from a PEP node. > That's it. (And converting that to base64.) Different people might

Re: [Standards] Proto-XEP: Pre-Authenticated Roster Subscription

On Wed, May 10, 2017 at 12:41 PM, Jonas Wielicki wrote: > Secondly, since Client 2 needs to know of the protocol in any case, can we > maybe elide the server of Client 2 from the equation? Then the usability of > tokens doesn’t depend on the server of Client 2 but only on the

[Standards] 2017-05-10 Council Meeting Minutes

# 2017-05-10 Council Meeting Logs: logs are down ## Roll call - Daniel (chairing) - SamWhited - Link Mauve - Dave Cridland - Tobias (absent) ## SHA-1 Migration Plan No progress to report. ## Date of next 2017-05-17T15:00Z ## AOB - Peter Waher has asked for the IP he assigned to the

Re: [Standards] Proto-XEP: Pre-Authenticated Roster Subscription

Fair warning, I'm not fully up to date on this discussion, but I was asked to drop some notes from the room earlier into the thread so here I am, this message from Daniel appears to be a good place to start. On Thu, Apr 27, 2017 at 10:56 AM, Daniel Gultsch wrote: > as

[Standards] Council Minutes 2017-04-26

# 2017-04-26 Council Meeting Logs: Logs currently offline ## Roll call - Tobias (chairing) - SamWhited - inputmice (aka "Different account daniel") - Link Mauve - Dave Cridland ## SHA-1 Migration Plan Tobias and Link Mauve to sync after the meeting to determine what needs to be done. No

Re: [Standards] [Council] Council Meeting Minutes April 5th 2017

On Thu, Apr 20, 2017 at 3:47 AM, Dave Cridland wrote: > What about MUC web logs? Presumably if they're not using some custom API they have to support parsing MUC messages with a separately namespaced child anyways, so they can parse the hint regardless of what the namespace

Re: [Standards] [Council] Council Meeting Minutes April 5th 2017

On Wed, Apr 12, 2017 at 10:14 AM, Dave Cridland wrote: > I'd be interested in Sam's counter-arguments, mind. - Discoverability: if or or whatever is only used from carbons, why do I have to click through to a different long XEP to find the one hint that I care about while

Re: [Standards] [Council] Council Meeting Minutes April 5th 2017

On Wed, Apr 19, 2017 at 9:29 AM, Tobias M wrote: > Having an own XEP for each hint feels a bit over the top. I agree, let's not do this. > Moving each hint to the XEP that uses it would lead to duplication of hints > or one XEP using > a hint defined in an otherwise

Re: [Standards] [Council] Council Meeting Minutes April 5th 2017

On Wed, Apr 12, 2017 at 9:20 AM, Tobias M wrote: > Which XEPs need changes in response to this? Do the hints get under a > different namespace? Just MAM and Carbons, I think. Yes, in my opinion these sorts of thihngs should be namespaced with the spec that uses them.

Re: [Standards] Council Meeting Minutes April 5th 2017

On Wed, Apr 12, 2017 at 6:43 AM, Daniel Gultsch wrote: > 4) Vote on advancing XEP-0334: Message Processing Hints > Everyone to vote on list. -1 I've thought about this some more, and I still don't think it makes sense to have a "hints" XEP. In my opinion we should move

Re: [Standards] Deprecating Privacy Lists (again)

On Thu, Mar 23, 2017 at 8:09 AM, Dave Cridland wrote: > I'm in favour of deprecation (but not elimination). I forgot there was a difference, but I used the word I meant purely by accident. To make sure it's absolutely clear: I am advocating that we move XEP-0016 to the

Re: [Standards] Deprecating Privacy Lists (again)

On Wed, Mar 22, 2017 at 2:28 PM, Yann Leboulanger wrote: > One nice feature we also don't have with blocking command is blocking a > while group. Ah yes! I knew there was something else that I was forgetting to address from last time. I also think this is not a good thing;

Re: [Standards] UPDATED: XEP-0369 (Mediated Information eXchange (MIX))

On Wed, Mar 22, 2017 at 12:48 PM, wrote: > Last Updated: 2017-03-27, looks like someone in the XSF got a DeLorean Sorry, I didn't notice this until after I'd already published. Will try to be better about verifying this sort of thing in the future. —Sam

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

On Mon, Mar 20, 2017 at 12:50 PM, XMPP Extensions Editor wrote: > URL: https://xmpp.org/extensions/inbox/isr-sasl2.html > Example 2. An xmlns:isr='urn:xmpp:isr:0' \ isr:mechanism='X-HT-SHA-256-ENDP'/> I don't think that namespaced attributes are necessary; they add

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

On Mon, Mar 20, 2017 at 3:02 AM, Marvin Gülker wrote: > I looked into this problem a little more, and it appears that the > Makefile only runs xelatex once. Sorry about that; this was an oversight on my part. I've fixed it and will merge the changes when CI passes

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

On Wed, Feb 8, 2017 at 5:07 PM, XMPP Extensions Editor wrote: > This message constitutes notice of a Last Call for comments on XEP-0280 > (Message Carbons). Since there is still open discussion and pending changes to this XEP, I have extended the LC until 2017-03-28. —Sam

Re: [Standards] LAST CALL: XEP-0352 (Client State Indication)

On Wed, Feb 8, 2017 at 5:07 PM, XMPP Extensions Editor wrote: > This message constitutes notice of a Last Call for comments on XEP-0352 > (Client State Indication). Since there is still open feedback and open changes on this XEP, I have extended the Last Call again. The LC

Re: [Standards] [Council] Council Meeting Minutes for 2017-03-08

On Wed, Mar 8, 2017 at 11:50 AM, Daniel Gultsch wrote: > 2. Entity Caps 2 > > Vote on accepting Entity Caps 2 > (https://xmpp.org/extensions/inbox/ecaps2.html) as experimental. +1 ___ Standards mailing list Info:

Re: [Standards] urn:xmpp:hashes:2

On Wed, Mar 15, 2017 at 11:34 AM, Christian Schudt wrote: > The only difference I see is, that the document now explicitly mentions the > base64 encoding, but I think it was clear enough before (due to samples). > Is that worth a namespace bump? Are there any

Re: [Standards] LAST CALL: XEP-0333 (Chat Markers)

On Sat, Jan 28, 2017 at 11:25 AM, XMPP Extensions Editor wrote: > This message constitutes notice of a Last Call for comments on XEP-0333 (Chat > Markers). Daniel has taken over maintaining the XEP and the last call has expired without a vote. At his request I've moved it back

Re: [Standards] LAST CALL: XEP-0333 (Chat Markers)

On Wed, Feb 15, 2017 at 6:45 PM, Sam Whited <s...@samwhited.com> wrote: > I have reached out to the author to give them a chance to address > feedback, and to find out if they are still interested in maintaining > this XEP. > To give them time to respond, the LC has been extende

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

On Wed, Feb 8, 2017 at 4:50 PM, XMPP Extensions Editor wrote: > This message constitutes notice of a Last Call for comments on XEP-0233 (XMPP > Server Registration for use with Kerberos V5). > … > This Last Call begins today and shall end at the close of business on >

Re: [Standards] LAST CALL: XEP-0334 (Message Processing Hints)

On Wed, Feb 8, 2017 at 5:07 PM, XMPP Extensions Editor wrote: > This message constitutes notice of a Last Call for comments on XEP-0334 > (Message Processing Hints). > … > This Last Call begins today and shall end at the close of business on > 2017-02-22. I have extended the

Re: [Standards] LAST CALL: XEP-0333 (Chat Markers)

On Sat, Jan 28, 2017 at 11:25 AM, XMPP Extensions Editor wrote: > This Last Call begins today and shall end at the close of business on > 2017-02-11. I have reached out to the author to give them a chance to address feedback, and to find out if they are still interested in

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

On Sat, Jan 28, 2017 at 11:26 AM, XMPP Extensions Editor wrote: > This Last Call begins today and shall end at the close of business on > 2017-02-11. To give the author time to address feedback, the LC has been extended until 2017-02-22. —The Editor

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

On Wed, Feb 15, 2017 at 8:32 AM, Travis Burtrum wrote: > "All security setup and certificate validation code SHOULD be shared > between the STARTTLS and direct TLS logic as well." These aren't the issues you're likely to hit though; I can't imagine anyone actually using

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

On Mon, Feb 13, 2017 at 3:39 PM, Evgeny Khramtsov wrote: > I don't understand why we need to redefine how stream features work. My > element with a list inside is the same as > element with a list of SASL methods inside. What's the difference? Maybe you're right, I was

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

On Mon, Feb 13, 2017 at 3:20 PM, Evgeny Khramtsov wrote: > > > http://jabber.org/protocol/commands'> > register > recover > unregister > change-email > > I don't see all those things fitting into this XEP, so we go back to my original position:

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

On Mon, Feb 13, 2017 at 12:58 PM, Travis Burtrum wrote: > It's worded in a passive way because it depends on the choices you make > with regard to the spec. Which is why we probably shouldn't include a possibly-not-true security disclaimer like this at all. —sam

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

On Mon, Feb 13, 2017 at 2:57 PM, Evgeny Khramtsov wrote: > As I have already said, only register and recover requires user > interaction, but not sasl or bind, because the latter are supposed for > software interaction. So you're suggesting we have a "register or recover"

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

On Mon, Feb 13, 2017 at 2:13 PM, Evgeny Khramtsov wrote: > 1) A client executes a command > 2) A server sends a form to fill in (username and password). > … Right, this is what I thought you meant at first; in this case the command would be something like "register" or

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

On Mon, Feb 13, 2017 at 1:53 PM, Evgeny Khramtsov wrote: > Well, I just looked into REQUIREMENTS section, all of them can be > implemented using XEP-0050. > We can just extend XEP-0050 to allow including available command nodes > into and can easily send elements without any

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

On Mon, Feb 13, 2017 at 11:06 AM, Evgeny Khramtsov wrote: > I think bind2 and sasl2 are different, because they're supposed to be > processed by automated software without user interaction. IBR, in > contrast, requires user interaction and data fields don't need to be >

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

On Mon, Feb 13, 2017 at 10:14 AM, Goffi wrote: > I was thinking about a human challenge (question specific to user), which need > manual intervention, while proof of work can be fully automated (but expensive > for spammers). Ah, I see; yes, one of the benefits of this system

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

On Mon, Feb 13, 2017 at 7:28 AM, Goffi wrote: > - proof of work would be really nice, with a fallback mechanism. If by a "fallback mechanism" my understanding is correct and you mean "something to fall back too if the client does not support the particular proof-of-work function

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

On Mon, Feb 13, 2017 at 2:48 AM, Evgeny Khramtsov wrote: > Why can't we use ad hoc commands (XEP-0050) for this? ad hoc commands are defined in terms of IQs; this all happens before a resource is bound and before the stream has started. —Sam

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

On Sat, Jan 28, 2017 at 11:26 AM, XMPP Extensions Editor wrote: > 1. Is this specification needed to fill gaps in the XMPP protocol stack or to > clarify an existing protocol? Yes > 2. Does the specification solve the problem stated in the introduction and > requirements?

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

On Sun, Feb 12, 2017 at 8:23 AM, XMPP Extensions Editor wrote: > Title: Extensible In-Band Registration I wanted to go ahead and start getting community feedback on this approach, and on the following items. Still todo (possibly?): * Consider adding account deletion?

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

On Fri, Feb 10, 2017 at 5:58 AM, Georg Lukas wrote: > | - Removal of 'User Avatars' from IM-Core, making it IM-Advanced only. > … > | - avatars require a graphical display to make sense (this is slightly > | mitigated by footnote 20) So don't implement them in your TUI client.

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

On Thu, Feb 9, 2017 at 7:28 AM, Guus der Kinderen wrote: > Is footnote 10 "Support can be enabled via an external component or an > internal server module/plugin." relevant? I think the idea was to say "even if a server isn't compliant because it doesn't support

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

On Wed, Feb 8, 2017 at 8:05 PM, XMPP Extensions Editor wrote: > Title: Extensible SASL Profile > > Abstract: This document describes a replacement for the SASL profile > documented in RFC 6120 which allows for greater extensibility. Some early feedback about the new SASL

Re: [Standards] LAST CALL: XEP-0334 (Message Processing Hints)

On Wed, Feb 8, 2017 at 5:47 PM, Christian Schudt wrote: > Aren’t namespaces with a version? I.e. urn:xmpp:hints:0 instead of > urn:xmpp:hints? Just by convention (but I agree, it might be nice to have one just in case a hint ever has to change; although I also think

Re: [Standards] Summit MIX Decsions

On Wed, Feb 8, 2017 at 9:47 AM, Kevin Smith wrote: > Different use case, I’m afraid. Remote rosters don’t get to do broadcast > presence. Ah, yes, that's what we were missing. Makes sense; thanks all. —Sam ___ Standards mailing

Re: [Standards] Summit MIX Decsions

On Wed, Feb 8, 2017 at 3:32 AM, Steve Kille wrote: > 9. It is agreed that MIX Channels will be represented in the roster. > > > 10. It is intended to mark MIX clients in the roster with a server > generated annotation, so that MIX clients can clearly show MIX channels >

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

Nit pick: The language in the glossary entry feels a bit informal, but I don't have a better suggestion off the top of my head. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe:

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

On Tue, Feb 7, 2017 at 7:20 AM, Matthew Wild wrote: > Stream state pertains to a single stream/connection: > > - encrypted > - authenticated > - compressed > - bound > - active/inactive Yes, you're right of course, CSI is more "stream state", my mistake. Thanks! >

Re: [Standards] RFC 6120 vs. XEP

On Tue, Feb 7, 2017 at 9:15 AM, Evgeny Khramtsov wrote: > The problem is, formally speaking, it cannot ignore RFC's binding, > because there are MUSTs in the document (Marvin already listed them). Not at all; from 6120: > Support for resource binding is REQUIRED in XMPP

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

On Mon, Feb 6, 2017 at 3:53 AM, Evgeny Khramtsov wrote: > And do I have privacy list with another entity? Private XML storage? In > more general, why couldn't an external component maintain my CSI state > via XEP-0356? I think the difference is that CSI is a part of the

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

On Mon, Feb 6, 2017 at 3:16 AM, Evgeny Khramtsov wrote: > What does that "routable" mean? Are roster queries "routable"? Able to be forwarded by the server to another entity on the network on behalf of the sender. Only stanza's (message/presence/iq) with a "to" attribute are

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

On Sun, Feb 5, 2017 at 2:07 PM, Georg Lukas wrote: > * Florian Schmaus [2017-02-05 20:54]: >> CSI uses Nonzas, which are not covered by Stream Management, so you >> can't restore the CSI state after resumption. > > Ah right, another unfortunate design decision.

Re: [Standards] 2017 Compliance Suites

On Sun, Jan 29, 2017 at 7:14 AM, Georg Lukas wrote: > Seriously though, avatars require a graphical display and additional > bandwidth, so they can't be implemented in certain situations (think > console clients, or the military 9k6 links mentioned here from time to > time). We

Re: [Standards] 2017 Compliance Suites

On Thu, Jan 26, 2017 at 5:23 AM, Georg Lukas wrote: > I'm curious why we don't just rename XEP-0375 from 2016 to 2017? That > would reduce the number of deprecated XEPs and implementer confusion. I'm not sure; I originally submitted an update changing all the dates to 2017, but

Re: [Standards] DEFERRED: XEP-0352 (Client State Indication)

On Sat, Jan 28, 2017 at 10:56 AM, XMPP Extensions Editor wrote: > XEP-0352 (Client State Indication) has been Deferred because of inactivity. This has been stuck in a perpetual (expired) LC for over a year. I have deferred, but it also seems like another widely used XEP that

Re: [Standards] Syntax Highlighting in XEPs

On Sat, Jan 28, 2017 at 10:00 AM, Tobias M wrote: > You could have: > > type='set' id='74s'> > … > ]]> > > I hadn't considered making that part of the format; I'll play around with that, thanks. Personally though, I'm not a big fan of our XEP

[Standards] Syntax Highlighting in XEPs

Hi all, Currently there are several XEPs that contain examples of a round trip between the client and the server that delineate client sent packets and server sent packets with some text similar to this: ``` Client: Server: ``` This leads to strange results in the syntax highlighting of the

Re: [Standards] DEFERRED: XEP-0186 (Invisible Command)

On Fri, Jan 27, 2017 at 9:06 AM, Peter Saint-Andre wrote: > I volunteered to get this finished, but haven't made the time to do that > quite yet. Thanks Peter! I'm printing a copy of this to do a review now too, I'd be happy to help if you have any changes that need making

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

On Thu, Jan 26, 2017 at 5:54 AM, Georg Lukas wrote: > Can we get this advanced, please? It is used by 0313, 0364, 0384 and > 0384. Added to the council's agenda: https://trello.com/c/FEf0BApY ___ Standards mailing list Info:

Re: [Standards] Advance XEP-0368 to Proposed

On Tue, Jan 24, 2017 at 2:13 PM, Travis Burtrum wrote: > I still disagree, I know in the wild you will find poorly written > clients and servers that fall back to plain text when confronted with > STARTTLS stripping, but you will NEVER find software that falls back to >

Re: [Standards] Advance XEP-0368 to Proposed

On Tue, Jan 24, 2017 at 7:38 AM, Travis Burtrum wrote: > But you basically said it yourself, "Direct" TLS and STARTTLS are > equivalent security-wise ONLY IF you attempt STARTTLS regardless of > offer and give up with a security exception otherwise. That behavior is >

Re: [Standards] Advance XEP-0368 to Proposed

On Thu, Jan 19, 2017 at 2:19 PM, Travis Burtrum wrote: > What's the next step? Any thoughts? Added to the council agenda: https://trello.com/c/xrVh1W7C Please continue discussion here. —Sam ___ Standards mailing list Info:

Re: [Standards] 2017 Compliance Suites

On Wed, Jan 18, 2017 at 1:07 PM, Guus der Kinderen wrote: > Sam, you recently sparked a discussion on competing XEPs - obsoleting one of > those is currently under vote at the council, if I skimmed over my emails > correctly. Perhaps that's something that could be

Re: [Standards] 2017 Compliance Suites

On Wed, Jan 18, 2017 at 12:15 PM, Goffi wrote: > the idea is not new, but it would be very nice to have "profiles" for > compliance suites. Hi Goffi, The current compliance suites actually do this for Core, Web, IM, and Mobile: https://xmpp.org/extensions/xep-0375.html > Today

[Standards] 2017 Compliance Suites

Hi all, We discussed moving forward the 2016 compliance suites today in the council meeting, and it was decided to start a mailing list discussion about what worked, what didn't, and what should be different for the 2017 ones (which will hopefully advance quicker). We've had a few of these that

[Standards] 2017-01-18 Council Meeting

# 2017-01-18 Council Meeting Logs: http://logs.xmpp.org/council/2017-01-18#16:01:18 ## Roll call - Tobias (chairing) - Sam Whited - Dave Cridland Daniel and Link Mauve sent their apologies. ## Move XEP-0153: vCard-Based Avatars to "Obsolete" https://github.com/xsf/xeps/pull/357

Re: [Standards] Easy XMPP

On Wed, Jan 18, 2017 at 7:53 AM, Brian Cully wrote: > Whether they know about it or not, people do need to have encryption. > It’s a complicated, esoteric thing that they shouldn’t have to know about but > do silently benefit from. In the dreaded car analogy: how many

Re: [Standards] [xsf/xeps] Defers many old XEPs (#372)

On Wed, Jan 18, 2017 at 4:43 AM, Peter Waher wrote: > As you know, some of these have actually been touched on more recently, but > the editorial team chose not to accept the edits, after waiting several > months. You yourself chose not to accept the edits, because you

[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

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] 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

Re: [Standards] Easy XMPP

On Mon, Jan 16, 2017 at 10:28 AM, Peter Saint-Andre wrote: > Thus I repeat the question: what are we doing here? I agree with most everything Peter said, that being said, I also agree with most of Dave's response (although I don't personally have any problem with OWS, and use

Re: [Standards] Easy XMPP

On Tue, Jun 7, 2016 at 10:04 AM, Georg Lukas wrote: > in the last weeks we've seen that XMPP is too hard for the WhatsApp > generation. Instead of blaming them for not understanding federation, we > should make it as easy as possible to use XMPP (IM) in a secure fashion. I

Re: [Standards] Expected behavior when blocking all unknown JIDs

d me that it's not worth implementing; I'll pose a new argument for why we should deprecate privacy lists (but not implement this in blocking command before hand) next week. —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 ___ Standards mailing list Info:

[Standards] Expected behavior when blocking all unknown JIDs

Hi all, There was brief discussion earlier about adding the ability to "block everyone that I don't have in my roster" to XEP-0191: Blocking Command [1]. I was thinking about how this could be done, and it occured to me that it may break the UX a bit. Currently the blocking command blocks

Re: [Standards] Obsoleting vCard-Based Avatars

dation we may also encourage contributions to fix those outstanding issues. —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] UPDATED: XEP-0369 (Mediated Information eXchange (MIX))

n the server is correct. —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

<    1   2   3   4   5   6   7   >