Re: [Standards] XEP-0384: Staleness of devices

Note, I’m not familiar with OMEMO and it’s ratchet system, so take this with a grain of salt. On Dienstag, 28. August 2018 13:26:51 CEST Paul Schaub wrote: > Another countermeasure against stale devices is sending empty > ratchet-forward messages on a regular basis. Those messages do have the >

Re: [Standards] XMPP Council Agenda 2018-08-08

On Dienstag, 7. August 2018 19:38:36 CEST Dave Cridland wrote: > 3) Items for voting: > > [None!] Uh. I’d like to mention: - https://github.com/xsf/xeps/pull/693 - https://github.com/xsf/xeps/pull/692 - https://github.com/xsf/xeps/pull/690 Those have been added since the last meeting. While I

Re: [Standards] XMPP Council Minutes 2018-08-01

On Montag, 6. August 2018 17:25:57 CEST Tedd Sterr wrote: > 3d) Proposed XMPP Extension: Schrödinger's Chat - > https://xmpp.org/extensions/inbox/muc-selfping.html Georg has submitted an update for the ProtoXEP which I merged today. You can find the updated version at the same address. kind

[Standards] XEP-0060: pubsub#dataform_xslt (yes, but why?)

Hi all, So while running the XEP-0060 node_config data form [1] through the thing which builds aioxmpp code to process it, I came across this funny field: I was at first confused, but then figured out that this is an XSLT which can be applied to the payload in the node items to extract a

Re: [Standards] XEP-0060: "entity element" should be "subscription element"

On Freitag, 27. Juli 2018 18:09:35 CEST Melvin Vermeeren wrote: > I am not yet familiar with sending patches for XEPs. Could someone either > make the change or give me some directions? Thanks. There are basically two ways to do this, as Ralph already told: 1. By opening a pull request against

Re: [Standards] [XEP-0384] OMEMO: xml:lang + max_items

On Freitag, 27. Juli 2018 17:07:52 CEST Philipp Hörist wrote: > > but instead limit their queries to the newest item. > > They cant, because thats an optional feature of the Server. They could still execute the limit on the client side. kind regards, Jonas signature.asc Description: This is a

Re: [Standards] [XEP-0384] OMEMO: xml:lang + max_items

On Freitag, 27. Juli 2018 16:41:57 CEST Philipp Hörist wrote: > I think this is a good addition to the XEP, although i fear this would be a > namespace bump, but from practical experience every PEP impl sends only the > last item, so this is until now a academic problem This wouldn’t be a

Re: [Standards] UPDATED: XEP-0198 (Stream Management)

On Mittwoch, 25. Juli 2018 15:44:02 CEST Guus der Kinderen wrote: > Changelog date is off by a year, I think? Well spotted. Will fix. signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info:

Re: [Standards] Proposed XMPP Extension: File Sharing Notifications

On Montag, 23. Juli 2018 16:26:45 CEST Ненахов Андрей wrote: > сб, 21 июл. 2018 г. в 1:46, Tedd Sterr : > > > I'd rather call it 'extended chat state notifications' or something > > > like that. Recording audio is only distantly related to file sharing. > > > > "Media Stream Activity

Re: [Standards] Proposed XMPP Extension: File Sharing Notifications

On Mittwoch, 18. Juli 2018 17:34:08 CEST Jonas Wielicki wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. Again, the ProtoXEP has been updated. Available under the same URL. > Title: File Sharing Notifications > Abstract: > This specification provides a

Re: [Standards] Proposed XMPP Extension: File Sharing Notifications

On Donnerstag, 19. Juli 2018 15:28:20 CEST Jonas Wielicki wrote: > On Mittwoch, 18. Juli 2018 17:34:08 CEST Jonas Wielicki wrote: > > URL: https://xmpp.org/extensions/inbox/fsn.html A few more remarks. I’d normally against giving non-critical feedback in ProtoXEP stage,

Re: [Standards] Proposed XMPP Extension: File Sharing Notifications

On Mittwoch, 18. Juli 2018 17:34:08 CEST Jonas Wielicki wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. The proposal has been updated. The new version (0.2.0) is available under the same address as before. > Title: File Sharing Notifications >

Re: [Standards] Proposed XMPP Extension: File Sharing Notifications

On Mittwoch, 18. Juli 2018 17:34:08 CEST Jonas Wielicki wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: File Sharing Notifications > Abstract: > This specification provides a notification protocol for information > about ongoing file

Re: [Standards] File sharing states for XEP-0085: Chat State Notifications

On Dienstag, 17. Juli 2018 16:07:28 CEST Linus Jahn wrote: > On Tue, 17 Jul 2018 15:36:06 +0200, Jonas Wielicki wrote: > > Yes. Not tying this to seems like a good idea for > > flexibility. My suggestion would be to put your new elements next to > > the exist

Re: [Standards] File sharing states for XEP-0085: Chat State Notifications

On Dienstag, 17. Juli 2018 15:09:16 CEST Linus Jahn wrote: > Hello Matthew and Ненахов, > thank you for your answers. > > On Mon, 16 Jul 2018 13:59:23, Matthew Wild wrote: > > Authoring a new XEP for this case would not be hard. Take a look at > > https://xmpp.org/about/standards-process.html

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

On Mittwoch, 11. Juli 2018 04:02:23 CEST Kim Alvefur wrote: > Hello list, > > I have implemented tombstones for destroyed MUC rooms. My reading of the > sacred texts did not give me enlightenment as how to inform someone > who's attempting to enter the remains of such a place. I've so far opted >

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

On Samstag, 23. Juni 2018 13:28:54 CEST Tedd Sterr wrote: > Contrary to vicious rumours floating around, I have no interest in > supplanting Dave's position as Chair. With only a few hours remaining and > no agenda forthcoming, I thought a meeting with some agenda would be better > than with none

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

First of all, thanks to Georg for making Sam clarify his position, which I misread similarly. Thanks to Sam for clarifying, this makes *much* more sense now. I think you two rehashes the key parts. I’d like to chime in as a developer who recently implemented support for the MUC voice request

Re: [Standards] Business rules of Last Message Correction

On Montag, 11. Juni 2018 18:29:50 CEST Tedd Sterr wrote: > Upon receiving an RMC message, an LMC client would check whether the ID > matches its last message and see that it doesn't -- the first business rule > suggests that means it is a correction to a message directed to another > resource, and

Re: [Standards] NEW: XEP-0409 (IM Routing-NG)

So here comes my feedback to this. > URL: https://xmpp.org/extensions/xep-0409.html First of all, I like how this worked out. I think the compatibility between IM-NG and non-IM-NG realms is well-addressed. Kevin really did some good work distilling the lengthy discussion we had in the weeks

Re: [Standards] XMPP Council Minutes 2018-05-30

On Mittwoch, 6. Juni 2018 18:42:47 CEST Dave Cridland wrote: > I really don't want to have any IQ based flows prior to login if possible - > with my server-dev hat on, I find it worrying to have to do deep inspection > of IQ stanzas during pre-auth. With my client hat on, I agree 100%. But SASL2

Re: [Standards] Proposed XMPP Extension: Ephemeral Messages

On Mittwoch, 6. Juni 2018 13:13:23 CEST Marcel Waldvogel wrote: > I understand that time synchronization is important, but I would > recommend not to burden XMPP with timer synchronization. We do have a > reliable NTP infrastructure including pool.ntp.org; mobile devices > often have the

Re: [Standards] XMPP Council Minutes 2018-05-30

On Mittwoch, 6. Juni 2018 16:52:27 CEST Sam Whited wrote: > I'm not af an of how this one was done. -1 for now. I'd like to discuss how > this can be done better though; it seems to me that it would fit very well > as part of extensible IBR and/or SASL2. I agree that IBR or SASL2 or whatever

Re: [Standards] XMPP Council Agenda 2018-06-06

Hi Dave, you seem to have missed: https://github.com/xsf/xeps/pull/653 which Needs Council and has been open for a few days. Can this be appended to AOB or the main Agenda? kind regards, Jonas signature.asc Description: This is a digitally signed message part.

Re: [Standards] NEW: XEP-0409 (IM Routing-NG)

On Dienstag, 5. Juni 2018 11:26:46 CEST Jonas Wielicki wrote: > Version 0.1.0 of XEP-0409 (IM Routing-NG) has been released. > > Abstract: > This specification provides a new set of routing rules for modern > instant messaging. > > Changelog: > Accepted by vote of Cou

Re: [Standards] Addressing for IQs in MIX-CORE

On Montag, 4. Juni 2018 15:37:00 CEST Kevin Smith wrote: > On 4 Jun 2018, at 12:15, Dave Cridland wrote: > >> On 4 June 2018 at 11:37, Steve Kille wrote: > >> > >> To support IQs in MIX-CORE, there needs to be an addressing and routing > >> scheme. > >> > >> I am proposing that this uses a

Re: [Standards] Another proposal - Handling JIDs for MIX-CORE, MIX-PRESENCE and MIX-PAM

On Sonntag, 3. Juni 2018 01:33:12 CEST Steve Kille wrote: > Sam's message made me realize that none of the variant 1/2/3/4 stuff is > needed for MIX-CORE.There are some things that might be needed in > MIX-ANON, but let's worry about these in the MIX-ANON spec and keep them out > of MIX-CORE.

Re: [Standards] Another proposal - Handling JIDs for MIX-CORE, MIX-PRESENCE and MIX-PAM

On Sonntag, 3. Juni 2018 09:29:13 CEST Daniel Gultsch wrote: > 2018-06-03 1:33 GMT+02:00 Steve Kille : > > (Nick and Bare JID). > > I’m just on my way home from a very productive and interesting meetup > with designers and artists. And without knowledge of the current MIX > debate - just by

Re: [Standards] MIX Addressing

On Freitag, 1. Juni 2018 09:21:45 CEST Kevin Smith wrote: > On 31 May 2018, at 20:12, Jonas Wielicki wrote: > > On Donnerstag, 31. Mai 2018 13:45:06 CEST Kevin Smith wrote: > >> We’ve had some discussions recently about whether presence should come > >> from > &g

Re: [Standards] MIX Addressing

On Freitag, 1. Juni 2018 09:29:15 CEST Kevin Smith wrote: > > So here’s a straw-man proposal, Variant 3 (because, creating many variants > > is what we’re good at!): > > > > An occupant is identified by an occupant-identifier. The occupant JID is > > occupant-identifier@mix-service. The channel

Re: [Standards] MIX Addressing

On Donnerstag, 31. Mai 2018 13:45:06 CEST Kevin Smith wrote: > 1) Stick with proxy JIDs and user%channel@domain[/resource] (or similar), > with the resource missed off for bare-JID traffic, where > ‘user%channel@domain’ as the proxy JID is the user’s identifier used > everywhere. > 2) Drop proxy

Re: [Standards] MIX Addressing

On Donnerstag, 31. Mai 2018 13:45:06 CEST Kevin Smith wrote: > We’ve had some discussions recently about whether presence should come from > the channel’s JID, the user’s proxy JID, or be encoded in pubsub. Similarly > whether messages should be coming from the channel’s JID or the user’s > proxy

Re: [Standards] Taking a Machete to MIX

On Montag, 21. Mai 2018 18:06:30 CEST Tedd Sterr wrote: > My point is that it's difficult to tell what's mandatory and what's > optional, and so it's still going to require combing through all eight > documents first to find out what's necessary and second to decide what's > desirable. I’ve heard

Re: [Standards] Proposed XMPP Extension: Terms of Services

Hi, Thanks for your feedback, Ivan. On Mittwoch, 23. Mai 2018 16:38:08 CEST Ivan Vučica wrote: > --- > 4.2.1.1 Protocol support required > > If the client did not include a element in the initiating > request and the server requires support for the Terms of Service protocol, > it replies with

Re: [Standards] Proposed XMPP Extension: Terms of Services

On 22 May 2018 22:02:16 CEST, Jonas Wielicki <jo...@wielicki.name> wrote: >The XMPP Extensions Editor has received a proposal for a new XEP. > >Title: Terms of Services >Abstract: >This specification provides an in-band, unauthenticated way to request >the Terms of Se

Re: [Standards] XMPP Council Agenda 2018-05-16

On Donnerstag, 17. Mai 2018 15:11:45 CEST Kevin Smith wrote: > Although I was -1 yesterday on HACX, I’d like to update that to +0. I think > there’s sufficient difference in business rules that having its own number > might not be inappropriate. It would still make sense to re-base it to re-use

Re: [Standards] Maintaining a list of ongoing conversations

On Montag, 14. Mai 2018 12:28:17 CEST JC Brand wrote: > I'm interested in finding a way to keep track of ongoing conversations and > whether any new messages were added to them since the user was last online. > > I think this is the so-called "Inbox" feature that was brought up at the > 2018

Re: [Standards] Disappearing timers for OMEMO proposal

On Sonntag, 13. Mai 2018 15:37:18 CEST Alexander Krotov wrote: > On Sun, May 13, 2018 at 12:40:40PM +0200, Jonas Wielicki wrote: > > On Sonntag, 13. Mai 2018 00:07:32 CEST Alexander Krotov wrote: > > > For unencrypted timed messages we need to require hinting the server

Re: [Standards] Disappearing timers for OMEMO proposal

On Sonntag, 13. Mai 2018 00:07:32 CEST Alexander Krotov wrote: > For unencrypted timed messages we need to require hinting the server > not to store the message, by the way. You do realize that this will make the user not see the message, at all, ever, if their only clients supporting Timers

Re: [Standards] Disappearing timers for OMEMO proposal

On Samstag, 12. Mai 2018 19:55:52 CEST Paul Schaub wrote: > Hi! > > I get what you want to achieve, but I think it would be easier to define > disappearing messages for general XMPP (not only OMEMO). > > As already stated, you cannot trust devices that announce support, to > actually delete

Re: [Standards] Disappearing timers for OMEMO proposal

On Samstag, 12. Mai 2018 15:31:41 CEST Alexander Krotov wrote: > On Sat, May 12, 2018 at 10:45:49AM +0200, Florian Schmaus wrote: > > On 12.05.2018 10:14, Alexander Krotov wrote: > > > On Fri, May 11, 2018 at 10:24:35AM +0200, W. Martin Borgert wrote: > > >> Quoting Alexander Krotov

Re: [Standards] UPDATED: XEP-0369 (Mediated Information eXchange (MIX))

On Freitag, 11. Mai 2018 15:27:53 CEST Jonas Wielicki wrote: > Version 0.10.0 This is the 0.9.7 people have been talking about already. We chose 0.10.0 because the update included non-editorial changes and that deserves a version bump in the second number. Sorry for the confusion. k

Re: [Standards] Disappearing timers for OMEMO proposal

On Donnerstag, 10. Mai 2018 08:23:04 CEST Daniel Gultsch wrote: > I implemented this several times for various closed systems. I always > attached a per message timeout that started the moment the message was > read. How is this state synchronized across clients? "Displayed" Markers? kind

Re: [Standards] Disappearing timers for OMEMO proposal

On Donnerstag, 10. Mai 2018 14:31:27 CEST VanitasVitae wrote: > Am 10. Mai 2018 14:24:47 MESZ schrieb "Remko Tronçon" : > >I don't see why a XEP for data retention hints needs to be tied to > >other XEPs like > >OMEMO, though. > > I'd also rather not tie it to OMEMO. Agreed,

Re: [Standards] Disappearing timers for OMEMO proposal

On Donnerstag, 10. Mai 2018 14:36:46 CEST Ненахов Андрей wrote: > 2018-05-10 17:31 GMT+05:00 VanitasVitae : > > > > I'd also rather not tie it to OMEMO. > > By the way ,self-destructing messages should also be deleted from > message archives on both sender and

Re: [Standards] Thoughts on MIX adoption (and will MIX ever happen?)

Hi Steve, I’m interested in implementing MIX in aioxmpp and JabberCat. I consider the model of MUC broken (I’m not going to list the brokenness here) and unfixable within the existing specification. MIX is huge, I agree. Splitting the spec seems like a good idea, but it will not be easy (to

Re: [Standards] XEP-0363 (HTTP Upload): Privacy Considerations & Deletion

On Freitag, 27. April 2018 14:58:02 CEST Daniel Gultsch wrote: > If this is about local law I don’t think a delete function will do that > justice. · Clients might not implement the delete part of the XEP and as a > service provider I can not solely rely on my users using the right > client.

Re: [Standards] XEP-0369: MIX - Forced room ownership

On Donnerstag, 26. April 2018 09:52:08 CEST Steve Kille wrote: > I really don't want to mandate this sort of thing in the core. > > However, I will place a hook into the text, so it can be developed as a > bolt-on XEP later I think this is a good way forward. Thanks. kind regards, Jonas

Re: [Standards] XEP-0363 (HTTP Upload): Privacy Considerations & Deletion

On Freitag, 27. April 2018 04:59:25 CEST Travis Burtrum wrote: > On 04/26/2018 10:35 AM, Jonas Wielicki wrote: > > As it turns out, several implementations are making it not trivial for > > operators to be GDPR compliant. One of the things definitely necessary (as > > far as o

Re: [Standards] XEP announcements delay?

On Freitag, 27. April 2018 02:59:31 CEST Ludovic BOCQUET wrote: > Dear all, > > Today I have received new announcements about 4 XEPs (0363/0223/0122/0373): > - https://xmpp.org/extensions/xep-0363.html -> Version: 0.6.0 / Last > Updated:2018-04-21 > - https://xmpp.org/extensions/xep-0223.html

Re: [Standards] XEP-0068 and MAM

Hi Ivan, On Donnerstag, 26. April 2018 14:03:15 CEST Ivan Vučica wrote: > Today I learned about XEP-0068 which seems to specify an IDL-like XML > for data forms. It also defines a registry for FORM_TYPEs maintained > by the XMPP Registrar. I feel this could be very useful to client > libraries,

[Standards] XEP-0363 (HTTP Upload): Privacy Considerations & Deletion

Hi all, During the last "XSF & GDPR" meeting (minutes pending), we were discussing HTTP Upload. As it turns out, several implementations are making it not trivial for operators to be GDPR compliant. One of the things definitely necessary (as far as our understanding goes) is that users must

Re: [Standards] Removal of GC1.0 from MUC / XEP-0045

On Dienstag, 10. April 2018 10:29:36 CEST Georg Lukas wrote: > It is this time of the month again. Georg is trying to fix MUC. > This time, I'm asking the Council to remove GC1.0 support from XEP-0045. +1. > In case this motion is approved, I'd prepare a PR against 0045 where the > respective

Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)

On Donnerstag, 22. März 2018 08:36:10 CET Matthew Wild wrote: > On 21 March 2018 at 18:37, Jonas Wielicki <jo...@wielicki.name> wrote: > > On Mittwoch, 21. März 2018 18:07:53 CET Sam Whited wrote: > >> On Wed, Mar 21, 2018, at 12:01, Kevin Smith wrote: > >> &

Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)

On Mittwoch, 21. März 2018 18:07:53 CET Sam Whited wrote: > On Wed, Mar 21, 2018, at 12:01, Kevin Smith wrote: > > I’d argue (and did at the Summit) that the opposite is true and that if > > we want (especially impromptu) MUC to start working nicely across > > multiple accounts we need clients to

Re: [Standards] XEP-0394: too weak to replace XEP-0071

On Mittwoch, 21. März 2018 10:19:34 CET Kozlov Konstantin wrote: > Hello, Jonas! > > 19.03.2018, 10:51, "Jonas Wielicki" <jo...@wielicki.name>: > A client can use 394 without support 393 just fine. I don’t see where you > got this notion from, I guess my i

Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)

On Dienstag, 20. März 2018 19:12:57 CET Georg Lukas wrote: > > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Bookmarks 2 (This Time it's Serious) > > A number of issues I have with the current Bookmarks XEPs, and that I'd > like to see addressed in the mid-term

Re: [Standards] XMPP Extension Editor

t; in sender name and without too. Yes, this is true. The reason is that the editor emails are now sent from private machines instead of the XSF servers. Thus we cannot really use @xmpp.org addresses. I use the "Jonas Wielicki (XSF Editor)" alias when sending such "automated" emails.

Re: [Standards] Proper SRV Record Fallback

Hi all, Let’s do a neat TOFU mail to bump this thread (you’ll find a more detailed inline reply from me at the start of the thread). In aioxmpp, we now (v0.10+) implement the following: - pre-auth stream errors are treated like any other connection error (e.g. connection refused). This

Re: [Standards] XEP-0394: too weak to replace XEP-0071

On Freitag, 16. März 2018 12:11:31 CET Kozlov Konstantin wrote: > Yes. CSS is really a hard part. But we don't need full support of CSS for IM > message styling. Maybe it's better to simplify XEP by specifying a small > subset of CSS rules needs to be implemented, as it was done with XHTML tag >

Re: [Standards] XEP-0394: too weak to replace XEP-0071

On Freitag, 16. März 2018 15:03:28 CET Tedd Sterr wrote: > I like the idea and design of 0394, and look forward to seeing these > extensions; the unholy hybrid attempting to shoehorn in 0393, not so much. > > Attempting to extend the inline text styling to support all of the > additional

Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)

utojoin password protected > > MUCs > > without a prompt or that individual clients must store the password (so > > you'd have to log in once on each client the first time it fetches the > > bookmarks and joins the room). > > > > —Sam > > > > On Sun, Mar 1

Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071

On Samstag, 17. März 2018 21:33:54 CET Tedd Sterr wrote: > I didn't expect this to turn into a drawn-out argument; I merely suggested a > simple solution to something that could otherwise be seen as a problem. Nor > am I continuing it for my own amusement, but I genuinely don't understand > why

Re: [Standards] XEP-0394: too weak to replace XEP-0071

On Donnerstag, 15. März 2018 19:19:30 CET W. Martin Borgert wrote: > Quoting Jonas Wielicki <jo...@wielicki.name>: > > If you are doing graphics/text design/publishing with your IM client, > > you’re doing it wrong, in my opinion. > > But XMPP is not only IM. Wh

Re: [Standards] XEP-0394: too weak to replace XEP-0071

I’m sorry for the messed up quoting, but the plaintext part of these HTML emails is unusable. On Donnerstag, 15. März 2018 16:24:58 CET Kozlov Konstantin wrote: > Hello! > > 15.03.2018, 17:40, "Sam Whited" : > On Thu, Mar 15, 2018, at 02:22, Kozlov Konstantin wrote: > >

Re: [Standards] XEP-0394: too weak to replace XEP-0071

On Donnerstag, 15. März 2018 15:46:43 CET Kozlov Konstantin wrote: > It sounds promising. I just wonder why no links and no font customization? Yeah, I forgot to mention links (and possibly other things). Font customization is out-of-scope, for the reasons Daniel stated. Just like setting

Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071

On Donnerstag, 15. März 2018 11:31:37 CET W. Martin Borgert wrote: > On 2018-03-15 10:22, Kozlov Konstantin wrote: > > I don't want to discuss XEP-0393, 'cause the whole idea of using LML in IM > > sounds bad. Flaws if it is obvious, so it's needless to mention them > > again. > > I disagree. Yes

Re: [Standards] Call for Experience: XEP-0066: Out of Band Data

On Mittwoch, 7. März 2018 20:17:29 CET Jonas Wielicki wrote: > 1. What software has XEP-0066 implemented? We have support for the flow in JabberCat (GPLv3), like in gajim and Conversations as already mentioned elsewhere in this thread. We do not implement the IQ workflow, nor do we int

Re: [Standards] XEP-0394: too weak to replace XEP-0071

On Donnerstag, 15. März 2018 14:02:41 CET Daniel Gultsch wrote: > What intrigues me on something markdown ish (albeit probably something > more than Styling currently has to offer) are its limitations. > Particularity no color (that will never work in a federated > environment where you don't know

Re: [Standards] XEP-0394: too weak to replace XEP-0071

On Donnerstag, 15. März 2018 13:36:50 CET VanitasVitae wrote: > I would claim that a huge part of XMPP nowadays happens on mobile devices > and I haven't seen a single rich text editor in any mobile application. > Thats why I think that markdown is the way to go. > > Sending greeting cards in

Re: [Standards] XEP-0372: References

On Montag, 12. März 2018 16:31:57 CET Sam Whited wrote: > On Mon, Mar 12, 2018, at 10:17, Jonas Wielicki wrote: > > This is true, XML restricts to Scalar Values. Thanks, I didn’t know that > > term. > Your entire reply seems to be hinged on the fact that all XML libraries >

Re: [Standards] XEP-0372: References

On Montag, 12. März 2018 15:56:04 CET Sam Whited wrote: > On Mon, Mar 12, 2018, at 09:20, Jonas Wielicki wrote: > > FWIW, I’d argue that using codepoints is much saner, > > because those are readily available and consistent across all receiving > > entities of the same

Re: [Standards] XEP-0283 Moved - Security and Usability

Hi Georg, Thanks for taking this up. On Freitag, 9. März 2018 17:53:27 CET Georg Lukas wrote: > XEP-0283 "Moved" provides the signaling mechanism to make this possible, > with two "little" issues: > > 1) the Security Considerations spoil all the fun of automatic account > > transfers: > | In

[Standards] XEP-0372: References

Hi list, Some feedback on XEP-0372 references from me after reading it thoroughly for the first time [1]. First, it uses ranges of "characters" into , but doesn’t specificy which language. Since there can be multiple elements with different effective xml:lang values, this is ambiguous. I

Re: [Standards] XEP-0283 Moved - Security and Usability

On Freitag, 9. März 2018 18:16:25 CET Sam Whited wrote: > On Fri, Mar 9, 2018, at 10:53, Georg Lukas wrote: > > as part of Easy XMPP I wanted to have a way to completely migrate from > > one account to another, or to be able to move a subset of your contacts > > to another (local) JID. > > What

Re: [Standards] XEP-0393 and XEP-0394 naming

On Donnerstag, 8. März 2018 17:18:02 CET Kozlov Konstantin wrote: > Hello! > > 08.03.2018, 19:03, "Sam Whited" : > On Thu, Mar 8, 2018, at 10:01, Kozlov Konstantin wrote: > > I think "Markup" more suits > for XEP-0393 and "Styling" for XEP-0394.I guess, we should think

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

On Donnerstag, 8. März 2018 10:38:55 CET Kozlov Konstantin wrote: > Hello! > > 08.03.2018, 12:18, "Dave Cridland" : > The personal choice of Council was to deprecate XHTML-IM based on > these facts. The previous Council decided to ensure there were > alternates for XHTML-IM

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

On Donnerstag, 8. März 2018 08:28:27 CET Daniel Gultsch wrote: > 2018-03-08 8:22 GMT+01:00 Jonas Wielicki <jo...@wielicki.name>: > > On Donnerstag, 8. März 2018 07:38:42 CET Daniel Gultsch wrote: > >> It feels a bit sad that we aren't able to advance a XEP that is widely

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

On Donnerstag, 8. März 2018 07:54:04 CET Evgeny Khramtsov wrote: > Wed, 07 Mar 2018 21:33:13 +0300 > > Kozlov Konstantin wrote: > > So, the only reason to obsolete the XEP is not the XEP itself, but > > bad implementations? > > Yes. This is kinda religion among some Council

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

On Donnerstag, 8. März 2018 07:38:42 CET Daniel Gultsch wrote: > It feels a bit sad that we aren't able to advance a XEP that is widely > deployed (in a way) but I think it is just too late. Can’t we revert to XEP-0049 (if no other XEP-0223 implementations show up), advance *that* to final and

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

On Mittwoch, 7. März 2018 20:17:24 CET Jonas Wielicki wrote: > 1. What software has XEP-0048 implemented? We have support for Private XML (XEP-0049)-based bookmarks in aioxmpp (LGPLv3) and based on that in JabberCat (GPLv3). We haven’t gotten around to implement PEP-based bookmarks, even tho

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

Due to popular request, I’m going to re-post the reply I gave earlier on GitHub: The core reason is that it caused quite a few XSS vulnerabilities. There are lengthy threads on the standars mailing list: * starting with Security issues with XHTML-IM (again) [1] * some discussion on replacement

Re: [Standards] xep-0313 missing features

On Dienstag, 6. März 2018 14:19:41 CET Kevin Smith wrote: > On 6 Mar 2018, at 13:14, Jonas Wielicki <jo...@wielicki.name> wrote: > > I think it would be great to have a way to limit the MAM query to an > > end-ID > > indeed. Matt, Kevin, any chance we get that i

Re: [Standards] xep-0313 missing features

On Dienstag, 6. März 2018 13:23:21 CET Lazar Otasevic wrote: > Conclusion: > > 1. it is not possible to iterate efficiently backwards by including both > & in the query because once is included in the query > then it iterates forwards. that means when iterating backwards client has > to omit

Re: [Standards] xep-0313 missing features

On Dienstag, 6. März 2018 14:02:49 CET Philipp Hörist wrote: > You dont need to determine holes, maybe you should first come up with a > scenario where this "hole" of yours can even happen. > > 1. if you receive a message live you get the archive-id, then you save it. > 2. You go offline > 3.

Re: [Standards] What is the size limit of node and item ids in XEP-0060: Publish-Subscribe?

Hi Peter, Thank you very much for the clarification, comments inline. On Dienstag, 6. März 2018 02:59:04 CET Peter Saint-Andre wrote: > On 3/5/18 12:17 AM, Jonas Wielicki wrote: > > On Sonntag, 4. März 2018 19:42:39 CET Peter Saint-Andre wrote: > >> On 3/4/18 10:54 AM, Jo

[Standards] XEP-0390: use of separators which are valid (but discouraged) in XML 1.1 (as opposed to 1.0)

Dear list, Florian discovered that the ASCII separators we use, while invalid in XML 1.0 (upon which RFC 6120 bases), are only discouraged in XML 1.1. I wonder whether we should be concerned about this. While the XML parsers I tested back then *did* reject those ASCII characters, I wonder

Re: [Standards] What is the size limit of node and item ids in XEP-0060: Publish-Subscribe?

On Sonntag, 4. März 2018 19:42:39 CET Peter Saint-Andre wrote: > On 3/4/18 10:54 AM, Jonas Wielicki wrote: > > On Sonntag, 4. März 2018 17:02:07 CET Peter Saint-Andre wrote: > >> If we want to specify this, I would recommend the UsernameCaseMapped > >>

Re: [Standards] What is the size limit of node and item ids in XEP-0060: Publish-Subscribe?

On Sonntag, 4. März 2018 17:02:07 CET Peter Saint-Andre wrote: > If we want to specify this, I would recommend the UsernameCaseMapped > profile defined in RFC 8265. > > However, there's a twist: if a node ID can be a full JID, then do we > want to apply the normal rules of RFC 7622 to all the JID

Re: [Standards] Releases

On Sonntag, 4. März 2018 10:29:02 CET Gerion Entrup wrote: > Hi, > > I'm a user of XMPP and have very mixed experiences with different clients. > > There are clients that do very well and implement a lot of availabe XEPs, > but other clients only implement a fraction of available XEPs. The XEPs

Re: [Standards] xep-0313 missing features

On Samstag, 3. März 2018 23:53:21 CET Lazar Otasevic wrote: > Hi, I think I miss some features here: > > 1. fetching messages by giving a set of ids, also similar like xep-013 > > Fetching message by id(s) is needed for example when i have a custom push > notification with a given message id(s)

Re: [Standards] What is the size limit of node and item ids in XEP-0060: Publish-Subscribe?

On Donnerstag, 1. März 2018 08:52:29 CET Florian Schmaus wrote: > On 01.03.2018 01:17, Peter Saint-Andre wrote: > > On 2/28/18 3:18 PM, Timothée Jaussoin wrote: > >> Hi, > >> > >> I came across a database limitation while implementing Pubsub in Movim. > >> > >> I'd like to know if we have a

Re: [Standards] Message-IDs

On Mittwoch, 28. Februar 2018 10:28:01 CET Kevin Smith wrote: > On 26 Feb 2018, at 15:59, Simon Friedberger wrote: > > So, lest this discussion just die. Here is a proposal: > Thanks for the proposal. Bashing follows. > > >Client-A generates message-ID based on

Re: [Standards] Message-IDs

On Montag, 26. Februar 2018 16:59:46 CET Simon Friedberger wrote: > So, lest this discussion just die. Here is a proposal: > > * > > Client-A generates message-ID based on HASH(connection_counter, > server_salt). The connection_counter needs to be maintained only for > one

[Standards] Council Agendum: Re: XEP-0153: Encoding of photo hash?

On Sonntag, 25. Februar 2018 21:39:03 CET Tedd Sterr wrote: > > For me the text and examples are not clear. > > > > „sha1-hash-of-image“ in the example doesn’t say anything about the > > encoding. > True. It appears to defer that to RFC-3174, but that document only specifies > how to calculate

Re: [Standards] XEP-0153: Encoding of photo hash?

Hi Christian, On Samstag, 24. Februar 2018 20:22:39 CET Christian Schudt wrote: > I’ve got a question about XEP-0153. Its XML schema defines that the photo > hash is encoded as Base64: > >

Re: [Standards] NEW: XEP-0401 (Easy User Onboarding)

On Freitag, 23. Februar 2018 12:36:01 CET Georg Lukas wrote: > * Jonas Wielicki <jo...@wielicki.name> [2018-02-23 11:39]: > > - This is a larger one: If we’re changing XEP-0077 flow in a backward- > > incompatible manner, wouldn’t it make more sense to do this in a wholly

Re: [Standards] NEW: XEP-0401 (Easy User Onboarding)

I found a few other nits to pick: - The command @node values should probably be namespaced somehow (e.g. with urn:xmpp:invite#) - This is a larger one: If we’re changing XEP-0077 flow in a backward- incompatible manner, wouldn’t it make more sense to do this in a wholly new namespace, with a

Re: [Standards] [XEP-0234] Jingle File Transfer, Last Call and File Sharing

On Freitag, 23. Februar 2018 09:47:00 CET Goffi wrote: > 1) XEP-0234 is in Last Call which is supposed to be finished, what the > status about that? The Council vote isn’t over yet (but from what it looks like, advancement will be rejected since Daniels feedback has not been addressed; it looks

Re: [Standards] undefined state in XEP-0050

On Donnerstag, 22. Februar 2018 10:29:18 CET Kevin Smith wrote: > FWIW, I think this isn’t what the standard already says, although may be > sensible. Hmm… I think you are right there. "execute" is equivalent to whatever the Responder says in the "execute" attribute on . Which unfortunately

  1   2   3   >