[Standards] Re: XEP-0045: Stanzas when loosing membership in member-only room

On 7/10/24 5:08 AM, Guus der Kinderen wrote: Hello! Section 9.4 of XEP-0045 Multi-User Chat defines XMPP interaction when a member of a room gets their membership removed. In the last few lines of the section, the section describes how, in a  members-only room, the affected user is to be

[Standards] Re: XEP-0045 combining valid and invalid ban list modification in one request

Hallo Guus, On 7/5/24 8:49 AM, Guus der Kinderen wrote: Hello! XEP-0045 Section 9.1 defines that: - a user cannot be banned by an admin with a lower affiliation. - if an admin or owner attempts to ban himself, the service MUST deny the request. Section 9.2, that deals with modifying the ban

[Standards] Re: XEP-0045 definition of Ban List JIDs

On 7/5/24 8:31 AM, Guus der Kinderen wrote: Hello! XEP-0045 Multi-User Chat, section 9.2 defines that the ban list is always based on a user's bare JID (in the first paragraph). That same section also defines a matching order (in the last paragraph) in which items with a full JID are

[Standards] Re: Council (and what it does, and what it should do)

On 6/3/24 3:02 AM, Goffi wrote: All feedback from experienced community members is valuable, and I see no reason why council feedback should matter more. This is a very important point. Council members are not special people with special insight - they are simply community members who are

[Standards] Re: Council (and what it does, and what it should do)

On 6/2/24 12:30 PM, Florian Schmaus wrote: On 27/05/2024 15.07, Dave Cridland wrote: Equally, I've seen other proposals suggesting much higher bars for accepting a protoXEP, with in effect a pre-Experimental stage tacked on beforehand. I think this would be bad, too, and risks just

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

On 5/8/24 8:12 AM, Sam Whited wrote: maybe we should have a "how to use TLS with XMPP" informational spec of our own at some point? Thijs Alkemade and I wrote RFC 7590 [1] for that purpose, but it was published in 2015 (via the UTA WG) and much has changed since then. Peter [1]

[Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))

On 3/10/24 11:19 AM, Maxime Buquet wrote: On 2024/03/10, Daniel Gultsch wrote: This message constitutes notice of a Last Call for comments on XEP-0360. Title: Nonzas (are not Stanzas) Abstract: This specification defines the term "Nonza", describing every top level stream element that is not a

[Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))

On 3/10/24 9:18 AM, Daniel Gultsch wrote: This message constitutes notice of a Last Call for comments on XEP-0360. Title: Nonzas (are not Stanzas) Abstract: This specification defines the term "Nonza", describing every top level stream element that is not a Stanza. URL:

[Standards] Re: Proposed XMPP Extension: Host Meta 2 - One Method To Rule Them All

directly and he responded promptly, thanks for that! He asked me to convey his message and he'd respond with a +1 so I'm doing so here: On 2/7/24 21:05, Peter Saint-Andre wrote: > On 2/7/24 6:56 PM, Peter Saint-Andre wrote: >> Hi Travis! >> >> On 2/7/24 5:37 PM,

[Standards] Re: Feedback requested: SVCB for XMPP

On 2/13/24 11:18 PM, Travis Burtrum wrote: 5. Ultra-minor nit: is BOSH needed or useful with websockets and upcoming webtransport? legacy clients that don't support either of those won't support this either, and will look up bosh the old way. Could we perhaps deprecate BOSH at this point?

[Standards] Re: Feedback requested: SVCB for XMPP

On 2/13/24 11:30 PM, Stephen Paul Weber wrote: 2. It mentions QUIC, and links to the XEP, but I don't see a way to indicate a QUIC connection? Maybe because QUIC is still experimental, so probably not ready to be enshrined in an RFC, especially with WT coming. QUIC was published as RFC

[Standards] Re: LAST CALL: XEP-0458 (Community Code of Conduct)

A work-in-progress pull request is here: https://github.com/xsf/xeps/pull/1301 On 11/30/23 9:01 AM, Peter Saint-Andre wrote: On 11/30/23 1:55 AM, Guus der Kinderen wrote: Thanks Peter, The improvements look good to me. I've left some minor feedback inline. Great. One comment at the end

[Standards] Re: LAST CALL: XEP-0458 (Community Code of Conduct)

On 11/30/23 1:55 AM, Guus der Kinderen wrote: Thanks Peter, The improvements look good to me. I've left some minor feedback inline. Great. One comment at the end. >      > As for the applicability: much (all?) of the violations that I >     witnessed >      > are simple

[Standards] Re: LAST CALL: XEP-0458 (Community Code of Conduct)

, Peter Saint-Andre <mailto:stpe...@stpeter.im>> wrote: Hallo Guus, Thanks for sharing your thoughts. In my comments below, I haven't yet provided suggested text, but I wanted to reply quickly and I will send another note when I can make concrete proposals. On 10/31/2

[Standards] Re: LAST CALL: XEP-0458 (Community Code of Conduct)

Hallo Guus, Thanks for sharing your thoughts. In my comments below, I haven't yet provided suggested text, but I wanted to reply quickly and I will send another note when I can make concrete proposals. On 10/31/23 3:18 PM, Guus der Kinderen wrote: Hello, Thank you for the work that has

[Standards] LAST CALL: XEP-0458 (Community Code of Conduct)

This message constitutes notice of a Last Call for comments on XEP-0458, a Procedural XEP that the XSF Board of Directors is considering for advancement to a status of Active. Title: Community Code of Conduct Abstract: This document describes the XMPP Standard Foundation's Code of Conduct.

[Standards] updated RFCs

On 2/24/23 8:47 AM, Tedd Sterr wrote: The original sender of a message stanza SHOULD give it id=UUID. Unfortunately, this wasn't a requirement in the RFCs, so now we have various hacks to try to deal with that because we can't just fix the problem while maintaining compatibility. At some

Re: [Standards] uppercase/lowercase of keywords

Or: hey, it's great that we already did the work, let's merge it! On 1/18/23 12:46 PM, Thilo Molitor wrote: So the PR is lying around for ~5 years and nobody merged it even if it was approved? Why that? -tmolitor Am Mittwoch, 18. Januar 2023, 18:45:30 CET schrieb Florian Schmaus: On

Re: [Standards] uppercase/lowercase of keywords

On 1/18/23 9:26 AM, Thilo Molitor wrote: In Appendix F: Requirements Conformance all our XEPs refer to RFC 2119 defining "MUST", "SHALL" etc. But since RFC 2119 does not specify which case should be used for these keywords, a XEP using "shall" or even "sHaLl" uses normative keywords, no? My

[Standards] Fwd: [kitten] Common Authentication Technology Next Generation (kitten) WG Virtual Meeting: 2023-01-17

Hi folks, just so you're aware the IETF's KITTEN working group will hold an interim virtual meeting tomorrow, and various SASL2-related topics are on the agenda. Feel free to join if you're interested! /psa Forwarded Message Subject: Re: [kitten] Common Authentication

Re: [Standards] standardization process

[no hats] On 1/6/23 6:49 AM, Florian Schmaus wrote: I'd like the XSF to provide infrastructure to publish (and discuss) XEPs without Councils approval. Everyone can already publish stuff (cause "internet"). So the XSF not allowing this just scatters the documents around the web and does more

[Standards] standardization process (was: Re: XEP-0353 propose id syntax)

On 1/5/23 3:18 AM, Florian Schmaus wrote: I become more and more convinced that we may be better with an IETF I-D / RFC style standardization process. Where an I-D is a mutable, living document on the road to become an immutable RFC. You know, we could move all of our activities to an IETF

[Standards] Fwd: [Uta] BCP 195, RFC 9325 on Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)

FYI. The XMPP community should be aware of this document, which obsoletes RFC 7525 and thereby updates RFC 7590: https://www.rfc-editor.org/rfc/rfc7590.txt https://www.rfc-editor.org/rfc/rfc9325.txt Peter Forwarded Message Subject: [Uta] BCP 195, RFC 9325 on

Re: [Standards] Proposed XMPP Extension: SASL SCRAM Downgrade Protection

On 10/17/22 5:27 PM, Thilo Molitor wrote: Thanks for your feedback Dave! Am Montag, 17. Oktober 2022, 15:36:56 CEST schrieb Dave Cridland: Any attacker able to manipulate the data coming from the server such that the client sees a restricted set of TLS channel bindings can also manipulate the

Re: [Standards] Hash Algorithm Names in Bits of Binary

Thanks, Sam. This seems like a reasonable approach. On 7/25/22 10:45 AM, Sam Whited wrote: Hi all, There was a brief discussion on jdev@ today about how Bits of Binary is not consistent with newer XEPs in terms of the hash algorithm names it uses. Currently it only mentions using the name

Re: [Standards] What to do about multi-item data forms?

On 7/19/22 6:46 AM, Sam Whited wrote: Thinking about this more, I'm not sure that it makes sense to clarify this in a new XEP. Did we ever come up with something along the lines of IETF erratas or editors notes that we could put at the beginning of the document? We don't have errata, we have

Re: [Standards] What to do about multi-item data forms?

On 7/17/22 3:03 PM, Sam Whited wrote: On Sun, Jul 17, 2022, at 14:04, Peter Saint-Andre wrote: Maybe. The text in effect says "here are some additional elements not mentioned so far in the spec", not "these new elements are included in addition to other elements within the XML&

Re: [Standards] What to do about multi-item data forms?

XEP-0004 co-author here... On 7/17/22 9:05 AM, Sam Whited wrote: Several people [1, 2] have recently asked about how to use multi-item data forms. XEP-0004 when introducing multi-item forms says: Therefore, a data form of type "result" MAY contain two child elements not described in the basic

Re: [Standards] XMPP Council Agenda 2022-06-15

On 6/28/22 4:05 AM, Georg Lukas wrote: * Daniel Gultsch [2022-06-14 22:07]: a) Proposed XMPP Extension: WebSocket S2S (https://xmpp.org/extensions/inbox/websocket-s2s.html) +1 though I wonder if it makes sense to release a XEP for s2s where we have an RFC for c2s. Maybe harmonizing both

Re: [Standards] XEP-0072 si-pub namespace inconsistency

On 3/10/22 2:46 AM, Georg Lukas wrote: Hi, I've been looking into our legacy namespaces recently (the ones starting with `http://jabber.org/`), with a goal to implement HTTP Redirects to the respective XEPs (first map at https://op-co.de/tmp/namespacemap.txt) I identified a bunch of

Re: [Standards] XEP-0156 _xmppconnect is vulnerable to MITM

Co-author of XEP-0156 here. Thanks for raising this issue. I would go even farther and note that DNS TXT records were never a great idea for this functionality (they're actively discouraged in the DNS community for application-level uses like this). On 2/9/22 4:29 PM, Travis Burtrum wrote:

Re: [Standards] Proposed XMPP Extension: PubSub Namespaces

On 1/8/22 4:02 PM, Maxime Buquet wrote: On 2022/01/08, Dave Cridland wrote: On Tue, 4 Jan 2022 at 17:55, Jonas Schäfer wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: PubSub Namespaces Abstract: This extension defines a new PubSub node attribute to specify

Re: [Standards] Proposed XMPP Extension: PubSub Namespaces

On 1/5/22 5:41 AM, Ralph Meijer wrote: On 04/01/2022 18.55, Jonas Schäfer (XSF Editor) wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: PubSub Namespaces Abstract: This extension defines a new PubSub node attribute to specify the type of payload.

Re: [Standards] Proposed XEP-0060 Changes

On 12/21/21 2:54 AM, Florian Schmaus wrote: On 16/12/2021 14.32, Melvin Keskin wrote: Hi Melvin, 1. Should I add that as § 3.5 to XEP-0004 (after https://xmpp.org/extensions/xep-0004.html#protocol-results)? 2. Should I change

Re: [Standards] XEP-0353: Rework whole spec, namespace bump

On 12/8/21 1:42 AM, Philipp Hancke wrote: Am 07.12.21 um 23:31 schrieb Lance Stout: +1 on merging. There’s been a lot of foundational improvements since mid-2014 that we can safely rely on now, so these changes make sense. with authors hat: what Lance said! IIRC the only reason we didn't go

Re: [Standards] XEP-0371: Jingle ICE Transport Method - Question on ICE Restart detection

On 11/17/21 2:25 AM, Philipp Hancke wrote: Am 16.11.21 um 20:31 schrieb Daniel Gultsch: Hi, I’m trying to implement ICE Restarts with XEP-0371. The XEP states that ICE restarts can be detected by a changed ufrag and pwd attributes in the transport-info. However what I'm currently unclear

Re: [Standards] MPP Council Agenda 2021-10-27

Regarding the subject line, it's about time that we finally got rid of the "X"! ;-) /psa ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org

Re: [Standards] Stable is the new Draft

On 9/8/21 6:19 AM, Dave Cridland wrote: > > > On Tue, 7 Sept 2021 at 16:44, Peter Saint-Andre <mailto:stpe...@mozilla.com>> wrote: > > On 8/31/21 9:41 AM, Jonas Schäfer wrote: > > > The term "Draft" for our non-Final but also non-Experiment

Re: [Standards] Stable is the new Draft

On 8/31/21 9:41 AM, Jonas Schäfer wrote: > The term "Draft" for our non-Final but also non-Experimental standards has > been adopted from our "mother" organization, the Internet Engineering Task > Force. The IETF has since abandoned that term. In fact, the IETF moved from a three-stage track

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

On 8/13/21 7:47 AM, Dave Cridland wrote: > > > On Wed, 11 Aug 2021 at 22:49, Peter Saint-Andre <mailto:stpe...@mozilla.com>> wrote: > > On 8/11/21 3:35 PM, Kim Alvefur wrote: > > On Wed, Aug 11, 2021 at 02:25:56PM -0600, Peter Saint-Andre wrote: >

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

On 8/11/21 3:35 PM, Kim Alvefur wrote: > On Wed, Aug 11, 2021 at 02:25:56PM -0600, Peter Saint-Andre wrote: >> 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... > > We were always at w

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

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... On 8/11/21 2:13 PM, Philipp Hancke wrote: > tl;dr: its a mess. What is the deployment state of xep-0368? > > Am 11.08.21 um 19:08 schrieb Peter Sa

[Standards] Fwd: [Uta] STARTTLS vulnerabilities

Perhaps of interest here... Forwarded Message Subject: [Uta] STARTTLS vulnerabilities Date: Wed, 11 Aug 2021 17:42:40 +0200 From: Hanno Böck To: u...@ietf.org Hi, I wanted to share some research we have done on vulnerabilities in STARTTLS implementations:

[Standards] ALPACA attack

I haven't seen notice of the ALPACA attack on this list, but it might be of interest to those running XMPP services and non-XMPP services (e.g., HTTP or IMAP) on the same machine: https://alpaca-attack.com/ We've added some text about this to the forthcoming revision of RFC 7525 (on which the

Re: [Standards] XEP Advancement Shortlist

On 6/1/21 3:44 PM, Tedd Sterr wrote: > I'll just leave this here… > > https://mail.jabber.org/pipermail/standards/2020-January/036918.html Some of those most definitely deserve to be deprecated or obsoleted. For instance, is anyone still using SOAP, let alone SOAP over XMPP? Peter

Re: [Standards] Incorrect example in XEP-0198?

On 5/7/21 7:33 AM, Edwin Mons wrote: > On 07/05/2021 14:33, Kevin Smith wrote: >> On 7 May 2021, at 13:30, Matthew Wild wrote: >>> On Fri, 7 May 2021 at 12:10, Edwin Mons wrote: Hi all, I was looking at XEP-0198, and noticed something odd in Example 6. Shouldn't that have

Re: [Standards] DEPRECATED: XEP-0013 (Flexible Offline Message Retrieval)

Finally! :-) On 5/4/21 11:57 AM, Jonas Schäfer (XSF Editor) wrote: > Version 1.3 of XEP-0013 (Flexible Offline Message Retrieval) has been > released. > > Abstract: > This specification defines an XMPP protocol extension for flexible, > POP3-like handling of offline messages. The protocol

Re: [Standards] RFC 8692

Oops, I meant RFC 8962! On 4/2/21 4:34 PM, Peter Saint-Andre wrote: > There's a cute reference to XMPP in RFC 8692, published just yesterday: > > https://www.rfc-editor.org/rfc/rfc8962.html > > /psa > ___ Standards mailin

[Standards] RFC 8692

There's a cute reference to XMPP in RFC 8692, published just yesterday: https://www.rfc-editor.org/rfc/rfc8962.html /psa ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org

Re: [Standards] Message Carbons authors and LC

On 3/11/21 11:02 AM, Joe Hildebrand wrote: > I have no objections to someone else taking over, and removing my name from > the doc. Feel free to do that for any docs where I'm an author going > forward, as needed. Thanks, Joe. Our long-time practice has been to keep the original authors but

Re: [Standards] XEP-0294: update the reference from RFC 5285 to RFC 8285 and add a mapping for a=extmap-allow-mixed

Hi Fippo! On 3/10/21 11:04 AM, Philipp Hancke wrote: > I submitted a PR to update XEP-0294 here: >   https://github.com/xsf/xeps/pull/1044 > after Chrome 89 (after a lot of time) started shipping the >   a=extmap-allow-mixed attribute (which old Chrome versions wrongly > attempted to parse as

Re: [Standards] Message Carbons authors and LC

On 3/11/21 9:48 AM, Georg Lukas wrote: > * Sam Whited [2021-03-11 15:05]: >> The authors of message carbons haven't been active for a while if I'm >> not mistaken. > > As somebody who has done the most non-editorial changes on the XEP in > the last six years, and saw (and contributed to) it

Re: [Standards] Message Carbons authors and LC

On 3/11/21 7:01 AM, Sam Whited wrote: > Hi all, > > The authors of message carbons haven't been active for a while if I'm > not mistaken. Correct. Also Joe Hildebrand's email address in XEP-0280 won't work anymore, but I've bcc'd him and Matt Miller on this message. > Do we have any current

Re: [Standards] Important change of process for changes to XEPs under control of the XMPP Council

On 2/17/21 9:42 AM, Jonas Schäfer wrote: > Change proposals to XEPs which > are under the control of Council do not get put on the Council agenda before > there has been a thread on the standards mailing list. This seems reasonable. By "XEPs which are under the control of Council" do we mean

Re: [Standards] Proposed XMPP Extension: DOAP usage in XMPP

On 1/13/21 12:35 PM, Dave Cridland wrote: > > > On Wed, 13 Jan 2021 at 18:24, Sam Whited > wrote: > > I'd like to recommend that we do not publish this spec in its current > form. The XML community has the tendency to over-engineer everything to > try and

Re: [Standards] Deprecating Dialback

On 12/2/20 8:36 AM, Dave Cridland wrote: > > > On Wed, 2 Dec 2020 at 14:09, Sam Whited > wrote: > > I've been having a think about dialback recently and came to the > conclusion that it would be nice to begin discouraging its use on the > public network.

Re: [Standards] form field types: text-multi vs list-multi with

Hi. Florian asked me to reply, so here I am. :-) On 5/7/20 10:00 AM, Florian Schmaus wrote: > On 5/5/20 12:35 PM, Matthew Wild wrote: >> On Sat, 2 May 2020 at 21:29, Florian Schmaus > > wrote: >> >> So why go for the slightly more complicated semantic of >>

Re: [Standards] Registrar: disco-categories: Add 'telegram' gateway type

On 4/5/20 10:44 AM, Maxime Buquet wrote: > On 2020/04/04, Linus Jahn wrote: >> Hello, >> >> I opened a pull request more than 1.5 years ago and received a +1 from >> stpeter, >> but no further interaction. The pull request was not merged. >> >> The pull request can be found here: >>

Re: [Standards] Registrar: disco-categories: Add 'telegram' gateway type

On 4/4/20 12:15 PM, Linus Jahn wrote: > Hello, > > I opened a pull request more than 1.5 years ago and received a +1 from > stpeter, > but no further interaction. The pull request was not merged. > > The pull request can be found here: > https://github.com/xsf/registrar/pull/30 > > Can I do

Re: [Standards] A Meta-Discussion about the Standards Process

On 1/16/20 2:49 PM, Dave Cridland wrote: [ historical inaccuracies elided :P ] > > Peter Saint-Andre (I think) designed our standards process to > avoid the > > Internet Draft stage and go straight to the wild-west of Experimental, > > but it's otherwise the

Re: [Standards] A Meta-Discussion about the Standards Process

s. > > Then they formalized the step before, Internet Drafts, and > gradually the Proposed Standard quality (and gating function by the > IESG) improved, to the point where it was felt that there was an > additional stage that added little, so they dropped it. > > Peter Saint-A

Re: [Standards] Clarification for XEP-0054: private fields

On 9/19/19 1:01 AM, Wichert Akkerman wrote: > I am looking for a clarification on XEP-0054. The history description > for the XEP mentions that it essentially encapsulates > draft-dawson-vcard-xml-dtd-01 over XMPP, with changes to using > xuppercase for elements and adding JABBERID and > DESC. 

Re: [Standards] Clarification for XEP-0054: private fields

On 9/19/19 1:24 AM, Matthew Wild wrote: > Prosody also historically preserved everything (it basically treated > the vcard as an XML blob). However now we have moved to vcard4, our > compatibility code can obviously only convert fields it knows and > understands - therefore any custom fields

Re: [Standards] XEP-0184: normative message @type rules (Was: Council Voting Summary 2019-04-14)

On 5/8/19 12:23 PM, Florian Schmaus wrote: > On 25.04.19 21:09, Georg Lukas wrote: >> * Kevin Smith [2019-04-17 20:28]: PR #779 - XEP-0184: add a box about types and JIDs - https://github.com/xsf/xeps/pull/779 >>> >>> This seems a little backwards to me - it’s only saying the

Re: [Standards] XEP-0184: normative message @type rules (Was: Council Voting Summary 2019-04-14)

On 5/8/19 9:27 AM, Jonas Schäfer wrote: > On Donnerstag, 25. April 2019 21:09:04 CEST Georg Lukas wrote: >> * Kevin Smith [2019-04-17 20:28]: PR #779 - XEP-0184: add a box about types and JIDs - https://github.com/xsf/xeps/pull/779> >>> This seems a little backwards to me - it’s only

Re: [Standards] NEW: XEP-0418 (DNS Queries over XMPP (DoX))

On 4/4/19 11:08 AM, Dave Cridland wrote: > > > On Thu, 4 Apr 2019 at 17:26, Peter Saint-Andre <mailto:stpe...@mozilla.com>> wrote: > > On 4/1/19 12:59 PM, Florian Schmaus wrote: > > On 30.03.19 16:48, Jonas Schäfer (XSF Editor) wrote: > >>

Re: [Standards] NEW: XEP-0418 (DNS Queries over XMPP (DoX))

On 4/1/19 12:59 PM, Florian Schmaus wrote: > On 30.03.19 16:48, Jonas Schäfer (XSF Editor) wrote: >> Version 0.1.0 of XEP-0418 (DNS Queries over XMPP (DoX)) has been >> released. >> >> Abstract: >> This specification defines an XMPP protocol extension for sending DNS >> queries and getting DNS

Re: [Standards] One true final way to mark up messages

On 3/27/19 12:24 PM, Sam Whited wrote: > On Wed, Mar 27, 2019, at 17:14, W. Martin Borgert wrote: >> 0393 is not bad, IMHO. It might need two or three additions, esp. >> hyperlinks, but most typical use cases are covered. > > What is the use case for hyper links and who does it benefit? I > keep

Re: [Standards] Move XEP-0353: Jingle Message Initiation to Draft

On 3/14/19 11:05 AM, Dave Cridland wrote: > > > On Thu, 14 Mar 2019 at 15:14, Peter Saint-Andre <mailto:stpe...@mozilla.com>> wrote: > > On 3/14/19 5:05 AM, Dave Cridland wrote: > > > > > > On Wed, 13 Mar 2019 at 21:

Re: [Standards] Move XEP-0353: Jingle Message Initiation to Draft

On 3/14/19 5:05 AM, Dave Cridland wrote: > > > On Wed, 13 Mar 2019 at 21:46, Ralph Meijer <mailto:ral...@ik.nu>> wrote: > > On 13/03/2019 22.16, Kevin Smith wrote: > > > > > >> On 13 Mar 2019, at 17:37, Peter Saint-A

Re: [Standards] Move XEP-0353: Jingle Message Initiation to Draft

On 3/14/19 6:17 AM, Dave Cridland wrote: > > > On Thu, 14 Mar 2019 at 11:25, Ненахов Андрей > mailto:andrew.nenak...@redsolution.ru>> > wrote: > > > People send comments on the list, and we answer their questions, > propose > modifications to the text of the document,

Re: [Standards] Move XEP-0353: Jingle Message Initiation to Draft

On 3/13/19 11:46 AM, Ненахов Андрей wrote: > > > ср, 13 мар. 2019 г. в 21:54, Dave Cridland >: > > Philipp, Peter, > > Do either of you want to remain involved with this one? > > Andrew, > > If they don't, would you be able to handle processing Last

Re: [Standards] Proposed XMPP Extension: DNS Queries over XMPP (DoX)

Many years ago, people in Cuba used XMPP to get to the web because HTTP ports were blocked. :-) However, with DoH I am not sure we need DoX, too. Peter On 3/13/19 2:02 AM, Sergey Ilinykh wrote: > I guess it's something about accessing forbidden resources from > restrictive corporate networks. 

Re: [Standards] Move XEP-0353: Jingle Message Initiation to Draft

I can help, but I would not object to adding a more active co-author (preferably an implementor of the spec). Peter On 3/13/19 10:53 AM, Dave Cridland wrote: > Philipp, Peter, > > Do either of you want to remain involved with this one? > > Andrew, > > If they don't, would you be able to

Re: [Standards] XEP-0013 Flexible Offline Message Retrieval, MAM and smacks

On 2/27/19 5:18 AM, Georg Lukas wrote: > * Thilo Molitor [2019-02-17 14:03]: >> Does anyone of you use XEP-0013 in your client other than for purging >> offline >> messages when you support MAM? > > To write down our discussion from the MUC: I think this is a bad idea > for multiple reasons. >

Re: [Standards] XEP-0388 (SASL2): Format of tasks, internationalisation of messages, Security Considerations

On 1/31/19 8:58 AM, Jonas Schäfer wrote: > So since during the summit, it was desired to have a breaking change to SASL2 > (that’s rare, isn’t it?), I have two suggestions for things which could use > fixing and which could trigger a namespace bump and one thing which should be > mentioned

Re: [Standards] XEP-0292: vCard4 - advance?

> On Jan 19, 2019, at 5:50 PM, Kim Alvefur wrote: > >> On Sun, Jan 20, 2019 at 12:29:43AM +, Philipp Hörist wrote: >> Only thing i would change is this sentence >> >>> When a client stores items at this node, it SHOULD NOT include an >>> ItemID, so that the pubsub service can assign those

Re: [Standards] XEP-0292: vCard4 - advance?

+1. It sure would be great to kill off vcard-temp after all these years. Another benefit: vcard4 is extensible and thus can be used in a wide variety of specialized applications (gaming, IoT, etc.). Peter On 1/19/19 1:44 PM, Kim Alvefur wrote: > Hi, > > I would like to see XEP-0292: vCard4

Re: [Standards] Tidying Deferred

On 1/17/19 3:43 AM, Ralph Meijer wrote: > On 17/01/2019 11.25, Evgeny wrote: >> On Thu, Jan 17, 2019 at 1:05 PM, Dave Cridland wrote: >>> we do not require it until Final - not even Draft has an absolute >>> requirement. >> >> I thought transitioning to Draft requires Call For Implementors, >>

Re: [Standards] Confusing Language in XEP-0261 (Jingle In-Band Bytestreams Transport Method)

On 1/12/19 1:01 PM, Jonas Schäfer wrote: > On Montag, 17. Dezember 2018 16:50:17 CET Sebastian Riese wrote: >> XEP-0261 uses "bytestream" >> for the overall Jingle session and "session" for the IBB session (at >> least it does so consistently). This is

Re: [Standards] Should we split XEP-0300 (Use of Cryptographic Hash Functions in XMPP) up?

On 12/16/18 2:37 AM, Jonas Schäfer wrote: > This may sound ridiculous at first, given that the text easily fits on less > than 10 pages in font size, but bear with me. > > I was proposing an LC for it to Kevin, because the protocol IMO is rather > mature, but then I realized that we have a

Re: [Standards] MIX (XEP-0369) channel discovery

On 9/25/18 10:58 AM, Steve Kille wrote: > Ralph, > > >> -Original Message- >> From: Standards On Behalf Of Ralph Meijer >> Sent: 20 September 2018 08:43 >> To: XMPP Standards >> Subject: [Standards] MIX (XEP-0369) channel discovery >> >> Hi, >> >> Recently I have been looking at

Re: [Standards] [XEP-0384] OMEMO: xml:lang + max_items

On 7/27/18 11:21 AM, Goffi wrote: > Le vendredi 27 juillet 2018, 17:24:27 CEST Peter Saint-Andre a écrit : >> On 7/27/18 8:03 AM, Goffi wrote: >>> Hello, >>> >>> I'm currently working on OMEMO implementation in Salut à Toi thanks to >>> the work of Syn

Re: [Standards] field report on authentication methods

On 8/9/18 9:51 AM, Sam Whited wrote: > This is great stuff, thanks Peter! I'd love it if we could use jabber.org > more; it's easy to forget that we have a great source of data about the > network at our fingertips. > > Given how small the percentage of logins over CRAM-MD5 and XEP-0078 are,

Re: [Standards] XEP-0060: Affiliations vs. access models

On 8/8/18 2:05 PM, Matthew Wild wrote: > And another question... (for Ralph? :) ) > > There are some cases which are not clear regarding the permission model. > > These two things contradict for example: > > Table 1: "Affiliations and their Privileges" states that entities with > affiliation

Re: [Standards] XEP-0163: support for "subscriber" affiliation

On 8/8/18 1:11 PM, Matthew Wild wrote: > This seems like a bug in the XEP, but I wanted to run it past the list > before I submit a PR. > > According to https://xmpp.org/extensions/xep-0163.html#defaults - > > " > A PEP service MUST: > > [...] > * Support the "owner" and "subscriber"

Re: [Standards] XEP-0060: Item ordering

On 8/8/18 3:17 AM, Philipp Hörist wrote: > I always thought the most recent refers to the publish date/time of the > item, hence if i override a item it also changes the updated time/date > and it becomes the most recent That seems reasonable. So it's really "last modified item". I'm curious what

Re: [Standards] XEP-0060: pubsub#dataform_xslt (yes, but why?)

[replying on-list] On 8/7/18 12:37 PM, Jonas Wielicki wrote: > On Dienstag, 7. August 2018 18:28:45 CEST you wrote: >> On 8/5/18 4:59 AM, Jonas Wielicki wrote: >>> Hi all, >>> >>> So while running the XEP-0060 node_config data form [1] through the thing >>> >>> which builds aioxmpp code to

Re: [Standards] XMPP Council Minutes 2018-08-01

On 8/6/18 9:53 AM, Dave Cridland wrote: > > > On 6 August 2018 at 16:45, Kevin Smith > wrote: > > On 6 Aug 2018, at 16:25, Tedd Sterr > wrote: > > > > http://logs.xmpp.org/council/2018-08-01/#14:59:59 >

Re: [Standards] XEP-0060: Inconsistency between SHIM registration and SHIM registry

On 8/2/18 2:02 PM, Melvin Vermeeren wrote: > Hi, > > In XEP-0060, Publish-Subscribe, there appears to be an inconsistency > regarding > the SHIM registration and the current listing in the SHIM registry. > > XEP-0060, in the examples, reads: >> > > This is also consistent with the "SHIM

Re: [Standards] [XEP-0384] OMEMO: xml:lang + max_items

On 7/27/18 8:03 AM, Goffi wrote: > Hello, > > I'm currently working on OMEMO implementation in Salut à Toi thanks to the > work of Syndace (https://github.com/Syndace/python-omemo), and I have two > issues with it: > > - SàT is using xml:lang attribute, and I don't see a way to specify it with

Re: [Standards] message encryption session at IETF 102

I see activity in the chatroom anyway. Sent from mobile, might be terse > On Jul 19, 2018, at 7:39 AM, Peter Saint-Andre wrote: > > Hmm, that doesn’t sound right, let me check. > > Sent from mobile, might be terse > >> On Jul 19, 2018, at 7:34 AM, Peter Wa

Re: [Standards] message encryption session at IETF 102

Hmm, that doesn’t sound right, let me check. Sent from mobile, might be terse > On Jul 19, 2018, at 7:34 AM, Peter Waher wrote: > > Hello > > Tried to join the IETF 102 meeting, but it said it has concluded. It is now > July 19 (”tomorrow, as seen on the 18th”), 13:33 UTC. When is the next

[Standards] message encryption session at IETF 102

Hi folks, the first meeting of the Messaging Layer Security working group will be held tomorrow at IETF 102 from 09:30 to 12:00 EDT (i.e., starting at 13:30 UTC): https://datatracker.ietf.org/meeting/102/materials/agenda-102-mls-00 Remote participation is available via the following links: *

Re: [Standards] Proposed XMPP Extension: Best practices for GDPR compliant deployment of XMPP

On 5/25/18 2:00 AM, W. Martin Borgert wrote: > On 2018-05-25 09:13, Winfried Tilanus wrote: >> Beside that informative XEP, I (or a group of people willing to do so) >> publish an own document discussing XMPP & the GDPR in detail. > > Having XEPs explaining best practices for > > - retrieving

Re: [Standards] Proposed XMPP Extension: Best practices for GDPR compliant deployment of XMPP

On 5/23/18 7:11 AM, Winfried Tilanus wrote: > On 23-05-18 10:47, Kevin Smith wrote: >>> It's also expressly not legal advice(!) >> I’m not convinced that saying “this isn’t legal advice” while giving >> advice on how to interpret/comply with law actually makes it so :) > > Yeah, showing a picture

Re: [Standards] Proposed XMPP Extension: Best practices for GDPR compliant deployment of XMPP

On 5/22/18 11:19 AM, Jonas Wielicki (XSF Editor) wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Best practices for GDPR compliant deployment of XMPP > Abstract: > This informational XEP provides information on deploying XMPP in way > that is compliant with

[Standards] Fwd: [new-work] WG Review: Messaging Layer Security (mls)

Hi all, Please take a look at the charter for this proposed IETF working group and consider getting involved! The XMPP community's experience with end-to-end encryption is extremely relevant here. Peter Forwarded Message Subject: [new-work] WG Review: Messaging Layer Security

Re: [Standards] Abolishing 'proposed' status for XEPs

On 4/23/18 8:09 AM, Matthew Wild wrote: > We have a number of XEPs stuck in 'proposed' with an expired Last Call. > > I think the reality is that the council "rejected" these, or last call > feedback is awaiting to be incorporated. By "rejected" I mean to imply > that the council didn't want to

Re: [Standards] XMPP Council Minutes 2018-04-11

On 4/12/18 5:47 PM, Tedd Sterr wrote: >> But we might never know if someone is building an application or service >> on top of a library... > > Isn't this the point of the CFE - to find out? > There is always the **possibility** that somebody somewhere could > possibly maybe have implemented a

  1   2   3   4   5   6   7   8   9   10   >