[Standards] Re: Encrypted peer-to-peer XML channel

On 15/07/2024 21.51, Tim Henkes wrote: 2. Are encrypted direct client-to-client channels a thing? There is JET [2], but it seems to focus on key negotiation (which I would do differently) […] There's also a XEP called jingle-xtls [3] in the Inbox, but it's even more abandoned than XEP-0247 and

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

Thanks Dave, I really appreciate you kicking off this discussion. On 27/05/2024 15.07, Dave Cridland wrote: > I've rejected protoXEPs as arbitrarily as anyone else when in Council, > but loosely a few things crop up repeatedly: > * Unwarranted duplication of effort: The problem being solved is

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

On 08/05/2024 16.42, Florian Schmaus wrote: On 08/05/2024 12.41, Marvin W wrote:> To address your concerns I'd suggest the following changes to 0440: - Reduce tls-server-end-point to SHOULD for servers and MAY for clients, specifically mention that this is only for better compatibility.

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

On 08/05/2024 12.41, Marvin W wrote:> To address your concerns I'd suggest the following changes to 0440: - Reduce tls-server-end-point to SHOULD for servers and MAY for clients, specifically mention that this is only for better compatibility. I'd like to note that we previously explicitly

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

Hi Travis, Thanks for your mail. I am sorry that xep440 failed to communicate its goal, as it seems. I will try to improve upon that. You write that tls-server-end-point should not be used and that TLS-intercepting proxies can implement tls-exporter "just fine by simply passing the keying

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

On 10/03/2024 16.18, 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: LAST CALL: XEP-0386 (Bind 2)

On 18/03/2024 09.59, Daniel Gultsch wrote: This message constitutes notice of a Last Call for comments on XEP-0386. Title: Bind 2 Abstract: This specification provides a single-request replacement for several activities an XMPP client needs to do at startup. URL:

[Standards] Re: LAST CALL: XEP-0388 (Extensible SASL Profile)

On 18/03/2024 09.59, Daniel Gultsch wrote: This message constitutes notice of a Last Call for comments on XEP-0388. Title: Extensible SASL Profile Abstract: This document describes a replacement for the SASL profile documented in RFC 6120 which allows for greater extensibility. URL:

[Standards] Re: Remove requirement to send disco#info feature in XEP-0030

On 10/03/2024 17.27, Jonas Schäfer wrote: Dear community, it's been a while I spoke up here. I would like to discuss the removal of the following part-sentence from XEP-0030 (in Final status!): every entity MUST support at least the 'http://jabber.org/protocol/disco#info' feature I agree

[Standards] Re: XEP-0440 and tls-server-end-point

On 11/01/2024 14.03, Simon Josefsson wrote: tor 2024-01-11 klockan 13:48 +0100 skrev Florian Schmaus: Hi Simon, thanks for your mail. On 11/01/2024 13.39, Holger Weiß wrote: * Simon Josefsson [2024-01-11 13:10]: I believe tls-server-end-point is generally best left unimplemented to guide

[Standards] Re: XEP-0440 and tls-server-end-point

Hi Simon, thanks for your mail. On 11/01/2024 13.39, Holger Weiß wrote: * Simon Josefsson [2024-01-11 13:10]: I believe tls-server-end-point is generally best left unimplemented to guide efforts towards supporting the stronger tls-exporter. One use case I see for tls-server-end-point is

[Standards] Re: Moving OX to be based on SCE?

On 01/12/2023 03.46, Stephen Paul Weber wrote: Has this been discussed much before?  SCE clearly calls out OX as inspiration, but especially since both are still experimental would it not make sense to "reverse the arrow" and have OX be a profile of SCE? Yes this is probably sensible.

Re: [Standards] updated RFCs

On 25/02/2023 12.38, Marvin W wrote: On Sat, 2023-02-25 at 11:35 +0100, Florian Schmaus wrote: What I tried to express is that changing the semantics of the RFC 'id' attribute in a new RFC is not a viable solution. Simply because you still need to operate with older implementations that do

Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and

On 25.02.23 10:57, Marvin W wrote: On Sat, 2023-02-25 at 10:39 +0100, Florian Schmaus wrote: As I wrote before, if, for example, the recipient's server also stores groupchat messages in the user's archive, then the recipient will receive a groupchat message containing (at least) two stanza-id

Re: [Standards] updated RFCs

On 25.02.23 11:05, Marvin W wrote: On Sat, 2023-02-25 at 10:50 +0100, Florian Schmaus wrote: However, it is still unclear to me how changing the RFC 'id' attribute specification from "must be unique within the scope of the stream id" to "must be globally unique, for exampl

Re: [Standards] updated RFCs

On 25.02.23 00:56, Peter Saint-Andre wrote: 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

Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and

On 24.02.23 16:47, Tedd Sterr wrote: What I'm less sure of is the benefit 'by' actually brings in practice. If there are multiple stanza-ids then it obviously serves to differentiate them, but why the need for multiple? The client's id is the origin-id (so it can cross-reference with its

Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and

On 22/02/2023 20.59, Tedd Sterr wrote: > …this is the line of thought that neglects that we are working on a > federated  system where we can not assume that every actor is faithful. > ID assigned by the sending entity can potentially be observed by another > malicious actor and be

Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and

On 22/02/2023 20.00, Marvin W wrote: I believe we only disagree if a reference to a stanza should also contain the 'by' attribute. [And probably about our vision if groupchat messages should be stored in as many archives as possible or just in the groupchat service's archive. But we should

Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and

On 22/02/2023 18.00, Tedd Sterr wrote: But, being serious: the issue is that both clients and servers need an id for referring to stanzas, and if that id is dependably unique then it solves a number of difficulties; the reason we have problems is that the original RFC-defined 'id' attribute

Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and

On 22/02/2023 14.14, Marvin W wrote: Hi Flow, Hi Marvin, As it stands today, every message ideally has no more than two IDs: That is where we already think different. The more archives messages are contained in, the higher the chances are that they are preserved and recoverable. Which is

Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and

On 22/02/2023 12.35, Florian Schmaus wrote: With the current state of affairs, you only need to use origin-id in 1:1 chats.   Foosball tonight?   thumbs-up   I believe the last above should be thumbs-up which demonstrates how tricky this is. - Flow

Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and

It appears there are two possible design options A) do not state 'by' when referencing a stanza and provide rules how the 'by' value can be inferred depending on the usage context B) explicitly state the 'by' attribute and provide rules that allow to determine if the used 'by' attribute

Re: [Standards] XEP-0424: Message Retraction - Remove Fastening

On 20/02/2023 11.05, JC Brand wrote: On 20.02.23 10:32, Florian Schmaus wrote: On 13/02/2023 16.57, Daniel Gultsch wrote: I’m currently looking at implementing 'Message Retraction' and I think it should get rid of Fastening. I mentioned it during Summit and while it wasn’t discussed much

Re: [Standards] XEP-0424: Message Retraction - Remove Fastening

On 13/02/2023 16.57, Daniel Gultsch wrote: I’m currently looking at implementing 'Message Retraction' and I think it should get rid of Fastening. I mentioned it during Summit and while it wasn’t discussed much further my comment also didn’t get much protest: I think Fastening is dead. A

Re: [Standards] uppercase/lowercase of keywords

On 18/01/2023 17.26, 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? I

Re: [Standards] standardization process

On 10/01/2023 15.03, Dave Cridland wrote: On Sat, 7 Jan 2023 at 20:46, Florian Schmaus <mailto:f...@geekplace.eu>> wrote: But let use assume that we remove the council approval requirement for experimental XEPs. And further assume that we clearly state that experimental

Re: [Standards] standardization process

On 07/01/2023 22.15, Maxime Buquet wrote: On 2023/01/07, Florian Schmaus wrote: I believe we would be able bring back the good old days where new protocols ideas could be explored and bootstrapped without being bogged down in process by having such numberless XEPs and by the XSF to provide

Re: [Standards] standardization process

On 06/01/2023 23.08, Peter Saint-Andre wrote: On 1/6/23 6:49 AM, Florian Schmaus wrote: I am not sure which protections you are referring to, given that there are implementations out there which not comply with "our" specifications. And this can simply not be prevented. Instead,

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

On 06/01/2023 14.10, Dave Cridland wrote: On Thu, 5 Jan 2023 at 21:38, Florian Schmaus <mailto:f...@geekplace.eu>> wrote: On 05/01/2023 16.31, Peter Saint-Andre wrote: > On 1/5/23 3:18 AM, Florian Schmaus wrote: > >> I become more and more convinced

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

On 05/01/2023 16.31, Peter Saint-Andre wrote: 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

Re: [Standards] XEP-0353 propose id syntax

On 05/01/2023 10.51, Dave Cridland wrote: * The argument that this doesn't need a namespace bump is wrong because "experimental" has no effect here. The entire point of those 'versioned' namespaces was to ensure that we could freely implement Experimental XEPs without worrying about causing

Re: [Standards] Proposed XMPP Extension: Stream Limits Advertisement

On 31.12.22 13:19, Dave Cridland wrote: On Fri, 30 Dec 2022 at 19:40, Florian Schmaus <mailto:f...@geekplace.eu>> wrote: On 30.12.22 11:05, Dave Cridland wrote: > On Thu, 22 Dec 2022 at 09:23, Matthew Wild mailto:mwi...@gmail.com> > <mailto:mwi...@

Re: [Standards] Proposed XMPP Extension: Stream Limits Advertisement

On 30.12.22 11:05, Dave Cridland wrote: On Thu, 22 Dec 2022 at 09:23, Matthew Wild <mailto:mwi...@gmail.com>> wrote: On Wed, 21 Dec 2022, 15:05 Florian Schmaus, mailto:f...@geekplace.eu>> wrote: > Zash's proposal is, as far as I understand it, just an

Re: [Standards] Proposed XMPP Extension: Stream Limits Advertisement

On 21/12/2022 14.49, Peter Waher wrote: Hello This specification defines a way for an XMPP entity to announce the limits it will enforce for data received on a stream. URL: https://xmpp.org/extensions/inbox/xep-sla.html This is a sorely

Re: [Standards] XEP-0388 SASL2: #2 Inline features

On 19/11/2022 19.27, Matthew Wild wrote: On Sat, 19 Nov 2022 at 17:52, Florian Schmaus wrote: I was aware of what Daniel and you wrote. But that does not give an answer why there *need* to be two places. What would break if there was only one? It wouldn't be logical if it was only

Re: [Standards] XEP-0388 SASL2: #2 Inline features

On 19/11/2022 18.39, Thilo Molitor wrote: Am Samstag, 19. November 2022, 18:15:17 CET schrieb Daniel Gultsch: On Sat, Nov 19, 2022 at 5:55 PM Florian Schmaus wrote: Why not simply SCRAM-SHA-1-PLUS PLAIN SCRAM-SHA-1

Re: [Standards] XEP-0388 SASL2: #2 Inline features

On 19/11/2022 16.16, Dave Cridland wrote: On Sat, 22 Oct 2022 at 22:29, Thilo Molitor > wrote: Again, MattJ already explained this well: https://mail.jabber.org/pipermail/ standards/2022-October/038998.html

Re: [Standards] XEP-0388: SASL2 enhancements

Thanks Matt (and others) for pursuing this, IMHO very worthwhile goal. I think I like what I've seen so far, but… On 18/10/2022 16.01, Matthew Wild wrote: 1) Advertisement of supported "inline" features […] While implementing, I quickly realised that the server supporting SASL2 and also

Re: [Standards] NEW: XEP-0397 (Instant Stream Resumption)

On 22/08/2022 16.07, Daniel Gultsch wrote> I have some new found interest in Instant Stream Resumption and after reading the XEP again I find myself agreeing with a lot of what Dave said 4.5 years ago especially with regard to decoupling the HT-* family of authentication from ISR itself. One

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

Hi Zash, On 03/08/2022 15.00, Kim Alvefur wrote: On Wed, Jul 13, 2022 at 03:03:07PM -, Jonas Schäfer wrote: 2. Does the specification solve the problem stated in the introduction and requirements? Yes, and then some. I want to state for the record that the specification is overly generic

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

On 19/07/2022 14.46, 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? I would prefer to update the

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 other words. Without presence subscription you get only the (and related features) and with presence subscription you also get and features related to the account. Returning different results to disco#info (and disco#items) depending on who

Re: [Standards] Proposed XEP-0060 Changes

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] Proposed XEP-0060 Changes

On 15/12/2021 17.33, Dave Cridland wrote: On Wed, 15 Dec 2021 at 16:14, Florian Schmaus <mailto:f...@geekplace.eu>> wrote: On 15/12/2021 15.41, Dave Cridland wrote: > For the benefit of others wanting context, this is XEP-0060 section > 8.2.4. The

Re: [Standards] Proposed XEP-0060 Changes

On 15/12/2021 16.03, Dave Cridland wrote: That said, I think such things are better discussed in XEP-0004, and not here. Dito. Irregardless of the "MUST vs. SHOULD" discussion, I also feel that such a clarification should go into xep4. We have similar situations in other XEPs that use xep4

Re: [Standards] Proposed XEP-0060 Changes

On 15/12/2021 15.41, Dave Cridland wrote: For the benefit of others wanting context, this is XEP-0060 section 8.2.4. The existing SHOULD in this section is probably wrong, in as much as it's either meaningless (to configure a node, obviously you send the form) or else egregious (if you pull

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

On 13/09/2021 16.15, Kim Alvefur wrote: 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

Re: [Standards] XEP-0372 references pointing to different elements in same stanza

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? What if there is another first-level stanza child element with a

Re: [Standards] Thoughts on XEP-0385 Stateless Inline Media Sharing

On 02.07.21 12:15, JC Brand wrote: > So, my proposal is that XEP-0385 be updated so that the XEP-0300 hash > requirement gets relaxed to a SHOULD +1. I would even make the hash OPTIONAL as SHOULD is already pretty strong. > and that the inclusion of the Etag > header be documented as an

Re: [Standards] XSF (unofficial) Modernization Working Group looking for XEPs to discuss

On 29/05/2021 13.08, Sam Whited wrote: I'll change the name if using "Working Group" is what's concerning you, fair enough, I can see how that makes this seem "official" somehow, I could imagine that using 'XSF' in the title is more concerning. Maybe simply call it "XEP Modernization Working

Re: [Standards] Proposed XMPP Extension: Content Rating Labels

On 3/9/21 9:11 PM, Jonas Schäfer (XSF Editor) wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Content Rating Labels Abstract: This specification provides a wire format in the form of a Service Discovery extension to allow services of various kinds to publish

Re: [Standards] Year of the OX

On 2/11/21 1:42 PM, Paul Schaub wrote: Hey everyone! Tomorrow will be new years eve in the Chinese calendar. The Berlin XMPP Meetup celebrated the beginning of the "year of the ox" by talking about OX (XEP-0373.5±0.5 - OpenPGP for XMPP). With around 30 attendants the Jitsi room was quite

Re: [Standards] XML Element Ordering

On 2/18/21 12:16 AM, Dave Cridland wrote: On Wed, 17 Feb 2021 at 19:22, Kevin Smith <mailto:kevin.sm...@isode.com>> wrote: On 17 Feb 2021, at 18:42, Florian Schmaus mailto:f...@geekplace.eu>> wrote: > > On 2/16/21 4:14 PM, Jonas Schäfer wrote: >&g

[Standards] XML Element Ordering

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 Florian Schmaus wrote: Eventually, this is a situation where we

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

On 2/17/21 5:28 PM, Jonas Schäfer wrote: In today’s council meeting, we decided on what we think is an improvement to the proposal in #1032 and which we are all OK with. You can observe the updated diff at: https://github.com/xsf/xeps/pull/1032/files Please provide feedback until the next

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

On 2/11/21 7:09 PM, Drew Varner wrote: First time caller, long time listener. Some model-driven CODECs may not enforce nor detect order. P1’s model-based XMPP CODEC (https://github.com/processone/xmpp) does not enforce nor care about the order of the elements. ``` 2> ReportedFirst =

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

On 2/10/21 10:00 PM, Dave Cridland wrote: On Wed, 10 Feb 2021 at 20:22, Florian Schmaus <mailto:f...@geekplace.eu>> wrote: Since you asked: Smack relies on the ordering (in case a non-default form field type is used), since Smack needs to see the first to ass

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

On 2/10/21 6:54 PM, Dave Cridland wrote:> There's a few options. 1) We ignore the problem. 2) We note that there may exist implementations which rely on the ordering, but say receivers MUST NOT rely on ordering. 3) We note that there may exist implementations which rely on the ordering, and

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

On 2/10/21 5:28 PM, Jonas Schäfer wrote: Thanks for the minutes! On Mittwoch, 10. Februar 2021 16:58:30 CET Tedd Sterr wrote: 4b) PR #1032 (Data Forms Clarifications) - https://github.com/xsf/xeps/pull/1032 Jonas sees this as a massive normative change, rather than the clarification it

Re: [Standards] Proposed XMPP Extension: Implicit XMPP WebSocket Endpoints

On 2/10/21 10:10 AM, Dave Cridland wrote: (Sorry, I'm replying slowly, having to carve out time at the moment). On Wed, 3 Feb 2021 at 17:34, Sonny Piers > wrote: __ I agree with the points raised, but I suggest we forget about public deployments, looks

Re: [Standards] Explicitly require SRV RRs / XEP-0156 in compliance suites?

On 2/10/21 9:54 AM, Dave Cridland wrote: On Wed, 3 Feb 2021 at 15:50, Florian Schmaus <mailto:f...@geekplace.eu>> wrote: On 2/3/21 3:52 PM, Sonny Piers wrote: > On Wed, Feb 3, 2021, at 14:20, Florian Schmaus wrote: >> On 2/3/21 1:47 PM, Sonny Piers wrote>

Re: [Standards] Proposed XMPP Extension: Implicit XMPP WebSocket Endpoints

On 2/3/21 5:43 PM, Dave Cridland wrote: On Wed, 3 Feb 2021 at 07:33, Jonas Schäfer > wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Implicit XMPP WebSocket Endpoints Abstract: This document specifies implicit

Re: [Standards] Proposed XMPP Extension: Implicit XMPP WebSocket Endpoints

On 2/3/21 2:49 PM, Marvin W wrote: wss://:5443/ws ws://:5443/ws wss:///ws ws:///ws - ws://...:5443/ws makes no sense. Port 5443 is obviously a reference to HTTPS 443 port which is TLS encrypted, so you shouldn't make non-TLS connections to 5443. If any, use something like port 5080 or 5280.

[Standards] Explicitly require SRV RRs / XEP-0156 in compliance suites?

On 2/3/21 3:52 PM, Sonny Piers wrote: On Wed, Feb 3, 2021, at 14:20, Florian Schmaus wrote: On 2/3/21 1:47 PM, Sonny Piers wrote> > The equivalent for TCP (srv records) is in core so why not its > equivalent for web ? I don't see xmpp-*. SRV RRs in 'Core'. Only xmpps-*

Re: [Standards] Proposed XMPP Extension: Implicit XMPP WebSocket Endpoints

as Daniel describes then, could not declare conformity with the compliance suites. - Florian On Wed, Feb 3, 2021, at 09:19, Florian Schmaus wrote: On 2/3/21 8:53 AM, Daniel Gultsch wrote: Hi Daniel, Thanks for your feedback. :) > On Wed, Feb 3, 2021 at 7:34 AM Jonas Schäfer <

Re: [Standards] Proposed XMPP Extension: Implicit XMPP WebSocket Endpoints

On 2/3/21 8:53 AM, Daniel Gultsch wrote: Hi Daniel, Thanks for your feedback. :) On Wed, Feb 3, 2021 at 7:34 AM Jonas Schäfer wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Implicit XMPP WebSocket Endpoints Abstract: This document specifies implicit

Re: [Standards] Announcing Slummit 2021

On 1/28/21 10:29 AM, Dave Cridland wrote> On Wed, 27 Jan 2021 at 22:11, Tedd Sterr > wrote: In lieu of an official Summit, I invite all interested parties to participate in the unofficial Slummit! Yeah \o/ Additionally, if there's interest, I was

Re: [Standards] Proposed XMPP Extension: Service Outage Status

On 1/20/21 4:55 PM, Jonas Schäfer (XSF Editor) wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Service Outage Status Abstract: This document defines an XMPP protocol extension that enables a server to communicate issues with the server to all users in a semantic

Re: [Standards] UPDATED: XEP-0434 (Trust Messages (TM))

I am surprised to find that this XEP does not specify the format of the key identifier anywhere (at least I couldn't find it). I had expected to find that the key identifier is qualified by the encryption scheme of the key. That is, instead of

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

On 12/7/20 11:34 PM, Marvin W wrote> On 07.12.20 19:34, Florian Schmaus wrote: We do have xml:lang, don't we? Unforunately, it doesn't help in all cases. It's perfectly fine to write a message with xml:lang="en": "chlapec" is "boy" in slowak This is 27 gr

[Standards] RFC 2119 boilerplate in XEPs

On 12/8/20 9:40 AM, Dave Cridland wrote: Sorry, I completely missed this for some reason. On Thu, 19 Nov 2020 at 15:30, Marvin W > wrote: > Anyway, I understand what you're trying to do here at a high level, I > just think it's broadly not going to be useful, and

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

Hi Marvin :) On 12/7/20 4:22 PM, Marvin W wrote: On 04.12.20 21:23, Florian Schmaus wrote: And I am in favor of code points because it allows us to aim for the extended grapheme cluster algorithm, while also allowing for the "simply count code points" fallback. XEP-0426 already

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

On 12/4/20 9:33 PM, Sam Whited wrote: And I am in favor of code points because it allows us to aim for the extended grapheme cluster algorithm, while also allowing for the "simply count code points" fallback. If you do bytes you could also easily convert to codepoints and then to grapheme

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

On 12/4/20 8:25 PM, Sam Whited wrote: On Fri, Dec 4, 2020, at 19:00, Florian Schmaus wrote: My problem with your proposal is that it uses bytes. I don't get why you want to use bytes here. Naturally. Likewise my problem with your proposal is that it uses code points and I don't get why you'd

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

On 12/4/20 7:29 PM, Sam Whited wrote: I don't understand this, if you get out bytes why would they be different to what was in the stream? Often you don't get raw bytes from your XML parser, but an instance of your programming language's native String type. But often your programming

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

On 12/4/20 4:01 PM, Sam Whited wrote: On Fri, Dec 4, 2020, at 14:50, Florian Schmaus wrote: But this String will be represented in your programming language's native String representation, which may or may not match the bytes on the wire. That's the point, we can't guarantee what

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

On 12/4/20 3:27 PM, Sam Whited wrote: FWIW I was a big proponent of doing it this way too, but I've changed my mind after seeing too many grapheme segmentation implementations be broken in small, different, ways. My new position is that we have to just count bytes and figure out a sane behavior

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

On 12/4/20 3:03 PM, Andrew Nenakhov wrote: Upping a year-old email thread for Florian. Thanks, but I am well aware of the thread and the situation. I think this below mixes aspects the XML layer with the Unicode layer, which do not have to get mixed when counting "characters". Ultimately

Re: [Standards] Off-by-one error in XEP-372 "References"

On 12/4/20 1:31 PM, JC Brand wrote: Hey folks In XEP-0372 in section 3.1, there is the following text: An end attribute is similarly  used for the index of the last character of the reference However, in the example in 3.2, the "end" attribute is set to 78, which is the index of the space

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

On 10/23/20 3:31 PM, Tedd Sterr wrote: *4a) MR !22 (XEP-0118: add composer, date, genre, language, lyricist, and performer tags; make rating optional)* - https://gitlab.com/xsf/xeps/-/merge_requests/25 Zash notes that XEP-0118 is Draft and the

Re: [Standards] MUC identity + feature on mixed-operation domains / gateways (XEP-0045)

On 10/4/20 5:10 PM, Georg Lukas wrote: 1. If you have a domain that hosts mixed entities (both user accounts and rooms), which features / identities should that service advertise. The features and identities of the protocols the XMPP address provides. Assume r...@muc.example.org is a MUC

Re: [Standards] Stanza ID of outgoing message

On 9/27/20 5:45 PM, Holger Weiß wrote: > I'd prefer a solution that doesn't involve reflecting the entire stanza > just to make the client aware of the stanza ID. So if (1) is not an > option, I think I'd opt for extending XEP-0359 or XEP-0313 (or, if > people prefer, adding a new XEP) to return

Re: [Standards] LAST CALL: XEP-0335 (JSON Containers)

On 9/15/20 1:41 PM, Dave Cridland wrote: > On Tue, 15 Sep 2020 at 10:08, Florian Schmaus <mailto:f...@geekplace.eu>> wrote: > > On 9/14/20 9:28 PM, Sam Whited wrote: > > What escaping mechanism, the JSON one or the XML one (probably the > JSON >

Re: [Standards] LAST CALL: XEP-0335 (JSON Containers)

On 9/14/20 9:28 PM, Sam Whited wrote: > What escaping mechanism, the JSON one or the XML one (probably the JSON > one to avoid weird double-escaping issues)? I wonder if this does matter. The tricky part are code points that do not need to be escaped in JSON, but are invalid and not escapeable

Re: [Standards] LAST CALL: XEP-0335 (JSON Containers)

On 9/14/20 5:06 PM, Matthew Wild wrote: > Does the following resolve everyone's issues? (specifically Jonas and Waqas) > > - Add the following sentence: "If the JSON data contains any > characters that are unrepresentable in XML 1.0, these characters MUST > be escaped in the JSON data." Maybe

Re: [Standards] Very Simple Questions about Compliance Suites

On 9/4/20 11:06 AM, Andrew Nenakhov wrote: > […] if you really > want a compliance suite, you shouldn't pollute the list of extensions > with this day-to-day bureaucracy, but simply publish a 'compliance > suite' page on https://xmpp.org/compliance/ URL and update it when > necessary. You get

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

On 05.08.20 16:04, Jonas Schäfer wrote: > On Mittwoch, 29. Juli 2020 00:29:11 CEST Tedd Sterr wrote: >> 4a ii) PR #971 (XEP-0004: Clarify field type omission for 'submit' and >> 'result' form field types) - https://github.com/xsf/xeps/pull/972 Jonas: >> [on-list] >> Zash: [on-list] >> Daniel:

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

On 7/21/20 8:28 PM, Dave Cridland wrote: > > > On Tue, 21 Jul 2020 at 18:57, Florian Schmaus <mailto:f...@geekplace.eu>> wrote: > > Based on the discussion in this thread, I suggest the following changes > > http://geekplace.eu/xeps/xep-sasl-cb-types/d

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

Based on the discussion in this thread, I suggest the following changes http://geekplace.eu/xeps/xep-sasl-cb-types/diff.html#sasl-mech-interaction - Florian signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info:

Re: [Standards] [Council] XMPP Council Agenda 2020-07-22

On 7/21/20 5:33 PM, Jonas Schäfer wrote: > 4) Items for voting > > 4a) PR#971 vs. PR#972 > URL: https://github.com/xsf/xeps/pull/971 > URL: https://github.com/xsf/xeps/pull/972 > Summary: The first one is truly an (editorial) clarification (AFAICT), the > second one is a normative change to the

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

On 7/16/20 12:33 PM, Daniel Gultsch wrote: > Am Do., 16. Juli 2020 um 10:13 Uhr schrieb Florian Schmaus > : > >> If you send 'y', which implies that you, the client, did not select a >> -PLUS mechanism for authentication, while the server announces at least >>

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

On 7/16/20 11:46 AM, Daniel Gultsch wrote: > Am Mi., 1. Juli 2020 um 20:03 Uhr schrieb Ruslan N. Marchenko > : >> >> Am Sonntag, den 14.06.2020, 13:05 + schrieb XEP Editor Pipeline: >>> Version 0.1.0 of XEP-0440 (SASL Channel-Binding Type Capability) has >>> been released. >>> >>> Abstract:

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

On 7/2/20 1:26 PM, Ruslan N. Marchenko wrote: > Am Donnerstag, den 02.07.2020, 11:23 +0200 schrieb Florian Schmaus: >> >> I am not sure if this is a downgrade attack (at least a full-blown), >> or, >> if it is, if it. Without xep440 the client would have send 'p' i

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

On 01.07.20 22:01, Ruslan N. Marchenko wrote: > Am Sonntag, den 14.06.2020, 13:05 + schrieb XEP Editor Pipeline: >> Version 0.1.0 of XEP-0440 (SASL Channel-Binding Type Capability) has >> been released. >> >> Abstract: >> This specification allows servers to annouce their supported SASL >>

Re: [Standards] Adding namespaced content to Registry entries

On 6/3/20 10:50 PM, Dave Cridland wrote:> That said, I think there's two useful things we can do here: > > 1) Validation information is clearly useful in this case; we should add > that to the XEP-0068 registry by an update to XEP-0068 I would like to avoid steering us in a world where we are

Re: [Standards] Adding namespaced content to Registry entries

On 6/3/20 5:25 PM, Jonas Schäfer wrote:> Hi everyone, > > Flow and I got in a discussion about whether it is OK to add foreign, > namespaced elements to Registry entries. I think registry entries should be just as extensible as the elements that are registered. This would also align nicely with

Re: [Standards] Call for Experience: XEP-0050: Ad-Hoc Commands

On 5/26/20 10:24 PM, Tedd Sterr wrote: > It's worth noting "the execute issue" and considering a fix before > advancing. > > > From "Council Minutes 2018-04-18" - > https://mail.jabber.org/pipermail/standards/2018-April/034790.html > > *3) XEP-0050 'execute' Issue* > … Kev explains that it's

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

On 5/23/20 12:24 PM, Mathieu Pasquet wrote: > > On 12.09.2017 12:45, Georg Lukas wrote: >> * Sam Whited [2017-09-12 01:52]: >>> I had assumed that the server would be storing things and we didn't need >>> to send it back, but maybe that's not always the case. This does seem >>> like the kind of

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

On 5/13/20 1:50 PM, Kevin Smith wrote: > 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

  1   2   3   4   5   6   >