waqasThe "Character counting in message bodies" thread on the Standards ML is mildly amusing, we haven't had one of these in a while.
KevI hope I helped with that :)
waqasIt's basically a "someone is wrong on the internet" thread
edhelasdo we have somewhere a full list of forbidden characters for JIDs ?
jonas’Kev, I liked your email :D
jonas’also, can someone point me at an XML library which really gives you the raw bytes on the wire and how it handles entities? :)
jonas’because if we’re going to count bytes on the wire, we obviously also have to count the bytes used for entities.
jonas’"have fun with *that*"
Ge0rGI was very much interested in the IoT hot-path where you really need the body character counts, but jonas’ kind of already raised this question.
flowI think statements like these and "…much easier than writing 20 emails on this topic" are potentially harmful, as they could interpreted as an attempt to suppress discussion. I found the thread insightful (at least some parts of it).
jonas’flow, ok, noted, thanks for the feedback
jonas’I am a bit annoyed by the thread because I had essentially the same discussion already a few years back when I brought this specification gap up in References.
KevAs far as I can see, it should be codepoints.
flowjonas’, I get that, but that is probably more an indication that we are not good in transforming those discussions into a specification
flowKev, nice try ;)
mathieui(as long as I don’t have to transform my unicode codepoints into entities again to be able to use this XEP I will be happy with the result, so I’m staying out of that discussion)
jonas’flow, yeah, because nobody makes a final call
jonas’mathieui, oh, why not? don’t you want to guess whether the sender used = instead of 'a' everywhere?!
flowKev, nice try ;) (or was that not an attempt to resurfcace that discussion here?)
jonas’mathieui, oh, why not? don’t you want to guess whether the sender used a instead of 'a' everywhere?!
mathieuithat would be fun
Kevflow: I wasn't trying to start discussion, I was saying that to me the case is clearcut for codepoints.
Ge0rGjonas’: but what if you want to highlight the "#"?
Kev(Commenting as the References author)
jonas’I should write an XML serialiser which creates the most expanded version possible of any character data
Ge0rGthe recent MS Teams "important, spoofing" issue makes me want to stuff U+0000 into an xmpp message and see where it gets killed.
Kevjonas': Take that, "nobody makes a final call" ;p
jonas’Ge0rG, libexpat and libxml2 throw errors at you when they encounter it on the input
jonas’so at least prosody should kill your stream
jonas’not sure what ejabberd does
waqasjonas’: I think wrapping each character in CDATA is the best you can do
waqasNo wait, empty CDATA sections are legal, so you can do a lot better
jonas’waqas, oh, that means infinite expansion… let us omit CDATA sections from considerations then :)
waqasGe0rG: \0 isn't a legal XML character. CDATA sections, entities, etc don't let you work with non-legal characters, they are more an alternate encoding, but work with the same characters.
Ge0rGwaqas: I know. But it wouldn't be the first time for illegal characters going places.
ZashYou know what doesn't have character counting problems? Embedded markers. Perhaps we could use some special characters to "mark up" sections that have some special meaning.
waqasGe0rG: You can probably target pseudo-XML parsers that some servers have, e.g., Tigase I think was pretty liberal
Ge0rGZash: yes, let's use the zero-width-space as an escape character, followed by an xml element defining the markup
ZashOr we could use <> since those are special in xml
waqasI think counting bytes or code points is a mistake, we should instead count graphemes, as that corresponds to what is rendered and the user sees!
Zashwaqas: that position is taken already
Ge0rGwaqas: ITYM grapheme clusters.
jonas’let’s count rendered CSS pixels
jonas’(as opposed to device pixels)
Zashjonas’: I was just about to type 'what about pixels'
waqasWe'll just need to include the font and font-size, etc used for rendering, and then we are all set
Ge0rGhow do you treat off-screen hidden text?
waqasOr does that need to be configurable?
jonas’waqas, no, obviously that’s all available from context.
emusHi, I know this is a religious question (no troll): But when one wants to if a client runs on Unix... can I just say Linux? 😅️
Zash"Do you mean *nix or UNIX®?"
Zash> when one wants to if a
accidentally a word?
emusOkay, doesnt matter really
emusThe XMPP Newsletter for November 2020 is out!
This is the last newsletter for this year! Thanks to everyone contributing!
Read about an important circumstance regarding certificates to all parties involved in XMPP! Also updates for several clients and servers!
wurstsalatargh, typo "comming year", my bad
emus😩️ - no, really wurstsalat - you did a great job on the XEP section, you are excused!
SeveNeustradamus: let us know if you can read the future
arcShh. He can.
arcBut he can only write about it in the perspective of a 16th century astrologer
emusNeustradamus, we are happy for new contributors and reviewers to reduce time on drafting and reviewing.
ZashCould just call it The Newsletter
Neustradamusemus: With new system, I can not contribute into... Badly.
emus^^ we have "signifcant growth" since this year (seeing email stats). I guess most subcribers are happy 😊️ and also from the personal feedback I receive
emusWhy you cannot?
Zashemus: Hm, if it's published just before the end of $month, with a Call To Action™ at the end of "did we miss something from tomorrow? tell us in the comments/repliy to the tweet/whaever"...
emuszash, I dont understand what you mean?
ZashCover november-01 to 28, publish on 29, ask people to reply with the cool thing that wasn't in the newsletter in order to generate more noise. Not entirely serious.
Zashand also make sure cool thing happens on the 29 that people can reply with.
ZashAnyways, don't listen to me, I can't into marketing.
emushehe. I personally think it wont really make a change. I introduced the two review phases to get things less pressure on the team and have more time to ensure quality and force everyone to get done in one night (we also dont have the ressources). I think many people read it rather like a summary of the month, or not as hard into the XMPP development as most here are. I think this request comes from a very different perspective than most readers.
emusFor me that is mostly a question of ressources. If I need to squash things together, I cannot do that usually in one evening alone
emusand also I dont want to do this alone
wurstsalat> For me that is mostly a question of ressources. If I need to squash things together, I cannot do that usually in one evening alone
+1 I'm happy with how it works at the moment
emusYes, and I will go with what the contributors can manage currently
emusneustradamus - what is your exact problem with this?
emusI see the links, but what is the issue you have=
NeustradamusLook links, date
Neustradamushttps://github.com/xsf/xmpp.org/issues/638 it is not solved yet.
emusOkay, I see, but lets be honest I is too old to fix on that. but what is it with the other links?
emusAnd even more imporant, what is preventing you from contributing to the Newsletter?
ZashCool URLs don't change.
NeustradamusFebruary: https://xmpp.org/2020/02/newsletter-04-february/ -> https://xmpp.org/2020/02/newsletter
April: https://xmpp.org/2020/04/everyone-go-for-decentralisation-03-apr-2020 -> https://xmpp.org/2020/04/newsletter
July: https://xmpp.org/2020/07/newsletter-01-july/ -> https://xmpp.org/2020/07/newsletter
August Part 1: https://xmpp.org/2020/08/newsletter-06-august/ -> https://xmpp.org/2020/08/newsletter-1
August Part 2: https://xmpp.org/2020/08/newsletter-08-august/ -> https://xmpp.org/2020/08/newsletter-2
October: https://xmpp.org/2020/09/newsletter-09-september/ -> https://xmpp.org/2020/10/newsletter
November: https://xmpp.org/2020/10/newsletter-10-october/ -> https://xmpp.org/2020/11/newsletter
December: https://xmpp.org/2020/11/newsletter-11-november/ -> https://xmpp.org/2020/12/newsletter
emusNeustradamus, I dont see why we need to change the links now. I personally lag the knowledge for this. I can offer you the following, if you want to commit anything to the next release in February 2021 you join the MUC and if you write up a news you have you can post it there and we can commit that to the next draft. However, the PR your self should work, we always provide a direct link from now on. I see you already have a Github account. So that should work
NeustradamusDo not forget that I have been the last Communication team member.
I have contributed several years before the new draft system on GitHub which has a lot of problems (bad link names, bad publication dates)
Harmonization needs to be done to solve all problems.
The problem is not new and people keep... Strange.
emusI am happy for support, but I cannot do that my self 🤷♂️️
NeustradamusIn more when you click on the date of all publications:
NeustradamusIt is easy, create a PR with perfect name to all files.
emusI dont see the problem with creating a PR right now? Anyway, Im out for today
NeustradamusYou can see: https://github.com/xsf/xmpp.org/issues/638
-> https://xmpp.org/2019/01/the-xmpp-newsletter-31-january-2018/ -> https://xmpp.org/2019/01/newsletter
It will be remove the bad link problem "January 2018" in "January 2019"