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

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

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,

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

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

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.

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 >

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

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?

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

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.

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

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

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:

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 >

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. > >

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

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

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

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

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:

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

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

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

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 >

Re: [Standards] Adding logo to MUC and PubSub node

Thu, 8 Feb 2018 14:21:49 +0100 Daniel Gultsch <dan...@gultsch.de> wrote: > 2018-02-08 13:43 GMT+01:00 Evgeny Khramtsov <xramt...@gmail.com>: > > Thu, 8 Feb 2018 13:17:14 +0100 > > Daniel Gultsch <dan...@gultsch.de> wrote: > > > >> at least for

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. ___

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)

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

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,

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

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

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).

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

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

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

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

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

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

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

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.

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

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

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:

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

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

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:

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

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

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.

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

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,

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

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

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

Re: [Standards] IM Message Routing 2: Device Identity

Tue, 24 Oct 2017 10:41:06 +0300 Evgeny Khramtsov <xramt...@gmail.com> wrote: > same user's resource I wanted to say "same user's application". ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Uns

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

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*

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:

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

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

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

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,

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:

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

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

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:

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

Wed, 27 Sep 2017 13:10:58 +0300 Evgeny Khramtsov <xramt...@gmail.com> wrote: > Wed, 27 Sep 2017 10:17:14 +0100 > Dave Cridland <d...@cridland.net> wrote: > > > I believe I have the right records and code running at > > dave.cridland.net if you'd like to try

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,

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

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

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 >

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

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

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

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?

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

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

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

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

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

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

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

Mon, 11 Sep 2017 15:54:33 -0500 Sam Whited <s...@samwhited.com> 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, a

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

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.

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

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:

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

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

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,

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

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]

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

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

Re: [Standards] Reputation system for XMPP

Tue, 5 Sep 2017 23:06:22 +0200 Remko Tronçon wrote: > This couples presence (and the roster) even more tightly with > messaging than it already is. I agree that presences and rosters are second-class citizens in modern IM world. We could use another stuff (like a requirement

Re: [Standards] Reputation system for XMPP

Tue, 5 Sep 2017 15:52:50 -0600 Peter Saint-Andre wrote: > Given that all the XMPP spam I have ever received is about paying > someone to send even more XMPP spam (nothing about pharmaceuticals, > easy ways to make money, or anything really interesting like that), I > expect

Re: [Standards] Reputation system for XMPP

Tue, 5 Sep 2017 15:20:05 -0600 Peter Saint-Andre wrote: > Remko, what do you suggest? > > When I log in and receive dozens of spam messages, that's a degraded > user experience. If we can use tools we have (such as rosters and > presence subscriptions) to make that

Re: [Standards] Reputation system for XMPP

Tue, 05 Sep 2017 09:10:22 -0500 Sam Whited wrote: > Removing the text doesn't seem like an appropriate solution to me in > general. Presumably this means you get a request from an unknown JID, > but now have no way to tell that it's spam and not a friend reaching > out, so

Re: [Standards] Reputation system for XMPP

Tue, 5 Sep 2017 08:23:57 +0100 Dave Cridland wrote: > We're teaching client developers not to render the textual part of > the subscription request, which for previously unknown contacts would > normally prove most interesting After we started receiving subscriptions from

  1   2   3   >