Re: [Standards] SHA-1

2017-02-23 Thread Dave Cridland
On 23 February 2017 at 20:57, Florian Schmaus wrote: > On 23.02.2017 18:19, Dave Cridland wrote: >> On 23 February 2017 at 16:53, Florian Schmaus wrote: >>> On 23.02.2017 15:36, Florian Schmaus wrote: On 23.02.2017 15:19, Peter Waher wrote: > Hello all. > > > SHA-1 is used in

Re: [Standards] SHA-1

2017-02-23 Thread Florian Schmaus
On 23.02.2017 20:45, Jonas Wielicki wrote: > On Donnerstag, 23. Februar 2017 17:19:13 CET Dave Cridland wrote: >> On 23 February 2017 at 16:53, Florian Schmaus wrote: >>> On 23.02.2017 15:36, Florian Schmaus wrote: On 23.02.2017 15:19, Peter Waher wrote: > Hello all. > > > SHA

Re: [Standards] SHA-1

2017-02-23 Thread Florian Schmaus
On 23.02.2017 18:19, Dave Cridland wrote: > On 23 February 2017 at 16:53, Florian Schmaus wrote: >> On 23.02.2017 15:36, Florian Schmaus wrote: >>> On 23.02.2017 15:19, Peter Waher wrote: Hello all. SHA-1 is used in many places throughout XMPP. Examples include authenticat

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

2017-02-23 Thread Ruslan N. Marchenko
On 23.02.2017 08:36, Sam Whited wrote: I *think* I'm against continuing to reference 0334 here. While this hint is theoretically useful for other specs (eg. if there were some kind of pubsub-MAM-sync in the future that replaced carbons), I'm not sure we need to try and make it that reusable, and

Re: [Standards] SHA-1

2017-02-23 Thread Jonas Wielicki
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Donnerstag, 23. Februar 2017 17:19:13 CET Dave Cridland wrote: > On 23 February 2017 at 16:53, Florian Schmaus wrote: > > On 23.02.2017 15:36, Florian Schmaus wrote: > >> On 23.02.2017 15:19, Peter Waher wrote: > >>> Hello all. > >>> > >>> > >>

Re: [Standards] SHA-1

2017-02-23 Thread Dave Cridland
On 23 February 2017 at 16:53, Florian Schmaus wrote: > On 23.02.2017 15:36, Florian Schmaus wrote: >> On 23.02.2017 15:19, Peter Waher wrote: >>> Hello all. >>> >>> >>> SHA-1 is used in many places throughout XMPP. Examples include >>> authentication mechanisms (SCRAM-SHA-1) and entity capabilitie

Re: [Standards] SHA-1

2017-02-23 Thread Florian Schmaus
On 23.02.2017 15:36, Florian Schmaus wrote: > On 23.02.2017 15:19, Peter Waher wrote: >> Hello all. >> >> >> SHA-1 is used in many places throughout XMPP. Examples include >> authentication mechanisms (SCRAM-SHA-1) and entity capabilities >> (XEP-0115), for instance. Concerning the recent report ab

Re: [Standards] SHA-1

2017-02-23 Thread Dave Cridland
On 23 February 2017 at 14:19, Peter Waher wrote: > SHA-1 is used in many places throughout XMPP. Examples include > authentication mechanisms (SCRAM-SHA-1) and entity capabilities (XEP-0115), > for instance. Concerning the recent report about vulnerabilities found in > SHA-1, should there be an e

Re: [Standards] SHA-1

2017-02-23 Thread Florian Schmaus
On 23.02.2017 15:19, Peter Waher wrote: > Hello all. > > > SHA-1 is used in many places throughout XMPP. Examples include > authentication mechanisms (SCRAM-SHA-1) and entity capabilities > (XEP-0115), for instance. Concerning the recent report about > vulnerabilities found in SHA-1, should there

[Standards] SHA-1

2017-02-23 Thread Peter Waher
Hello all. SHA-1 is used in many places throughout XMPP. Examples include authentication mechanisms (SCRAM-SHA-1) and entity capabilities (XEP-0115), for instance. Concerning the recent report about vulnerabilities found in SHA-1, should there be an effort to upgrade all these to SHA-256 or la

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

2017-02-23 Thread Dave Cridland
On 8 February 2017 at 23:07, XMPP Extensions Editor wrote: > 1. Is this specification needed to fill gaps in the XMPP protocol stack or to > clarify an existing protocol? Yes. A number of private extensions have been filling this gap. > 2. Does the specification solve the problem stated in the

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

2017-02-23 Thread Dave Cridland
On 8 February 2017 at 23:07, XMPP Extensions Editor wrote: > 1. Is this specification needed to fill gaps in the XMPP protocol stack or to > clarify an existing protocol? Seems useful. > 2. Does the specification solve the problem stated in the introduction and > requirements? Mostly. > 3. D

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

2017-02-23 Thread Matthew Wild
On 23 February 2017 at 12:52, Matthew Wild wrote: > On 8 February 2017 at 23:47, Christian Schudt wrote: >> Do servers really have a distinction between a permanent and a temporar >> store? Aren’t offline messages usually stored permanently, too? >> If I’d develop a server message store/archive,

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

2017-02-23 Thread Matthew Wild
On 8 February 2017 at 23:47, Christian Schudt wrote: > >> 1. Is this specification needed to fill gaps in the XMPP protocol stack or >> to clarify an existing protocol? > > Partly. > XEP-0079: Advanced Message Processing already solves the same problem. > > dropforward => no-copy > dropst

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

2017-02-23 Thread Jakob Schröter
On Wed, Feb 8, 2017 at 5:07 PM, 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? Yes. 3. Do you plan

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

2017-02-23 Thread Kim Alvefur
On Wed, Feb 08, 2017 at 11:07:13PM +, XMPP Extensions Editor wrote: > This message constitutes notice of a Last Call for comments on > XEP-0334 (Message Processing Hints). > > Abstract: This document defines a way to include hints to entities > routing or receiving a message. > > URL: http://x

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

2017-02-23 Thread Michal Piotrowski
On 9 February 2017 at 00:07, XMPP Extensions Editor wrote: > This message constitutes notice of a Last Call for comments on XEP-0352 > (Client State Indication). > > Abstract: This document defines a way for the client to indicate its > active/inactive state. > > URL: http://xmpp.org/extensions/x

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

2017-02-23 Thread Daniel Gultsch
2017-02-09 0:07 GMT+01:00 XMPP Extensions Editor : > 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? Yes > 3. Do you plan to implement thi

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

2017-02-23 Thread XMPP Extensions Editor
Version 0.8.1 of XEP-0369 (Mediated Information eXchange (MIX)) has been released. Abstract: This document defines Mediated Information eXchange (MIX), an XMPP protocol extension for the exchange of information among multiple users through a mediating service. The protocol can be used to provid