[Standards] Re: Proposed XMPP Extension: Reporting Account Affiliations

On Wed, Jul 19, 2023 at 04:12:22PM +0200, Daniel Gultsch wrote: Hi Kev, council has accepted this XEP. cheers Daniel On Tue, Jul 4, 2023 at 3:56 PM wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Reporting Account Affiliations Abstract: This specification

Re: [Standards] XEP-0388 SASL2: #3 protocol agility - SASL mechanisms

On Sat, Oct 22, 2022 at 11:28:26PM +0200, Thilo Molitor wrote: That does not come without a cost, though: attackers could use this information to determine which accounts are present on the server and maybe even fingerprint which software might be used. Because of this, we suggest multiple

Re: [Standards] LAST CALL: XEP-0215 (External Service Discovery)

On Wed, Jul 13, 2022 at 03:03:07PM -, Jonas Schäfer wrote: This message constitutes notice of a Last Call for comments on XEP-0215. Title: External Service Discovery Abstract: This document specifies an XMPP protocol extension for discovering services external to the XMPP network. URL:

Re: [Standards] XEP-0004 Partial form submission

Daniel Gultsch skrev: (2 februari 2022 17:11:02 CET) >Hi, > >I wanted to bring everyone's attention to a proposed modification of >XEP-0004 that allows partial form submission. > >While this has originally been proposed in '[Standards] Proposed >XEP-0060 Changes' we (Council) wanted to have the

Re: [Standards] Danish chains too short

Hey, Dave Cridland skrev: (30 januari 2022 17:38:22 CET) >But the default choice to maximize interop should be to include the trust >anchor. > >1) Do people agree? Yes >2) If so, where on earth should we specify this? (A Best Practice doc on >PKIX/DANE?) Already covered in

Re: [Standards] Proposed XMPP Extension: PubSub Namespaces

On Tue, Jan 04, 2022 at 05:55:01PM -, 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 the type of payload. URL:

Re: [Standards] LAST CALL: XEP-0425 (Message Moderation)

On Tue, Dec 07, 2021 at 03:51:27PM -, Jonas Schäfer wrote: This message constitutes notice of a Last Call for comments on XEP-0425. Title: Message Moderation Abstract: This specification defines a method for groupchat moderators to moderate messages. URL:

Re: [Standards] UPDATED: XEP-0459 (XMPP Compliance Suites 2022)

On Tue, Nov 02, 2021 at 08:35:11PM -, Jonas Schäfer wrote: Version 0.2.0 of XEP-0459 (XMPP Compliance Suites 2022) has been released. Abstract: This document defines XMPP application categories for different use cases (Core, Web, IM, and Mobile), and specifies the required XEPs that client

Re: [Standards] LAST CALL: XEP-0459 (XMPP Compliance Suites 2022)

On Mon, Sep 27, 2021 at 10:37:37AM +0100, Dave Cridland wrote: On Tue, 21 Sept 2021 at 16:46, Matthew Wild wrote: On Tue, 21 Sept 2021 at 15:24, Tedd Sterr wrote: 4. The original version (XEP-0242/0243) had two simple categories, Core and Advanced, and that was all; later versions just

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

Hi, On Thu, Sep 09, 2021 at 04:29:37PM +0100, Kevin Smith wrote: To summarise what I’ve said before: MUC in MAM kinda sucks, but groupchat doesn’t (necessarily) mean MUC. Sometimes people want groupchat messages in their archive because they want their archive to represent all those messages

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

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 war with STARTTLS? -- Zash signature.asc Description: PGP signature

Re: [Standards] XEP-0227 update

On Wed, Jul 14, 2021 at 02:13:19PM +0100, Matthew Wild wrote: On Wed, 14 Jul 2021 at 12:12, Matthew Wild wrote: I think your point and Kev's are somewhat related. The current proposal does not allow for preservation of explicit subscriptions or affiliations. I think today's reality is that

Re: [Standards] XEP-0227 update

Hi, On Wed, Jun 02, 2021 at 04:59:40PM +0100, Matthew Wild wrote: I've prepared an update that adds some of the missing features: - PEP nodes (configuration and items) What about explicit subscriptions and affiliations relevant? While not strictly required for basic PEP, there are

Re: [Standards] Un-deferring XEP-0377: Spam Reporting

Hi Sam, On Sat Jun 19, 2021 at 9:34 AM CEST, Sam Whited wrote: > Can we undefer XEP-0377: Spam Reporting? I don't have any changes that > need to be made to it, but it's also in use and not abandoned. I remember there being a discussion about changes that should be done to it. Detaching it from

Re: [Standards] XEP Advancement Shortlist

Hello all! On Tue, Jun 01, 2021 at 09:21:06PM +0200, Jonas Schäfer wrote: Those can be XEPs which you think deserve some discussion before moving forward and where this would be a good time to discuss them, or those where you think that everything has been said and they should graduate to their

Re: [Standards] XMPP Council Agenda 2021-06-16

On Wed Jun 16, 2021 at 2:05 PM CEST, Sam Whited wrote: > Please consider obsoleting the 2020 compliance suites to the agenda. It > looks pretty bad having multiple draft compliance suites: > > https://xmpp.org/extensions/xep-0423.html Given that it has been over 6 months since

Re: [Standards] UPDATED: XEP-0060 (Publish-Subscribe)

On Tue, Jun 08, 2021 at 07:13:32PM -, Jonas Schäfer wrote: Version 1.20.0 of XEP-0060 (Publish-Subscribe) has been released. Changelog: Add integer-or-max datatype to use with Data Forms Validation. (pep) https://xmpp.org/extensions/xep-0122.html#usecases-datatypes states that data types

Re: [Standards] [Council] XMPP Council Agenda 2021-06-09

On Tue, Jun 08, 2021 at 09:12:59PM +0200, Jonas Schäfer wrote: 4b) XEP-0045 - Fix typo missed in rev. 1.25 URL: https://github.com/xsf/xeps/pull/1062 https://github.com/xsf/xeps/pull/1062#discussion_r643484629 suggests they were going to change this PR, is it really ready for a council vote?

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

On Wed, Mar 24, 2021 at 04:02:09PM -, Jonas Schäfer wrote: 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 interested

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

On Tue, Mar 16, 2021 at 08:20:06PM -, Jonas Schäfer wrote: This message constitutes notice of a Last Call for comments on XEP-0313. Title: Message Archive Management Abstract: This document defines a protocol to query and control an archive of messages stored on a server. URL:

Re: [Standards] Slummit 2021 - Tales

On Fri, Jan 29, 2021 at 03:09:18PM +, Tedd Sterr wrote: Post your tales of projects, developments, and other fascinating XMPP-related stories in this thread to keep them all in one place. I spent most of 2020 in some internship-ish thing at a stereotypical ENTERPRISE. This mostly consisted

Re: [Standards] Council Minutes 2021-01-13

overviews of things. 4b) Proposed XMPP Extension: OMEMO Media Sharing - https://xmpp.org/extensions/inbox/omemo-media-sharing.html Zash: [on-list] +1 4) Proposed XMPP Extension: Service Outage Status - https://xmpp.org/extensions/inbox/service-outage-status.html Zash: [on-list] +1 -- Kim

Re: [Standards] Council Minutes 2021-01-06

On Tue, Jan 12, 2021 at 03:01:04PM +, Tedd Sterr wrote: 4a) Proposed XMPP Extension: MUC Mention Notifications - https://xmpp.org/extensions/inbox/muc-mention-notifications.html Zash: [on-list] +1 -- Kim "Zash" Alvefur signature.asc Description: PGP signature

Re: [Standards] Council Minutes 2020-12-09

On Tue, Dec 22, 2020 at 03:17:04PM +, Sam Whited wrote: I'm not actually sure what this means, do you have more specific feedback about the XEP that I can fix? Thanks! Mostly that I had trouble understanding who was sending what in the various examples. I'm sure this can be fixed during

Re: [Standards] Council Minutes 2020-12-09

On Thu, Dec 10, 2020 at 09:18:35PM +, Tedd Sterr wrote: https://logs.xmpp.org/council/2020-12-09?p=h#2020-12-09-b1b9c3afef6268d5 4) Proposed XMPP Extension: Stanza Multiplexing - https://xmpp.org/extensions/inbox/mux.html Zash: [on-list] +1 With the number of entities that can be

Re: [Standards] Council Minutes 2020-12-02

On Sat Dec 5, 2020 at 11:26 PM CET, Tedd Sterr wrote: > 4a) PR #1014 (XEP-0176: Improve compatibility with WebRTC clients) - > https://github.com/xsf/xeps/pull/1014 +1 > 4d) Proposed XMPP Extension: Automatic Trust Management - > https://xmpp.org/extensions/inbox/automatic-trust-management.html

Re: [Standards] Council Minutes 2020-11-04

On Wed, Nov 11, 2020 at 02:42:25AM +, Tedd Sterr wrote: https://logs.xmpp.org/council/2020-11-04?p=h#2020-11-04-51d2be3786d1879f 4b) Proposed XMPP Extension: Pre-Authenticated In-Band Registration - https://xmpp.org/extensions/inbox/ibr-token.html Georg: +1 Daniel: [on-list] Jonas:

Re: [Standards] XEP-0060: max #max_items

On Wed, Sep 30, 2020 at 11:53:02AM +, Daniel Gultsch wrote: However maybe we can also define this in 0122 instead? This would allow other XEPs to reuse this as well. I think this could be interesting for MUC (max number of participants) or some ad hoc commands scenarios as well. Ideally it

Re: [Standards] [Council] XMPP Council Agenda 2020-08-19

Hi, Votes: On Wed, Aug 19, 2020 at 08:30:32AM +0200, Jonas Schäfer wrote: > 4) Items for voting > > 4a) Proposed XMPP Extension: Message Archive Management Preferences > URL: https://xmpp.org/extensions/inbox/xep-mam-prefs.html > Abstract: This document defines a protocol to control a user's

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

On Tue, Aug 04, 2020 at 04:05:22PM -, XEP Editor Pipeline 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] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails

Hello list On Tue, Jun 30, 2020 at 05:59:34PM +0200, Jonas Schäfer wrote: > https://github.com/xsf/xeps/pull/963 > > Input from server operators specifically would be welcomed to see if > this change is in fact desirable or if you can see any issues with > that. At least one member of the

Re: [Standards] Council Minutes 2020-06-10

On Tue, Jun 16, 2020 at 01:25:41PM +, Tedd Sterr wrote: > 4b) PR #598 (XEP-0050: Try to clarify usage of 'execute') - > https://github.com/xsf/xeps/pull/598 > > Zash: [on-list] +1 -- Zash signature.asc Description: PGP signature ___ Standards

Re: [Standards] Evaluating gitlab.com as new location for XEP Editor repositories (xeps+registar)

On Sun Jun 14, 2020 at 6:31 PM CEST, Jonas Schäfer wrote: > Dear community members, > > TL;DR: Due to considerable technical advantages, the Editor team is > considering moving the repositories currently hosted at > github.com/xsf/xeps adn gitlab.com/xsf/registrar to gitlab.com/xsf. > This will

[Standards] XEP-0389: What username did I register?

Hi, I would wish that at the end of registration, the server could tell the client what JID and/or SASL username they registered. I can imagine that there may be flows where your username/JID is decided by the server. Examples: - Corporate onboarding might want to enforce some username policy

Re: [Standards] Council Minutes 2020-05-13

On Thu May 14, 2020 at 8:56 PM CEST, Tedd Sterr wrote: > 4) PR #943 - XEP-0068: Clarify FORM_TYPE field type on 'submit' type > forms = > - https://github.com/xsf/xeps/pull/943 > Jonas notes this is re-do of PR #913 after it was vetoed by Dave [1]. > Jonas suggests the following addition - '=85as

Re: [Standards] Sprint for Message Routing

On Sat, May 09, 2020 at 06:35:30PM +0200, Jonas Schäfer wrote: > Please reply to this message on-list or privately to me if you are > interested in participating within a week. I'm interested. -- Zash signature.asc Description: PGP signature ___

Re: [Standards] Proposed XMPP Extension: Channel Binding Pseudomechanisms

On Wed May 6, 2020 at 8:19 PM CEST, Sam Whited wrote: > On Wed, May 6, 2020, at 18:03, Dave Cridland wrote: > > The TL;DR is "horrible syntax, but really useful idea". … So, I would > > love to see this problem tackled properly, but without a syntax that > > involves me wanting to stab myself in

Re: [Standards] Council Minutes 2020-04-15

On Wed, Apr 22, 2020 at 02:45:59PM +, Tedd Sterr wrote: > https://logs.xmpp.org/council/2020-04-15?p=h#2020-04-15-515165c7293c9539 > > 1) Roll Call > Present: Daniel, Jonas, Zash, Georg > Apologies: Dave > > 2) Agenda Bashing > No additions. > > 3) Editor's Report > * Expired calls: None >

Re: [Standards] Council Minutes 2020-04-15

On Thu, Apr 23, 2020 at 10:16:41AM +0100, Dave Cridland wrote: > * The XML namespace is not under XSF control. > > Of these, the last is blocking for me; we have run into problems when > non-XSF namespaces have been baked into XEPs before, and I'd rather not > repeat that. Should be trivial to

Re: [Standards] XEP-0215: External Service Discovery

On Sat, Apr 11, 2020 at 08:24:12PM +0200, Philipp Hancke wrote: > I think that was intended for the XMPP variant of > https://tools.ietf.org/html/draft-uberti-behave-turn-rest-00 > but I don't think that variant was ever implemented. Isn't that what https://modules.prosody.im/mod_turncredentials

[Standards] [XEP-0114 / XEP-0225] What error to use when component unavailable?

Hi, Some time ago I tried to join an IRC channel via a gateway, but the client said that the room had too many users in it. Confused, I dug into logs to see what was going on and it turned out that the gateway was down and the XMPP server bounced any stanza sent to it with an error of type=wait,

Re: [Standards] Council Minutes 2020-02-26

On Sun, Mar 01, 2020 at 01:12:18AM +, Tedd Sterr wrote: > 4b) Advance XEP-0198 (Stream Management) - > https://xmpp.org/extensions/xep-0198.html > Georg is unsure, but it's doing its job, expect for the unclear resume host > connection mechanism. > Dave noted a comment on s2s, possibly from

Re: [Standards] LAST CALL: XEP-0398 (User Avatar to vCard-Based Avatars Conversion)

On Tue, Feb 25, 2020 at 05:14:57PM +0100, Jonas Schäfer wrote: > > 4. Do you have any security concerns related to this specification? > > There is the obvious issue that the vCard is world-readable, which has > in the past caused surprise with XMPP users from the instant messaging > world.

Re: [Standards] LAST CALL: XEP-0398 (User Avatar to vCard-Based Avatars Conversion)

On Wed, Feb 12, 2020 at 04:22:49PM -, Jonas Schäfer wrote: > This message constitutes notice of a Last Call for comments on > XEP-0398. > > Title: User Avatar to vCard-Based Avatars Conversion > Abstract: > This specification describes a method for using PEP based avatars and > vCard based

Re: [Standards] Council Minutes 2020-01-22

Hi! Thanks for the minutes! Votes: On Tue Jan 28, 2020 at 6:01 PM, Tedd Sterr wrote: > 3a) Proposed XMPP Extension: Full Text Search in MAM - > https://xmpp.org/extensions/inbox/fulltext.html > Georg: [on-list] > Jonas: +1 (dead simple; I like it) > Zash: [on-list] > Dave: +1 (will almost

Re: [Standards] Council Minutes 2020-01-02

On Tue, Jan 07, 2020 at 04:04:56PM +, Tedd Sterr wrote: > 3c) Proposed XMPP Extension: Fallback Indication - > https://xmpp.org/extensions/inbox/fallback.html > Zash: [on-list] +1 From a server perspective, it's unclear to me if this really adds anything. Many messages that have a fallback

Re: [Standards] Council Voting Summary 2019-10-22

On Tue Dec 10, 2019 at 12:05 PM, Kevin Smith wrote: > On 30 Oct 2019, at 23:26, Kim Alvefur wrote: > > Does this wording look sane? > > > > https://github.com/xsf/xeps/pull/848/commits/21128e508c76bfe5e0f50b490d9f4849472a2955 > > > It does to me, at first glance. I

Re: [Standards] Council Voting Summary 2019-10-22

On Wed, Oct 30, 2019 at 10:52:35PM +, Kevin Smith wrote: > On 23 Oct 2019, at 15:25, Tedd Sterr wrote: > > Advance to Draft: XEP-0292 (vCard4 Over XMPP) - > > https://xmpp.org/extensions/xep-0292.html > > Dave: [pending] > > Georg: [on-list] > > Jonas: [on-list] > > Kev: [on-list] (feels

Re: [Standards] Support for stickers (custom emojis)

On Thu, Oct 24, 2019 at 08:32:04PM +0200, Marvin W wrote: > Thus, I would vote for using codepoints. I agree. > The rule should just be that clients should not do that on outgoing > data. I agree with this as well. > We should refrain from using things like grapheme clusters in wire formats, >

Re: [Standards] Support for stickers (custom emojis)

On Thu, Oct 17, 2019 at 04:17:23PM +0100, Matthew Wild wrote: > On Thu, 17 Oct 2019 at 13:34, JC Brand wrote: > > "some other entity" isn't terribly well defined. How do I (or the > > recipient of my stickers) know what other entity to ask? > > It's part of the identifier, e.g. >

Re: [Standards] XEP-0084: User Avatar - Invalid example?

> On 31.08.19 15:30, Paul Schaub wrote: > Hello everyone! > > XEP-0084 Example 4 shows a Metadata publication which does contain a > single info element which has type image/gif. However section §4.2.1 > states in the last paragraph: > >> The root element MAY contain more than one > element.

[Standards] XEP-0122: Data Forms Validation "x:" prefix

XEP-0122: Data Forms Validation states > The 'datatype' attribute specifies the datatype. This attribute is > OPTIONAL, and defaults to "xs:string". It MUST meet one of the > following conditions: (some others) > - Start with "x:", and specify a user-defined datatype. > > Note that while "x:"

Re: [Standards] XEP-0368: What does a . for a target mean?in?_xmpps-client/server records?

On Sun, Jun 30, 2019 at 06:23:36PM +, Sam Whited wrote: > On Sun, Jun 30, 2019, at 18:15, Kim Alvefur wrote: > > Please don't. While detecting use of TLS or plain is fairly simple it > > is more complicated to handle both on the same port. I don't know any > > sock

Re: [Standards] XEP-0368: What does a . for a target mean?in?_xmpps-client/server records?

On Sun, Jun 30, 2019 at 04:55:47PM +, Sam Whited wrote: > On Sun, Jun 30, 2019, at 16:32, Ralph Meijer wrote: > > Do you know which server implementations currently support both TLS > > and non-TLS (with STARTLS) on the same port? > > I'm sure if any of them do, but the fallback would still

Re: [Standards] XEP-0191 leads to stale presence?

Hi, Also consider clients that do not understand XEP-0191, for which it would be even more confusing, as they would not have any way to know that the presence they've seen is stale. (Clients that implement '191 can know via blocklist push.) Having server generate unavailable presence when

[Standards] XEP-0191 leads to stale presence?

Hi, While working on a fix for Prosodys XEP-0191 implementation¹ regarding presence sent to a blocked JID to pretend that the blocking user is offline, and then re-send presence again if they unblock. However, since if you block someone, your view of their presence will become stale. The XEP

Re: [Standards] Stanza Content Encryption

On Tue, Jun 18, 2019 at 11:03:51AM +0200, Philipp Hörist wrote: > Feature negotiation in encryption process is a fail in General. Feature negotiation doesn't work becasue since the introduction of Carbons and MAM you no longer have any idea which clients will receive anything you sendwhich will

Re: [Standards] Solving the not staying connected in a MUC problem

Hello, On Tue, Jun 18, 2019 at 11:47:10AM +, Daniel Gultsch wrote: > There are a few reasons why a participant might get (knowingly or not) > be kicked out of a MUC. While it might be tempting to find a solution > that works for every scenario I suggest we look into the different > So

Re: [Standards] LAST CALL: XEP-0292 (vCard4 Over XMPP)

On Mon, Feb 04, 2019 at 07:17:22PM -, Jonas Schäfer wrote: > This message constitutes notice of a Last Call for comments on > XEP-0292. > > Title: vCard4 Over XMPP > Abstract: > This document specifies an XMPP extension for use of the vCard4 XML > format in XMPP systems, with the intent of

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

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 identifiers. > > Maybe i dont understand why this was written

[Standards] XEP-0292: vCard4 - advance?

Hi, I would like to see XEP-0292: vCard4 Over XMPP advanced. Since popularity and deployment of XEP-0084 appears to be on the rise, much thanks to XEP-0398, now seems like a good time to dust it off and finish it. One benefit over vcard-temp is improved and configurabel access control, if

Re: [Standards] LAST CALL: XEP-0410 (MUC Self-Ping (Schrödinger's Chat))

On Tue, Jan 08, 2019 at 04:54:22PM -, Jonas Schäfer wrote: > This message constitutes notice of a Last Call for comments on > XEP-0410. > > Title: MUC Self-Ping (Schrödinger's Chat) > Abstract: > This protocol extension for XEP-0045 Multi User Chat allows clients to > check whether they are

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

ion open source)? MIT, like Prosody, so yes. It works so well that I've had no reason to look at it for half a decade. IIRC there were interop issues with M-Link, which was solved by a blacklist and forgetting all about it. I would be positive to moving it forward. -- Regards, Kim Alvefur

Re: [Standards] Proposed XMPP Extension: Simple Buttons

On Sat, Dec 08, 2018 at 10:28:41PM +, Tedd Sterr wrote: > A few thoughts (some of which have already been touched on by others)… > > * clicking a button results in a textual message that provides no indication > that it came from a button press as opposed to being typed (I could type >

Re: [Standards] Proposed XMPP Extension: Simple Buttons

On Thu, Dec 6, 2018, 20:54 Dave Cridland wrote: > Looks like a problem worth solving, but note below. > > I'd prefer - non blockingly - the following: > > * A click element. I feel that having an id and a click is superior given > the ambiguity of a text string. An earlier draft had a element,

Re: [Standards] XMPP Council Minutes 2018-10-03

On Fri, Oct 5, 2018 at 10:10 PM, Tedd Sterr wrote: Zash thinks there are 3 client BM2 implementations. I meant PEP-Bookmarks actually. Sorry if I was unclear. -- Kim "Zash" Alvefur ___ Standards mailing list Info:

Re: [Standards] Generalisation of XEP-xxxx: MUC Avatars

Hi, On Tue, Sep 25, 2018 at 07:49:24PM +0200, Timothée Jaussoin wrote: > What I'd like to propose is to generalize this XEP I am opposed to entrenching vcard-temp more. This MUC avatar XEP is as I understand it meant to define a slightly less breaking way to do something that was already

Re: [Standards] XEP-0045: How to signal tombstones for destroyed rooms?

On Wed, Jul 11, 2018 at 07:52:55AM +0200, Jonas Wielicki wrote: > Is there a reason to not use a presence type="error"? I’d expect clients to > handle those already. Mostly becasue I simply copied code from the room destruction handler. > I’d use a type error, which encodes the semantics

[Standards] XEP-0045: How to signal tombstones for destroyed rooms?

Hello list, I have implemented tombstones for destroyed MUC rooms. My reading of the sacred texts did not give me enlightenment as how to inform someone who's attempting to enter the remains of such a place. I've so far opted to return an with the same child that was in the inital announcement

Re: [Standards] XMPP Council Minutes 2018-06-20

On Sat, Jun 23, 2018 at 11:28:54AM +, Tedd Sterr wrote: > On Stream Compression: as TLS is pretty much a requirement now and it > already does compression (unless explicitly disabled), wouldn't that > make Stream Compression surplus to requirements at this point? It is explicitly disabled and

[Standards] XEP-0191: Blocking of subscription request denials

Hey, After implementing XEP-0191: Blocking Command, an issue was raised about how, if you blocked someone after they sent you a subscription request, you were unable to deny that subscription request. The XEP does not have much to say about this, apart from this paragraph: > If the user

Re: [Standards] Call for Experience: XEP-0048: Bookmarks

On Wed, Mar 07, 2018 at 07:17:24PM -, Jonas Wielicki wrote: > The XEP Editor would like to Call for Experience with XEP-0048 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] [XEP-0264] thumbnails: we should be able to transmit them with XEP-0234

On Sat, Feb 24, 2018 at 09:12:30AM +0100, Goffi wrote: > currently thumbnails are transmitted using http(s) or BoB (XEP-0231). > But with resolutions we can have todays even on small screens, size of > images is growing. Transmitting them using BoB can block the > connection and is a useless waste

Re: [Standards] XEP-0313: Treatment of type=groupchat in user archive with or without hint

On Thu, Nov 23, 2017 at 06:11:32PM +0100, Daniel Gultsch wrote: > ignoring the »A server SHOULD also include messages of type > 'groupchat' that have a \« statement from the XEP.) I must have either overlooked that text or forgotten about it. > For me it doesn't ever make sense to store

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

On Mon, Oct 16, 2017 at 06:38:45PM -, Jonas Wielicki 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

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

On Thu, Nov 09, 2017 at 10:26:37PM -0800, Arc Riley wrote: > However, XEP-0114 does not cover the ability to have an external > process add support for a new XEP. [...], but AFAIK that protocol > has never been documented in a XEP - certainly not this one. But perhaps this one?

Re: [Standards] Time-bound unsubscription from presence info of particular users

Hi! (shortened) On Fri, Oct 20, 2017 at 04:01:31PM +0530, vaibhav singh wrote: > a person who was logging in and out of IM frequently. One possible way to mitigate this would be to collapse such events and only show the last one. Swift does a good job of this in MUCs. The Prosody community

[Standards] PubSub publish-options in various XEPs

Hey. So a bunch of XEPs are using publish-options. Listed the ones a simple grep caught below. I believe that our current interpretation of these is that they must be registered, while from the looks of the XEPs listed, the previous interpretation seems to be that it is essentially node creation

Re: [Standards] XEP-0045 MUC: am I still there?

On Thu, Oct 05, 2017 at 12:20:12PM +0100, Kevin Smith wrote: > > > On 5 Oct 2017, at 11:39, Jonas Wielicki wrote: > > > > On Mittwoch, 4. Oktober 2017 21:19:33 CEST Kevin Smith wrote: > I think > that “presence things with magic side effects” is one of the

Re: [Standards] XEP-0199: XMPP Ping - question on ping timeout

On Tue, Oct 03, 2017 at 09:53:06AM -0500, Sam Whited wrote: > I suspect it would be easier to only send a ping if you haven't heard > anything from the client in some configurable amount of time This is in line with what XMPP Core says here: https://xmpp.org/rfcs/rfc6120.html#streams-silence --

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

Hi, On Mon, Sep 11, 2017 at 12:32:09PM -0500, Sam Whited wrote: > On Mon, Sep 11, 2017, at 12:13, Jonas Wielicki wrote: > > XEP-0377 (Spam Reporting) has been Deferred because of inactivity. > > Hi all. Spam reporting was just (correctly) deferred. Several servers > have implemented it, but only

Re: [Standards] Proposed XMPP Extension: Jingle Encrypted Transports

> On Sep 1, 2017 10:55, "Florian Schmaus" wrote: > > I don't think that this is necessarily always true. And I always find it > > strange to find unimplementable XEPs in experimental (IIRC PAM and FMUC > > where or are still examples). > > > > That's why I've been advocating

Re: [Standards] XEP-0163: depend on persistent-items, node-config and publish-options

On Mon, Aug 28, 2017 at 12:03:37PM +0200, Daniel Gultsch wrote: > Now that the PR regarding publish-options has been merged into > XEP-0060 I want to bump this thread and ask if anyone objects to that > proposal (making persistent-items, node-config and publish-options > mandatory). Otherwise I

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

On Wed, Feb 08, 2017 at 10:50:03PM +, 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). > > Abstract: This specification defines the Kerberos principal name of an > XMPP server. It also

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

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:

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

Hi, On Tue, Feb 21, 2017 at 09:35:51PM +0100, Ruslan N. Marchenko wrote: > 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. == id='1'/>. No, the current account is

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

On Sat, Jan 28, 2017 at 05:26:00PM +, XMPP Extensions Editor wrote: > This message constitutes notice of a Last Call for comments on > XEP-0368 (SRV records for XMPP over TLS). > > Abstract: This specification defines a procedure to look up > xmpps-client/xmpps-server SRV records (for TLS

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

On Tue, Feb 07, 2017 at 10:35:50AM -0600, Sam Whited wrote: > On Tue, Feb 7, 2017 at 7:20 AM, Matthew Wild wrote: > > Session state pertains to a user's account: > > > > - Roster > > - Privacy/block lists > > - Private XML > > - PEP > > - ... > > I think the roster

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

On Mon, Feb 06, 2017 at 12:16:31PM +0300, Evgeny Khramtsov wrote: > Mon, 6 Feb 2017 03:14:54 -0600 > Sam Whited wrote: > > > Not at all; the nonzas are semantically correct here because it > > doesn't make sense to have the CSI enable/disable "commands" be > > routable. > >

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

On Sun, Feb 05, 2017 at 08:53:31PM +0100, Florian Schmaus wrote: > On 05.02.2017 20:19, Georg Lukas wrote: > > * Florian Schmaus [2017-02-05 19:41]: > >> I've just submitted https://github.com/xsf/xeps/pull/402 > > > > I really really don't understand why 0198 should change

Re: [Standards] Proposed XMPP Extension: Bind 2.0

On Wed, Jan 25, 2017 at 10:32:41AM +, Kevin Smith wrote: > On 23 Jan 2017, at 15:38, Georg Lukas wrote: > > 3. Server performs magic: > > > > - if the SM session is valid, perform a SM resume, otherwise: > > That seems like it might be interesting. > > > - kill the old

Re: [Standards] Advance XEP-0368 to Proposed

On Thu, Jan 19, 2017 at 03:19:12PM -0500, Travis Burtrum wrote: > I am proposing advancing XEP-0368 from Experimental to Proposed, and the > XSF MUC said to do this by sending an email to the standards list. > > https://xmpp.org/extensions/xep-0368.html > Any thoughts? > TLS provides more

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

On Sun, Jan 15, 2017 at 11:35:58AM -, Steve Kille wrote: > A setting for most users (default) where 1:1 messages from JIDs not in > the roster are rejected seems good to me. Possibly allow users to > change this. This is what I meant. Emphasis on *a setting*, that users could toggle, similar

Re: [Standards] XMPP Registrar: Registration policy

On Mon, Jan 02, 2017 at 11:24:21AM -0700, Peter Saint-Andre wrote: > In the past, we have added things like service discovery identities without > updating a spec: Perhaps a good start would be to document the current way of things? Then, whatever happens, new editors would have something

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

On Thu, Dec 29, 2016 at 11:32:18PM +0100, Tobias Markmann wrote: > Conclusions from the talk and possible actions to address them are: > > * The XMPP manifesto from 2014 was a nice start and had very visible and > noticeable effects, >95% of public XMPP services require TLS for C2S > connections.

[Standards] Punycode in stream 'to' attr

Hi list! An issue was filed against Prosody¹ for not converting punycode in stream headers to Unicode. Now I'm wondering if this is really something the server is expected to do. RFC7622 § 3.2.1.² states as following: > An entity that prepares a string for inclusion in an XMPP domainpart >

Re: [Standards] "Self-destruct" message timeout deletion hints

On 2016-10-19 08:51, Daniel Gultsch wrote: > In that regard we might as well standardize it even > though it will probably be only implemented in closed systems were you > can be relatively certain that messages will in fact be deleted. The question becomes why should we standardize something

Re: [Standards] Proposed XMPP Extension: Explicit Message Encryption

On 2016-08-18 13:09, Emmanuel Gil Peyrot wrote: > On that basis, maybe I could make @name optional, as in “MAY NOT be > included for those three XEPs already listed”, “SHOULD for any > mechanism not listed here”, and “SHOULD be ignored on a received > message if you already have a correct name for

Re: [Standards] Extending MAM results with results from a transport component

On 2016-07-06 20:42, Ivan Vučica wrote: > - Option 4: Hack clients to discover and use mod_mam on individual > full-JIDs. Hack the component to advertise MAM on individual full -JIDs. > - Additional cap can be advertised by full-JIDs. (No matter if it's > from a component or not.) > - Same

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

On 2015-08-13 22:18, XMPP Extensions Editor wrote: > This message constitutes notice of a Last Call for comments on XEP-0280 > (Message Carbons). Friendly inquiry regarding the status of this LC. -- Kim "Zash" Alvefur signature.asc Description: OpenPGP digital signature

  1   2   >