[Standards] Re: LAST CALL: XEP-0421 (Anonymous unique occupant identifiers for MUCs)
I strongly disagree that this does not belong in the security considerations. "anonymous" is not a formally provable security property. You and I may know that that means "don't take a SHA-1 and assume that it will be hard to guess", but as we see over and over and over again many people won't (I should start keeping an "X days since I saw a breach due to a website using a naive hash" sign at my desk; it wouldn't get very high). This seems like a common enough misunderstanding of a complicated topic that I think we should explicitly call it out as the way this is most likely to fail. I can't see that being more explicit could hurt in any way, and if there's a bad thing that defeats the entire purpose of the XEP and is likely to happen, it seems worth calling out. —Sam On 2024-05-08 10:29, Marvin W wrote: On Wed, 2024-05-08 at 10:19 -0400, Sam Whited wrote: I'd like to see the security considerations expanded on this. In particular, in the business rules it mentions the fact that if occupant-id isn't supported it could be spoofed. This should exist in the security considerations. Fair. Also, I suspect the naive way to implement this will be to hash the bare JID. We probably want to mention that this is a bad idea and that these identifiers should be random (or we should explicitly define the security properties that are required if they're derived, which probably includes using a salt and ensuring high entropy). This is not only a bad idea, but is very much non-compliant: "The occupant identifier MUST be generated such that it is anonymous. This means that it MUST be sufficiently hard to determine the real bare JID of an occupant from its occupant identifier. Additionally, a MUC service SHOULD generate the identifier such that the occupant identifier of a user in one room of the service does not match the occupant identifier of the same user in another room of the same service." Nonetheless could be made even more specific that this is not allowed (aka MUST NOT just hash using widely known, static parameters). However, I think this does not belong into Security Considerations, as not complying is not just "bad for security", but actually defeats the whole purpose of the XEP. Marvin ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org -- Sam Whited s...@samwhited.com ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: LAST CALL: XEP-0421 (Anonymous unique occupant identifiers for MUCs)
Indeed, sorry to be unclear, I'm suggesting that we should discuss this in the security considerations section (probably detailing exactly what "The occupant identifier MUST be generated such that it is anonymous" actually means in terms of security properties). In addition, I think we should mention the naive use case that people may think is also fine (just doing a hash of the bare JID) and be explicit that this is not good instead of just passively assuming this is covered and understood by the word "anonymous". —Sam P.S. re-sending something I accidentally sent off-list, sorry for the duplicate Stephen. On 2024-05-08 10:22, Stephen Paul Weber wrote: Also, I suspect the naive way to implement this will be to hash the bare JID. We probably want to mention that this is a bad idea and that these identifiers should be random (or we should explicitly define the security properties that are required if they're derived, which probably includes using a salt and ensuring high entropy). The XEP suggests "One way to ensure these properties is to generate a private secret key for every room and use an HMAC algorithm with a sufficiently secure hash function to generate the occupant identifier from the real bare JID and that secret key." ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org -- Sam Whited s...@samwhited.com ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: LAST CALL: XEP-0421 (Anonymous unique occupant identifiers for MUCs)
I'd like to see the security considerations expanded on this. In particular, in the business rules it mentions the fact that if occupant-id isn't supported it could be spoofed. This should exist in the security considerations. Also, I suspect the naive way to implement this will be to hash the bare JID. We probably want to mention that this is a bad idea and that these identifiers should be random (or we should explicitly define the security properties that are required if they're derived, which probably includes using a salt and ensuring high entropy). —Sam On 2024-05-08 05: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 reconnects and renames. It thus prevents impersonification of anonymous users. URL: https://xmpp.org/extensions/xep-0421.html This Last Call begins today and shall end at the close of business on 2024-05-27. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated! ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org -- Sam Whited s...@samwhited.com ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: LAST CALL: XEP-0440 (SASL Channel-Binding Type Capability)
I'm a bit torn on this one. Mostly I agree with what Travis wrote. I'm slightly concerned that the way this spec makes recommendations (ie. putting exporter and end-point at the same level of "SHOULD" [1]) may lead to a false sense of security (this is already true of most everywhere we write about tls-end-point where we don't make it clear that it provides vastly different security properties than unique mechanisms like tls-unique and tls-exporter). I also strongly agree with Dave that we should run this by KITTEN first; asking the advice of the experts seems pertinent. Overall I'm not against having a way to do this negotiation: if tls-exporter starts showing signs of weaknesses it's probably good to have a way to quickly update. But I'm somewhat against this document making recommendations for compatibility and would prefer that to exist elsewhere (probably somewhere we can update quicker than a standards track XEP if future problems arise; maybe we should have a "how to use TLS with XMPP" informational spec of our own at some point? Finally, I'd like to see a trust-on-first-use model added to the spec. If we're going to do this, the client may want to cache the mechanism list on the first connection to the server and fail if that list is downgraded in the future, or something along those lines. TL;DR — overall I'm not against the general idea, but I don't think this spec is ready for last call yet. —Sam [1]: actually, it looks like tls-exporter isn't even a SHOULD, it's a "should". That SHOULD probably be fixed :) On 2024-05-06 13:21, Daniel Gultsch wrote: This message constitutes notice of a Last Call for comments on XEP-0440. Title: SASL Channel-Binding Type Capability Abstract: This specification allows servers to annouce their supported SASL channel-binding types to clients. URL: https://xmpp.org/extensions/xep-0440.html This Last Call begins today and shall end at the close of business on 2024-05-20. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated! ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org -- Sam Whited s...@samwhited.com ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: LAST CALL: XEP-0333 (Displayed Markers (was: Chat Markers))
I very much think we should stop the trend of adding other comments in the title. This is better than a funny joke, but it's still something that's going to show up in citations. Let's just stick "note that this was previously known as Chat Markers" in the introduction somewhere and call it good. Otherwise, this spec is useful and widely implemented, so let's go for it. —Sam On 3/25/24 15:16, Daniel Gultsch wrote: This message constitutes notice of a Last Call for comments on XEP-0333. Title: Displayed Markers (was: Chat Markers) Abstract: This specification introduces a method to let the sender, or multiple participants in a group chat, know that a client has displayed messages up to a certain point. URL: https://xmpp.org/extensions/xep-0333.html This Last Call begins today and shall end at the close of business on 2024-04-08. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated! ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org -- Sam Whited s...@samwhited.com ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))
I have similar views to Dave and Daniel on this. This specification is not needed to fill any gaps in the protocol, it is quite easy to refer to "non-stanza top-level elements" or "non-stanza stream-level elements" without inventing a new word for them. We have enough jargon floating around without making things impenetrable to new users and if I were to write more XEPs in the future I would not use this word, standardized or no. Writing technical specs is all about clear communication. Inventing new words for the sake of saving a few characters of typing (but let's ignore the inevitable citation to this document that would be necessary on every single first use of the word in another XEP) is not doing anything to make our communication clearer, instead it's just one more thing you have to read before you can understand any other spec that references it. —Sam On 3/10/24 11: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: https://xmpp.org/extensions/xep-0360.html This Last Call begins today and shall end at the close of business on 2024-03-25. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated! ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org -- Sam Whited s...@samwhited.com ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: LAST CALL: XEP-0392 (Consistent Color Generation)
> 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol? I don't think this specification specifically needs to be defined in the XMPP protocol stack, but I do think it's nice to have a recommended method for doing this. If there are other already-standardized ways of doing this, I would prefer that we adopt one of those instead of doing our own. I don't actually know if there are any though, and am happy for it to be standardized here as well if there aren't. > 2. Does the specification solve the problem stated in the introduction > and requirements? I have only implemented an older version of this specification which I intend to continue using and it solves the problem well enough. I am not qualified to know whether it addresses the accessibility requirements, but as far as I can tell it does. I have no reason to believe that the current, more up-to-date version does a worse job at this, so I suspect it still solves all the problems and meets all the requirements. > 3. Do you plan to implement this specification in your code? If not, > why not? I have implemented an older version, but do not plan on implementing the current version. If we are going to standardize this we should be using existing standard color spaces that are widely implemented. In the latest version a color space that was defined by an individual and is not otherwise widely used has been adopted, which I feel isn't the right way to go about any standards development. I am sure critics will counter with "but it's so easy to implement, and the author has libraries in various languages", but never the less it is my belief that we should stick to widely used and widely vetted color spaces from other standards bodies, and not just whatever trendy new thing one or two people on hacker news have created this week. We are just making more work for ourselves by going this route. I should not have to vet a color space and a library that an individual made, and I am likely not qualified to do so. As a standards body we should re-use other standards bodies work unless there is a very good reason not to, and I don't believe there is one here. We should go back to a color space that is already used in the industry, or at least hold off advancing this XEP until we're sure the colors space that has been picked is actually being widely adopted itself. > 4. Do you have any security concerns related to this specification? It's worth mentioning that any sort of color hash like this will be somewhat limited and that the human eye can only distinguish between so many colors, so it shouldn't be used to do things where the user would have to discern uniqueness. ie. if the user has two contacts that both hash to the same color (or close to the same color), they could become confused about who is speaking and who they're writing to if this isn't paired with other visual indicators that differentiate the contacts. > 5. Is the specification accurate and clearly written? Yes, it's easy enough to follow along with. —Sam On 3/10/24 10:24, Daniel Gultsch wrote: This message constitutes notice of a Last Call for comments on XEP-0392. Title: Consistent Color Generation … URL: https://xmpp.org/extensions/xep-0392.html This Last Call begins today and shall end at the close of business on 2024-03-25. -- Sam Whited s...@samwhited.com ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Update XEP-377
The general idea here was that the URI is for *machines* to process, so it doesn't have to be exact. A machine would treat spam and generic abuse differently (eg. it might apply automated spem scanning to one message, but immediately forward the other along to a moderator). In my view any new URI should be something that can be handled by a machine and that would be different than how the existing URIs are handled. This means they are very general in nature. Everything else should be handled by the description. That being said, I'd like to make more improvements to this spec and think we can do a lot better, but since adoption is already low I'm hesitant to expand it without first figuring out how to increase adoption. —Sam On 2/27/24 06:59, Matthew Wild wrote: Hey, Thanks for the feedback. On Tue, 27 Feb 2024 at 11:48, em...@msavoritias.me wrote: JoinJabber is interested in possibly hosting an rtbl instance and holding domains accountable to our CoC. With that in mind the XEP-377 seems to be inadequate. Specifically here: https://xmpp.org/extensions/xep-0377.html#payload It mentions only: urn:xmpp:reporting:spam Used for reporting a JID that is sending unwanted messages. urn:xmpp:reporting:abuse Used for reporting general abuse. That is severely limiting. For example what if somebody sends hate speech? or transphobia? or racism? or moderation is non existent in this server? One solution when i talked about was removing the limitation of being only two and allowing any label basically. Wdyt? Actually the XEP defines a registry for these: https://xmpp.org/extensions/xep-0377.html#registrar-reporting This allows defining new reasons without needing to update the XEP. It's also intentionally a URI, so that other URIs can be used there. However I would also suggest considering whether using one of the existing reasons (likely the generic 'urn:xmpp:reporting:abuse') combined with a text description to provide the additional detail would suffice, in the interests of interoperability. Regards, Matthew ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org -- Sam Whited s...@samwhited.com ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Wrapping up the XMPP Lemmy Experiment
I tend to agree; I just posted what I see as the results of the experiment from my perspective on Lemmy, so I'll copy it over here as well: My personal opinion is that the results of the experiment are that Lemmy is not a good platform for community building. I’m glad we gave it a shot, but I probably won’t be using it anymore either way for a few reasons: - The moderation just isn’t very good (we still have Nazi imagery and accounts on the server from the early spam wave with no way to purge them, though they are blocked and can’t post anymore but the images and what not are still being served as far as I can tell) - The UI is generally confusing and hard to use, things aren’t logically grouped, etc. - The federation capabilities don’t seem to actually be very good (I’m sure this will improve, but there’s other software out there that’s good already so if we wanted to try this again I think we should use something else instead) - Generally buggy/over-javascripty UI - Generally hard to follow new content on Lemmy: it tries to imitate reddit too much I think so stuff that’s “Hot”, whatever that means, get surfaced but you have to constantly switch over to a non- algorithmic timeline if you just want to see what you’ve missed I’d still like to find a way to build community between XMPP projects, but I’ve started to think it may be better if projects interact with other existing instances more that aren’t focused on XMPP, this spreads the message a bit better. I forget who made this argument early on, so apologies for not letting you know directly, but I think the experiment has brought me around to this way of thinking as well. I will follow up after we decide what to do with a list of possible places that it might be good for XMPP projects to join if I can remember to put it together. —Sam On Tue, Jun 6, 2023, at 08:40, Matthew Wild wrote: > On Tue, 6 Jun 2023 at 12:53, Guus der Kinderen > wrote: >> >> I fear that this never lived up to its potential. Unless someone is >> actively going to do something with this, I'd not let it linger. That >> only adds to fragmentation and overhead. Too bad though. > > +1. We always considered it an experiment, and this was always a > likely outcome (even if we hoped it might not be). > > Thanks Sam, for taking the lead on this initiative. > > Regards, Matthew > ___ > Standards mailing list -- standards@xmpp.org Info: Unsubscribe: %(real_name)s- > unsubscribe@%(host_name)s > ___ -- Sam Whited ___ Standards mailing list -- standards@xmpp.org Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s ___
[Standards] Wrapping up the XMPP Lemmy Experiment
Hi all, It's been over a year and the folks hosting the XMPP Lemmy experiment at community.xmpp.net have asked us to start transitioning it to our own hosting. I'm writing to see what the community would like to do, or if anyone wants to take over hosting? The instance was never very widely used, so I think we can probably shut it down safely as well without too much loss. What do you think? —Sam -- Sam Whited ___ Standards mailing list -- standards@xmpp.org Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s ___
Re: [Standards] XEP-0353 propose id syntax
> 1. It is impossible to guarantee that an identifier is "globally >unique", thus this requirement should not end up in any >specification. The term "globally unique" is a widely understood term of art that is perfectly acceptable to use. We don't need to worry about the fact that it's technically possible that sometime before the eventual heat death of the universe it may be possible for two IDs generated in such a way that they could be called "globally unique" to not be unique. The probability is close enough to zero to be negligible. We can always point to the definition in the glossary section of the spec if you're worried about this. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Lemmy Community Check In
Hi all, It's been 4 months since I launched an XMPP focused Lemmy instance (TL;DR — like Reddit, but federated) and aside from an initial spam wave, so far it's going well, though it's also a little quiet. This post is just a check in to see how folks are feeling about it. I wanted to see how many XSF members have tried it, and whether they think it's a good idea to maintain going forwards? Have you had any good or bad experiences with it? Other thoughts about how things are going? We have the hosting for free for 1 year, so plenty of time left to try it and make a decision before then! If you haven't tried it, head over to https://community.xmpp.net/ and sign up for an account! —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Hash Algorithm Names in Bits of Binary
Hi all, There was a brief discussion on jdev@ today about how Bits of Binary is not consistent with newer XEPs in terms of the hash algorithm names it uses. Currently it only mentions using the name "sha1" to refer to the SHA-1 hash algorithm. However, other XEPs that follow the guidelines from "XEP-0300: Use of Cryptographic Hash Functions in XMPP" [1] say to use the names from the "IANA Hash Function Textual Names Registry" [2] which uses the name "sha-1". Since BoB does not actually mention what other algorithms are supported or what they should be called, I have submitted the following text to clarify that names should be taken from the IANA registry and XEP-0300 except if the algorithm is SHA-1 which must remain "sha1" for historical reasons. I believe this is simpler than creating a new namespace or entirely new mechanism for sending binary data around and is backwards compatible with all existing implementations, but if you have arguments to the contrary I'd love to hear them. The PR is here if you'd like to peruse the text or suggest changes: https://github.com/xsf/xeps/pull/1193 —Sam [1]: https://xmpp.org/extensions/xep-0300.html [2]: https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] What to do about multi-item data forms?
I have submitted the following to try and remedy this issue: https://github.com/xsf/xeps/pull/1194 Though I don't think we came to consensus in this thread, I get the impression that not mixing and matching normal form and multi-item form elements was the original intent. For users that want to use tables in their normal forms, they could define a new XEP that standardizes a "table" field or similar later, so we're not really losing anything since as far as I know no one does this yet anyways. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] What to do about multi-item data forms?
I agree with this in principal, however by doing this (but not allowing field) we're definitely moving beyond clarifying the text and into making normative changes. The text either meant "no elements other than item/reported are allowed in multi-part forms" or "items are allowed in forms along with everything else" so saying "item/reported/other elements are allowed, but not 'field'" would be new territory. Although it appears that at least some libraries are already doing this even though it's in violation of the spec, so maybe we'd just be updating the spec to match reality. —Sam On Tue, Jul 19, 2022, at 15:55, Philipp Hörist wrote: > Hi, > > While i also think that its probably better to write a note that says > and should not be mixed in the same form, i dont see > a good reason why we cant use and with the > reported form. > > It does not add complexity and is useful to provide some context with > the form. > > So if we limit the usage of the XEP lets not throw the baby out with > the bathwater. > > Regards Philipp > > Am Di., 19. Juli 2022 um 21:47 Uhr schrieb Florian Schmaus > >: > >> 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 existing XEP if this is an option. I >> think it may be. >> >> >> > After re-reading this thread it's still unclear to me what the >> > original intent was and it doesn't seem like anyone else besides >> > Peter and I have opinions, >> >> It was not so long ago when I reworked Smack's Data Form code. IIRC I >> was under the impression that and do *not* appear >> within the same data form. >> >> I believe that disallowing mixing and within the >> same form makes interoperability easier, as it reduces the valid >> possibilities how the protocol could be used. Ideally use-cases like >> the one mentioned (jmp.chat) can instead be build of an optional >> extension protocol, probably based on using two data forms. >> >> In any case, this should be clarified in the XEP. So thanks for your >> effort Sam! :) >> >> - Flow >> ___ >> Standards mailing list Info: >> https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards- >> unsubscr...@xmpp.org >> ___ >> > > ___ > Standards mailing list Info: > https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards- > unsubscr...@xmpp.org > ___ -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] What to do about multi-item data forms?
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? After re-reading this thread it's still unclear to me what the original intent was and it doesn't seem like anyone else besides Peter and I have opinions, so I'm tempted to write something that says "multi-item forms are a separate thing and can't have fields/instruction/title/etc." as that seems the simplest solution, but I'm not sure where we'd put this text. —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] What to do about multi-item data forms?
Just that forms with fields and multi-item forms can't be mixed. Ie you can have or but not . On Sun, Jul 17, 2022, at 19:02, Peter Saint-Andre wrote: > Could you clarify what you mean by a separate data type? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] What to do about multi-item data forms?
On Sun, Jul 17, 2022, at 14:04, Peter Saint-Andre wrote: > Maybe. The text in effect says "here are some additional elements not > mentioned so far in the spec", not "these new elements are included in > addition to other elements within the XML". This sounds like the original intent was for this to be a separate data type that does not include fields, instructions, or title elements. >> (though there are no examples where a form contains reported/items >> and any other form element). > > The lack of examples is indeed not good. But this sounds like it should contain those other elements, so it's still not clear to me what the original intent was :) > What use cases do folks have in mind nowadays for multi-item data > forms of type 'result'? I think singpolymas example was a good one: the jmp.chat folks would like to display some form information that includes your account balance, and below that a table (aka multi-item form) of recent transactions. > Do these libraries allow multiple items in forms of type 'cancel', > 'form', and 'submit', or only 'result'? As far as I can tell aioxmpp errors if you try to create or parse a form with multiple items that is of a type other than result [1], but nbxmpp and Smack will let you parse or build a form of any type with items [2, 3]. —Sam [1]: https://github.com/horazont/aioxmpp/blob/949a91c25b550f5fa0ca84c8134c2c6f566cb094/aioxmpp/forms/xso.py#L615-L617 [2]: https://dev.gajim.org/gajim/python-nbxmpp/-/blob/master/nbxmpp/modules/dataforms.py#L710 [3]: https://github.com/igniterealtime/Smack/blob/ef003bbc5c8c47fb6f32ac78631168d4b197fe0a/smack-extensions/src/main/java/org/jivesoftware/smackx/xdata/provider/DataFormProvider.java#L69-L73 -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] What to do about multi-item data forms?
Several people [1, 2] have recently asked about how to use multi-item data forms. XEP-0004 when introducing multi-item forms says: > Therefore, a data form of type "result" MAY contain two child elements > not described in the basic syntax above Then proceeds to give examples using the reported/items. However, the text makes it sound like these XML elements might be in addition to existing elements such as title/introduction and various fields (though there are no examples where a form contains reported/items and any other form element). This would lead to a lot of edge cases (what if you have a field in between multiple items?) that also aren't described by the XEP, which makes me wonder what the original intent is and how we should interpret it going forward. Looking over a few existing libraries, they appear to interpret this differently. For example: - aioxmpp and nbxmpp do not allow mixed fields/items, but do allow multi- item forms with instructions, although this appears to be incorrect no matter how you interpret the spec, but makes a sort of logical sense - smack allows mixing fields and items but if parsing a form with them it loses ordering between fields and items while maintaining ordering between fields and items individually, eg. in the form "field1, item1, field2, item2" you could ask Smack for fields and it would give you "field1, field2" or items and it would give you "item1, item2" Since the spec is not clear and users of these libraries could easily write forms that would be compatible with some clients and incompatible with others (without the user realizing they've done this), I think we should find a way to clear up the inconsistency, possibly with a new informational XEP. A few options have been discussed: 1. Disallow mixing fields/items (possibly allowing instructions on both) 2. Allow mixing fields/items and treat them as separate ordered entities that should be displayed separately 3. Treat individual items as fields to be displayed in a column and allow them to be ordered together (ie. item is effectively just a field with multiple values that are themselves fields and it happens to have a slightly different wire representation) I'd love to hear what other libraries do or any pros/cons of the above. In [2] it was suggested that the jmp.chat folks would like to display a form containing your account balance, followed by a table of recent transactions. This could be allowed by option 1 only if we also specify that multiple forms should be displayed one after the other; I am unsure if this conflicts with the use of multiple-forms in existing specs. Option 2 and 3 it would just work. Your thoughts would be appreciated. —Sam [1]: https://logs.xmpp.org/xsf/2022-06-07?p=h#2022-06-07-50bc9a07d99ec16a [2]: https://logs.xmpp.org/jdev/2022-07-17#2022-07-17-d81ddc5a53cd0080 -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Moving server-side MAM search forwards
Reading through this thread my instinct is that we're over complicating
and over-specifying things. It's quite possible that each server will
want to have their own search syntax, and I don't think we need to
expose any specific syntax (eg. a simple search vs. advanced search) in
MAM. Instead, maybe it would be better to let the server send a URL that
can be displayed next to the search box that links to a help page with a
description of the syntax they use?
On Fri, Jun 3, 2022, at 05:50, Matthew Wild wrote:
> Hi folks,
>
> Thanks to Guus's persistence, I finally took time to close a few
> issues I have with the current XEP-0431 (Full Text Search in MAM).
>
> The main issue is that the current version of the spec provides no
> guarantees about how the search string (generally input from a
> user) will be interpreted. Usually in such cases, I would say this
> is fine... an implementation that returns all messages containing
> "bar" when you submit a search for "foo" is obviously broken and
> nobody would want to use it, even if it's 100% permitted behaviour
> by the XEP.
>
> But full-text search is actually a complex topic, and there are
> various backend implementations that servers are likely to lean on.
> Each of them has a different search syntax, and there is no way (in an
> open ecosystem) for a user to know which of these may be used.
>
> My proposal does two things to fix this situation:
>
> 1) Add a "simple" search type, which is recommended to be
> implemented as a baseline for interoperability. For simple
> searches, the server promises that no search terms or symbols
> will be interpreted as special syntax - what you search is what
> you get.
>
> 2) Extend the existing ("advanced") search field with a
> recommendation that the server includes a element (already
> defined in XEP-0004) to explain the supported syntax to the user,
> and an (entirely optional) machine-readable hint that can be used
> to indicate to a client that a commonly-used syntax is supported.
>
> Finally, most full-text search engines are not language-agnostic. This
> is because they perform operations such as stemming, and utilize a
> "stop word" list while building the index to help improve the search
> results. Many default to English, and while searches in other
> languages generally work, they may be silently worse. I've added an
> optional tag through which the server can indicate the natural
> languages that the search is optimized for. I feel least strongly
> about this addition, since this information is usually going to be
> apparent to the user already based on the context.
>
> Commit:
> https://github.com/xsf/xeps/compare/master...mwild1:xep-0431-v0.3.0?expand=1
> Rendered: https://matthewwild.co.uk/uploads/xeps/xep-0431.html
>
> Feedback welcome, including from Dave (document's author) who I
> haven't consulted about these changes. If there are no objections,
> I'll raise a PR soon.
>
> Regards, Matthew
> _______
> Standards mailing list Info:
> https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards-
> unsubscr...@xmpp.org
> ___
--
Sam Whited
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
[Standards] Lemmy: a new XMPP Community Space
Hi all, I've been experimenting with an alternative to Reddit and have created a Lemmy instance to act as an XMPP community space: https://community.xmpp.net/ If you're not familiar with Reddit, it's effectively forums and link sharing rolled into one. Each project can have its own forum where members can ask questions, post replies, get updates from the project leadership, etc. However, unlike Reddit, Lemmy is federated and there are lots of other great instances out there that you can follow communities and users of! I hope you'll consider joining us and setting up a community for your project, or just joining as an individual to follow updates from your favorite projects and chat in the various communities! I'm looking forward to seeing where this experiment goes! If you do join as a project or individual, feel free to say hi and introduce yourself in the default community! https://community.xmpp.net/c/main Or check out a list of communities to join: https://community.xmpp.net/communities See you on the fediverse! —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0424 (Message Retraction)
I would like to point out that this specification relies on XEP-0359, XEP-0422, and XEP-0428 all of which are deferred. While 0359 is widely implemented and probably fine to rely on, I don't believe 0422 is as widely used and we should probably let a solution for referencing other messages shake out before advancing something that relies on one that may not be the final solution. I also just think that fastening is unnecessary in this context; retract can just include the stanza ID directly, no need for all the extra protocol. Because of this I'd be against this advancing at this time. That being said, my answers to the questions we always ask are below: On Tue, Dec 7, 2021, at 10:51, Jonas Schäfer wrote: > 1. Is this specification needed to fill gaps in the XMPP protocol >stack or to clarify an existing protocol? Yes > 2. Does the specification solve the problem stated in the introduction >and requirements? Yes > 3. Do you plan to implement this specification in your code? If not, >why not? Not anytime soon, I'm hoping for other changes to be made to this spec first (see above). > 4. Do you have any security concerns related to this specification? It is probably worth mentioning in the security considerations that the context of a conversation can appear to be changed if you don't include a tombstone in the client as well to show that something was removed. > 5. Is the specification accurate and clearly written? Yes. —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Office Hours, 5th October: Overview of Open Collective and Fiscal Hosting
Hi all! At tomorrow's office hours we'll be showing off the features of Open Collective and talking about the XSF's new role as a fiscal host for XMPP based projects. This session will be especially useful for creators of small projects who may want to use the XSF's services in the future, and there will be plenty of time for questions! The session will be recorded. We hope to see you there! *What:* Overview of Open Collective and Fiscal Hosting *Where:* https://socialcoop.meet.coop/sam-pku-dud-niv *More info:* https://wiki.xmpp.org/web/Office_Hours_Checklist —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Fiscal Hosting by the XSF
Hi all, As you may (or may not) be aware, the XSF recently approved becoming a fiscal host for XMPP related projects! This means that they can accept tax-free donations on behalf of XMPP related projects, making it easier to get started accepting donations without having to create a bank account or legal entity. The XSF does the financial paperwork and you can just focus on your project! More details can be found in the announcement blog post: https://xmpp.org/2021/09/the-xsf-as-a-fiscal-host/ I wanted to make sure to get this news out as widely as possible within the XSF, so my apologies for the spam if you were already aware. I hope this will be useful to XMPP projects trying to reach more donors! —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0372 references pointing to different elements in same stanza
Seems like we might as well use the element name since that has to be
unique; one less unique ID to store. Also if you have a schema, structs,
etc. in your language of choice you now don't have to go update them for
every possible element to add an id attribute, there aren't conflicts
with anything that already has an id attribute that we inevitably will
want to reference in the future, etc.
That being said, my concern is that some libraries would treat
as "{}subject" and some would treat it as
"{jabber:client}subject".
—Sam
On Thu, Sep 9, 2021, at 13:15, Kevin Smith wrote:
> It’s not the element name, it’s just (possibly unfortunately) the same
> in that example. It’s the id.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Re: [Standards] MAM Sync Strategies
I may have misunderstood, but if we're only fetching the last message
the first time, do you start out with no history? Also, why set "before"
at all if it's only one message, the direction won't matter, no?
—Sam
On Fri, Aug 27, 2021, at 09:34, Thilo Molitor wrote:
> When the user first sets up a new account, we query the archive with
> end= and RSM {max=1, before=""}
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Re: [Standards] MAM Sync Strategies
Thanks JC! You're right, I should have mentioned gaps. It's still possible to have them in a desktop client because it could always close before it finishes paging through catching up on history. I had planned to solve that by either switching to committing the entire query in one transaction, or changing from using the last message for the sync query to using a separate "last message pointer" that gets updated only after the entire transaction is over. If for any reason there is a gap, this would effectively be the "there's a gap here" pointer because you'd see that there existed messages after the last message pointer. You could then fill it, or add a marker as you've done. I haven't decided what's best yet, so I don't have this implemented right now, but it's on my list. —Sam On Fri, Aug 27, 2021, at 03:57, JC Brand wrote: > The potential presence of gaps and how to deal with them is something > that I don't see mentioned in Sam's description. Probably because with > a desktop client you can just fetch all messages and don't have to > worry about gaps. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] MAM Sync Strategies
In case anyone else is interested in documenting their MAM strategy, please consider editing this page: https://docs.modernxmpp.org/client/sync/ Thanks! ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Fwd: [Uta] STARTTLS vulnerabilities
We've had this discussion before but for context in this thread: I ignore that as it doesn't make any sense (and follow the second thing and just decide myself how I want to connect). I know at least one or two others do to, but I don't know which strategy is more wide spread. —Sam On Thu, Aug 12, 2021, at 09:16, Holger Weiß wrote: > | Both 'xmpp-' and 'xmpps-' records SHOULD be treated as the same > | record with regard to connection order as specified by RFC 2782 [3], > | in that all priorities and weights are mixed. This enables the > | server operator to decide if they would rather clients connect with > | STARTTLS or direct TLS. However, clients MAY choose to prefer one > | type of connection over the other. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Fwd: [Uta] STARTTLS vulnerabilities
In my experience it's widely supported these days. Out of the 119 providers on the jabber.at server list 74 of them (62%) have xmpps records (though I did not test whether these resulted in a successful connection with a reasonable TLS configuration). I also don't know if clients prioritize these records over starttls. —Sam On Wed, Aug 11, 2021, at 16:13, Philipp Hancke wrote: > tl;dr: its a mess. What is the deployment state of xep-0368? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] MAM Sync Strategies
Hi all, I started a PR against modernxmpp to document MAM sync strategies after a discussion on jdev yesterday: https://github.com/modernxmpp/modernxmpp/pull/41 I wondered if anyone would share what their sync strategy is (or even possibly add it to that PR) so that we can document a few clients and maybe move towards an XEP that outlines one or two ideal ones? I'll start with the one I described in the chat yesterday that's used (experimentally) by Mellium/Communiqué: On client start iterate through all items in the roster. If no messages exist in the local archive: Query in reverse order (in case the server breaks it up by page and we end up committing pages separately) with before: now && limit: X (where X is some configurable number, what we think will fit on the page with some margin, etc.). Otherwise query with after-id: (making sure that the last message was pulled from the DB before we send initial presence). If the user scrolls to the top of the history, query in reverse order with before-id: . Fetch the next page for as long as they continue to scroll up. Thanks, Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Carbons Stream Feature
On Fri, Jul 16, 2021, at 10:49, Jonas Schäfer wrote: > The "immediately after resource binding" was which was led me to > believe that this was about enabling carbons, well, *after* resource > binding, not before. Ah yes, I see; thanks! Will fix. > From (4) onward, it is exactly the same as if carbons had been enabled > pre- resource-binding, with the exception that your resource > technically existed prior to enabling carbons already. As you have not > sent presence before, that doesn't matter, as nobody knows about your > resource anyway. Oh, I see, you just meant "you can enable carbons before sending the initial available presence". I thought I was doing that and still running into this race condition, but you're right and I don't see how this would work. Let me go re-read some of the initial presence language in 6120 or wherever, maybe you're right and this just isn't a problem. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Carbons Stream Feature
On Fri, Jul 16, 2021, at 08:55, Jonas Schäfer wrote: > How is a nonza different from an IQ, if both happen post-resource- > binding, as I understand from your text? This is not what the PR says (see next section). I would be curious what made it sound like that though, this should be fixed but reading and re- reading it I can't find anything that makes me think this. > If the nonza (from the stream feature) were allowed to be sent > *before* resource binding, then there would be an interesting case > where you could announce to the server that you want carbons before > the first message is delivered. It doesn't fix the issue with MAM, but > at least you know that from the point on your resource was bound, you > got a complete picture of all (carbons-eligible) messages received on > the account, which is somewhat nice. That is what I'm trying to fix here and exactly what this does. This is a stream feature that gets negotiated pre-reource-binding and enables carbons immediately after resource binding but before any stanzas can be received. > Though I should mention that you could also simply ignore all incoming > messages until you get a reply to your carbons IQ and you had > approximately the same sync point (due to the in-order requirement of > stanza processing in XMPP). Servers could do this if they *know* the client is planning on enabling carbons, but if that's the case they might as well just enable carbons from the get-go (and that will never be the case). If you mean that clients can do this then I don't understand how it would solve anything, they can just ignore messages, but that seems bad and carbons still wouldn't have been enabled for them which is the point. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Carbons Stream Feature
Hi all, There has been a lot of discussion about bind2 as a potential way to fix the Message Carbons race condition (quick summary: when the connection starts you go to enable carbons with the IQ, but you've already received a few messages that aren't carbon copied before the IQ gets sent). However, bind2 is still in an early unfinished state and even once it's done isn't likely to achieve adoption immediately because it's a bigger XEP than just the single feature that it enables carbons and it does a lot more that people will hae to think about, making its adoption slower (though hopefully still relatively fast). In the mean time I'd like to suggest that carbons just add a simple stream feature and call it a day so that we can stop dealing with the race condition. I've proposed some text here: https://github.com/xsf/xeps/pull/1090 —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Moved 2.0
Another thought: Any spec that triggers traffic to a third party JID based on other incoming traffic can be used for DOS amplification attacks. This one seems only somewhat vulnerable (max payload size of the pubsub element + max JID size bytes) but any of them can also become worse if implementations have flaws (such as naively copying the payload which could also result in any unknown garbage elements on the end being copied, making the attack much worse if vulnerable clients existed). It may be worth mentioning this in the security considerations section, or providing a way to verify by a push from the old account instead of querying it. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Moved 2.0
This is looking good; thanks! I've started an implementation here (currently only supports sending a moved request from the client side): https://github.com/mellium/xmpp/tree/moved2/moved After work I'll add the server side so that I can write some round trip test cases and then move on to what other contacts need to do with the subscription requests and let you know if I run into anything odd. Things will look a lot cleaner once I get a pubsub implementation done too, which I really need to get on at some point. —Sam On Fri, Jun 25, 2021, at 09:05, Jonas Schäfer wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Moved 2.0 Abstract: This specification details a way for a user > to notify their contacts about an account move. > > URL: https://xmpp.org/extensions/inbox/moved2.html > > The Council will decide in the next two weeks whether to accept this > proposal as an official XEP. > ___ > Standards mailing list Info: > https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards- > unsubscr...@xmpp.org > ___________ > -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP Modernization Roundtable Results
Sorry, my notes were getting rapid right at the end and we didn't discuss it all that long. The last thing was basically just "maybe we should have a discussion about bind2; having it would fix the carbons/mam race condition and it's probably higher priority than a lot of the other stuff." —Sam On Tue, Jun 22, 2021, at 13:23, Kevin Smith wrote: > 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 there > already? > > > Carbons/MAM race condition > > > What’s the race condition? I thought that enabling carbons > automatically removed the race condition here. > > /K > > ___ > Standards mailing list Info: > https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards- > unsubscr...@xmpp.org > ___ > -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP Modernization Roundtable Results
Hi all, A few of us just had a quick chat about some XEPs we think need to be modernized. We came to a rough consensus on what we thought would happen, and they're mostly in line with what's been discussed on list. Here are the notes we took: Present: - Sam - MattJ - moparisthebest * XEP-0138: Stream Compression, XEP-0229: Stream Compression with LZW * MattJ: everyone is streaming video on mobile devices so XML is not a big resource hog that we need to worry about anymore * Sam: for large deployments compression can actually save CPU cycles (fewer TLS packets to encrypt) * Moparisthebest: thinks someone (Zash?) argues that a new thing is needed with better negotiation to avoid the security issues * **Recommendation:** deprecate and replace, there are newer algorithms that will need different negotiation (zstd with fixed dictionary?) * XEP-0114: Jabber Component Protocol, XEP-0225: Component Connections * MattJ: it's been a decade, no progress, no real benefit to moving from 0114 but the new one does SASL and TLS * Sam: SASL would be nice, TLS seems like it could just be done directly or w/o the component and servers knowledge and be fine * Sam: structured my XMPP library differently because I knew I'd want multiple different types of stream handshake, maybe it would have been simpler w/o knowing 0114 would be coming in the future * MattJ: chicken-and-egg problem. Not enough gained when switching but we just need implementations in prosody and ejabberd and the ecosystem will follow * Sam: is namespace delegation easier with 0014 or 0225 or completely orthogonal? * moparisthebest: if a new person implements this how do they know which to do? * MattJ: One has green text, one has red text. * MattJ: which is easier if you're implementing from scratch? 0114 easier from scracth, 0225 easier if you have an existing XMPP handshake library to use * **Recommendation:** not high priority, no action needed for now. * XEP-0072: SOAP Over XMPP * **Recommendation:** Obsolete * XEP-0054: vcard-temp, XEP-0153: vCard-Based Avatars, XEP-0292: vCard4 Over XMPP * moparisthebest: make large stanxa sizes * MattJ: trying to move away from vcard-temp in Prosody, not much interest from anyone else (Gajim maybe has newer stuff), official support deprecated in next Prosody (support provided through a backwards compatibility module) * MattJ: privacy controls are in the new version, that would be a benefit to moving but does not create a compelling need to move forward, but it's one less thing to worry about (everything is PEP) * MattJ: one weird thing from a spec perspective is that it defines an IQ to fetch/set vcard, but it's PEP based so you can just use PEP. Maybe get rid of that? * **Recommendation:** * start LC on vcard4, * bring up why it has an IQ and a PEP access method, * hopefully move vcard4 forward * put it in compliance suites (2022?) * bind2? * Carbons/MAM race condition * Persistent device tracking * MattJ: bind2 needs new author or someone with more time then it should be fairly easy * everyone has to leave around this point Thanks for participating, and we hope the council will consider some of these recommendations if they're not already. There were only three of us, so more discussion on list would be great! —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] UPDATED: XEP-0377 (Spam Reporting)
Thinking about this more I wonder if client authors would have a use for a disco#info node that returns the list of supported reporting reasons? Similarly, if we're going to do that, maybe clients don't need to know anything about reporting reasons and the server can return the ones it supports (along with a human readable name) and clients can just display that. This would get rid of the need for the registry and each server could just do whatever it wanted. Thoughts? —Sam On Tue, Jun 22, 2021, at 11:09, Jonas Schäfer wrote: > Version 0.3 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: Rework based on list feedback. (ssw) > > URL: https://xmpp.org/extensions/xep-0377.html > > Note: The information in the XEP list at https://xmpp.org/extensions/ > is updated by a separate automated process and may be stale at > the time this email is sent. The XEP documents linked herein are > up-to- date. > ___ > Standards mailing list Info: > https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards- > unsubscr...@xmpp.org > _______ > -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Un-deferring XEP-0377: Spam Reporting
Thank you, thinking about it more that makes perfect sense. I've submitted an overhaul based on the list feedback that Zash reminded me of. —Sam On Mon, Jun 21, 2021, at 02:55, Dave Cridland wrote: > > > On Sat, 19 Jun 2021 at 12:35, 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. > > It has one or two implementations but I don't know of any services > > actually using it so I don't think it's ready for advancement, but > > it definitely shouldn't be deferred. > > Modulo Kim's comments, there's a simpler answer: > > No. > > If there are no changes to be made, then it's either ready for > enhancement or needs dropping. > > Movement in and out of Deferred is automatic for a reason - it's to > eliminate XEPs which aren't progressing through Experimental. > > We don't require implementations at the Experimental->Draft > transition; we require them at the Draft->Final one. Getting > widespread implementations before Draft is, in fact, a problem to the > process - look at MAM, Carbons, and so on, which end up stuck in > Experimental. > > Because moving things out of Deferred (or stopping them getting there) > is just a minor edit away, there's no need to ask, anyway. But really, > if there's some implementation but you think some more changes will be > needed, then force the issue with a Last Call. > > (In this case, of course, sort through the changes Kim found > discussed, first!) > > Dave. > ___ > Standards mailing list Info: > https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards- > unsubscr...@xmpp.org <mailto:Standards-unsubscribe%40xmpp.org> > ___ > -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Un-deferring XEP-0377: Spam Reporting
oops, thanks, I'll have to go back through those. —Sam On Sat, Jun 19, 2021, at 13:16, Kim Alvefur wrote: > 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 the blocking command, inclusion of stanza-id > references. Not sure if there was anything else. > > Here: > https://mail.jabber.org/pipermail/standards/2017-September/033313.html > https://mail.jabber.org/pipermail/standards/2020-May/037444.html > > -- > Regards, > Kim "Zash" Alvefur > Council member > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Un-deferring XEP-0377: Spam Reporting
Hi editors et al, 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. It has one or two implementations but I don't know of any services actually using it so I don't think it's ready for advancement, but it definitely shouldn't be deferred. —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XMPP Council Agenda 2021-06-16
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 Thanks, Sam On Tue, Jun 15, 2021, at 14:05, Jonas Schäfer wrote: > Hi everyone, > > The next XMPP Council Meeting will take place on 2021-06-16 at 15:00Z > in xmpp:coun...@muc.xmpp.org?join. Everyone is welcome to join and add > to the discussions. > > This agenda is composed from: > > - Editor notifications to standards@ > - xsf/xeps GitHub PRs marked as Needs Council > - xsf/xeps GitLab MRs marked as Needs Council > - Suggestions directly sent to me (see below) > > Agenda as follows: > > 1) Roll Call > > 2) Agenda Bashing > > * Feel free to pre-bash on-list or directly to me if you think > something is missing. > > 3) Editor’s Update > > * Proposed XMPP Extension: Pre-auth Registration Key Generation and > Validation > > 4) Items for voting > > 4a) PR#1064: XEP-0227: New revision 1.1 URL: > https://github.com/xsf/xeps/pull/1064 Abstract: > - Discourage inclusion of plaintext passwords > - Document a format for including SCRAM data > - Define data formats for PEP and MAM data > > 5) Pending Votes > > None. > > 6) Date of Next > > 7) AOB > > 7a) Code of Conduct Experimental Procedural XEP > > 8) Close > > End of Agenda. > > Note that I am aiming for 30 minutes, but meetings may be extended as > necessary if all council members agree. > > Meetings are normally held every Wednesday at 15:00 UTC in the > xmpp:coun...@muc.xmpp.org?join chatroom. Meetings are open, and anyone > (XSF Member or not) may attend, though only XMPP Council members may > vote. Relevant comments from the floor are welcomed. > > Using your web browser, you can join anonymously via > https://xmpp.org/chat?council > > Note that conversations in the room are logged publicly at > https://logs.xmpp.org/council/ > > If you have suggestions for an agenda item, you can message me via > XMPP or email at this address or at jo...@zombofant.net. > > I aim to publish the Agenda on the day before the Council > meeting before > 19:00Z. > > Stay safe, smart & healthy, Jonas > > ___ > Standards mailing list Info: > https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards- > unsubscr...@xmpp.org > ___ > > Attachments: > * signature.asc -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Office Hours: Modernization Roundtable
Hi all, This is a quick reminder (since I forgot to send it out yesterday) that the Office Hours start in 1 and a half hours! Today's topic is a round table discussion about modernizing XEPs. Anything you want to discuss can be added to this list: https://pad.disroot.org/p/XSF_Modernization_Working_Group_Recommendations I hope to see you there! Where: https://socialcoop.meet.coop/sam-pku-dud-niv More info: https://wiki.xmpp.org/web/XMPP_Office_Hours —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proto XEP: Pre-authed IBR Token Format
I wanted to also mention that I have thrown together an example of its use. https://github.com/mellium/fediverse-xmpp-onboarding The example lets you log in with a Mastodon (or probably other fediverse compatible tools) instance and if the account is verified it uses this to generate a token that allows you to register on an associated XMPP server, giving Mastodon communities easy self-provisioning on a related chat network. It is just an example and doesn't look good, but it should "work" (if any servers used the new protoXEP). —Sam On Sun, Jun 6, 2021, at 08:51, Sam Whited wrote: > Hi all, > > I just submitted a protoXEP [1] defining a token format for pre- > authenticated IBR (this has a number of benefits that are covered in > the protoXEP). However, it may be that this belongs in XEP-0445 or XEP- > 0401 instead (I'm not entirely sure what the difference between the > two is). > > I've gone ahead and submitted the PR, but I wanted to start the > discussion before council votes on it as a way to determine where (and > if) this functionality should exist. > > What do you think? > > —Sam > > [1]: https://github.com/xsf/xeps/pull/1068 -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)
> Note also that this is not intended to mean that any XMPP developer's > behaviour will be scrutinised constantly - using, for example, racist > language in a talk about your XMPP project would be problematic here, > but using sexualised language in an unrelated setting is likely to be > irrelevant to this Code of Conduct. While I think it's fine to call out that we won't actively police behavior outside of XSF functions (which seems reasonable), I don't think that makes them irrelevant to the CoC. If we do hear about and verify some egregious behavior outside of the XSF we still may not want that person representing the XSF. If nothing else I'd remove "is likely to be irrelevant to this CoC" and put the decision in the hands of the working group. > please do call it out to that person at the time Should we define how this is done? I assume it means "gently mention that you don't believe this lives up to the CoC in the venue the behavior occurred in or in the chat" and not "post in every single forum you can find about it and include the users home phone number and email". > Who you report it to depends on who was involved in the incident. Can this be clarified? I would assume we'd always want to go to the contact team unless it was a member of the contact team (then maybe the board, or if they're the same, the rest of the board). > The Conduct Team will always hand its recommendation on Sanctions or > other Actions to the Board. The Board will discuss and vote on these > "in camera" (ie, not in public and not minuted). It seems like there's not much point having a conduct team if the board also has to relitigate their decisions. I'd just allow the board to delegate this authority fully (which presumably they could do anyways and this document doesn't curtail board power?) > In high profile cases, the result will be announced publicly. I'd also just say "At the conduct teams discretion" instead of limiting it to "high profile" cases which seems vague and confusing. > While the sanctions described herein are, by their nature, > exclusionary, and much of the behaviour discussed is negative, the > intent is the opposite - we want to maximize inclusion, and promote > positive behaviours. This is great, but feels out of place at the end of a section about appeals. Also a general nit picky note for the editor: all the various hyphens should be converted to em-dashes and "a XEP" should be "an XEP" (I thought? Maybe that's not true in all dialects but I didn't think this is one that would change). Overall this is a great start, thank you! —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Policy XEPS [was: NEW: XEP-0458 (Community Code of Conduct)]
Ü https://redsolution.com > > > <http://www.redsolution.com> > > > > > > ___ > > > Standards mailing list Info: > > > https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: > > > standards-unsubscr...@xmpp.org > > > ___ > > > > > > > ___ > > Standards mailing list Info: > > https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards- > > unsubscr...@xmpp.org > > ___ > > > -- > Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com > <http://www.redsolution.com/> > ___ > Standards mailing list Info: > https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards- > unsubscr...@xmpp.org <mailto:Standards-unsubscribe%40xmpp.org> > ___ > -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XSF (unofficial) Modernization Working Group looking for XEPs to discuss
Hi all, I bumped this to the 15th since I forgot to send out the reminder messages on Monday and then ended up having a busy day yesterday. Sorry for the lack of advanced warning, but we'll do the next office hours on the 15th instead. —Sam On Fri, May 28, 2021, at 10:29, Sam Whited wrote: > Hi all, > > I'm doing another experiment with the office hours. Sometime in the > near future (currently 2021-06-08, but this may change) we're going to > try having a "working" session where we go through a list of XEPs > suggested by you all and write up recommendations for what should > happen to these XEPs. If we don't finish within an hour we will spread > it over multiple days. > > These recommendations won't be actual language or work on any specific > XEP but should be process things like "issue LC", "deprecate", > "obsolete", or "needs rewrite". We'll try to discuss each XEP and come > to consensus on what the future of it looks like, write it up in a > document along with our reasoning and any dissents if we can't come to > consensus, and then present the document to the council (who of course > may or may not choose to use it). > > If this sounds fun to anyone, please submit your ideas of XEPs that > need discussion and work before 08 June to the following list: > > https://pad.disroot.org/p/XSF_Modernization_Working_Group_Recommendations > > Consider setting a name for yourself before you edit and please keep > the list sorted. Thank you! > > —Sam > > -- > Sam Whited -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Proto XEP: Pre-authed IBR Token Format
Hi all, I just submitted a protoXEP [1] defining a token format for pre- authenticated IBR (this has a number of benefits that are covered in the protoXEP). However, it may be that this belongs in XEP-0445 or XEP-0401 instead (I'm not entirely sure what the difference between the two is). I've gone ahead and submitted the PR, but I wanted to start the discussion before council votes on it as a way to determine where (and if) this functionality should exist. What do you think? —Sam [1]: https://github.com/xsf/xeps/pull/1068 -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP Advancement Shortlist
XEP-0153: vCard-Based Avatars XEP-0054: vcard-temp XEP-0055: Jabber Search XEP-0072: SOAP Over XMPP XEP-0114: Jabber Component Protocol XEP-0131: Stanza Headers and Internet Metadata XEP-0138: Stream Compression XEP-0145: Annotations XEP-0149: Time Periods XEP-0153: vCard-Based Avatars XEP-0160: Best Practices for Handling Offline Messages XEP-0181: Jingle DTMF XEP-0185: Dialback Key Generation and Validation XEP-0220: Server Dialback XEP-0229: Stream Compression with LZW XEP-0234: Jingle File Transfer XEP-0292: vCard4 Over XMPP XEP-0334: Message Processing Hints XEP-0385: Stateless Inline Media Sharing (SIMS) (Dedup with OOB?) XEP-0423: XMPP Compliance Suites 2020 -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XMPP Office Hours: ad-hoc commands and forms with Mellium demo
Hi all, Sorry I forgot to send this out yesterday. Today's Office Hours are a demo of using ad-hoc commands and forms with Mellium. We'll demo using ad-hoc commands to draw forms and we'll discuss some problems with the spec and how they could be resolved. I hope to see you there! https://wiki.xmpp.org/web/XMPP_Office_Hours —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XSF (unofficial) Modernization Working Group looking for XEPs to discuss
On Sat, May 29, 2021, at 15:40, Dave Cridland wrote: > "Working Group" does have a particular meaning in the standards world, > but I was more concerned with the "XSF" prefix, yes. Oops, didn't realize that was in there, I've changed the title. > It does not, and as noted, I didn't say the words in quotation marks. Those were supposed to be a paraphrase of what you said, I think that was clear enough given that we were in an email thread where your exact words were readily available and also quoted in my reply. I think they were a reasonable paraphrase, but I apparently still don't understand what's going on or how any of this relates to a round table discussion, so maybe I'm wrong. > > Dave's issue is probably that the outcome of such a discussion is > > potentially submitted and accepted into a XEP. And suppose later, a > > participant of that discussion claims part of the submission as his > > work, but is unwilling (or unable) to agree to XSF's IPR policy. In > > that case, the XEP could be viewed as tainted. > > > > That, yes. I'd hope the problem - figuring out where the text came > from and whether the author agreed to the IPR policy - would be > spotted earlier than that, though, but that would just mean the > contribution getting rejected, meaning lots of people have wasted > their time. > > > But I don't see how this is different if the discussion took > > place on a XSF mailing list (or even at the XSF summit). I don't > > remember agreeing that every idea I express on an XSF mailing > > list is automatically covered by the IPR policy when subscribing > > to the list. > > > > That is a whole other problem. I didn't understand this section. We're not writing an XEP, we're having discussions about what should happen with existing XEPs. > > Hence suggesting that such a venue requires XSF approval appears to > > me just inflicting unnecessary bureaucracy. > > > > Well, we can flip it around - if our existing discussion venues are > insufficient, then that's clearly a bug, and how do we fix that? I don't know if they're insufficient or not, but a round table is a nice casual venue that makes a good addition to everything else. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XSF (unofficial) Modernization Working Group looking for XEPs to discuss
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, but "it's concerning if anyone discusses XEPs outside the XSF" is not a position that makes any sense and we absolutely don't need permission form the board or council to go ahead as planned. We're going to go ahead and discuss some XEPs. Naturally, the council doesn't have to take any recommendations we come up with. —Sam On Sat, May 29, 2021, at 05:47, Dave Cridland wrote: > > > On Sat, 29 May 2021 at 04:10, Sam Whited wrote: > > I don't understand how this would have anything to do with IPR, can > > you expand on that? > > > > Our IPR rules dictate that the XSF owns the IPR in our XEPs, and also > the contributions to them. This is straightforward and simple on a > mailing list, or a formal XSF activity like a summit. > > Outside of the XSF, things get murky, since if your group suggests > changes, we're going to need to get IPR assignments from all of them. > > And if you're saying this is, and I quote, an "XSF Modernization > Working Group", then things get murkier still, when it's not an XSF > activity at all. > > To be very clear here, I think the actual goal here, and indeed the > format, is great. With my Council hat on, I'm absolutely 100% > behind this. > > But with my XSF Member hat on, and my XSF Board hat on, I'm concerned > that this looks very like an XSF activity but isn't one, and I'm > concerned that there are potential risks here. > > So what I'd like to propose is that we put this on hold for a bit, and > get consensus from the membership and sanction from the Board to turn > this into a virtual XMPP Summit (or mini-summit, or something). > There's a delay involved because we'll need to get this sorted at the > next Board meeting on Thursday, although I'm fine with trying to get > agreement from the Board beforehand if the consensus from the > membership is clear enough, and I'm happy to help seek and frame that > consensus. > > How does that sound? > > Dave. > > > The idea is just to have a discussion about a bunch of XEPs and > > where they are in the process. This sort of thing normally happens > > on the mailing list, but getting a bunch of people in a room > > together (more or less) is also a good way to generate ideas and > > spark discussion. > > > > —Sam > > > > On Fri, May 28, 2021, at 14:54, Dave Cridland wrote: > > > Hey Sam, > > > > > > I'm a little worried about this, and how it squares with our IPR > > > policies. > > > > > > What do you feel can't be done within the XSF here? > > > > > > Dave. > > > > > > On Fri, 28 May 2021 at 15:31, Sam Whited > > > wrote: > > > > Hi all, > > > > > > > > I'm doing another experiment with the office hours. Sometime in > > > > the near future (currently 2021-06-08, but this may change) > > > > we're going to try having a "working" session where we go > > > > through a list of XEPs suggested by you all and write up > > > > recommendations for what should happen to these XEPs. If we > > > > don't finish within an hour we will spread it over multiple > > > > days. > > > > > > > > These recommendations won't be actual language or work on any > > > > specific XEP but should be process things like "issue LC", > > > > "deprecate", "obsolete", or "needs rewrite". We'll try to > > > > discuss each XEP and come to consensus on what the future of it > > > > looks like, write it up in a document along with our reasoning > > > > and any dissents if we can't come to consensus, and then present > > > > the document to the council (who of course may or may not choose > > > > to use it). > > > > > > > > If this sounds fun to anyone, please submit your ideas of XEPs > > > > that need discussion and work before 08 June to the following > > > > list: > > > > > > > > https://pad.disroot.org/p/XSF_Modernization_Working_Group_Recommendations > > > > > > > > Consider setting a name for yourself before you edit and please > > > > keep the list sorted. Thank you! > > > > > > > > —Sam > > > > > > > > -- > > > > Sam Whited > > > > ___ > > >
Re: [Standards] XSF (unofficial) Modernization Working Group looking for XEPs to discuss
I don't understand how this would have anything to do with IPR, can you expand on that? The idea is just to have a discussion about a bunch of XEPs and where they are in the process. This sort of thing normally happens on the mailing list, but getting a bunch of people in a room together (more or less) is also a good way to generate ideas and spark discussion. —Sam On Fri, May 28, 2021, at 14:54, Dave Cridland wrote: > Hey Sam, > > I'm a little worried about this, and how it squares with our IPR > policies. > > What do you feel can't be done within the XSF here? > > Dave. > > On Fri, 28 May 2021 at 15:31, Sam Whited wrote: > > Hi all, > > > > I'm doing another experiment with the office hours. Sometime in the > > near future (currently 2021-06-08, but this may change) we're going > > to try having a "working" session where we go through a list of XEPs > > suggested by you all and write up recommendations for what should > > happen to these XEPs. If we don't finish within an hour we will > > spread it over multiple days. > > > > These recommendations won't be actual language or work on any > > specific XEP but should be process things like "issue LC", > > "deprecate", "obsolete", or "needs rewrite". We'll try to discuss > > each XEP and come to consensus on what the future of it looks like, > > write it up in a document along with our reasoning and any dissents > > if we can't come to consensus, and then present the document to the > > council (who of course may or may not choose to use it). > > > > If this sounds fun to anyone, please submit your ideas of XEPs that > > need discussion and work before 08 June to the following list: > > > > https://pad.disroot.org/p/XSF_Modernization_Working_Group_Recommendations > > > > Consider setting a name for yourself before you edit and please keep > > the list sorted. Thank you! > > > > —Sam > > > > -- > > Sam Whited > > ___ > > Standards mailing list Info: > > https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards- > > unsubscr...@xmpp.org > > ___ > ___ > Standards mailing list Info: > https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards- > unsubscr...@xmpp.org <mailto:Standards-unsubscribe%40xmpp.org> > ___ > -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XSF (unofficial) Modernization Working Group looking for XEPs to discuss
Hi all, I'm doing another experiment with the office hours. Sometime in the near future (currently 2021-06-08, but this may change) we're going to try having a "working" session where we go through a list of XEPs suggested by you all and write up recommendations for what should happen to these XEPs. If we don't finish within an hour we will spread it over multiple days. These recommendations won't be actual language or work on any specific XEP but should be process things like "issue LC", "deprecate", "obsolete", or "needs rewrite". We'll try to discuss each XEP and come to consensus on what the future of it looks like, write it up in a document along with our reasoning and any dissents if we can't come to consensus, and then present the document to the council (who of course may or may not choose to use it). If this sounds fun to anyone, please submit your ideas of XEPs that need discussion and work before 08 June to the following list: https://pad.disroot.org/p/XSF_Modernization_Working_Group_Recommendations Consider setting a name for yourself before you edit and please keep the list sorted. Thank you! —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Office Hours today moved back 1 hour!
Hi all, Today's office hours are a Gajim 1.4 Preview by Philipp Hörist. Please note that the time has been moved back by 1 hour to 1700 UTC at the request of the presenter. I hope to see you there! Where: https://socialcoop.meet.coop/sam-pku-dud-niv More info: https://wiki.xmpp.org/web/XMPP_Office_Hours Signup and Schedule: https://calc.disroot.org/jek96xaqjvlb —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XMPP Office Hours: "Intro to JMAP" by Daniel Gultsch, 2021-04-27 1600 UTC
Reminder that tomorrow is the XMPP Office Hours! We hope to see you there for "Intro to JMAP" by Daniel Gultsch. When: 2021-04-27 1600 UTC Where: https://socialcoop.meet.coop/sam-pku-dud-niv More info: https://wiki.xmpp.org/web/XMPP_Office_Hours —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XMPP Office Hours: Intro to XMPP, April 20th at 16:00 UTC
Absolutely; it will be recorded! —Sam On Tue, Apr 20, 2021, at 09:29, Bill Munyan wrote: > Hello, > Would it be possible to make this presentation available on whatever > youtube channel you've posted to before? I'd like to attend this > presentation but unfortunately have conflicts that can't be rescheduled. > > Cheers, > -Bill M. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XMPP Office Hours: Intro to XMPP, April 20th at 16:00 UTC
Hi all, It's that time of the week again! This week for the XMPP Office Hours I am giving a technical introduction to XMPP. We'll discuss how a connection is created, stanza semantics, and a quick overview of some useful XEPs. If you're an experienced XMPP developer please join us and provide feedback on the presentation (I give something like this at work on occasion and would love to make sure it captures the most useful information), or invite your technically minded friends who might be interested in getting involved! We hope to see you there! When: 2021-04-20 16:00 UTC Where: https://socialcoop.meet.coop/sam-pku-dud-niv Info: https://wiki.xmpp.org/web/XMPP_Office_Hours Signups/schedule: https://calc.disroot.org/jek96xaqjvlb -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Round Table Discussion: Towards XMPP 2.0
Join us tomorrow (Tuesday, April 13th) for a round table discussion about the features, changes, additions, deletions, and other things we'd like to see done in a hypothetical XMPP 2.0. There will be a moment for agenda bashing before we start the meeting, so bring your best ideas for discussion! * When: 2021-03-13 16:00 UTC * Where: https://socialcoop.meet.coop/sam-pku-dud-niv * More info: https://wiki.xmpp.org/web/XMPP_Office_Hours -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Office Hours: "Cryptographic Identity: Conquering the Fingerprint Chaos" on 6 April 16:00 UTC
Hi all, it's that time of the week again! Tomorrow we have a brand new presentation of the XMPP Office Hours! * What: "Cryptographic Identity: Conquering the Fingerprint Chaos" * Who: Paul Schaub (vanitasvitae) * When: Tuesday, 6 April 16:00 UTC * Where: https://socialcoop.meet.coop/sam-pku-dud-niv * More info: https://wiki.xmpp.org/web/XMPP_Office_Hours * Signup and schedule: https://calc.disroot.org/jek96xaqjvlb See you there! —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Disabling message history when MAM is being used
Hi all, Currently a lot of clients use one tiny piece of XEP-0013: Flexible Offline Message Retrieval to purge offline messages and stop them from being sent when that client will use MAM to retrieve messages anyways (and therefore doesn't need the offline messages). However, this feels like a bit of a hack. Disabling offline messages probably shouldn't be required at all if you're using MAM, or doing so shouldn't rely on one tiny part of an old XEP that's no longer used. Bind 2.0 (XEP-0386) also implements this functionality, so that's one option. Alternatively, we could move this functionality into MAM, or find a way for the server to detect MAM and just implicitly disable offline messages. And of course all of this could be in a new XEP if necessary. Any thoughts on what should be done here? —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Office Hours: 17:00 UTC March 31st "Soprani.ca: bridging us all together" by singpolyma
Join us Wednesday March 31st at 17:00 UTC, for the XMPP Office Hours! This week we have a talk by Stephen Paul Weber (singpolyma) titled "Soprani.ca: bridging us all together"! More info at https://wiki.xmpp.org/web/XMPP_Office_Hours Meeting room: https://socialcoop.meet.coop/sam-pku-dud-niv See you there! —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Office Hours Time Change?
Hi all! After next Week (which is a different date/time at the presenters request) I have tentatively moved the "default" time slot for the office hours to Tuesdays at 16:00 UTC. This seems to be the time that works best for the most people. Thank you to everyone who has attended so far, and thanks to everyone who filled out the time slot survey! —Sam On Tue, Mar 16, 2021, at 08:38, Sam Whited wrote: > If you've missed my constant pestering about trying to get a series > of short talks together recently, see here first for the signup sheet > and agenda! > > https://wiki.xmpp.org/web/XMPP_Office_Hours ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Office Hours: 17:00 UTC March 26th "Designing Message Styling" by Sam Whited
Join us Friday March 26th at 17:00 UTC, for the XMPP Office Hours! This week we have a talk by Mellium developer Sam Whited (me!) on "Designing Message Styling"! More info at https://wiki.xmpp.org/web/XMPP_Office_Hours Meeting room: https://socialcoop.meet.coop/sam-pku-dud-niv See you there! —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] March 19th Office Hours: "Verifying A/V calls with OMEMO"
Join us tomorrow, March 19th, for a talk by Conversations developer Daniel Gultsch on verifying A/V calls with OMEMO at 17:00 UTC! More info at https://wiki.xmpp.org/web/XMPP_Office_Hours See you there! —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0313 (Message Archive Management)
On Tue, Mar 16, 2021, at 16:20, Jonas Schäfer wrote: > This message constitutes notice of a Last Call for comments on > XEP-0313. Thank you! > 1. Is this specification needed to fill gaps in the XMPP protocol >stack or to clarify an existing protocol? Yes, this specification is already widely implemented across the public network. > 2. Does the specification solve the problem stated in the introduction >and requirements? Yes, it works quite well. > 3. Do you plan to implement this specification in your code? If not, >why not? Yes, I have an implementation in progress. It requires more dependencies than I would like, and I don't feel like it's as simple as it could be, but given how widely adopted it is already I don't think it's worth trying to further modify it and we should advance it. > 4. Do you have any security concerns related to this specification? Not yet. > 5. Is the specification accurate and clearly written? Some of the dependencies around forms can be hard to untangle, but people seem to have done well enough given how widely implemented it is. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Office Hours Time Change?
If you've missed my constant pestering about trying to get a series of short talks together recently, see here first for the signup sheet and agenda! https://wiki.xmpp.org/web/XMPP_Office_Hours --- Hi all, A few people suggested the current time of Friday's at 1700 UTC doesn't work for them, so I'm sending out a survey to the community: what time works best for you if you'd be interested in attending our office hours? This weeks will likely remain the same, but next week or the week after we can reschedule if a substantial number of people can't make the Friday time slot. Assume dates are the day of the week, not the specific date listed in the poll please. Also be sure to select the correct timezone at the top. Your name isn't actually needed if you don't want. Thanks! https://whenisgood.net/kr97tfy —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XMPP Office Hours
Thanks Paul! And don't forget to sign up to give a talk! ;) —Sam On Fri, Mar 12, 2021, at 08:20, Paul Schaub wrote: > Hi Sam, > > that's a great initiative! I'll note it down in my calendar :) > > Paul ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XMPP Office Hours
Hi all, Several places I've worked and a co-op I recently joined do weekly "office hours" where anyone can sign up to do a short talk on a topic of interest to them. I'd like to see something like this for XMPP, and have decided to give it a shot. Topics could be anything from a round-table discussion about a protocol you'd like to see improved, to a presentation on your new favorite feature in your client or server and why you're proud of it. Maybe you want to walk us through a new XMPP-adjacent project you recently found, or explain how your day job is utilizing XMPP. If no topic is chosen, we'll just have an XMPP-themed happy hour, so break out your favorite beverage and join us. Talks will take place on Fridays at 1700 UTC (we can change this if necessary). Up-to-date info: https://wiki.xmpp.org/web/XMPP_Office_Hours Signup: https://calc.disroot.org/jek96xaqjvlb Please sign up for topics and fill the slots; see you there! —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Message Carbons authors and LC
I definitely second this then, Georg would be a great maintainer. Since it keeps having last calls, keeps being used and working well enough, and then no changes end up being made, I think we might as well continue to request LCs until some changes are made or it actually passes :) Maybe having a new official author would help with that. —Sam On Thu, Mar 11, 2021, at 11:48, Georg Lukas wrote: > As somebody who has done the most non-editorial changes on the XEP in > the last six years, and saw (and contributed to) it failing Last Calls > in 2020, 2019, 2018, 2017, and 2015, I'd be glad and honored to > volunteer as the new maintainer. > > However, given the history of Last Calls, I can not make any promises > to successfully get the XEP into Draft status. > > > Kind regards, > > Georg > > ___ > Standards mailing list Info: > https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards- > unsubscr...@xmpp.org > ___________ > > Attachments: > * signature.asc -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Message Carbons authors and LC
Hi all, The authors of message carbons haven't been active for a while if I'm not mistaken. Do we have any current authors? If not, I'd like for us to consider appointing someone (I am also happy to volunteer, but others who have been more involved with these discussions may be a better choice) or just sending it to LC again if the editors would be so kind. Thanks! —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Message Styling Test Suite
Hi all, After chatting earlier with someone who was implementing XEP-0393: Message Styling and answering a few questions about how things should be styled, I decided to export my tests in a language-agnostic format. Feel free to use these to test your own implementations. I'm ~99% sure they're compliant with the text. https://gist.github.com/SamWhited/55e35347a7eb6df60c0b1df67db76f05 A few notes: Exactly where new lines belong may be different in your implementation (eg. it doesn't necessarily matter if a newline is counted as part of the "end pre formatted text" directive or as the next plain line after the directive), not all implementations will be token based so you may need to do extra work to get this into a format you can use if yours isn't, there are some styles that don't correspond to actual tokens or concepts in the spec that are just provided as a convenience (ie. the "BlockQuoteEnd" style doesn't apply to any actual text, but is included after quotes so you know where they should end). Let me know if you notice anything that appears to be broken or wrong. —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0393 styling directive logic still incorrect
Nevermind then; got confused after a discussion over chat. This is exactly what I wanted, thanks for the help. —Sam On Tue, Feb 23, 2021, at 13:22, Tedd Sterr wrote: > Greedy matching means take as many characters as you can while still > satisfying the condition, i.e. find the longest match. Lazy matching > means take the first match you find, i.e. find the shortest. > > In the form of regular expressions, we have: > * greedy = /\*.+\*/ > * lazy = /\*.+?\*/ > > The text is already correct. -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0393 styling directive logic still incorrect
Hi all, I recently made a change to XEP-0393 that attempted to clarify the rules for span selection (https://github.com/xsf/xeps/pull/1001). However, the text is *still* wrong and does not match the examples. The text says: > Spans are always parsed from the beginning of the byte stream to the > end and are lazily matched. However, all of the examples (including the updated ones from the last change) are *greedily* matched. > *strong* plain *strong* > *strong*plain* If these were lazily matched only the outermost asterisks would be styling directives. Can anyone sanity check me on this? If we make this change to the text it won't break any of the examples as far as I can see, and I think this was just a simple typo on my part, but I wanted to follow up and ask here first. —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Council Minutes 2021-02-03
I believe this is only allowed between first-level elements elements per RFC 6120 § 11.7, so it will likely break something if used elsewhere (outside of nodes that are meant to contain text, that is). On Wed, Feb 17, 2021, at 10:50, drew.var...@ninefx.com wrote: > Whitespace in between elements. This does not include the SASL stuff > where we cannot have it. > > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Slummit 2021 - Tales
Copied from a draft of an upcoming blog post. Further reading moved to the front for easy access: - Docs: https://pkg.go.dev/mellium.im/xmpp@master - Website: https://mellium.im/xmpp - A Message Styling retrospective: https://blog.samwhited.com/2020/11/message-styling/ - An overview of the Mellium project and its design: https://blog.samwhited.com/2020/06/xmpp-in-go/ - A guide to designing (not programming) XMPP related Go packages: https://blog.samwhited.com/2020/02/extensions-in-mellium/ --- Last year the main Go module of the Mellium project, [`mellium.im/xmpp`] received a huge number of updates, bug fixes, and API overhauls, many of which will be released in the upcoming `v0.18.0` release. Some of the highlights include: - WebSocket support - The ability to negotiate multiple virtual hosts - More server side implementations of stream features such as SASL and resource binding - An implementation of [Message styling][XEP-0393] - [Chat marker][XEP-0333] support - Support for [XEP-0202: Entity Time][XEP-0202] and [XEP-0082: XMPP Date and Time Profiles][XEP-0082] - Integration testing against common servers and clients - Better fallback behavior when looking up XMPP servers - Easier sending of IQs without having to think about XML tokens - Easier APIs for registering handlers against specific IQ payloads - XMPP URI and IRI parsing support The full (much longer) list can be found in the [changelog]. [changelog]: https://mellium.im/xmpp/changelog ## Message Styling The change to `mellium.im/xmpp` that I'm most proud of in the past year might be the Message Styling implementation which can be found at [`mellium.im/xmpp/styling`]. The actual styling implementation comprises three parts: the [`Style`] type, the `Scan` function, and the [`Decoder`] type. The [`Style`] type is a `uint32` that represents a bitmask of styles such as "strong and emph" or "pre-formatted text and block quoted". It only contains information about the styles, not about metadata related to the styles or the token stream. For example, given a style you can know that the text is in a blockquote, but not the level of nesting (if any) of the blockquote, or you might know that it is in a strong span, but not where the start and endpoints of that span are. The package provides the various styles and a handful of masks for various common combinations as constants for the users convenience. For more, see my retrspective post, [_Message Styling_][Message Styling]. ## Stream Initialization and Virtual Hosts XMPP servers likely want to serve more than one domain, but prior to the upcoming v0.18.0 release this was difficult or impossible. This required changes to the [`Negotiator`] type to allow input and output streams to be stored on the session, and to the built-in `Negotiator`'s [`StreamConfig`] type which is used for configuring options on the built in default negotiator to allow the user to select the features in a callback. Unfortunately, these are breaking changes, but it should be one of the last major API changes before we can begin thinking about stabilizing the API in v1.0.0. The `S2S` option was also removed from the `StreamConfig` in favor of new functions for receiving and negotiating a stream which mark the s2s state bit on the session before beginning negotiation. This removes a long standing redundancy, and also a bug where the first stream feature negotiated wouldn't know that the session was a server-to-server session because it couldn't be set until the negotiator function returned for the first time. The current list of stream negotiation functions is: - [`DialClientSession`] - [`DialServerSession`] - [`DialSession`] - [`NewClientSession`] - [`NewServerSession`] - [`NewSession`] - [`ReceiveClientSession`] - [`ReceiveServerSession`] - [`ReceiveSession`] [`Negotiator`]: https://pkg.go.dev/mellium.im/xmpp#Negotiator [`StreamConfig`]: https://pkg.go.dev/mellium.im/xmpp#StreamConfig [`DialClientSession`]: https://pkg.go.dev/mellium.im/xmpp#DialClientSession [`DialServerSession`]: https://pkg.go.dev/mellium.im/xmpp#DialServerSession [`DialSession`]: https://pkg.go.dev/mellium.im/xmpp#DialSession [`NewClientSession`]: https://pkg.go.dev/mellium.im/xmpp#NewClientSession [`NewServerSession`]: https://pkg.go.dev/mellium.im/xmpp#NewServerSession [`NewSession`]: https://pkg.go.dev/mellium.im/xmpp#NewSession [`ReceiveClientSession`]: https://pkg.go.dev/mellium.im/xmpp#ReceiveClientSession [`ReceiveServerSession`]: https://pkg.go.dev/mellium.im/xmpp#ReceiveServerSession [`ReceiveSession`]: https://pkg.go.dev/mellium.im/xmpp#ReceiveSession ## Testing While it's not an exciting user-facing feature, one of the most valuable changes this year has been the addition of integration testing against [Prosody], Ejabberd, McAbber (Loudmouth), and `sendxmpp(1)`. We've already caught several issues both in Mellium and in some of the services we're testing against thanks to the new tests! This is all facilitated by the
Re: [Standards] Proposed XMPP Extension: Implicit XMPP WebSocket Endpoints
On Wed, Feb 3, 2021, at 13:42, Sonny Piers wrote: > Because the XEP is not for me. > > My goal is to let xmpp(.js) users say this is the service (as domain) > I want to connect to - I don't care how just establish an XMPP > connection there. This doesn't seem consistent with your previous statement that I was responding to: On Wed, Feb 3, 2021, at 12:29, Sonny Piers wrote: > I suggest we forget about public deployments, looks like the only > valid use case for this proposal is to have default endpoints for non- > public facing services (CI, localhost, development, ...) Maybe I'm misunderstanding? —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Implicit XMPP WebSocket Endpoints
In that case, why have an XEP at all? If you're doing anything like this you don't need the defaults to be standardized across services to aid in interop, you just know what your servers default is and can just connect to it. —Sam On Wed, Feb 3, 2021, at 12:29, Sonny Piers wrote: > I agree with the points raised, but I suggest we forget about public > deployments, looks like the only valid use case for this proposal is > to have default endpoints for non-public facing services (CI, > localhost, development, ...) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Implicit XMPP WebSocket Endpoints
Making some integration tests easier without a concrete use case for real world XMPP seems like a bad reason to increase complexity and make a large change to websocket discovery and fallback. If this is just for integration tests, why does it need to be standardized and added to everything else's fallback behavior? You know where the server lives, so just connect to it and call your integration tests done. —Sam On Wed, Feb 3, 2021, at 11:09, Florian Schmaus wrote: > Again, my personal motivation steems from Smacks' integration test > suite and the XMPP server I use to run those against. I have access to > port 443, but setting up XEP-0156 would involve multiple steps, > including > - setup webserver > - setup TLS certificate > - create XRD which I avoided simply by using the proposed XEP. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Implicit XMPP WebSocket Endpoints
A question since I know nothing about web development:
If we accept it as true for the sake of argument that you might want to
run an XMPP server but not have access to run an HTTP server on the
domain you want to use, can you not use the TXT record format from
JavaScript land to get the records specified in XEP-0156? I know there
is no native "DNS lookup" API, but DNS over HTTP is a standardized thing
and there are public providers these days (or you can run your own, but
the point is that you can use a public provider if you have limited
access to services).
For example, if you wanted to use Coudflare's public DNS over HTTP
service you could do something like:
httpRequest = new XMLHttpRequest();
httpRequest.open('GET',
'https://cloudflare-dns.com/dns-query?name=conversations.im=SRV');
httpRequest.setRequestHeader('accept', 'application/dns-json');
httpRequest.Send();
And you'd get back a JSON blob full of SRV records. Would this be bad to
do for some reason since it is a standard now and other DNS providers
are adopting it (so even if you can't run your own there are choices)?
—Sam
On Wed, Feb 3, 2021, at 02:28, 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 connection endpoints for XMPP over WebSocket
> (RFC 7395).
>
> URL: https://xmpp.org/extensions/inbox/xep-iwe.html
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Re: [Standards] Proposed XMPP Extension: Implicit XMPP WebSocket Endpoints
Oops, this is not true, I copied over my last paragraph into a new email and then right as I was about to send it realized it couldn't possibly work at all. —Sam On Wed, Feb 3, 2021, at 08:20, Sam Whited wrote: > Alternative coming in a separate email since I think it might be a > separate thread. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Implicit XMPP WebSocket Endpoints
On Wed, Feb 3, 2021, at 03:19, Florian Schmaus wrote: > XMPP service operators may not always have the according HTTPS > endpoint under their control In what situation would you not have the HTTPS endpoint? If you only have an XMPP server config and can't modify anything else, it doesn't seem unreasonable to say "you can't run websockets in your very restricted setup, sorry". I'd love for as many people as possible to be able to run an XMPP server, but at some point you are administering a server and need to have enough access to actually setup and administer things. > Furthermore, it imposes additional steps when configuring your XMPP > service for WebSocket connectivity. I do agree that setting up an HTTP server or configuring DNS records can be an annoying burden, but it doesn't seem big enough that we should try to work around it for the sake of a handful of people who have a very restricted setup. We already have issues with servers that don't setup SRV records for the normal TCP protocol and you have to guess if they're using 5222, or the legacy TLS port, or TLS on 5222, etc. we shouldn't add to that guessing game. > But as I said, I found the implementation of implicit endpoints > trivial in Smack. It is far easier than implementing xep156. And, as > you correctly identified, clients could use implicit endpoints only if > no xep156 information is found. This is part of the problem, as Daniel pointed out. I don't see this as widely useful but if we do implement it it's easier so fewer people will do it the "right" way and the less useful thing becomes the defacto initial implementation. I'm sure it's trivial to implement, but that doesn't mean we should standardize it. > Yes, "lazy" and non-standard compliant clients cause trouble and > frustration. But I most cases those clients are to blame, not the > standard/specification/protocol. I see how this is similar to the XHTML- > IM discussion, so this is likely a subjective matter. I don't believe that's a subjective matter in either case. If you make the easiest thing to do the wrong thing, clients will do it. That's their fault, but it's also our fault for not designing protocols that are robust in the face of human error. We can't prevent every lazy client dev from doing bad things, but we can certainly try to make the default the easy thing. That being said, I don't think it's nearly as bad if we add an implicit fallback for websockets, I just don't think it's necessary either and adds complexity for little to no benefit. > Eventually, it is a trade-off, and I believe the benefits of having > implicit endpoints specified overweight the risk of client > implementations become lazy. I still don't understand what these benefits are. A message to this list to help me understand what the tradeoffs are would be helpful I think. Is it just that a handful of people might not be able to run an HTTP server? That seems like it's likely a very tiny (possibly "empty") group of situations to cater too. > 1: That is also the reason the ProtoXEP's implicit connection endpoint >specification matches what ejabberd uses per default. If we do end up adopting this protocol, we should not use the defaults from Ejabberd. The endpoint "/ws" is too generic and may conflict with other HTTP endpoints on services that run more than just XMPP on their domains. If anything let's use "/xmpp-websocket" which is used in all the examples in RFC 7395 so that we at least sort of "namespace" the endpoint to XMPP land and make it obvious what it's for / make conflicts less likely. Alternative coming in a separate email since I think it might be a separate thread. —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Announcing Slummit 2021
If we're streaming any of this for public consumption please let's also stream it on YouTube. We need to meet people where they're at, and for video streaming that's YouTube. We can of course do PeerTube too if people want that, but most of the public are on YouTube. —Sam On Thu, Jan 28, 2021, at 08:48, goffi wrote: > Le 2021-01-28 10:29, Dave Cridland a écrit : > > 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! > >> > >> Reply in this thread with a few short paragraphs about what you've > >> been working on, participating in, any projects you feel others > >> should be made aware of, or anything XMPP-related that you think > >> others would find interesting. Feel free to include a link to a > >> longer, more detailed description elsewhere, but provide a > >> digestible summary first. > > > > Great idea! I shall start writing one, and post it later. > > > >> Additionally, if there's interest, I was considering organising a > >> few voice/video call mini-conferences for groups of 3-7 people > >> (larger groups become a communication burden), each focusing on a > >> particular topic. (Dates 3-5 Feb, times according to participants' > >> availability.) > > > > Can I suggest roadcast panel discussions instead? ie, lots of > > viewers, few speakers? > > > > Also are you going to participate, or just lurk in the background > > and write excellent minutes? > > > > Dave. > > ___ > > Standards mailing list Info: > > https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards- > > unsubscr...@xmpp.org > > ___ > > Hi, > > Maybe peertube (https://peer.tube/) could be used here ? I think it's > doing live streaming now, and we can pre-record talks and have a > questions sessions over a MUC room. Other option would be of course > Jitsi Meet, depending of number of attendees. > > I can write also a paragraph about what I'm working on, and would be > interested to do a short talk too. > > Regards Goffi > ___ > Standards mailing list Info: > https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards- > unsubscr...@xmpp.org > ___ > -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: DOAP usage in XMPP
On Thu, Jan 14, 2021, at 19:07, Mathieu Pasquet wrote: > thhus projects not publishing the file would be less accessible, which > is the current status). This is one of the reasons I am furious that we're seriously considering adopting this format for use on the website. This is absolutely not okay. > Second, I do not believe for a second that someone as computer > literate as an XMPP client/library/server author would have trouble > with an RDF XML representation. Well lucky you, but I have tried to do this multiple times and have no idea how to even verify that what I have done is correct, or have ended up finding out that bits of it aren't correct later. I'm sure that with a great amount of effort I could figure it all out, but that's exactly the problem, I shouldn't have to put in effort just to write up some simple metadata. > I do not mean to say that understanding the whole "semantic web" > technologies is easy or fast, but it is not actually required to write > a proper DOAP file. How can I even confirm that my DOAP file is correct? How do I discover the various properties that I can put in it? So far I've just been linked to various giant XML blobs which is not helpful. > (slightly offtopic, but the concept of RDF/Turtle/N- Triples was > introduced as a simple representation even before learning a > programming language in my first year of university) I don't know what any of those things are (except for some vague knowledge that RDF is a thing because we've been talking about it), but if you have to have it introduced at university it's too complicated for use describing simple metadata. They certainly didn't teach us a bunch of random XML concepts in school, thank goodness. > I would still argue that DOAP is the most widely-used and widely- > supported format across the board, given that the alternative is > something hand-rolled with the same fields that we need to write > tooling for and maintain. We apparently have to maintain a spec and custom namespaces either way and integrate with a complicated format. That's more work than just outlining a few standard key-value names and throwing them in an XML file. We can write tooling for the new thing if we want (and I will do it if people really want it), but if you need tooling just for some metadata you're already doing it wrong, which is the point I'm trying to make. If it's a normal XML format without tons of namespaces and schema imports and what not we don't have to do anything but pull out a few values and stick them up on the website which is trivial to do in JavaScript or Python (which I think the website's generator is written in, IIRC). What's not trivial is pulling in and validating various schemas. > There is a standard format, there are tools to query it, tools to > validate it, and writing it is not hard (and there are very few things > with bikeshedding potential in it). I'm just going to repeat this again because it's important and I believe a valid criticism: if I have to learn a bunch of tooling just to put a bit of metadata on my website it's over engineered and needs to stop. > I agree that the protoxep state is still a good moment to raise > serious objections or propose alternatives, but “I do not like it and > here is the same thing in json with no well-defined semantics and > please write new tools for it and maintain it” is not a stance I can > take very seriously. I presented an XML format too, I don't really care what it is, let's just define a few key value pairs and say "here's the info you need, here's an XML (or whatever) example". It's good enough. > I also fail to see how using this format would be “harmful” It's over complicated and you're putting all the burden on the people writing it. You will lose projects who would otherwise provide valid metadata because they'll try, it will be incorrect, and they'll give up, or they'll take a look at the "documentation" I keep being linked (a giant blob of XML) and not do it in the first place. Complexity is a problem, and this is about as complex as you can get to just store a few tiny bits of metadata. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: DOAP usage in XMPP
It wasn't becoming a standard 1.5 years ago so I tried to implement it, couldn't ever even figure out a way to verify if what I had was right, and decided it was pointless. Now it's becoming an XEP, so now is the time to raise objections to it being standardized or used on the website so that I can't list my client if I don't write this garbage format. On Thu, Jan 14, 2021, at 16:25, Jonas Schäfer wrote: > On Mittwoch, 13. Januar 2021 22:59:23 CET Sam Whited wrote: > > I hate to go down the rabbit trail of what "widely used means" but > > we seem to have different definitions of that too. The vast majority > > of projects on the web do not appear to use this format. Some do, > > but they seem to be a very small minority (albeit from a very very > > small sample of me searching specifically for projects that do use > > it, which should weight towards using it, and then picking a bunch > > of random projects that I use myself and seeing which ones use it). > > > > I am not concerned with making something that is perfect over > > something that is good, I would settle for something that is > > mediocre over actively harmful and bad. > > > > If effort is the concern, I will happily create and document an > > alternative just to avoid the over engineered mess we seem to want > > to find ourselves in. > > Oh, and to add: This was first brought up in July 2019 [1], discussion > was furthered a month later and you have been silent for > 1.5 years on this -- starting to complain after people have invested > is not fair to anyone. > > regards, Jonas > >[1]: https://mail.jabber.org/pipermail/standards/2019-July/036307.html > ___ > Standards mailing list Info: > https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards- > unsubscr...@xmpp.org > ___ > > Attachments: > * signature.asc -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: DOAP usage in XMPP
On Thu, Jan 14, 2021, at 16:23, Jonas Schäfer wrote: > Will you also go ahead and rewrite the code which has already been > written for DOAP integration [1]? Will you also go ahead and port the > projects which already have DOAP files? Will you also continue to put > effort in this? A handful of projects in XMPP land have DOAP files. There is an implementation for the website which is really nice, but it can't be that hard to change the XML it uses. Just because there are like 2 uses of a thing already doesn't mean we should make it the defacto standard. If that's the case, I have about a dozen random XMPP extensions that we never should have created new XEPs for, like the original message attaching which worked differently and was used by HipChat, or the original channel binding notification stuff that I have implementations for. It's perfectly fine to make changes to existing technologies before we put them in XEP form. This protocol is absolutely not okay, people have been complaining about the problems with XML for years, and we just keep doing the same stupid things that will make no one else want to use our protocol. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: DOAP usage in XMPP
I hate to go down the rabbit trail of what "widely used means" but we seem to have different definitions of that too. The vast majority of projects on the web do not appear to use this format. Some do, but they seem to be a very small minority (albeit from a very very small sample of me searching specifically for projects that do use it, which should weight towards using it, and then picking a bunch of random projects that I use myself and seeing which ones use it). I am not concerned with making something that is perfect over something that is good, I would settle for something that is mediocre over actively harmful and bad. If effort is the concern, I will happily create and document an alternative just to avoid the over engineered mess we seem to want to find ourselves in. On Wed, Jan 13, 2021, at 21:49, Dave Cridland wrote: > And just on this, it does seem to be widely used, but even if it > weren't, this is the only format people are putting effort into within > our community. Something else might be Perfect, but this is Good, with > all that that entails. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: DOAP usage in XMPP
I disagree, this is a handful of simple strings that need to be defined, we could document everything we need in an XEP and have it reference able from a single place trivially. If the council is worried about bike shedding they could shut that down easily because the absolute specifics of how everything is named don't really matter. We don't have any compatibility concerns because we don't need to be compatible with other open source projects and don't need to have them consume our projects since it's just a tiny bit of metadata for building the website. These drawbacks aren't as bad as having to learn 4 or 5 separate technologies just to figure out how to tell people where my license file lives or what my email is. —Sam On Wed, Jan 13, 2021, at 21:47, Dave Cridland wrote: > It's not great, I agree, but it's much better than inventing our own > from scratch. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: DOAP usage in XMPP
Where even are any of the values in this format defined? The DOAP link in the proto XEP just links to a giant blob of XML which is not useful. Every time I go through trying to create one of these I end up with a million questions that I can't actually get answers to. This format is not that widely used and isn't actually useful. Just as a quick example, if I wanted to set the property that I see used in the example, what are the valid values? Or is it text? Can I have multiple of them? Are they comma separated, or multiple elements? etc. None of that is defined by this XEP, and I don't know where I would even start to find out. On Wed, Jan 13, 2021, at 20:27, Matthew Wild wrote: > On Wed, 13 Jan 2021, 19:43 Sam Whited, wrote: > > I do not believe this is an appropriate technology whether it's an > > existing specification or not. It's just too complicated. > > It's really not. It's also easy to generate, so feel free to have a > different canonical format for your projects (a Lua DSL does tempt me, > personally...). > > But for external tools to collect and gather data from an array of > projects, DOAP is the existing standard interchange format for this > kind of data and we should use it. > > The alternative is some custom format that we will need to bikeshed, > document, version and maintain. I'm not keen on it. > > Regards, Matthew > ___ > Standards mailing list Info: > https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards- > unsubscr...@xmpp.org > ___ > -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: DOAP usage in XMPP
I do not believe this is an appropriate technology whether it's an existing specification or not. It's just too complicated. —Sam On Wed, Jan 13, 2021, at 19:35, Dave Cridland wrote: > > > On Wed, 13 Jan 2021 at 18:24, Sam Whited wrote: > > I'd like to recommend that we do not publish this spec in its > > current form. The XML community has the tendency to over-engineer > > everything to try and reuse schemas as much as possible which just > > makes things more difficult for no reason. This is a handful of > > simple key/value pairs, it doesn't need to use RDF or whatever the > > "schema" prefix means. > > > > If this spec is moved forward please consider either adding a JSON > > representation since this is mostly for the web and is effectively > > just a set of key-value pairs which probably makes JSON a better > > format for storing it, or a simplified XML representation that can > > be completely defined in this document and exists in a single > > namespace. > > I was under the impression that DOAP was an existing deployed > specification, and that the use of RDF/XML wasn't unexpected. > > In particular, it appears that both Mozilla and PyPI seem to use it, > so assuming reuse of existing standards is our thing - and > presumably that is exactly our thing - then use of DOAP seems like > the right choice. > > Dave. > ___ > Standards mailing list Info: > https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards- > unsubscr...@xmpp.org > ___ > -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: DOAP usage in XMPP
I'd like to recommend that we do not publish this spec in its current form. The XML community has the tendency to over-engineer everything to try and reuse schemas as much as possible which just makes things more difficult for no reason. This is a handful of simple key/value pairs, it doesn't need to use RDF or whatever the "schema" prefix means. If this spec is moved forward please consider either adding a JSON representation since this is mostly for the web and is effectively just a set of key-value pairs which probably makes JSON a better format for storing it, or a simplified XML representation that can be completely defined in this document and exists in a single namespace. —Sam On Wed, Jan 13, 2021, at 16:08, Jonas Schäfer wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: DOAP usage in XMPP Abstract: This specification defines how > XMPP projects can provide a machine- readable description of their > abilities, and how external entities can interact with it. > > URL: https://xmpp.org/extensions/inbox/doap-usage-in-xmpp.html -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Council Minutes 2020-12-09
That makes sense, thanks. I'll think about how the examples can be clarified going forward. —Sam On Tue, Dec 22, 2020, at 16:18, Kim Alvefur wrote: > On Tue, Dec 22, 2020 at 03:17:04PM +0000, 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 Experimental. > > This should be taken in the context of how every time I look at > Dialback, I get everything backwards and end up confused. > > I intend to follow up with some questions later. > > -- > Kim "Zash" Alvefur > > ___ > Standards mailing list Info: > https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards- > unsubscr...@xmpp.org > _______ > > Attachments: > * signature.asc -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Council Minutes 2020-12-09
I'm not actually sure what this means, do you have more specific feedback about the XEP that I can fix? Thanks! —Sam On Tue, Dec 22, 2020, at 14:55, Kim Alvefur wrote: > With the number of entities that can be involved in multiplexing it > can quickly become confusing and hard to keep track of everything. I > encourage the author to not be afraid of being explicit, verbose and > possibly even redundant. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Character counting in message bodies
I believe this is a mischaracterization of my argument. My argument is "everything will have a way to get at the underlying bytes, not everything will have them pre-converted into code points". Also "this gives us the option to do certain optimizations on systems that support them, but using code points doesn't so we should do the thing that is the most flexible". —Sam On Wed, Dec 9, 2020, at 19:09, Tedd Sterr wrote: > Regardless, your argument is still "bytes is more convenient for me, > so everyone else should do what's best for me." I don't think that's a > good argument. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Character counting in message bodies
I don't think this is true. XML is defined as UTF-8 (in this case), which is a collection of bytes. They don't have to be separated out and transformed into some higher representation of code points. Just because Python et al. convert things into UTF-32 strings first doesn't mean everything has to. Regardless of what language you're using it's trivial to deal with this as a UTF-8 byte stream, it is not always trivial to handle this as a UTF- 32 integer stream as the example shows. —Sam On Wed, Dec 9, 2020, at 14:03, Tedd Sterr wrote: > The decoding _should_ be done upfront - that's how you get a valid XML > document. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Character counting in message bodies
To try and show why I'm pushing back on this so hard here is an example of doing this three different ways: one assuming the references are bytes, two assuming the references are code points. https://play.golang.org/p/kKbr2hXd56U The third one I was forgetting I can do, and it looks quite nice (if we ignore the performance cost as people seem to want to do) but we can't do any error handling for reasons explained in the comments. If we're a client this may not matter, it's not the end of the world if we show the user a reference that starts or ends with an ugly error character box or something, if we're the server this might matter more, either way, I think having a sane way to do error handling on bad references is a requirement: Of course, this is Go specific but the solutions probably look similar in other C-like languages. I should also note that this is using a higher level decoding API than I am using, but it doesn't matter since the extra boilerplate required to do this at the lower- level where you get byte slices out would look the same for the first two examples. However it would require extra work for me to do the third example (because it would give me []byte, not a string) which makes it even less practical and the third example isn't a convenience that exists in eg. C, so generally it's worth just ignoring. If I'm having to pick between the code in the first and second example, please let me pick the first. —Sam On Tue, Dec 8, 2020, at 22:13, Sam Whited wrote: > The XML library I use does not give me a string or slice of code > points, it gives me a slice of bytes because that's the level I'm > operating at. Even at the higher level if I decode the bytes into a > string (A Go string in this case), that is still just a slice of UTF-8 > bytes (it does not decode them, ensure they're valid, and turn them > into a slice of code points, that is a very expensive operation that > it avoids until you need it or explicitly do it yourself). > > I don't understand how this is part of the XML data model. Do you mean > that only Unicode encodings are supported by XML? If so, that's fair > and removes one of my arguments, I did not know that was the case. > However, I still think the data on the wire should describe the other > data on the wire, not some higher- level "decoded" representation that > many XML libraries may not even use. > > —Sam > > On Tue, Dec 8, 2020, at 21:32, Jonas Schäfer wrote: > > But all implementations which want to be XMPP and XML 1.0 compliant > > need to have some way to convert or offer access to code points, as > > that’s the XML data model. Let’s build on that. > > > > Easy choice. > > > > Much easier than writing 20 emails on this topic, and that just in > > this thread. > ___ > Standards mailing list Info: > https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards- > unsubscr...@xmpp.org > ___ > -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Character counting in message bodies
The XML library I use does not give me a string or slice of code points, it gives me a slice of bytes because that's the level I'm operating at. Even at the higher level if I decode the bytes into a string (A Go string in this case), that is still just a slice of UTF-8 bytes (it does not decode them, ensure they're valid, and turn them into a slice of code points, that is a very expensive operation that it avoids until you need it or explicitly do it yourself). I don't understand how this is part of the XML data model. Do you mean that only Unicode encodings are supported by XML? If so, that's fair and removes one of my arguments, I did not know that was the case. However, I still think the data on the wire should describe the other data on the wire, not some higher- level "decoded" representation that many XML libraries may not even use. —Sam On Tue, Dec 8, 2020, at 21:32, Jonas Schäfer wrote: > But all implementations which want to be XMPP and XML 1.0 compliant > need to have some way to convert or offer access to code points, as > that’s the XML data model. Let’s build on that. > > Easy choice. > > Much easier than writing 20 emails on this topic, and that just in > this thread. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Off-by-one error in XEP-372 "References"
Oh yes, of course. I see what you're saying now. —Sam On Sat, Dec 5, 2020, at 01:24, Andrew Nenakhov wrote: > сб, 5 дек. 2020 г. в 05:12, Sam Whited : > > > > > > > > On Fri, Dec 4, 2020, at 23:34, Andrew Nenakhov wrote: > > > 4. Start = first character (inclusive) and length = length of a > > >substring. > > > > This is the same as "1. Start = first character (inclusive), end = > > last character (exclusive);" > > No. > > string: abcdefgh > > 4. start = 3, length = 2. Result: de > > With 1, it would be: > > 1. start = 3, end = 5. Result: de > > > > > -- > Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com > ___ > Standards mailing list Info: > https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards- > unsubscr...@xmpp.org > ___ > -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Off-by-one error in XEP-372 "References"
On Fri, Dec 4, 2020, at 23:34, Andrew Nenakhov wrote: > 4. Start = first character (inclusive) and length = length of a >substring. This is the same as "1. Start = first character (inclusive), end = last character (exclusive);" —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
