Re: [Standards] XEP-0398: Avatar Conversion, resend presence
Sun, 2 Sep 2018 10:22:40 +0200 Emmanuel Gil Peyrot wrote: > This is wrong, XEP-0045 notes that RFC6121 mandates that a server > would broadcast an unavailable presence to all previous directed > presence targets, this means the server MUST track them Well now this is wrong :) The server only tracks presence's recipient JID, it doesn't store full presence stanza, because this is not cheap. This is enough to send presence-unavailable, but it's not enough for stanza resending (for example, caps information will be lost). ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] field report on authentication methods
Thu, 9 Aug 2018 10:54:17 -0600 Peter Saint-Andre wrote: > hereas 4% for XEP-0078 is a fairly large percentage. I'd want to > do further investigation regarding client versions before shutting off > 4% of our users... I'm 99% confident that those 4% are in fact bots using abandonware (most likely some monitoring tools). Strictly speaking you don't cut off users, but only automated software. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XMPP Council Minutes 2018-06-20
Wed, 27 Jun 2018 09:34:02 +0200 Goffi wrote: > It would be even better to be able to list existing files and delete > them on request, but this can be done in a separated XEP. As someone already mentions here (or in another list/chat), a user may not want a server to keep tracking their files, especially when e2ee is used and the file is encrypted. So, yes, listing expiration date is great, but also a server should notify a client whether it's possible to upload files anonymously (without tracking) or not, and a client should set this flag when requesting a slot. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Update to MIX 0.9.7
Thu, 10 May 2018 12:39:54 +0100 Dave Cridland wrote: > XEP-0060 takes a message protocol and builds a pubsub service on top. I don't want to run into terminology debates, but XMPP strictly speaking is not a "message protocol", but a protocol for XML routing. > You're suggesting that MIX should build a message service on top of > this? Yes. MIX should build a message service on top of XML packets. > The problem, in my eyes, is that we have existing, well-defined, > handling for the concepts of "messages" and "presence", and I would > hate to have to deal with these entirely differently for group chat > compared to for 1:1 chat. There is probably no need to say for the 1000 time that the conception of "presence" is outdated. I also doubt messages by itself is a good concept. Yes, they are easy to understand for sure, but seems like in modern IM we are talking about replicas exchange between endpoints. The simple concept of a message carrying human readable text 1:1 is somewhat outdated too. Sorry for the "moot statements", but you started this discussion in the first place. Frankly, I would rather discuss technical aspects instead of this philosophic bullshit. > There are always going to be differences, of course (short of forcing > every 1:1 conversation into a 2-person groupchat, which has its own > unique problems), but it makes sense to me to minimize these, and > reuse existing handling wherever possible. Well, I actually suggest to reuse existing specification and, what's more important, existing code. Pubsub is something we have more or less implemented, and can reuse it, despite it doesn't fit ideology of some people. Your vision of Pubsub as a "building block" is wrong in my opinion, because this doesn't help me at all, I need to reimplement *all* pubsub code to handle MIX, because now Pubsub is not a protocol between a client and a disc storage, but rather some abstract stuff used by ad-hoc services which translate Pubsub requests in their internal state. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Update to MIX 0.9.7
Thu, 10 May 2018 12:14:12 +0100 "Steve Kille" wrote: > I'm not sure that I understand your question here. MIX does use a > PubSub node for message distribution. Great. So this use case should be described in the core: i.e. pubsub without ad-hoc services. Other stuff (like presence, anonymous messaging and so on) should go into separate documents (which will require some additional services as I understand). ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Update to MIX 0.9.7
Thu, 10 May 2018 11:46:10 +0100 "Steve Kille" wrote: > Sometimes the nature of problems does not lend itself to short > specification.The basic PubSub and MIX concepts are simple. > However, there is a lot of devil in a lot of details that needs to be > addressed. Ending large is not a goal, but is often a consequence > of addressing real world problems. Philosophic discussions aside, can you please tell what we're missing from the use case mentioned by Jonas: > essentially Joining, Leaving and Messaging, without any presence things Why we cannot use a pubsub node for this? The main argument I recall is that you cannot identify a sender, but this is not true, because we have a 'publisher' attribute. Another argument is that we cannot make it anonymous, but I think anonymous publishing should be a separate extension in the first place. We have some ability to set metadata, we have simple ACL configuration. So what details do we need to address? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Thoughts on MIX adoption (and will MIX ever happen?)
Thu, 10 May 2018 11:21:43 +0200 Daniel Gultsch wrote: > What worries me about MIX is that it looks like such a big spec that > no body is going to implement fully that years from now we are still > going to find 'bugs' in the XEP. Like we recently found 'bugs' (under > specified things) in PubSub and that XEP is 15+ years old. I agree with this (as I said many times). And I of course disagree with the XEP author: comparing MIX with other poorly implemented monster specs assuming that this is "normal" is beyond me. I'm for sure vetoing MIX implementation in ejabberd in the form it's presented currently. As I said: we just have to use pubsub and improve pubsub spec if we miss some really basic functionality. And I agree with Holger: if we cannot reuse pubsub for such simple functionality as group messaging then why we need pubsub at all? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0363 (HTTP Upload): Privacy Considerations & Deletion
Tue, 1 May 2018 09:28:39 +0100 Dave Cridland wrote: > That said, I don't think that saying that operators should be able to > delete files is a political statement - it's just that it's > potentially naïve, and does not have an impact on Security or > Interoperability (which is what RFC 2119 language is for). > > I'd be happier with a section in the document (or another document) > that pointed out legal compliance issues we are aware of, > irrespective of the regime they're affected by. I'm fine with having a separate GDPR-related document where you can accumulate all the caveats (although I have no idea how you will do it correctly without consulting a lawyer). But spreading the GDPR across several _technical_ papers is not the right way to go, IMO. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0363 (HTTP Upload): Privacy Considerations & Deletion
Tue, 1 May 2018 09:33:54 +0100 Dave Cridland wrote: > I appreciate the sentiment, but as an implementer I'd want to know > about potential legal requirements of software I'm writing, so I can > then gain some more confidence about offering that software to > various jurisdictions, and can take these requirements into > consideration when designing the software. You should consult lawyers then. Relying on a technical document written by engineers shouldn't make you more confident in the questions of law. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0363 (HTTP Upload): Privacy Considerations & Deletion
Mon, 30 Apr 2018 13:20:38 +0200 Jonas Wielicki wrote: > I agree with your stance about deletion. Which is why I made it a > separate PR. > > What do you think about the independent extension to the text I > proposed in https://github.com/xsf/xeps/pull/625 ? While I'm fine with having a separate extension, I'm against the PR itself. I think the behaviour is up to a local policy. We shouldn't make default recommendations based on some local laws (GDPR). Because if we do that, we can easily add "NOT" to all "SHOULD"s, and in this case we will describe the local law of Russia (where it is required to keep all users data for at least 6 months). I would really advise XSF to avoid making political statements. Not to mention that the text brings nothing to the document and only increases its size: it doesn't describe any protocol, it doesn't describe security considerations, it doesn't describe UX, so what does it do? Can we replace the text with "People SHOULD live in peace?" Because the meaning of the statement doesn't change a lot and a reader can easily ignore it. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0357 (push) needs options
Fri, 13 Apr 2018 13:15:03 +0500 Ненахов Андрей wrote: > The only correct way to send pushes is when user should recieve some > new content (messages). What about Jingle calls? Do we support them in the XEP? How a server knows what to send? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XMPP Council Minutes 2018-04-11
Thu, 12 Apr 2018 23:47:09 + Tedd Sterr wrote: > Isn't this the point of the CFE - to find out? > There is always the *possibility* that somebody somewhere could > possibly maybe have implemented a given feature, but if nobody knows > about it, do we just assume it does anyway? In which case, we can > always assume there are enough implementations because there *might* > be. That's why back in the days I suggested to keep track of XEP implementations. However, I was told the information there would be inaccurate. But I fail to see how polling a few users in rare meetings is going to be more accurate. Another objection is that XSF needs a lot of efforts to keep this table up to date. And this might be true, of course. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: IM Routing-NG
Wed, 28 Mar 2018 23:12:03 +0200 Manuel Rubio wrote: > I was reading XEP-0344 (Impact of TLS and DNSSEC on Dialback). I > understand that's for security connection between two XMPP servers > (S2S). I meant XEP-0334 (Message Processing Hints) of course, sorry. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: IM Routing-NG
Wed, 28 Mar 2018 17:18:36 - Jonas Wielicki (XSF Editor) wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: IM Routing-NG > Abstract: > This specification provides a new set of routing rules for modern > instant messaging. Not sure why XEP-0344 can't be used for this. We just need to set in Example 6 and for other cases we need to introduce new element and a server's disco feature (I would rather use stream feature, but one can argue it should be negotiated blah-blah-blah). ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Review of XEP-0369: Mediated Information Exchange (MIX) v0.9.5
Fri, 23 Mar 2018 20:57:41 + Kevin Smith wrote: > Thanks for the review, comments follow (I’ve elided trivial points). > > On 20 Mar 2018, at 16:34, Florian Schmaus wrote: > > As of now MIX is bloated and got way out of hand. > > I’m not sure to what extent this is true, but I’m going to go through > and see what can be simplified. I think the core of the XEP should not rely on ad-hoc services: the whole protocol should re-use existing pubsub spec. For relaying messages this would be enough. Other stuff like presence management, jid proxy, access rules and other nerdy features should go into an ad-hoc service and should be described in a separate document. > MIX is a very simple core concept XEP-0136 had also a very simple concept. > and I’m not entirely sure how we’ve got to the current situation > where it’s viewed as complex The XEP is 91 pages long. Even reading it will take a day. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
Sun, 18 Mar 2018 21:17:16 +0100 Philipp Hörist wrote: > If you want to work on MUC, there are a hundred threads about the > upcoming MIX standard. I hope this will never become an adopted standard. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
Sun, 18 Mar 2018 18:56:48 +0100 Jonas Wielicki wrote: > Two or more clients updating different bookmarks at the same time (or > maybe at different times, but one had a network outage inbetween and > can only actually perform the update at a later time). Currently, it > requires a nasty loop [1] until convergence to make that work. You need this loop too if you want to modify the same item (i.e. the bookmark of the same conference). ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071
Fri, 16 Mar 2018 20:11:19 + Tedd Sterr wrote: > > This is true, however mostly these are quite coarse-grained. > > Extensions with lots of optional > > > parts inside - I'm thinking about XEP-0060 for example - tend to > > end up with various interop issues. > > I don't disagree with that, and I'm not suggesting 0394 turns into a > mass of optional parts. So you only want to add a single part? But then comes another person with another feature request, then yet another one and eventually we have a mess of optional parts :) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071
Thu, 15 Mar 2018 11:31:37 +0100 "W. Martin Borgert" wrote: > Many people know Markdown syntax nowadays, there are parsers for > it in many different programming languages, and we already know > how ugly and illogical it is. Just needs a new XEP :~) >From what I understand you can use markdown with that another XEP: e.g. you can use `foobar` in the text and the client software will add corresponding markup elements from that another XEP. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)
Thu, 08 Mar 2018 08:51:26 +0100 Jonas Wielicki wrote: > How many XMPP clients have you seen which were owned by Billion > Laughs (which uses entities which are explicitly forbidden in RFC6120 > and trivial to turn off in all XML parsers I’ve seen so far) compared > to the amount of XMPP clients Sam has found which were vulnerable to > XHTML-IM XSS attacks? I think the comparison might not hold up, but > I’m open for data. (Likewise for any other XML vulnerability.) I don't know, I didn't count and not going to count them for you. Kids these days might not remember, but Billion Laughs was pretty serious vulnerability despite being well known with several implementations affected. So new XMPP implementations might be vulnerable just easily. > Also, XML vulnerabilities are both well-known and easy to test > against (in the sense: it is easy to write an automated test which > ensures that code is not vulnerable). And where are those tests? > I don’t think that’s so trivial with XSS attacks. During the > XHTML-IM debate I learnt that even CSS can be an XSS vector (in some > really broken implementations Sure, and were there debates of possible XML security holes? So the comparison is not quite fair. Not to mention that it's a logical fallacy to speculate about possible vulnerabilities: one can say everything might have security issues. > In contrast to XML, XHTML-IM is a custom thing which needs to be re- > implemented in ~every client. Well-known XML libraries exist for most > languages (even if they only FFI to libxml2 or libexpat). Well-known XML libraries didn't protect from Billion Laughs attack. Not sure what this argument is for. TL;DR: I conclude that the only argument is that XML is a bit more secure (with possibly less possible holes, lol). So, as I thought, this is purely a matter of personal choice and not a technical decision, that's why we debated about it so much. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)
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 members that if a technology can be misused then it should be deprecated. Their religion is, however, quite picky: there is a well-known list of security problems in XML (including the famous billion laughs attack), but they don't consider to get rid of XML. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XMPP Council Agenda 2014-02-28
Wed, 28 Feb 2018 15:05:32 + Dave Cridland wrote: > 2014-02-28 Time machine? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [XEP-0264] thumbnails: we should be able to transmit them with XEP-0234
Sat, 24 Feb 2018 11:24:39 -0500 Travis Burtrum wrote: > Unfortunately you also can't reasonably expect P2P to work today in > most cases because everyone is behind a NAT including most mobile > phone networks. So https is still your best bet, and since most > servers support http upload it's already done for you. This problem is solved already by TURN servers. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Council Agenda 2018-02-14
Thu, 15 Feb 2018 08:18:24 +0100 Daniel Gultsch wrote: > I want to put the current MAM preferences into the a disco features > form on the account. Ah, ok then. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Council Agenda 2018-02-14
Wed, 14 Feb 2018 10:01:31 -0600 Sam Whited wrote: > I'm sure we'll discuss this is the council meeting, but to my > knowledge this is the only part of the spec that anything implements > now (please correct me if there is significant adoption of the other > parts of the spec). Well, as Daniel noted, blindly purging all offline nodes is risky in a general case because you don't know if MAM is enabled in user's preferences. As a work-around you can first request the number of messages (before sending an initial presence), this, according to the spec, will automatically disable offline messages flood. In a later stage you can check if MAM is enabled and if it is, you purge, if it's not, you retrieve offline messages via any mechanism described in XEP-0013. Thus, other parts of specs can also be utilized. I know, this is ugly, but at least doable. For sure, new mechanism is needed in this situation (such as MAM interface to offline storage, dunno). ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Council Agenda 2018-02-14
Tue, 13 Feb 2018 17:04:36 + Dave Cridland wrote: > 4) Deprecate XEP-0013 Flexible Offline Message Retrieval > > https://xmpp.org/extensions/xep-0013.html Just my 3 cents: this XEP is, from what I know, the only way to disable offline messages on a client, so we need a similar mechanism if the XEP is going to be deprecated. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Entity Capabilities 2.0
Mon, 12 Feb 2018 09:12:02 +0100 Jonas Wielicki wrote: > Could you please be specific which cache you’d like to see properly > invalidated? Do you mean the (hash -> disco#info) cache or the > (entity JID -> hash / disco#info) cache? A server can change configuration in runtime at any time, potentially changing its disco#info. How to notify local clients about that? How to notify clients from remote servers? How to notify connected servers after all? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Entity Capabilities 2.0
Mon, 12 Feb 2018 00:41:54 +0100 Christian Schudt wrote: > - I am also missing a cache which maps entities to capabilities, i.e. > JIDs to disco#info objects. This is the whole point of the XEP (to be > able to know an entity’s abilities without service discovery). This > cache should be probably be non-persistent. The "Capability Hash > Cache“ (hash -> disco#info) is actually only the > intermediate/auxiliary cache. I think the XEP doesn't solve the main problem of cache invalidation and that's why I think it's pointless and I'm not going to implement it until the invalidating rules are described. And for those who think cache polution is a problem can request/store features per JID: there is absolutely no need to introduce yet another incompatibility just for a very tiny problem which can be solved in the other way. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Adding logo to MUC and PubSub node
Thu, 8 Feb 2018 14:21:49 +0100 Daniel Gultsch wrote: > 2018-02-08 13:43 GMT+01:00 Evgeny Khramtsov : > > Thu, 8 Feb 2018 13:17:14 +0100 > > Daniel Gultsch wrote: > > > >> at least for MUC I would prefer vCard + hash in presence from the > >> bare muc jid. (as discussed in our 34C3 meeting and/or various > >> discussions we had prior to this) > > > > What was the conclusion? (If any) > > > The question I had for the room was basically if any client would > break on receiving presence from the bare jid and everyone (in the > room) agreed that *their* client wouldn't break. > > On whether or not this is a good idea; I can't remember anyone voice > strong objections. Good. Then I will implement this in ejabberd. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Adding logo to MUC and PubSub node
Thu, 8 Feb 2018 13:17:14 +0100 Daniel Gultsch wrote: > I don't have an opinion on pubsub. I guess that's not a problem for PubSub service to send notifications? :) A dedicated and well-known node should be enough for this. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Adding logo to MUC and PubSub node
Thu, 8 Feb 2018 13:17:14 +0100 Daniel Gultsch wrote: > at least for MUC I would prefer vCard + hash in presence from the bare > muc jid. (as discussed in our 34C3 meeting and/or various discussions > we had prior to this) What was the conclusion? (If any) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Adding logo to MUC and PubSub node
Wed, 7 Feb 2018 22:16:30 +0100 "W. Martin Borgert" wrote: > Hi, > > this is an idea mainly for the "social network" aspect of XMPP: > A logo for a MUC or for a PubSub node, similar to a user avatar. > > Such a logo, emblem, or symbol can be a good indicator for users > to find the right MUC or PubSub node in a social network > application or graphical XMPP client. > > How about introducing two configuration variables, one in > https://xmpp.org/extensions/xep-0045.html#registrar-formtype-owneronfig: > > var='muc#muc_logo' > > And the second one in > https://xmpp.org/extensions/xep-0060.html#owner-configure: > > var='pubsub#node_logo' > > The value should be a element from > https://xmpp.org/extensions/xep-0221.html. > > IMHO, the value should be restricted to > 1. images, or would a sound make sense? Maybe... > 2. inline data, so that a link to a web resource cannot be > abused for snitching IP addresses > > What do you think? This is the same as to provide vCards by the service (which is implemented in ejabberd for MUCs for example), and has the same drawback: there is no way to tell clients that your logo has updated. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] NEW: XEP-0397 (Instant Stream Resumption)
Mon, 22 Jan 2018 13:42:59 + Dave Cridland wrote: > I don't think RTTs should block UI either, but startup RTTs mean we > cannot send or receive messages for several RTTs, and that's a very > real problem over slower networks. What problem? If you're on slow network, expect everything to be slow, because, well, the network is slow. > From a more cynical standpoint, it also addresses a commonly held > belief about XMPP (startup is really slow and it's really chatty!) > without causing harm. I don't see this as a "commonly held belief". If you know how Web works, you would never assume XMPP is slow. I don't remember anyone complaining in my bugtracker about slow RTT. To put it simply: I agree there can be use cases when you absolutely need to work in a slow network (sending stanzas to the Moon and back, as an example), and maybe there are indeed some problems with RTTs. But I see this as a very narrow use case. So I would agree that the XEP will be used by *some* software, and I'm fine with that. What bothers me is that this may become a trend, seeing the XEP as a successor to the "standard" approach, and even be put into "compliance suite". ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] NEW: XEP-0397 (Instant Stream Resumption)
Mon, 22 Jan 2018 11:16:40 - Jonas Wielicki (XSF Editor) wrote: > Version 0.1.0 of XEP-0397 (Instant Stream Resumption) has been > released. Previous discussion has faded away, so I will be ranting here again: I don't see excessive RTT as a problem. I'm not convinced that excessive RTTs block UI, I think that's a problem of bad UX design, and should be fixed by the application author. Also, the traffic is negligible during the RTTs anyway (compared to HTML pages). So the XEP is attempting to solve non-existing problem. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)
Sat, 13 Jan 2018 10:35:21 +0100 Jonas Wielicki wrote: > Can PEP-only clients somehow obtain avatars in MUCs? > > If not, we need read-only 153 support in clients and servers no > matter what. You're right here. Seems like we need clients to be able to read vCards. However, for Private XML this is not needed at all. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)
Fri, 12 Jan 2018 22:28:19 + Kevin Smith wrote: > I would almost certainly implement -49, in order to have interop with > the vast majority of currently deployed stuff, and as a server dev I > would absolutely certainly implement 49 - probably as one of the > first things I did. I disagree about clients. Conversion between PEP and Private XML is even easier to implement in servers (than PEP and vCard avatars). And we need a XEP for it as well, btw :) So, I think this should be a MUST for modern servers to support all these XEP + conversion, when clients may only support PEP ones. Note that this approach also resolves the current situation with clients as long as servers get updated. IMHO. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proper SRV Record Fallback
Wed, 10 Jan 2018 01:47:46 -0500 Travis Burtrum wrote: > Which question have I not addressed? Rephrasing, the question about what to consider a success connection. We have several phases of stream negotiation (not to mention mam or roster queries). ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proper SRV Record Fallback
Tue, 9 Jan 2018 21:28:55 -0500 Travis Burtrum wrote: > Is there any reason why any client would rather fail and show a > 'cannot connect' to a user rather than actually allowing them to > connect? I can't actually think of one. You continue ignoring the question about all possible such scenarios. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proper SRV Record Fallback
Tue, 9 Jan 2018 11:55:15 +0100 Florian Schmaus wrote: > A client supporting xep368 but not ALPN would This sounds like asking for troubles ;) Since one of the use case of XEP-0368 is multiplexing and you cannot do this easily without ALPN. > 2. xep368 makes ALPN mandatory ^^^ This. Not sure why it's not mandatory though. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proper SRV Record Fallback
Tue, 09 Jan 2018 11:30:25 +0100 Marcel Waldvogel wrote: > So, a connection runs into a timeout: Why not try the fallback? Runs into a timeout in what state? TCP? TLS? SASL? Roster-get? MAM-request? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proper SRV Record Fallback
Tue, 9 Jan 2018 10:03:24 + Dave Cridland wrote: > What's the distinction between invalid TLS certificates and > authentication failure? Another question is what if I get an error response on, let's say, roster get? I bet there are situations where I benefit from reconnecting to other SRV record, but should we put this into the RFC (or any other standard document)? I really don't understand how far we should go in defining cases for reconnect. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proper SRV Record Fallback
Mon, 8 Jan 2018 23:19:36 -0500 Travis Burtrum wrote: > In my opinion, at least all of cannot-connect-to-port, non-XML, > not-proper-stream and invalid TLS cert should trigger a fallback to > the next highest priority SRV record. I disagree. In the most cases the same result will be for other SRV records and you just waste resources and introduce delays. It seems like you have a particular problem (misconfigured software, or what? I'm not sure), you generalize it and now try to solve this generalized non-existing problem. Initially, from what I understand, the RFC has the exact problem to solve: dead network links or halted/overloaded hardware/software, now you're adding a misconfiguration? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] UPDATED: XEP-0363 (HTTP File Upload)
Tue, 05 Dec 2017 12:28:01 +0100 Jonas Wielicki wrote: > 3. What happens now if ejabberd doesn’t know the element? > Who gets the error? Does the client receive an error for their upload > request, or will they time out while waiting for their reply? Well, yes, it will be timed out. I also don't think this is a violation, because in this case we cannot block IQ from flooders for example, as this is also a violation. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] UPDATED: XEP-0363 (HTTP File Upload)
Tue, 05 Dec 2017 10:31:36 +0100 Jonas Wielicki wrote: > I don’t think that’s ok. ejabberd would violate the expectation of > the user that either a type="result" or type="error" is returned, if > they simply filter out the "erroneous" stanza. Obviously ejabberd replies with a correct error message, currently it will send an error stanza with diagnostic text, e.g.: "Unknown tag qualified by namespace 'urn:xmpp:http:upload:0'" > Also, I still don’t believe that intermediate servers should validate > content which doesn’t concern them. I disagree. The feature is useful for client developers for example, so they get validation errors when sending garbage and, thus, can fix the code easily. For example, some of our customers just add new elements within existing namespace (such as 'jabber:client'), and this will be easily rejected by the validator. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] UPDATED: XEP-0363 (HTTP File Upload)
Tue, 5 Dec 2017 08:30:38 + Kevin Smith wrote: > 2) New namespace: previous version payloads are allowed through, new > versions won’t be allowed through until the validator is updated No, new namespaces are treated as unknown and are routed untouched. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] UPDATED: XEP-0363 (HTTP File Upload)
Mon, 4 Dec 2017 11:18:27 +0100 Florian Schmaus wrote: > For changes that are are not backwards compatible. You can set then and this will also be "backwards compatible". Also, as I said, I can use within the same HTTP-Upload namespace, but with other semantics. Because why not? It's backward compatible for me. > While I am a fan of validation, for the reasons mentioned, I don't > think that the approach you are going with the server side validator, > as far as I understand it, is possible, needed nor a good idea. Well, I think the idea is good under some circumstances. If you don't like the idea, don't enable validation. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] UPDATED: XEP-0363 (HTTP File Upload)
Mon, 4 Dec 2017 09:29:41 +0100 Florian Schmaus wrote: > That is what we always did when extending XMPP in a backwards > compatible way. I'm not aware of a case where we did something > different. And given that we want to avoid namespace bumps whenever > possible, I'm happy with that. Even if it means that live schema > validation is not feasible. Well this approach is wrong. Why would we need other namespaces then? We can put everything inside 'jabber:client'. Or, otherwise, what stops me from putting my own invented elements (and attributes) inside existing registered namespaces? Do we really need this mess? > Serous question: I wonder where do you see the benefit in schema > validation? You (always) need a parser which ensures that protocol > requirements like "this attribute must exist", or "this attribute must > be a uint32_t" are fulfilled. I have this validator in ejabberd, yes. And if it's enabled, the stanza with element will be rejected. And I consider this as a correct behaviour. > And you want to enforce a maximum top-level stream element size early > in the processing chain. I didn't understand the stuff about top-level stream element size, how this relates to validation? > But if you have that, what is the gain in validating against a schema? Have what? Again, in my case server validation is needed to avoid sending garbage to clients (i.e. x='abc' when it should be an integer). ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] UPDATED: XEP-0363 (HTTP File Upload)
Sun, 03 Dec 2017 19:01:58 - Jonas Wielicki (XSF Editor) wrote: > Version 0.4.0 of XEP-0363 (HTTP File Upload) has been released. The new element is added within *existing* namespace. Now we have two different schemas with the same namespace. In the case you don't care: why didn't you add it inside 'jabber:client' namespace, then? Why do we need namespaces at all? Let's put any new elements inside 'jabber:client'. Also, I remind, that RFC6120 Section 11.4 says: > An implementation MAY choose to accept or send only data that has been > explicitly validated against the schemas provided in this document, > but such behavior is OPTIONAL So, this rule doesn't apply to XEPs schemas? In the case it does, what schema version should a server use to validate the content? In the case it doesn't, what a server should do with unknown element within *known* namespace (sic): dropping element? remain it untouched? The latter case is meaningless, because the idea of server-side validation is to prevent sending garbage to clients. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0313: Treatment of type=groupchat in user archive with or without hint
Thu, 23 Nov 2017 19:19:38 +0100 Kim Alvefur wrote: > It does make some sense to allow a for a future where MIX is common > and the problems with storing MUC messages in personal archives has > gone away. How will it be gone away? MIX still suggests using MUC archives directly when you're joining a room first time. Also, messages could be lost (due to server outage for example). So eventually we will end up with inconsistent archives (i.e. local archive differs from MUC archive). I tend to think using local archives for MUC is a terrible idea. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] 2017-11-08 XSF Council Minutes
Mon, 20 Nov 2017 21:34:52 +0500 Konstantin Kozlov wrote: > It's too bad you didn't use your veto against that awful proto. Which proto do you mean? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0136: Message Archiving moved to Deprecated
Thu, 16 Nov 2017 11:50:55 +0300 Kozlov Konstantin wrote: > It's a nice idea to recommend experimental XEP's. I agree with your irony, but this is the case where formal rules don't work as planned. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0136: Message Archiving moved to Deprecated
Thu, 16 Nov 2017 11:42:58 +0300 Kozlov Konstantin wrote: > Bad thing is that developers of new clents don't know which XEP to > implement. XEP-0136 (which is deprecated) or XEP-0313 (which is still > experimental and may be deferred, retracted and so on). MAM is recommended by the compliance suite. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Message Markup
Tue, 07 Nov 2017 20:34:04 - Jonas Wielicki (XSF Editor) wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Message Markup > Abstract: > This specification provides an alternative to XHTML-IM with rigid > separation of content and markup information, improving the resilience > against spoofing and injection attacks. > > URL: https://xmpp.org/extensions/inbox/markup.html Decent XEP. It doesn't require external parsers and is hard to screw up. I wish XSF will advance it. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Styling
Wed, 15 Nov 2017 08:54:07 + Dave Cridland wrote: > Conversations is following an existing trend. Sam has merely > documented it, and we're trying to ensure that the downsides of this > approach - and I don't think anyone pretends there aren't any - are > mitigated. Fine. Then, according to XSF policy, you should mark this XEP as "Historical". ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Styling
Wed, 15 Nov 2017 08:48:42 +0100 Jonas Wielicki wrote: > That is in fact incorrect. The whole council needs to be convinced, > since voting is veto-based. A single "-1" counters a proposal. Oh, we have a hope ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Styling
Wed, 15 Nov 2017 09:21:22 +0300 Kozlov Konstantin wrote: > I hope the Council will never accept such inconsistent thing as an > official XEP. Too late, it's already implemented in Conversations and, since it's kinda a trend maker, this stuff will stick around. Which is sad, because: 1) no matter what arguments you bring if a Council member wants it, it will be merged making all XSF discussions pointless 2) a trend making app is a bad thing: all IT is suffering because of this and the consequence is hyped adopted technologies (like Markdown and the whole HTML5 pile of shit) which sucks in technical sense. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Styling
Tue, 7 Nov 2017 20:10:19 + Dave Cridland wrote: > * The format is quite small, so a parser - while still a parser, with > all that that entails - is about as simple as one could imagine. Really? Can I use LALR parser for this? If yes, there should be a YACC-like grammar I can use in my language, I don't want to spend time on this. Otherwise I will just take existing implementation and patch it. Not everybody likes writing parsers. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Styling
Mon, 6 Nov 2017 13:07:02 -0700 Peter Saint-Andre wrote: > Why not just use Markdown (or a subset thereof)? By whom? By Sam? From what I understand the intention to be markdown incompatible is a fool protection. But I think this will not work for the reason I just described. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Styling
Mon, 06 Nov 2017 13:31:32 -0600 Sam Whited wrote: > This spec does not use Markdown, nor is it compatible with markdown, > so if people use a Markdown library they won't get the same formatting > described in this spec. But they can easily fork existing md-to-js engines like [1] and patch it. So we still need to rely on reliability of those engines. [1] https://github.com/showdownjs/showdown ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] IM Message Routing 2: Device Identity
Tue, 24 Oct 2017 08:28:00 +0100 Kevin Smith wrote: > You’re describing exactly the problem that the split-resource > approach we’re talking about avoids. If you have nodes choose > node-specific resources for the clients, it’s not possible for there > to be a collision when the cluster merges after a partition. I also don't see how this is superior to just having resource -> node mapping in your table, e.g.: u...@server.com -> [(resource1, node1), (resource2, node2)]. and generate resources for clients by yourself. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] IM Message Routing 2: Device Identity
Tue, 24 Oct 2017 10:41:06 +0300 Evgeny Khramtsov wrote: > same user's resource I wanted to say "same user's application". ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] IM Message Routing 2: Device Identity
Tue, 24 Oct 2017 08:28:00 +0100 Kevin Smith wrote: > If you have nodes choose node-specific resources for the clients, > it’s not possible for there to be a collision when the cluster merges > after a partition. Technically yes, but you will end up with 2 sessions of the same user's resource (it's pretty much real situation). You will have problems in this state, for example, with IQ routing. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] IM Message Routing 2: Device Identity
Mon, 23 Oct 2017 10:11:54 +0100 Kevin Smith wrote: > bin it and trust the new value No. Let's imagine a situation: a cluster with 2 nodes, there is a transient partition between them. During this partition period, a client connects to different nodes with the *same* resource. When the cluster gets connected again you cannot just simply replace local session-id with remote session-id in your session table, you most likely need to apply last-write-wins strategy (or similar) and then kick the older resource. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Time-bound unsubscription from presence info of particular users
Fri, 20 Oct 2017 16:01:31 +0530 vaibhav singh wrote: > Is there provision in presence protocol for this? You can block incoming presences using Privacy Lists (XEP-0016). ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Security issues with XHTML-IM (again)
Wed, 18 Oct 2017 21:43:22 +0100 Maxime Buquet wrote: > I don't want to shut all doors, but I have a hard time seeing what > benefit this will bring. I only see wasted time and effort, and years > of incompatibilities and tensions between clients. All of this to > bring more or less the same product on the table, in a slightly > modified way. > > We have one XEP that allows embedding rich content in messages, and > that is XHTML-IM. I do agree that the XEP is not perfect, and that we > can garnish it a bit more with security recommendations, etc., but in > general it does the job. > > Replacing it with JSON or another specified format will certainly lead > to the same kind of issues that start this thread. > > Yes, developers have to be careful, and no, not everybody is. Once > we've reached this stage I don't think there is any point in > discussing if it's going to be more or less prone to vulnerabilities. Agreed. I also don't see how using another format guarantees absence of security issues. OK, with XHTML-IM we know some sort of attacks (XSS mostly), and we can consider this. Also, there might be other attacks we don't know about yet. But with other formats the situation is the same: there are some known vulnerabilities (bare minimum: failure to escape HTML tags correctly), and there are some unknown attacks. What is the difference? If we say that we cannot implement securely any XML markup, it doesn't magically mean we can implement securely other markups. Fine, we can assume that the amount of existing+potential bugs in XHTML is greater than in other proposed markup, but is it worth putting effort into writing a new XEP, breaking compatibility, requiring developers to re-implement the same in a different way only because it's less bug prone? Using the same logic we should rewrite XMPP in something more secure than XML, because it also has lots of security issues (see [1] for example). [1] https://www.owasp.org/index.php/XML_Security_Cheat_Sheet ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] IM Message Routing 2: Device Identity
Wed, 18 Oct 2017 16:43:54 +0100
Kevin Smith wrote:
> It’s much easier to keep a global lookup table if you don’t have to
> deal with conflicts because the identifiers are node-specific -
> that’s where the gain in not needing the (effective) lock comes in
> here.
You still need to resolve conflicts for any global table if you want to
be partition tolerant. I really see no benefits. Also sometimes you
need to fetch some info about a connection (like an IP address), but if
you keep only {jid -> resources} global mapping you need to perform RPC
calls to other nodes which is expensive as hell (in terms of latency).
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Re: [Standards] IM Message Routing 2: Device Identity
Wed, 11 Oct 2017 19:14:31 +0200 Georg Lukas wrote: > Contra: not cloud-scale, because it requires a global lock when a > client reconnects. However, a global lookup table is needed anyway to > enumerate all resource of a client for presence / bare-JID routing. I already replied in xsf@ chatroom, I'd like to clarify here why I think per-resource inter-node routing doesn't work as expected (at least in my practice): You need to know all user's connected resources in a lot of places: routing messages to bare jids, routing subscriptions, routing roster pushes, routing blocking commands, admin commands, etc. One may argue that you can just broadcast (or use gossip/epidemic routing) to all nodes, but in fact it's much more efficient to broadcast a c2s session pointer/record at all nodes only once (on login) or twice (on logout) in order to keep the "c2s" table replicated on all nodes instead of doing this indefinite amount of times (this will depend on use case). Or you can use internal cache in front of the global table in a database such as SQL/Redis/etc. This will still be more efficient in my opinion. For example, ejabberd uses both approaches depending on a database you choose to store sessions. Another issue with broadcasting is offline messages (we need to eliminate them to make it work) and per-priority routing (no idea how to solve this with broadcasting). Of course, it's possible to use broadcasting if the underlying XMPP routing protocol is changed, but I'm not sure we want to go this route because some complexity will be put on clients. Hope I was clear ;) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0045 MUC: am I still there?
Sat, 7 Oct 2017 16:11:49 +0200 Georg Lukas wrote: > What about RFC 6120, §8.2.3? I know about this rule, but it doesn't make sense for self-IQs, because it breaks no compatibility. > Also, one of the proposals actually was an IQ sent to the MUC JID > instead of the self-JID, which would be a better way than this. Fine, I'm just saying. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0045 MUC: am I still there?
Sat, 7 Oct 2017 09:56:38 +0200 Florian Schmaus wrote: > Would that require a namespace bump? What Georg said. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0045 MUC: am I still there?
Sat, 7 Oct 2017 10:12:14 +0200 Georg Lukas wrote: > Even if we mandate that self-IQs have to be reflected to the sender, > it's still two round-trips just to figure out if we are still joined: > > c->s: ping > c<-s: ping reflection > c->s: pong > c<-s: pong reflection No, you can filter out incoming self-IQs, nobody requires you to reply. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0045 MUC: am I still there?
Wed, 4 Oct 2017 10:19:47 +0200 Georg Lukas wrote: > (*) poezio and yaxim solve that by sending a 0199 ping to your own > participant JID. However, in Multi-Session Nick scenarios, the ping IQ > will be routed to a "random" client of yours, and if that client is > currently suffering from a bad connection, your desktop client will > run into a ping timeout and erroneously think it got disconnected > from the MUC. Can be fixed by specifying the server rules for such self-IQs, i.e. resources in 'from' and 'to' should match. MSNs anyway should be described in the XEP. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS
Wed, 27 Sep 2017 14:33:07 +0100 Dave Cridland wrote: > But in any case, I think we can declare victory. Neat. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS
Wed, 27 Sep 2017 13:10:58 +0300 Evgeny Khramtsov wrote: > Wed, 27 Sep 2017 10:17:14 +0100 > Dave Cridland wrote: > > > I believe I have the right records and code running at > > dave.cridland.net if you'd like to try. > > Yes, it works (connected to 5270 port and TLS auth is accepted), but > your server then connected on my _xmpp-server port, despite I have > _xmpps-server defined: > > $ host -t srv _xmpps-server._tcp.zinid.ru > _xmpps-server._tcp.zinid.ru has SRV record 0 0 5270 xmpp.zinid.ru. Ah, this is probably because of priority. I fixed that, but it will take time for DNS zone update. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS
Wed, 27 Sep 2017 10:17:14 +0100 Dave Cridland wrote: > I believe I have the right records and code running at > dave.cridland.net if you'd like to try. Yes, it works (connected to 5270 port and TLS auth is accepted), but your server then connected on my _xmpp-server port, despite I have _xmpps-server defined: $ host -t srv _xmpps-server._tcp.zinid.ru _xmpps-server._tcp.zinid.ru has SRV record 0 0 5270 xmpp.zinid.ru. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS
Wed, 27 Sep 2017 08:51:48 +0100 Dave Cridland wrote: > * We have one S2S implementation, supporting SNI. > > On that basis, I don't *think* we can include S2S in Final, which is > frustrating. We probably can include C2S, but with only one > client-side implementation it's playing a little fast and loose, I > think, and I'd much rather see SNI support server-side to feel > satisfied that SNI is actually covered. I just added partial support to ejabberd: https://github.com/processone/ejabberd/commit/c17ec50e3a989e3d8ceb78f94ee2a7d5eec5f7d3 Not sure if this is counted as THE IMPLEMENTATION, because incoming SNI is not processed (not a big deal if you have only a single virtual host, but a problem with multi-hosting deployments). ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Rename XEP status identifiers
Tue, 26 Sep 2017 14:22:17 +0200 Goffi wrote: > I've seen that there was a need > to get disco items in XEP-0355. I've tried to update my Prosody > implementation and Pubsub component to test it, and now that I see > it's working, I want to update the XEP. I actually found the disco part the most irritable. There is a state where a component is connected, a server sent a disco request and no disco response is received yet. In this state it's hard to say anything about correctness of work of a component: this can be use case dependent. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
Tue, 12 Sep 2017 09:21:00 -0500 Sam Whited wrote: > Would not making it a dependency and merging it into the Blocking XEP > solve this for you as well? And say bye-bye to namespace delegation? At the moment we don't have any plans to add XEP-0377 functionality (largely because we don't know what to do with the collected reports yet), but ejabberd supports namespace delegation and anyone can add spam reporting support to ejabberd using this delegation. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
Tue, 12 Sep 2017 13:10:54 +0200 Guus der Kinderen wrote: > By not tying this XEP to Blocking, the XEP becomes even easier to > implement, but also more versatile. As a slightly embarrassing, but > truthful, illustration: if this XEP would not have been dependent on > Blocking, it would now already be in Openfire (I tried, but failed, > as the privacy list implementation in Openfire is too complex to > easily integrate this). That's what I'm trying to say here. This is clearly a problem of software dependencies. Reducing them resolves the problem. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
Tue, 12 Sep 2017 12:11:45 +0200 Daniel Gultsch wrote: > By bundling it with blocking we 'force' a consistent UI among > clients. And on the other hand 'forces' server devs to put all functionality into a single module or building modules dependencies. In the case of clients you can add "UI Consideration" section, but what can you do in the case of servers? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
Tue, 12 Sep 2017 12:25:55 +0200 Jonas Wielicki wrote: > Nobody said that the element necessarily has the same namespace as > currently used by other XEP-0191 elements. So I can easily add elements such as inside a because why not? There is only SHOULD and also guys from XSF do this. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
Tue, 12 Sep 2017 11:34:26 +0200 Jonas Wielicki wrote: > You are wrong, I think. RFC 6120, Section 11.4 Validation: The section says nothing about servers. And the receiving entity is a server in our case. > That is the whole point of extensibility. No, as I see it, the point of extensibility is to add elements within another namespaces instead of injecting elements into existing ones. > Also, XML Schemas in XEPs are non-normative anyways Yes, and that's pity. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
Tue, 12 Sep 2017 10:02:26 +0100 Dave Cridland wrote: > I don't think so. We're just adding an element, so it could be done > with just a new disco feature, I think. Hum, am I missed something? Strict xmpp entities could not allow elements not defined in schema, no? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
Mon, 11 Sep 2017 18:14:38 -0500 Sam Whited wrote: > That sounds good to me, I'll see if I can't prepare an update to do > that. Since the blocking command is draft I'm not sure that it's > possible. There is a problem, because we need to bump XEP-0191's namespace (there is no element defined within current namespace). Ah, and another issue against wrapping: could be handled separately by an external entity, see XEP-0355. Having all that, given that some folks also suggest handling it separately I think we shouldn't wrap. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
Tue, 12 Sep 2017 00:05:07 +0200 Philipp Hörist wrote: > It just makes me sad, that not even about something basic and easy > like reporting a jid for spam, we can find to an agreement. Well, actually I'm open to find a compromise. If the author insists on wrapping it into element and says that this is a "blocking reason", then I'm fine with defining this in XEP-0191. This should not be a problem, right? Because it's assumed that spam reporting is unusable outside XEP-0191 anyway. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
Mon, 11 Sep 2017 22:28:29 + Sam Whited wrote: > XEP-0016 is deprecated so I am not interested in making this more > complicated to support it. Deprecating something doesn't magically solve the problem and force operators/users to update software (remember vcard avatars or private storage, though, they are not formally deprecated, but deprecation will not change anything). So we *must* be interested. And yes, this is complicated to support, we should deal with this. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
Mon, 11 Sep 2017 23:52:46 +0200 Philipp Hörist wrote: > Afterwards we could do the addition to blocking command for the report > function, as long as there is discovery for this additional feature to > blocking command I'm curious what problem does this solve? Is there a problem for a client to send two stanzas instead of one? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
Mon, 11 Sep 2017 16:32:23 -0500 Sam Whited wrote: > but if it is a spam report you probably always want it to result in a > block. So, probably? Or are you absolutely sure? Another question is what if the server doesn't have XEP-0191 module running, but, instead, have XEP-0016 running? Ah, I forgot, we don't care about backward compatibility anymore. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
Mon, 11 Sep 2017 23:07:57 +0200 Holger Weiß wrote: > I think it's obvious that you're not responding to the actual question > here, and I wonder why :-) Let me answer. Because he thinks that those two actions should be always performed together. But in this case why do we need to have a spam reporting mechanism? Let's assume that the blocked person is always a spammer. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
Mon, 11 Sep 2017 15:54:33 -0500 Sam Whited wrote: > On Mon, Sep 11, 2017, at 15:39, Evgeny Khramtsov wrote: > > What if we decide to report SPAM to a separate entities? > > That is out of the scope of this spec; that's more complicated, and is > not something that is allowed by this specification. > > > Really, we're now creating problems out of nothing. > > I don't understand how this creates any problems; it is an XEP that > lets you provide a reason when you block something. > > > Let's just use a separate query. > > I don't think this is any better. > > > What is the problem with this??? The software should be modular > > and, if possible, there should be as less dependencies between > > modules as possible. > > I agree with this. Why does this imply you need two modules? Build it > into the blocking command module. OK, I'm done. Do whatever you want. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
Mon, 11 Sep 2017 15:24:13 -0500 Sam Whited wrote: > In retrospect this flexibility feels poor to me; let's just have one > way to do things (which should be an extension of the blocking > command, IMO). What if we decide to report SPAM to a separate entities? Really, we're now creating problems out of nothing. Let's just use a separate query. What is the problem with this??? The software should be modular and, if possible, there should be as less dependencies between modules as possible. I don't see any problems with a separate request. Or are you trying to optimize traffic here again? :) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
Mon, 11 Sep 2017 22:21:17 +0200 Guus der Kinderen wrote: > spam can be reported to any entity that advertises support, > and could be inlined with Block if/when desired. So a server should support both methods? This is even worse. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
Mon, 11 Sep 2017 12:32:09 -0500 Sam Whited wrote: > Is there anything missing you think a spam reporting XEP must do? Was > your implementation experience (clients and servers) smooth? Did you > find any part of using it especially painful? How are you using it and > is the data it provides you useful or should more information be > attatched? etc. I actually reported the issue here: https://mail.jabber.org/pipermail/standards/2017-January/031883.html TL;DR: I don't like the inclusion of element inside element and, thus, will not implement it in such form. There should be a separate request for blocking. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Permanent slots for HTTP Upload
Fri, 8 Sep 2017 10:30:11 -0400 Denver Gingerich wrote: > https://jmp.chat/ Nice service, thanks for sharing :) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Permanent slots for HTTP Upload
Fri, 08 Sep 2017 14:36:47 +0200 Goffi wrote: > Also HTTP upload means that server must handle a totally different > protocol/ server with all the security considerations that this > imply I really don't see a problem here. I think we should reuse technologies which are proven to work and have tons of libs (like SIP for A/V and HTTP for bulk data). Why do we always want to use XMPP everywhere no matter what is beyond me. > I'm also thinking about serverless. You can always use IPFS on desktop (there is a problem with it on mobile though). ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Permanent slots for HTTP Upload
Fri, 8 Sep 2017 14:11:06 +0200 Philipp Hörist wrote: > This does not mean a Jingle Server component wouldnt be usefull in > other circumstances. I thought Jingle is supposed to work e2e. Not this time? :) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Permanent slots for HTTP Upload
Fri, 08 Sep 2017 12:28:56 +0200 Goffi wrote: > It's not poorly adopted at all None of my clients use it. And I use well-maintained clients (Dino+Conversations). Where is it adopted? How can I make an A/V-call to Gajim or Xabber or whatever? > it's well designed, support range, hash, metadata, NAT transversal, > alternative methods/fallbacks and various transports How is this superior to HTTP get/put? How hashes and metadata will help you exchanging avatars with mutually unsupported formats? In practice, clients never check caps of their peers, otherwise we would have avatars working. Also, we used to have avatars working, but after some clever improvements we have even this broken. > It's only missing part is an URI scheme to retrieve the data, it was > supposed to be done for a while, I'm not sure what happened there. Happened what always happens with Jingle: nobody wants to implement it, so no need to bother improving specs. Also, if there is an HTTP for file exchange which covers all the cases (offline/muc), why would client devs mess with Jingle which is much more complex? > Actually using HTTP upload would not be a problem for me if XEP-0084 > or anything adopted would accept files sent by jingle. How is this supposed to interact with old clients? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Permanent slots for HTTP Upload
Fri, 08 Sep 2017 11:12:00 +0200 Goffi wrote: > Hi Daniel, > > while I'm all in favor of using a way to request permanent storage, > I'm don't think using HTTP for avatars is a good idea at all. I'm with Daniel here. I'm strongly against sending media data via signaling channel. > Avatar handling is not good at the moment (too many ways to do it, > specifications not restrictive enough specially on format), and I > think we need a way to get several formats with one mandatory (so > everybody can get it), but with the ability to provide several sizes, > and vectorial format, which can't be provided by HTTP upload (or at > least not in the current state). We can write a brief XEP on how servers should "convert" between PEP/vCard/http avatars anyway, because seems like adoption of PEP-based avatars is failing. I'm personally ready to implement such XEP in ejabberd. > Also while HTTP upload is handy, I still think that we have far > better tools with Jingle, I only see HTTP upload as an ad-hoc quick > and dirty solution, not as something we should use to build more > elaborate things. No way Jingle is a better tool, really. It's complex and poorly adopted despite years have passed. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Permanent slots for HTTP Upload
Fri, 8 Sep 2017 10:58:46 +0200 Daniel Gultsch wrote: > However most servers currently have rather low retention periods of 10 > days or 30 days (which is fair). They should consider using IPFS [1] or something, instead of making such draconian restrictions. [1] https://ipfs.io ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Reputation system for XMPP
Wed, 6 Sep 2017 10:18:09 +0200 Georg Lukas wrote: > a) Throttle per-IP IBR attempts How? By restricting a period a single IP can register an account? Doesn't work: spammers walk through the huge list of servers, effectively bypassing the restriction. > b) Throttle outgoing presence/messages from "new" clients Spammers use tons of JIDs. I collected some statistics from jabber.ru: during a day a single SPAM jid only sends ~50 messages in general, it's about the amount of these jids, which is huge. > c) Improve methods for automatic s2s reporting: >- mandatory server operator JID publishing >- automatic way to report and handle spammer IBR accounts > > d) Improve ingress s2s spam detection / blocking (I'm currently > throttling s2s connections, but that's not ideal). > > e) Have a public shame list of servers where the admins don't do > anything about spam, and use that to degrade their experience in the > federated Jabber network. Maybe they don't care now, but they will > notice if their users complain - or migrate to other servers. Not sure how this will work when we have 30% of abandoned servers :-/ > c) Implement spam reporting (XEP-0377) - that only makes sense if > there is some action mechanism behind, so that the reports don't just > vanish in the server logs. There is a problem with spam reporting. Research shows that there should be an incentive for a user to report it and, if there is no incentives, the more the number of peers in the system, the less likely that anyone will report about a malicious peer [1]. So we should *force* users to report. Subscriptions are very good in this regard: you either accept or deny it. [1] http://ieeexplore.ieee.org/abstract/document/4156483 ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Reputation system for XMPP
Wed, 6 Sep 2017 08:44:22 +0200 Remko Tronçon wrote: > I was sort of hoping that you would come up with a magic trick after > getting through your reading list. Hehe, most of the problems in that list is about how to authenticate remote servers in SMTP (like SPF, DKIM and so on). I didn't find lots of new information from that list, frankly, and that's why I started investigating p2p literature. > I don't see an easy solution. Looking at my account, my guess is > badly setup servers are the biggest problem today. Servers probably > need to tighten their registration (e.g. no IBR, harder proof of > validity), server vendors might > take steps to discourage bad setups (e.g. make it hard to enable > IBR), but you'll always > have to deal with the case of badly setup servers (and eventually > malicious servers) on > a federated network, so you'll need to have S2S checks. The problem is, last time I checked[1], one third of ejabberd servers were running ancient versions, like 5 years old or more. There are also lots of jabberd servers, not sure they have any registration protection at all. Seems like we need to punish a lot of servers in order to tighten things up. [1] https://chatlogs.jabber.ru/ejabb...@conference.jabber.ru/2017/03/02.html#15:42:12.564438 ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
