On 27 Aug 2024, at 09:26, Dave Cridland wrote:
> Otherwise, setting autojoin to false is the same as a retraction, which seems
> to me like the autojoin flag is entirely redundant, and should simply be
> removed.
I’m not sure that’s true, as in that scenario a bookmark without an autojoin
can
> On 26 Aug 2024, at 21:27, Stephen Paul Weber
> wrote:
>
>> That sounds awfully like a MAY. SHOULD is "MUST unless you know what you're
>> doing, and you probably don't".
>
> Sure. I'd rather it be non-normative, or even omitted, but that's not a
> change we can make at this stage I think.
On 8 May 2024, at 10:20, Daniel Gultsch wrote:
>
> This message constitutes notice of a Last Call for comments on
> XEP-0421.
>
> Title: Anonymous unique occupant identifiers for MUCs
> Abstract:
> This specification defines a method that allows clients to identify a
> MUC participant across rec
I agree that a note would be helpful, but we're only noting that bugged
implementations exist, I don't think that even adding a SHOULD here
falls within the spirit of the Final requirements. So I think the right
thing to do is to add a note saying such bugs exist, but not change
normative langu
-- Original Message --
From "Jonas Schäfer"
To standards@xmpp.org
Date 10/03/2024 16:27:07
Subject [Standards] Remove requirement to send disco#info feature in
XEP-0030
Dear community,
it's been a while I spoke up here.
I would like to discuss the removal of the following part-se
-- Original Message --
From "Daniel Gultsch"
To standards@xmpp.org
Date 11/03/2024 09:14:36
Subject [Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))
On Sun, Mar 10, 2024 at 4:18 PM Daniel Gultsch wrote:
This message constitutes notice of a Last Call for comments on
XE
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: PubSub Server Information
Abstract:
This document defines a data format whereby basic information of an
XMPP domain can be expressed and exposed over pub-sub.
URL: https://xmpp.org/extensions/inbox/pubsub-server-info.html
T
Version 0.2.0 of XEP-0483 (HTTP Online Meetings) has been released.
Abstract:
This specification defines a protocol extension to request URLs from
an external HTTP entity usable to initiate and invite participants to
an online meeting.
Changelog:
* Use XEP-0482 to send the meeting link to another
Version 1.0.0 of XEP-0458 (Community Code of Conduct) has been
released.
Abstract:
This document describes the XMPP Standard Foundation's Code of
Conduct.
Changelog:
Changed status to Active per Board vote on 2024-01-05. (psa)
URL: https://xmpp.org/extensions/xep-0458.html
Note: The information
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Host Meta 2 - One Method To Rule Them All
Abstract:
This document defines an XMPP Extension Protocol for extending
XEP-0156 by modifying the JSON Web Host Metadata Link format to
support discovering all possible XMPP connecti
Version 0.1.0 of XEP-0484 (Fast Authentication Streamlining Tokens)
has been released.
Abstract:
This specification defines a token-based method to streamline
authentication in XMPP, allowing fully authenticated stream
establishment within a single round-trip.
Changelog:
* Promoted to Experimenta
Version 0.1.0 of XEP-0483 (HTTP Online Meetings) has been released.
Abstract:
This specification defines a protocol extension to request URLs from
an external HTTP entity usable to initiate and invite participants to
an online meeting.
Changelog:
* Promoted to Experimental. (XEP Editor: kis)
URL
Version 0.3.0 of XEP-0474 (SASL SCRAM Downgrade Protection) has been
released.
Abstract:
This specification provides a way to secure the SASL and SASL2
handshakes against method and channel-binding downgrades.
Changelog:
* Rework all explanations explaining why this specification is needed
* Simp
Version 0.4.0 of XEP-0458 (Community Code of Conduct) has been
released.
Abstract:
This document describes the XMPP Standard Foundation's Code of
Conduct.
Changelog:
Address Last Call feedback; complete a copy edit and apply
clarifications in several places. (psa)
URL: https://xmpp.org/extension
Version 1.1.4 of XEP-0402 (PEP Native Bookmarks) has been released.
Abstract:
This specification defines a syntax and storage profile for keeping a
list of chatroom bookmarks on the server.
Changelog:
Recommend setting pubsub#max_items to 'max' instead of some arbitrary
large number (egp)
URL: h
Version 1.6.1 of XEP-0198 (Stream Management) has been released.
Abstract:
This specification defines an XMPP protocol extension for active
management of an XML stream between two XMPP entities, including
features for stanza acknowledgements and stream resumption.
Changelog:
Clarify SASL2 and BIN
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: HTTP Online Meetings
Abstract:
This specification defines a protocol extension to request URLs from
an external HTTP entity usable to initiate and invite participants to
an online meeting.
URL: https://xmpp.org/extensions/in
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Communicate & Ask to AI
Abstract:
This document defines a protocol for asking questions to an artificial
intelligence or requesting it to make predictions.
URL: https://xmpp.org/extensions/inbox/xep-ai.html
The Council will
Version 0.3 of XEP-0458 (Community Code of Conduct) has been released.
Abstract:
This document describes the XMPP Standard Foundation's Code of Conduct
Changelog:
Address substantive feedback from JC Brand; add Peter Saint-Andre as
co-author to help address future feedback. (psa)
URL: https://xm
Version 0.4.0 of XEP-0424 (Message Retraction) has been released.
Abstract:
This specification defines a method for indicating that a message
should be retracted.
Changelog:
* Remove the dependency on XEP-0422 Message Fastening.
* Use 'id' attribute on 'retracted' element instead of a child
eleme
Version 0.3.1 of XEP-0377 (Spam Reporting) has been released.
Abstract:
This document specifies a mechanism by which users can report spam and
other abuse to a server operator or other spam service.
Changelog:
Add XML Schema. (egp)
URL: https://xmpp.org/extensions/xep-0377.html
Note: The inform
Version 1.1.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 and server software needs to implement for compliance with
the use
Version 0.4.1 of XEP-0333 (Chat Markers) has been released.
Abstract:
This specification describes a solution of marking the last received,
displayed and acknowledged message in a chat.
Changelog:
Changed discovery example to use client JIDs. (gdk)
URL: https://xmpp.org/extensions/xep-0333.html
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: MUC Token Invite
Abstract:
This specification provides a way to generate tokens to invite users
to a MUC room.
URL: https://xmpp.org/extensions/inbox/muc-token-invite.html
The Council will decide in the next two weeks wheth
Version 0.2.1 of XEP-0458 (Community Code of Conduct) has been
released.
Abstract:
This document describes the XMPP Standard Foundation's Code of Conduct
Changelog:
Add anchors to every section, for easier linking. Also fix a typo.
(egp)
URL: https://xmpp.org/extensions/xep-0458.html
Note: The
-- Original Message --
From "Melvin Keskin"
To "XMPP Standards"
Date 04/07/2023 17:51:04
Subject [Standards] Re: UPDATED: XEP-0453 (DOAP usage in XMPP)
Hi,
Thanks for the update! Only the year is wrong. We are not yet in 2024
Thanks.
You wouldn't believe that I checked that before
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Reporting Account Affiliations
Abstract:
This specification documents a way for an XMPP server to report to
other entities the relationship it has with a user on its domain.
URL: https://xmpp.org/extensions/inbox/xep-reporti
Version 0.1.2 of XEP-0453 (DOAP usage in XMPP) has been released.
Abstract:
This specification defines how XMPP projects can provide a machine-
readable description of their abilities, and how external entities can
interact with it.
Changelog:
Fix XMLNS typo (spw)
URL: https://xmpp.org/extension
Version 0.2.0 of XEP-0317 (Hats) has been released.
Abstract:
This specification defines a more extensible model for roles and
affiliations in Multi-User Chat rooms.
Changelog:
Select a syntax for hats. (mw)
URL: https://xmpp.org/extensions/xep-0317.html
Note: The information in the XEP list at
-- Original Message --
From "Matthew Wild"
To "XMPP Standards"
Date 28/06/2023 12:26:02
Subject [Standards] Controlling XEP-0060 publish-options behaviour
Or, we can add a new element:
[form here]
WFM.
/K
___
Standards
-- Original Message --
From "Matthew Wild"
To "XMPP Standards"
Date 06/06/2023 13:40:29
Subject [Standards] Re: Wrapping up the XMPP Lemmy Experiment
Thanks Sam, for taking the lead on this initiative.
Yes, thanks for trying a thing.
/K
Version 0.1.0 of XEP-0479 (XMPP Compliance Suites 2023) 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 and server software needs to implement for compliance with
the use
Version 0.1.0 of XEP-0478 (Stream Limits Advertisement) has been
released.
Abstract:
This specification defines a way for an XMPP entity to announce the
limits it will enforce for data received on a stream.
Changelog:
Promote to Experimental. (XEP Editor: ks)
URL: https://xmpp.org/extensions/xep
Version 0.1.0 of XEP-0482 (Call Invites) has been released.
Abstract:
This document defines how to invite someone to a call and how to
respond to the invite.
Changelog:
Promoting to Experimental. (XEP Editor: ks)
URL: https://xmpp.org/extensions/xep-0482.html
Note: The information in the XEP li
Version 0.1.0 of XEP-0481 (Content Types in Messages) has been
released.
Abstract:
This specification describes a generic method whereby content in
messages can be tagged as having a specific Internet Content Type. It
also provides a method for sending the same content using different
content type
Version 0.1.0 of XEP-0480 (SASL Upgrade Tasks) has been released.
Abstract:
This specification provides a way to upgrade to newer SASL mechanisms
using SASL2 tasks.
Changelog:
Promote to Experimental. (XEP Editor: ks)
URL: https://xmpp.org/extensions/xep-0480.html
Note: The information in the X
Version 1.1.0 of XEP-0313 (Message Archive Management) has been
released.
Abstract:
This document defines a protocol to query and control an archive of
messages stored on a server.
Changelog:
* Clarify archive metadata response in the case of an empty archive.
* Clarify query response in the case
Version 1.1.1 of XEP-0223 (Persistent Storage of Private Data via
PubSub) has been released.
Abstract:
This specification defines best practices for using the XMPP publish-
subscribe extension to persistently store private information such as
bookmarks and client configuration options.
Changelog:
Version 1.25.0 of XEP-0060 (Publish-Subscribe) has been released.
Abstract:
This specification defines an XMPP protocol extension for generic
publish-subscribe functionality. The protocol enables XMPP entities to
create nodes (topics) at a pubsub service and publish information at
those nodes; an
Version 0.2.0 of XEP-0472 (Pubsub Social Feed) has been released.
Abstract:
This specification defines a way of publishing social content over
XMPP.
Changelog:
* Change the pubsub#type to be consistent with other XEPs
* Add a Discovery section (tj)
URL: https://xmpp.org/extensions/xep-0472.html
Version 0.4.1 of XEP-0356 (Privileged Entity) has been released.
Abstract:
This specification provides a way for XMPP entities to have a
privileged access to some other entities data
Changelog:
Fixed some typos (gh/@bodqhrohro)
URL: https://xmpp.org/extensions/xep-0356.html
Note: The informatio
Version 0.4.1 of XEP-0356 (Privileged Entity) has been released.
Abstract:
This specification provides a way for XMPP entities to have a
privileged access to some other entities data
Changelog:
Fixed some typos (gh/@bodqhrohro)
URL: https://xmpp.org/extensions/xep-0356.html
Note: The informatio
Version 0.2.0 of XEP-0428 (Fallback Indication) has been released.
Abstract:
This specification proposes a mechanism by which message bodies or
parts thereof can be marked as being for fallback purposes, and
therefore to be ignored by anything that understands the original
intent of the message.
Version 0.4.0 of XEP-0388 (Extensible SASL Profile) has been released.
Abstract:
This document describes a replacement for the SASL profile documented
in RFC 6120 which allows for greater extensibility.
Changelog:
* Bump namespace
* Add reference to and
* Update security considerations and busin
Version 0.4.0 of XEP-0386 (Bind 2) has been released.
Abstract:
This specification provides a single-request replacement for several
activities an XMPP client needs to do at startup.
Changelog:
Various changes, made in parallel with working client and server
implementation experience, and SASL2 u
Version 0.7.0 of XEP-0359 (Unique and Stable Stanza IDs) has been
released.
Abstract:
This specification describes unique and stable IDs for messages.
Changelog:
Add security consideration regarding spoofability and reference
example (fs)
URL: https://xmpp.org/extensions/xep-0359.html
Note: The
Version 0.12.0 of XEP-0292 (vCard4 Over XMPP) has been released.
Abstract:
This document specifies an XMPP extension for use of the vCard4 XML
format in XMPP systems, with the intent of obsoleting the vcard-temp
format.
Changelog:
Removes raw-IQ mode and specifies the reuse of PEP (spw)
URL: htt
-- Original Message --
From "Melvin Keskin"
To "XMPP Standards"
Date 26/01/2023 11:52:39
Subject Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites
2023
Hi,
I would like to propose the removal of "The /me Command" from the IM
Compliance Suite. In my opinion, it is neith
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: XMPP Compliance Suites 2023
Abstract:
This document defines XMPP application categories for different use
cases (Core, Web, IM, and Mobile), and specifies the required XEPs
that client and server software needs to implement f
Version 0.2.0 of XEP-0474 (SASL SCRAM Downgrade Protection) has been
released.
Abstract:
This specification provides a way to secure the SASL and SASL2
handshakes against method and channel-binding downgrades.
Changelog:
* Add description of attack model
* Add section defining IETF interaction (t
Version 0.2.0 of XEP-0461 (Message Replies) has been released.
Abstract:
This document defines a way to indicate that a message is a reply to a
previous message.
Changelog:
Fix example character counting. Add disco feature. Relax the 'to'
attribute constraints. (nc)
URL: https://xmpp.org/extensi
Version 0.1.1 of XEP-0444 (Message Reactions) has been released.
Abstract:
This specification defines a way for adding reactions to a message.
Changelog:
Add the XML Schema (egp)
URL: https://xmpp.org/extensions/xep-0444.html
Note: The information in the XEP list at https://xmpp.org/extensions/
Version 0.3.0 of XEP-0426 (Character counting in message bodies) has
been released.
Abstract:
This document describes how to correctly count characters in message
bodies. This is required when referencing a position in the body.
Changelog:
Added section about subsequences. (lmw)
URL: https://xmp
Version 0.5.0 of XEP-0353 (Jingle Message Initiation) has been
released.
Abstract:
This specification provides a way for the initiator of a Jingle
session to propose sending an invitation in an XMPP message stanza,
thus taking advantage of message delivery semantics instead of sending
IQ stanzas t
Natalie, Marvin,
https://github.com/xsf/xeps/pull/1261 has been submitted to add a schema
- are you ok with the change?
/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
-- Original Message --
From "Mathieu Pasquet"
To "Kevin Smith" ; "XMPP Standards"
Date 06/01/2023 15:44:50
Subject Re: [Standards] XEP-0444 update: restrict reactions
Hi,
On 06.01.2023 11:01, Kevin Smith wrote:
My earlier iteration of the PR did in
-- Original Message --
From "Nicolas Cedilnik"
To standards@xmpp.org
Date 06/01/2023 06:12:36
Subject Re: [Standards] XEP-0444 update: restrict reactions
Thanks for the feedback.
I suspect that in most instances, you're happy to accept any reactions, and
forcing a poll of available
-- Original Message --
From "Nicolas Cedilnik"
To standards@xmpp.org
Date 30/12/2022 13:25:25
Subject [Standards] XEP-0444 update: restrict reactions
Hello all,
About https://github.com/xsf/xeps/pull/1249
My main reason for submitting a patch to this XEP is that most other walled gard
-- Original Message --
From: "Matthew Wild"
To: "XMPP Standards"
Sent: 26/09/2022 18:24:37
Subject: [Standards] Channel binding and token authentication
Does anyone have objections to proceeding with the definition of one
or more HT-*-NONE mechanisms for token authentication?
Seems e
-- Original Message --
From: "Steve Kille"
To: "'XMPP Standards'"
Sent: 15/07/2022 09:16:58
Subject: Re: [Standards] MIX-PAM: Change of annotate setting with second
roster get
My preference for resolving the issue raised is that the client should
indicate its preference in ALL ros
-- Original Message --
From: "Matthew Wild"
To: "XMPP Standards"
Sent: 13/06/2022 15:03:38
Subject: Re: [Standards] Moving server-side MAM search forwards
On Mon, 13 Jun 2022 at 14:49, Dave Cridland wrote:
On Sun, 12 Jun 2022 at 18:02, Matthew Wild wrote:
What I'm trying to pr
Hi Matt,
-- Original Message --
From: "Matthew Wild"
To: "XMPP Standards"
Sent: 03/06/2022 10:50:03
Subject: [Standards] Moving server-side MAM search forwards
1) Add a "simple" search type, which is recommended to be
implemented as a baseline for interoperability. For simple search
On 2 Feb 2022, at 16:11, Daniel Gultsch wrote:
> 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 exact word
Bordering on off-topic, but:
-- Original Message --
From: "Florian Schmaus"
To: standards@xmpp.org
Sent: 19/01/2022 11:20:56
Subject: Re: [Standards] [XEP-0030] we can't get basic information on a
bare JID without presence subscription
On 19/01/2022 11.17, Daniel Gultsch wrote> Or in
On 15 Dec 2021, at 14:41, Dave Cridland wrote:
> So, summary: I'd replace the opening text to 8.2.4 with:
>
> "If the owner wishes to change the configuration, they submit a completed
> configuration form. The server MUST treat any fields not included as though
> they are supplied with the defa
On 30 Sep 2021, at 09:56, Dave Cridland wrote:
>
> All,
>
> Kev Smith noted that we have been a bit weird about handling updates to XEPs
> from authors during the Proposal phase (that is, Proposed state, from Last
> Call through to completion of a vote to Stable).
Ta.
> 1) When can authors u
On 29 Sep 2021, at 17:32, Georg Lukas wrote:
>
> Sorry this is so late, and thanks to Sonny for taking up the hard task
> of fighting this through the Council.
>
> * Jonas Schäfer [2021-09-07 16:04]:
>> This message constitutes notice of a Last Call for comments on
>> XEP-0459 [...] XMPP Compli
> On 9 Sep 2021, at 18:06, Florian Schmaus wrote:
>
> On 13/08/2021 14.00, JC Brand wrote:> from="sch...@springfield.city">
>> Attention Bart Simpson
>> Please hand in your homework before the end of the
>> day
>>
>>
>
> Why is there a number sign ('#') before the element name
On 13 Aug 2021, at 13:00, JC Brand wrote:
>
> Hi everyone
>
> In XEP-0372, when references are used for "mentions", there is an implicit
> assumption that the referenced text is in the tag.
>
> There are however other elements where mentions could also occur, such as
> , and , and some stan
09:00, Georg Lukas wrote:
>
> * Kevin Smith [2021-09-07 18:41]:
>> At the risk of repeating myself, I think that storing groupchat messages in
>> the user archives is helpful, and people do this in the wild.
>
> Right, I remember hearing that before, and IIRC the rea
On 7 Sep 2021, at 16:22, Georg Lukas wrote:
>> §6.1.1: the business rules for user archives are inadequate:
>>
>> MUC messages in user archive: I think that implementation practice has
>> clearly shown that storing MUC messages in the user archive is a Bad
>> Idea, and nobody is doing it anyway.
Thanks Matt, a couple of comments:
On not namespace bumping:
227 already said you had to cope with unexpected elements, so simply including
the new elements in their new namespaces seems ok to me. (Although this may
generate warnings. *shrug*)
PEP:
Do you mean PEP as in 163, or full pubsub-on-a
tion and it's probably higher priority than a lot
> of the other stuff."
Thanks for making the notes :)
/K
>
> —Sam
>
> On Tue, Jun 22, 2021, at 13:23, Kevin Smith wrote:
>> On 22 Jun 2021, at 17:51, Sam Whited wrote:
>>> * MattJ: bind2
On 22 Jun 2021, at 17:51, Sam Whited wrote:
>* MattJ: bind2 needs new author
I was under the impression no-one had much interest in me driving bind2 and the
associated bits forward. If I update bind2, are there people ready to implement
it? Have people implemented what’s
On 11 Jun 2021, at 21:57, Ralph Meijer wrote:
>
>
>
> On June 11, 2021 10:12:31 PM GMT+02:00, Dave Cridland
> wrote:
>> On Fri, 11 Jun 2021 at 17:10, Kevin Smith wrote:
>>
>> * "No person has any automatic right to join a chatroom, or write a XEP
> On 11 Jun 2021, at 21:12, Dave Cridland wrote:
>
>
>
> On Fri, 11 Jun 2021 at 17:10, Kevin Smith <mailto:kevin.sm...@isode.com>> wrote:
> I’m just picking at replies here - as I said in the chatroom I think this is
> a generally positive direction and wan
I’m just picking at replies here - as I said in the chatroom I think this is a
generally positive direction and want to thank the people involved.
(I did make two suggestions there)
> On 11 Jun 2021, at 15:18, Dave Cridland wrote:
>
> > The Conduct Team will always hand its recommendation on Sa
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 been a stream error instead, as the text above
>> states? If so, will send out a PR.
>
On 20 Apr 2021, at 11:22, Kevin Smith wrote:
>
> Somewhat belatedly...
>
>> On 16 Mar 2021, at 20:20, Jonas Schäfer (XSF Editor)
>> wrote:
>>
>> This message constitutes notice of a Last Call for comments on
>> XEP-0313.
>>
>> Title: Messa
Somewhat belatedly...
> On 16 Mar 2021, at 20:20, Jonas Schäfer (XSF Editor)
> 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
> message
> On 24 Mar 2021, at 16:02, Jonas Schäfer (XSF Editor)
> 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 t
On 23 Feb 2021, at 09:30, Dave Cridland wrote:
>
>
>
> On Mon, 22 Feb 2021 at 19:02, Florian Schmaus <mailto:f...@geekplace.eu>> wrote:
> On 2/18/21 12:16 AM, Dave Cridland wrote:
> > On Wed, 17 Feb 2021 at 19:22, Kevin Smith > <mailto:kevin.sm
On 17 Feb 2021, at 18:42, Florian Schmaus wrote:
>
> On 2/16/21 4:14 PM, Jonas Schäfer wrote:
>> I think this is the best place in the thread to reply with all my thoughts.
>> Vote change to -0 (or +1 with additional fixes) instead of -1 inline.
>> On Sonntag, 14. Februar 2021 21:12:17 CET Floria
On 17 Feb 2021, at 16:49, Peter Saint-Andre wrote:
>
> 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.
On 17 Feb 2021, at 14:44, Dave Cridland wrote:
>
> Attribute order, namespacing method (xmlns vs. prefix), and insignificant
> white space could also change.
>
> Aside from the latter - it's not clear to me how you tell if whitespace is
> truly insignificant - those are all OK, though unexpect
On 10 Feb 2021, at 09:31, Florian Schmaus wrote:
> The purpose of the compliance suites is to incentivize implementing certain
> features *and* go guide new developers towards things worth implementing.
> Hence, do we really want that clients can claim XEP-0423's "Core Client"
> compliance leve
On 13 Jan 2021, at 17:29, Dave Cridland wrote:
>
> Some discussion in Council as to where this fits. I'm quite happy it is
> useful as a XEP.
>
> So, is this:
>
> Informational: It's a Best Practice for the community. We are recommending
> that projects use DOAP.
>
> Standards Track: It's a
On 23 Dec 2020, at 15:16, Marvin W wrote:
>
> Hi there,
>
> I actually was working on something with partially overlapping goals,
> that is
> a) being notified for relevant groupchat messages via push
> notifications. This is mostly relevant for iOS push notifications (at
> least as far as I und
On 8 Dec 2020, at 22:13, Sam Whited wrote:
> I still think the data on the wire should describe the other data on the
> wire, not some higher- level "decoded” representation
Agree 100%. References et al. need to calculate how the data are going to be
encoded on the wire, not some high level abst
Just to focus on a tiny bit of this...
> On 8 Dec 2020, at 08:40, Dave Cridland wrote:
> "this wasn't really a message at all, this message explains why". The latter
> feels like a case of failed feature negotiation, though.
I think we used to believe that. In the face of carbons and MAM, I it
On 4 Dec 2020, at 16:41, Sam Whited wrote:
> Bytes are the only way to not make assumptions about the libraries,
> languages, etc. being used.
Except that bytes are making significant assumptions about the libraries and
languages being used. It’s assuming that what you get out of your parser
co
On 7 Oct 2020, at 12:38, Dave Cridland wrote:
> Can we put Reactions on the agenda for adoption
I think the previous stance of Council - that it shouldn’t go around accepting
previously rejected XEPs just because the originally objecting Council member
is no longer on Council unless the present
On 7 Oct 2020, at 03:35, Tedd Sterr wrote:
>
> > * There is a reference to MAM-FC, which I'll remove on the basis that I
> > don't
> > see any interest in trying to solve that problem generically from anyone
> > but me
>
> General solutions should be preferred where possible, though that can
On 22 Sep 2020, at 17:05, Jonas Schäfer wrote:
>
> Re: https://github.com/xsf/xeps/pull/983
>
> I have a very simple technical question: Why do this instead of ensuring that
> special characters are URL-encoded for the node ID in the PubSub URIs? This
> seems to be fixing the issue at the wron
On 5 Aug 2020, at 16:47, Georg Lukas wrote:
>
> Hi,
>
> MUC-PMs are prone to errors, have weird interactions with Carbons, MAM
> and other specs and require the recipient to be in the room at the time
> of delivery. While I don't want to abolish them altogether, there is a
> compelling IM use ca
Hi Jonas,
I agree with Sam that it is very desirable for PRs to be accepted on github,
for the sake of contribution to the XSF - I *really* would not like to see the
repo move. If it’s at all practical for us to stay there, I think that is the
best option.
That said, if there is no other pract
On 1 Jun 2020, at 19:52, Kevin Smith wrote:
>
> I think all the discussed ideas have merit, although possibly not for the
> obvious reasons:
>
> I think there is merit in being able to mark some bits of a message as
> skipping styling. This is conceptually a hack (IMO), bu
I think all the discussed ideas have merit, although possibly not for the
obvious reasons:
I think there is merit in being able to mark some bits of a message as skipping
styling. This is conceptually a hack (IMO), but it’s a hack that has mileage
and we should follow this train of thought thro
the semantics for list-multi/list-single that were defined in
XEP-0004. It would be functionally equivalent to saying that MAM uses a
text-multi field with one id per line.
/K
> On 13 May 2020, at 13:50, Florian Schmaus wrote:
>
> On 5/13/20 1:50 PM, Kevin Smith wrote:
>> On 13 May 202
On 13 May 2020, at 03:40, Peter Saint-Andre wrote:
>
> We might want to face reality
> and allow text-multi to treat each line as semantically independent.
Sadly, I don’t think it would just be ‘facing reality’ to say that text-multi
isn’t multi-line text - there are implementations (every libr
1 - 100 of 1278 matches
Mail list logo
