[Standards] Re: NEW: XEP-0474 (SASL SCRAM Downgrade Protection)

Am Samstag, dem 28.10.2023 um 14:40 +0100 schrieb Matthew Wild: > > So, SSDP "only" allows the client to detect the difference between > two cases: > > 1) The real server advertises new channel binding methods the client > does not understand > 2) An MITM is trying to trick the client into

Re: [Standards] Fwd: [Uta] STARTTLS vulnerabilities

Am Mittwoch, dem 11.08.2021 um 14:25 -0600 schrieb Peter Saint-Andre: > Too bad we didn't stick to our guns in 2003 and insist on two ports > instead of one, but STARTTLS was the recommended approach back > then... > I am still not convinced the STARTTLS is ultimate evil. SMTP had way too many

Re: [Standards] Council Minutes 2021-02-03

Am Mittwoch, dem 10.02.2021 um 19:37 +0100 schrieb Thilo Molitor: > > I cannot recall now where exactly it was but there was definitelly > > something about the order of the fields somewhere, because I > > remember > > adding a separate list with original key order to be able to use > > hashmap

Re: [Standards] Council Minutes 2021-02-03

Am Mittwoch, dem 10.02.2021 um 17:28 +0100 schrieb Jonas Schäfer: > Thanks for the minutes! > > > As of now, I’m still -1. > > I want to elaborate the reason a little. Note that my -1 is solely > based on > the ordering requirement for , not the other commit in > that PR. > > I am not aware

Re: [Standards] Proposed XMPP Extension: Stickers (use of PubSub)

Am Donnerstag, den 19.11.2020, 18:10 +0500 schrieb Andrew Nenakhov: > So of course, we use HTTP > for hosting sticker packs and stickers themselves, and any client on > any OS can *easily* import any image by their URIs. This way clients > do not need to use pubsub or anything, just use the links,

Re: [Standards] Use of XEP-0198 resumption under adverse network conditions

Am Mittwoch, den 04.11.2020, 11:46 + schrieb Dave Cridland: > > Due to network analysis (and "thanks" to a bug in the server which > caused some useful logging), we were able to examine not only when > sessions went into the unresponsive state, but also when the client > subsequently sent

Re: [Standards] Fixing XEP-0066 (Out of Band Data)

Am Freitag, den 23.10.2020, 15:04 + schrieb Tedd Sterr: > (This is tangential to Dave's thread, but I didn't want to hijack > that, hence a new one.) > > There may be some argument to include the url in the body anyway for > backwards compatibility, but given the XEP is over 14 years old and

Re: [Standards] Call for Experience: XEP-0363: HTTP File Upload

Am Mittwoch, den 21.10.2020, 16:28 +0100 schrieb Dave Cridland: > > This specification is primarily intended for, and used for, the > purpose of transferring a file from one user to another. > > In practise, the clients upload a file, thereby obtaining a URL, and > pass that URL somehow to the

Re: [Standards] Call for Experience: XEP-0363: HTTP File Upload

Am Dienstag, den 20.10.2020, 14:31 + schrieb Jonas Schäfer: > The XEP Editor would like to Call for Experience with XEP-0363 before > presenting it to the Council for advancing it to Final status. > > > During the Call for Experience, please answer the following > questions: > > 1. What

Re: [Standards] Stanza ID of outgoing message

Am Montag, den 28.09.2020, 09:51 +0100 schrieb Dave Cridland: > > > On Sun, 27 Sep 2020 at 16:46, Holger Weiß > wrote: > > > > I think it would be good to find a better solution. > > OK, just out of curiosity, why? I for one want that to be formalized. So far the formal response to that

Re: [Standards] Stanza ID of outgoing message

Am Sonntag, den 27.09.2020, 17:45 +0200 schrieb Holger Weiß: > When opening a new session, MAM clients might want to use the > most-recent known XEP-0359 stanza ID to sync messages. One problem > they > face is that there's no way to figure out the stanza ID of outgoing > messages, short of

Re: [Standards] Very Simple Questions about Compliance Suites

Am Mittwoch, den 02.09.2020, 16:23 +0100 schrieb Dave Cridland: > Hey all, > > Really simple questions, so please do reply and answer: > > If you have an XMPP product or public project, do you claim > compliance with XEP-0423? > > If you do not claim compliance, are you aiming for compliance

Re: [Standards] XEP0384 OMEMO pubsub#publish-options clarification

Am Samstag, den 29.08.2020, 09:15 +0200 schrieb Philipp Hörist: > Hi, > > Just to be clear, the XEP mandates protocol features, not a default > config on your PubSub Service. > > Default config does not make much sense, as other XEPs would need > another configuration, that would mean we would

Re: [Standards] XEP0384 OMEMO pubsub#publish-options clarification

Am Samstag, den 29.08.2020, 08:37 +0200 schrieb Philipp Hörist: > Am Sa., 29. Aug. 2020 um 08:16 Uhr schrieb Ruslan N. Marchenko < > m...@ruff.mobi>: > > The way I read it initially was "pubsub service MUST support > > persitent items" but it seems it really

Re: [Standards] XEP0384 OMEMO pubsub#publish-options clarification

Am Samstag, den 08.08.2020, 09:22 +0200 schrieb Philipp Hörist: > Hi, > > Note that major server implementation don’t support checking all > fields they support with publish-options > > Means only because a server supports max_items, it does not mean it > can check the value via publish-options.

Re: [Standards] XEP0384 OMEMO pubsub#publish-options clarification

Am Samstag, den 08.08.2020, 07:13 + schrieb Daniel Gultsch: > Am Sa., 8. Aug. 2020 um 07:07 Uhr schrieb Ruslan N. Marchenko < > m...@ruff.mobi>: > > > > I.e. I know the form can contain any arbitrary data just wonder if > > any > > implementatio

[Standards] XEP0384 OMEMO pubsub#publish-options clarification

Hi Standards, I'm trying to extend PEP server implementation to support OMEMO and stumbled upon following issue: the OMEMO 5.3.2 stipulates the max_items should be specified in the publish-options form, however neither form registry nor XEP-0060 allow anything but access-model in the publishing

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

Am Dienstag, den 04.08.2020, 16:05 + schrieb XEP Editor Pipeline: > This message constitutes notice of a Last Call for comments on > XEP-0352. > > Title: Client State Indication > Abstract: > This document defines a way for the client to indicate its > active/inactive state. > > URL:

Re: [Standards] NEW: XEP-0440 (SASL Channel-Binding Type Capability)

Am Dienstag, den 21.07.2020, 19:28 +0100 schrieb Dave Cridland: > On Tue, 21 Jul 2020 at 18:57, Florian Schmaus > wrote: > > Based on the discussion in this thread, I suggest the following > > changes > > > > > > > > http://geekplace.eu/xeps/xep-sasl-cb-types/diff.html#sasl-mech-interaction >

Re: [Standards] NEW: XEP-0440 (SASL Channel-Binding Type Capability)

Am Donnerstag, den 16.07.2020, 13:08 +0200 schrieb Ruslan N. Marchenko: > Am Donnerstag, den 16.07.2020, 10:33 + schrieb Daniel Gultsch: > > Am Do., 16. Juli 2020 um 10:13 Uhr schrieb Florian Schmaus < > > f...@geekplace.eu>: > > > > > If you send 'y', whi

Re: [Standards] NEW: XEP-0440 (SASL Channel-Binding Type Capability)

Am Donnerstag, den 16.07.2020, 10:33 + schrieb Daniel Gultsch: > Am Do., 16. Juli 2020 um 10:13 Uhr schrieb Florian Schmaus < > f...@geekplace.eu>: > > > If you send 'y', which implies that you, the client, did not select > > a > > -PLUS mechanism for authentication, while the server

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

Am Dienstag, den 31.03.2020, 20:38 + schrieb Jonas Schäfer: > This message constitutes notice of a Last Call for comments on > XEP-0280. > > Title: Message Carbons > Abstract: > In order to keep all IM clients for a user engaged in a conversation, > outbound messages are carbon-copied to all

Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails

Am Donnerstag, den 09.07.2020, 11:27 +0100 schrieb Dave Cridland: > On Wed, 8 Jul 2020 at 12:44, Ruslan N. Marchenko > wrote: > > Am Dienstag, den 07.07.2020, 10:55 +0100 schrieb Dave Cridland: > > > If Alice connects and authenticates Bob via some means, and Bob > > &g

Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails

Am Dienstag, den 07.07.2020, 10:55 +0100 schrieb Dave Cridland: > On Mon, 6 Jul 2020 at 15:41, Ruslan N. Marchenko > wrote: > > Am Montag, den 06.07.2020, 16:20 +0200 schrieb Ruslan N. Marchenko: > > > Am Montag, den 06.07.2020, 13:19 +0100 schrieb Dave Cridland: > > &

Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails

Am Montag, den 06.07.2020, 16:20 +0200 schrieb Ruslan N. Marchenko: > Am Montag, den 06.07.2020, 13:19 +0100 schrieb Dave Cridland: > > On Mon, 6 Jul 2020 at 12:44, Ruslan N. Marchenko > > wrote: > > > Am Montag, den 06.07.2020, 10:46 +0100 schrieb Dave Cridland: > >

Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails

Am Montag, den 06.07.2020, 13:19 +0100 schrieb Dave Cridland: > On Mon, 6 Jul 2020 at 12:44, Ruslan N. Marchenko > wrote: > > Am Montag, den 06.07.2020, 10:46 +0100 schrieb Dave Cridland: > > > On Sun, 5 Jul 2020 at 22:13, Ruslan N. Marchenko > > > wrote: > >

Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails

Am Montag, den 06.07.2020, 10:46 +0100 schrieb Dave Cridland: > On Sun, 5 Jul 2020 at 22:13, Ruslan N. Marchenko > wrote: > > Am Samstag, den 04.07.2020, 19:47 +0100 schrieb Dave Cridland: > > > On Thu, 2 Jul 2020 at 06:58, Ruslan N. Marchenko > > > wrote: > >

Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails

Am Samstag, den 04.07.2020, 19:47 +0100 schrieb Dave Cridland: > On Thu, 2 Jul 2020 at 06:58, Ruslan N. Marchenko > wrote: > > Am Mittwoch, den 01.07.2020, 22:53 +0100 schrieb Dave Cridland: > > > On Wed, 1 Jul 2020 at 17:31, Ruslan N. Marchenko > > >

Re: [Standards] NEW: XEP-0440 (SASL Channel-Binding Type Capability)

Am Donnerstag, den 02.07.2020, 17:37 +0200 schrieb Florian Schmaus: > On 7/2/20 1:26 PM, Ruslan N. Marchenko wrote: > > Am Donnerstag, den 02.07.2020, 11:23 +0200 schrieb Florian Schmaus: > > > I am not sure if this is a downgrade attack (at least a

Re: [Standards] NEW: XEP-0440 (SASL Channel-Binding Type Capability)

Am Donnerstag, den 02.07.2020, 11:23 +0200 schrieb Florian Schmaus: > > I am not sure if this is a downgrade attack (at least a full-blown), > or, > if it is, if it. Without xep440 the client would have send 'p' in the > case you described, with a channel-binding type not supported by the >

Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails

Am Mittwoch, den 01.07.2020, 22:53 +0100 schrieb Dave Cridland: > On Wed, 1 Jul 2020 at 17:31, Ruslan N. Marchenko > wrote: > > Because Alice's authentication fails on this particualr conneciton? > > So it may be not Alice after all speaking, despite what 'from' > > t

Re: [Standards] NEW: XEP-0440 (SASL Channel-Binding Type Capability)

Am Sonntag, den 14.06.2020, 13:05 + schrieb XEP Editor Pipeline: > Version 0.1.0 of XEP-0440 (SASL Channel-Binding Type Capability) has > been released. > > Abstract: > This specification allows servers to annouce their supported SASL > channel-binding types to clients. > This describes

Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails

Am Mittwoch, den 01.07.2020, 10:37 +0100 schrieb Dave Cridland: > On Tue, 30 Jun 2020 at 17:59, Ruslan N. Marchenko > wrote: > > Am Dienstag, den 30.06.2020, 17:59 +0200 schrieb Jonas Schäfer: > > > > > Hi list, > > > > > > > > &

Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails

Am Dienstag, den 30.06.2020, 19:27 +0200 schrieb Holger Weiß: > * Ruslan N. Marchenko [2020-06-30 18:58]: > > Now if EXTERNAL fails - that means there's something wrong with the > > certificates. And proposal to fail back to dialback means we want > > to > > tolerate ce

Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails

Am Dienstag, den 30.06.2020, 17:59 +0200 schrieb Jonas Schäfer: > Hi list, > > (Editor hat on) > > On behalf of the Council, I’d like to bring this pull request to the > attention > of the community: > > https://github.com/xsf/xeps/pull/963 > > Input from server operators specifically would

Re: [Standards] XMPP Council Agenda 2020-06-24

Am Dienstag, den 23.06.2020, 18:55 +0200 schrieb Jonas Schäfer: > Hi everyone, > ... > 4a) PR#963: PR#963: XEP-0178: Clarify SASL-EXTERNAL specification > when s2s > auth fails > URL: https://github.com/xsf/xeps/pull/963 > Abstract: A while back it was discussed that XEP-0178 (SASL-EXTERNAL) >

Re: [Standards] Proposed XMPP Extension: Quick Response

Am Dienstag, den 21.04.2020, 10:44 + schrieb p...@bouah.net: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Quick Response > Abstract: > Quickly respond to automated messages. > I like the quick response thingy, reminds me of canned messages on pebble. So

Re: [Standards] LAST CALL: XEP-0357 (Push Notifications)

Am Dienstag, den 31.03.2020, 20:38 + schrieb Jonas Schäfer: > This message constitutes notice of a Last Call for comments on > XEP-0357. > > Title: Push Notifications > Abstract: > This specification defines a way for an XMPP servers to deliver > information for use in push notifications to

Re: [Standards] XEP-0313: pending 0.7 update review

Am Samstag, den 04.04.2020, 11:47 +0200 schrieb Philipp Hörist: > Hi, > > Am Sa., 4. Apr. 2020 um 11:33 Uhr schrieb Ruslan N. Marchenko < > m...@ruff.mobi>: > > Thanks, that makes perfect sense to me as in my limited _mere p2p > > conversation_ use case all those

Re: [Standards] XEP-0313: pending 0.7 update review

Am Freitag, den 03.04.2020, 21:51 +0100 schrieb Matthew Wild: > Hi folks, > > XEP-0313 is a well-established protocol at this point, but didn't yet > make it to the next stage in the standards process. Time to fix that! > > I have made a final round of updates to incorporate the various >

Re: [Standards] LAST CALL: XEP-0353 (Jingle Message Initiation)

On Thu, Sep 05, 2019 at 12:58:53PM +0200, Philipp Hörist wrote: > Am Do., 5. Sept. 2019 um 12:36 Uhr schrieb Ruslan N. Marchenko > : > > > > And in 0353 messages are body-less hence not > eligible for carbons. > > > > bodyless is eligible for carbon

Re: [Standards] LAST CALL: XEP-0353 (Jingle Message Initiation)

On Thu, Sep 05, 2019 at 12:42:23PM +0500, Andrew Nenakhov wrote: > вт, 3 сент. 2019 г. в 23:18, Georg Lukas : > > > > Speaking of 0353 as is, it was also not designed for Carbons. I think we > > should explicitly make use of Carbons (by similar means as with MAM), so > > that we do not need

Re: [Standards] XEP-0288 - Bidi - Maybe CFE?

Am Dienstag, den 03.09.2019, 10:58 + schrieb Maxime “pep” Buquet: > On September 3, 2019 10:55:18 AM UTC, Dave Cridland < > d...@cridland.net> wrote: > > Thanks for your snappy response. > > > > On Mon, 2 Sep 2019 at 18:13, Ruslan Marchenko wrote: > > > > > Hi, > > > > > > I've recently

Re: [Standards] [XEP-0234] Jingle File Transfer, Last Call and File Sharing

Am Dienstag, den 27.02.2018, 15:37 -0700 schrieb Peter Saint-Andre: > On 2/27/18 10:33 AM, Ruslan N. Marchenko wrote: > > That actually touches a point which is nagging me each time I'm > > looking > > into implementation. Who is responsible for closing the session? > >

Re: [Standards] [XEP-0234] Jingle File Transfer, Last Call and File Sharing

Am Montag, den 26.02.2018, 19:21 -0700 schrieb Peter Saint-Andre: > > The idea there was to allow multiple files to be sent in a session; > you > wouldn't close the session if you want to send more files, so you > would > send the element defined in §8.1 instead. IMHO a good > solution would be

Re: [Standards] XEP-0198: Stream should be closed when 'h' value is to high

Am Mittwoch, den 21.02.2018, 16:17 + schrieb Kevin Smith: > On 21 Feb 2018, at 13:21, Jonas Wielicki wrote: > > > > On Mittwoch, 21. Februar 2018 11:57:56 CET Kevin Smith wrote: > > > On 21 Feb 2018, at 09:41, Jonas Wielicki > > > wrote: > > > > On

Re: [Standards] Jingle (File Transfer) Session termination

On 28.12.2017 22:41, Ruslan N. Marchenko wrote: On 28.12.2017 20:41, Lance Stout wrote: Both sides locally terminated the session, so both sides should be in the ENDED state. Period. Full stop. That is a perfectly legal sequence of actions to take, but this particular combination suggests

Re: [Standards] Jingle (File Transfer) Session termination

On 28.12.2017 20:41, Lance Stout wrote: Both sides locally terminated the session, so both sides should be in the ENDED state. Period. Full stop. The fact that one side ended up getting an error response to their session-terminate is irrelevant, because (as you quoted) when locally

Re: [Standards] Jingle (File Transfer) Session termination

On 29.11.2017 20:25, Ruslan N. Marchenko wrote: On 29.11.2017 17:42, Jonas Wielicki wrote: Daniel thinks that there are clients which can only do SI, but doesn’t recall any off the top of his head. Telepathy-gabble for one supports only SI. I'm currently looking if i can monkeypatch

Re: [Standards] LAST CALL: XEP-0363 (HTTP File Upload)

On 29.11.2017 20:16, Jonas Wielicki (XSF Editor) wrote: This message constitutes notice of a Last Call for comments on XEP-0363. Title: HTTP File Upload Abstract: This specification defines a protocol to request permissions from another entity to upload a file to a specific path on an HTTP

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

On 07.12.2017 18:35, Jonas Wielicki (XSF Editor) wrote: This message constitutes notice of a Last Call for comments on XEP-0352. Title: Client State Indication Abstract: This document defines a way for the client to indicate its active/inactive state. URL:

Re: [Standards] UPDATED: XEP-0363 (HTTP File Upload)

On 05.12.2017 10:39, Evgeny Khramtsov wrote: Tue, 5 Dec 2017 08:30:38 + Kevin Smith wrote: 2) New namespace: previous version payloads are allowed through, new versions won’t be allowed through until the validator is updated No, new namespaces are treated as

Re: [Standards] 2017-11-29 XMPP Council Meeting Minutes

On 29.11.2017 17:42, Jonas Wielicki wrote: Present: Dave (Chair), Kevin, Georg, Daniel, Sam Minutes: Yours truly. Chat logs: http://logs.xmpp.org/council/2017-11-29#15:55:08 ... 2. Vote on deprecating XEP-0095 (Stream Initiation) --- Sam did

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

On 18.11.2017 17:14, Philipp Hörist wrote: Why would a server allow that if it has no use case and leads to problems? When a client sets the preferences the server replies with the full pref list, this gives the server the possibility to refuse some entries. The XEP also states note that

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

On 05.11.2017 19:21, Ruslan N. Marchenko wrote: Hi, On 16.10.2017 20:38, Jonas Wielicki (XSF Editor) wrote: 5. Is the specification accurate and clearly written? The first thing I stumbled upon while starting drafting implementation is - empty result. ? ? 0? Or perhaps even ? Some more

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

On 14.11.2017 22:37, Sam Whited wrote: What do the server devs here think? To be fair this protocol is implemented in majority(?) of existing xmpp server implementations so the burden is zero. The question is rather - what is the future vision for this component protocol? It considered as

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

On 09.11.2017 23:54, Arc Riley wrote: On Thu, Nov 9, 2017 at 12:30 PM, Florian Schmaus > wrote: Fact is, if you would implement a new XMPP server without xep114, you would miss a lot of fun. I haven't run an XMPP component since the

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

Hi, On 16.10.2017 20:38, Jonas Wielicki (XSF Editor) wrote: This message constitutes notice of a Last Call for comments on XEP-0313. Abstract: This document defines a protocol to query and control an archive of messages stored on a server. This Last Call begins today and shall end at the

Re: [Standards] Proposed changes to OMEMO's use of PEP

On 26.03.2017 00:01, Timothée Jaussoin wrote: Hi, It seems that this pull request brought some interesting discussions. I'll try to clarify my position regarding this pull request. Le vendredi 24 mars 2017 à 17:03 +0100, Andreas Straub a écrit : Hey all, this topic has been discussed at

Re: [Standards] Deprecating Privacy Lists (again)

On 23.03.2017 14:18, Dave Cridland wrote: On 22 March 2017 at 20:08, Ruslan N. Marchenko <m...@ruff.mobi> wrote: On 22.03.2017 20:37, Sam Whited wrote: On Wed, Mar 22, 2017 at 2:28 PM, Yann Leboulanger <aste...@lagaule.org> wrote: One nice feature we also don't have with bloc

Re: [Standards] Deprecating Privacy Lists (again)

On 22.03.2017 20:37, Sam Whited wrote: 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.

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

On 18.03.2017 11:16, Dave Cridland wrote: On 18 March 2017 at 09:53, Florian Schmaus <f...@geekplace.eu> wrote: On 18.03.2017 09:43, Dave Cridland wrote: On 17 Mar 2017 21:52, "Ruslan N. Marchenko" <m...@ruff.mobi <mailto:m...@ruff.mobi>> wrote: On 11.02

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

On 11.02.2017 21:43, Florian Schmaus wrote: It should be explicitly stated that the CSI state is *not* (because it can not) restored after a stream resumption. I've created a PR to address this: https://github.com/xsf/xeps/pull/402 Why *not* btw? Device may detect the connection is dropped (by

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

On 07.03.2017 12:31, Jonas Wielicki wrote: I would like a rationale for why after going visible again, the session is treated as before sending initial presence. This feels counter-intuitive to me: I would expect all my contacts to see the presence I most recently sent to those on my "visible

[Standards] xmpp namespaces registry lacks rosterver namespace

Hi, I've been trying to find a registration of the urn:xmpp:features:rosterver namespace and found it's only mentioned once(!) in RFC6121 and nowhere else - namely neither in https://xmpp.org/registrar/namespaces.html nor in https://xmpp.org/registrar/stream-features.html registry. Is it

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

On 28.02.2017 17:27, XMPP Extensions Editor wrote: This message constitutes notice of a Last Call for comments on XEP-0186 (Invisible Command). Abstract: This document specifies an XMPP protocol extension for user invisibility. URL: https://xmpp.org/extensions/xep-0186.html This Last Call

[Standards] XEP-0186 typo

Hi, there's a typo in Example 8. Service discovery response - should have reversed direction (to/from). Regards, Ruslan ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe:

Re: [Standards] Bind 2.0 and Best Practices for Handling Offline Messages interoperability

On 24.02.2017 13:10, Michal Piotrowski wrote: Maybe initial presence should also be wrapped up inside bind2? This could be handy. On the other hand how should this interoperate with RFC 6121 4.2.1. In this section it's "recommended" that the client first get's roster from the server

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

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,

Re: [Standards] MAM: misleading archiving node in examples

On 21.02.2017 22:00, Kim Alvefur wrote: Hi, On Tue, Feb 21, 2017 at 09:35:51PM +0100, Ruslan N. Marchenko wrote: If I understand it right - in absence of 'to' attribute on c2s - the server itself is assumed as a recipient - i.e. == . No, the current account is assumed, so ... In MAM case

[Standards] MAM: misleading archiving node in examples

Good evening, In the examples across XEP-0313 the IQs are all to-less. If I understand it right - in absence of 'to' attribute on c2s - the server itself is assumed as a recipient - i.e. == to='example.org' id='1'/>. In MAM case archiving node for the user is user's bare jid - hence

[Standards] MAM: Conflicting storage prefs behaviour

Good afternoon, I'm preparing implementation of the mam and since there're very few details in the XEP-0313 about actual archiving, mostly about querying - i believe the archiving process is then left at the discretion of the implementers. Now, to avoid storing multiple copies of the

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

On Wed, Feb 15, 2017 at 11:39:33AM +0300, Evgeny Khramtsov wrote: > > But we don't have these tools. XMPP is a "niche" protocol, > Ok, so let's keep it niche protocol by generating standards for each and every use case. ___ Standards mailing list Info:

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

On 15.02.2017 08:26, Evgeny Khramtsov wrote: Wed, 15 Feb 2017 08:21:39 +0100 "Ruslan N. Marchenko" <m...@ruff.mobi> wrote: Well, high-load is always a "corner" case: a very few people need it. That doesn't mean we should ignore it. For example, SIP folks never ign

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

On 15.02.2017 04:24, Travis Burtrum wrote: Really? How many ports do you have to open? At least 3 - 25, 465, 587 I have port 25 for SMTP Lucky you ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe:

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

On 15.02.2017 07:44, Evgeny Khramtsov wrote: I'm not here to convince you using balancers or/and ssl offload, feel free not to use them. The thing is load balancers exist and some people want to use them for whatever reason. Exactly and normally load-balancers are making balancing decision

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

On 14.02.2017 20:36, Evgeny Khramtsov wrote: There is yet another use case: letting load balancers (haproxy, nginx, etc) support tls themselves and route decrypted traffic to an XMPP backend. Currently, haproxy and nginx don't support XMPP STARTTLS (although a patch for nginx exists with

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

On 14.02.2017 15:25, Travis Burtrum wrote: (airports, coffee shops etc), save roundtrips. And this is the maybe, most TLS libs I've seen it's easier to establish a direct TLS connection than xmpp's custom STARTTLS. Maybe it's because I'm not using high-level abstraction libs but with openssl

Re: [Standards] XEP-0198 stream resumption with too high 'h' parameter

On Tue, Feb 14, 2017 at 02:19:57PM +0100, Michal Piotrowski wrote: > > Why, there's general case in error handling section: > >  Stream management errors SHOULD be considered recoverable; >  however, misuse of stream management MAY result in termination of the >  stream. > > >

Re: [Standards] XEP-0198 stream resumption with too high 'h' parameter

On Tue, Feb 14, 2017 at 12:17:10PM +0100, Michal Piotrowski wrote: > In XEP-0198 I didn't find any information what should happen if clients sends > too high 'h' parameter.  > > What should be the server response in this case? The safest is probably to > close the stream with error indicating a

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

On Mon, Feb 13, 2017 at 03:55:13PM -0600, Sam Whited wrote: > On Mon, Feb 13, 2017 at 3:43 PM, Ruslan N. Marchenko <m...@ruff.mobi> wrote: > > I don't understand what do we need to hide here by summoning port 5223 from > > the oblivion. > > This is another reason why I

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

On 13.02.2017 21:57, Travis Burtrum wrote: On 02/13/2017 02:26 PM, Ruslan N. Marchenko wrote: So security here will be just in the sense "all or nothing" - either you pass through (non-paranoid) or not (paranoid). That's not true though, there are firewalls in practice today that

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

On 13.02.2017 19:58, Travis Burtrum wrote: Boy am I glad you missed the last call deadline by a day so I don't have to address your concerns. :) On 02/12/2017 11:03 AM, Sam Whited wrote: A minor nitpick: The requirements section isn't really requirements, it's the actual main content of the

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

On 09.02.2017 00:07, XMPP Extensions Editor wrote: This message constitutes notice of a Last Call for comments on XEP-0280 (Message Carbons). Abstract: In order to keep all IM clients for a user engaged in a conversation, outbound messages are carbon-copied to all interested resources.

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

On 09.02.2017 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/xep-0352.html

Re: [Standards] RFC 6120 vs. XEP

On 08.02.2017 21:42, Evgeny Khramtsov wrote: Wed, 8 Feb 2017 20:06:19 +0100 "Ruslan N. Marchenko" <m...@ruff.mobi> wrote: RFC restricts nowhere binding process to this extension Actually it does, Section 14.4: 14 is a namespace section, so apparently it defines na

Re: [Standards] RFC 6120 vs. XEP

Allow me to put my two cents On 08.02.2017 09:53, Evgeny Khramtsov wrote: Wed, 8 Feb 2017 08:19:17 + Dave Cridland wrote: Right, I understand, and largely agree. I might scribble a draft to address this, by clarifying what we really meant here. I see also two issues