[Standards] UPDATED: XEP-0319 (Last User Interaction in Presence)
Version 1.0.1 of XEP-0319 (Last User Interaction in Presence) has been released. Abstract: This specification defines a way to communicate time of last user interaction with her system using XMPP presence notifications. Changelog: Be precise about the profile used. (egp) URL: https://xmpp.org/extensions/xep-0319.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
On Montag, 11. September 2017 18:51:35 CEST Sam Whited wrote: > On Mon, Sep 11, 2017, at 17:39, Kim Alvefur wrote: > > The SPAM payload itself is of interest for further analysis, so a way to > > get it would be nice. But we don't want to make it easy to lie and > > submit something and claim it came from an innocent. Perhaps a message > > id, that could be corelated with either an archive or some simple > > buffer? > > I had assumed that the server would be storing things and we didn't need > to send it back, but maybe that's not always the case. This does seem > like the kind of thing we might need to store or send back somehow. I think it makes sense to specifically address a message. The server can of course source the last N messages from the archive concerning the reporeted JID, but that seems error prone to me. On the other hand, users could have difficulties to report a SPAM attack which consited of multiple messages if only a single one (even if multiple ones can be reported, it’s more work and unlikely to happen) can be reported. Not sure there’s a good and easy solution here. > > Since you can send out multiple stanzas without waiting for a reply, > > there doesn't have to be any additional roundtrips. A network stack can > > even return the responses in the same TCP segment. > > A service operator can't guarantee that the clients connected to them > will do that though. If a client can’t pipeline stanzas, it has worse issues (it would likely block while waiting for MAM to download on connect for example). This should, IMO, not be an argument. As for the XEP in general, it is unclear to me what the features actually say. The features are phrased to announce support for "Spam Reporting". The use with the blocking command looks a bit example-ish to me, and if future uses in other places are planned, having a separate feature indicating support for embedding into the blocking command seems reasonable. That said, I’m strongly in favour for making this a separate IQ. Merging this in XEP-0191 seems wrong to me (do one thing and do it well). Having this extend XEP-0191 in the way it currently does also seems wrong to me. It at least needs to clearly specify a feature which indicates support for embedding the report into the blocking command. I think in that case I’m fine with it, but still not happy. A separate IQ seems semantically more reasonable, especially since experience shows that blocking a JID is rarely useful. If anything, blocking a domain is useful, but then we’re back to "how does the server learn which messages from this domain were actually SPAM?". For the Security Considerations: I would argue that it definitely needs more. It appears that a client can harm the reputation of a JID by blocking it as spam. This should be mentioned, since it possibly attacks the availability of the affected JID for others, too. I think something along the lines of "Servers should take care when using the spam reports for actions besides blocking the JID for the reporting user, unless the spam report has been verified to be actually spam in some way." would make sense. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
On 12.09.2017 00:39, Kim Alvefur wrote: > On Mon, Sep 11, 2017 at 12:32:09PM -0500, Sam Whited wrote: >> On Mon, Sep 11, 2017, at 12:13, Jonas Wielicki wrote: >>> XEP-0377 (Spam Reporting) has been Deferred because of inactivity. >> >> Hi all. Spam reporting was just (correctly) deferred. Several servers >> have implemented it, but only a handful of operators and client >> developers, as far as I can tell so I wanted to see what the experience >> with it is so far: >> >> Is there anything missing you think a spam reporting XEP must do? > > The SPAM payload itself is of interest for further analysis, so a way to > get it would be nice. But we don't want to make it easy to lie and > submit something and claim it came from an innocent. Perhaps a message > id, that could be corelated with either an archive or some simple > buffer? Definitely that. >> Was your implementation experience (clients and servers) smooth? > > I think it's fine. I can understand wanting it to be a standalone IQ > request instead and I have nothing against changing it to that. I also that that it would be far better design if it was a standalone IQ. > Since you can send out multiple stanzas without waiting for a reply, > there doesn't have to be any additional roundtrips. A network stack can > even return the responses in the same TCP segment. Exactly that, the roundtrip argument does not apply. Also the argument that (client) libraries may not perform this optimization is going into the wrong direction. We had a similar situation with MAM (remember the 'fin' message?), where a bad protocol design was justified with "it's easier to impement". Good that we switched and do the right thing now. - Florian signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
On Mon, Sep 11, 2017, at 17:39, Kim Alvefur wrote: > The SPAM payload itself is of interest for further analysis, so a way to > get it would be nice. But we don't want to make it easy to lie and > submit something and claim it came from an innocent. Perhaps a message > id, that could be corelated with either an archive or some simple > buffer? I had assumed that the server would be storing things and we didn't need to send it back, but maybe that's not always the case. This does seem like the kind of thing we might need to store or send back somehow. > Since you can send out multiple stanzas without waiting for a reply, > there doesn't have to be any additional roundtrips. A network stack can > even return the responses in the same TCP segment. A service operator can't guarantee that the clients connected to them will do that though. > XEP-0191 allows blocking multiple JIDs at a time, which one has to keep > in mind when implementing 337 as it currently is. I hadn't actually thought of that; that seems like a UI concern that it's probably worth mentioning in the XEP. Thanks! > From what I've understood of current spammer tactics, it doesn't really > help to block individual JIDs, as they seem to be used only once. That may be so. Does it hurt to block them somehow though? —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
On Mon, Sep 11, 2017, at 17:51, Evgeny Khramtsov wrote: > 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. 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. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
On Mon, Sep 11, 2017, at 17:39, Evgeny Khramtsov wrote: > 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. I disagree, they'll get the new functionality when they upgrade. If not, they don't get it. We can't be backwards compatible forever and this isn't even a lack of backwards compatibility, it's a new feature so they have to implement something either way. —Sam ___ 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)
Hi, On Mon, Sep 11, 2017 at 12:32:09PM -0500, Sam Whited wrote: > On Mon, Sep 11, 2017, at 12:13, Jonas Wielicki wrote: > > XEP-0377 (Spam Reporting) has been Deferred because of inactivity. > > Hi all. Spam reporting was just (correctly) deferred. Several servers > have implemented it, but only a handful of operators and client > developers, as far as I can tell so I wanted to see what the experience > with it is so far: > > Is there anything missing you think a spam reporting XEP must do? The SPAM payload itself is of interest for further analysis, so a way to get it would be nice. But we don't want to make it easy to lie and submit something and claim it came from an innocent. Perhaps a message id, that could be corelated with either an archive or some simple buffer? > Was your implementation experience (clients and servers) smooth? I think it's fine. I can understand wanting it to be a standalone IQ request instead and I have nothing against changing it to that. Since you can send out multiple stanzas without waiting for a reply, there doesn't have to be any additional roundtrips. A network stack can even return the responses in the same TCP segment. > find any part of using it especially painful? XEP-0191 allows blocking multiple JIDs at a time, which one has to keep in mind when implementing 337 as it currently is. > How are you using it and is the data it provides you useful or should > more information be attatched? etc. I haven't quite figured out where the data should go yet, but made it so that other plugins can hook into it. >From what I've understood of current spammer tactics, it doesn't really help to block individual JIDs, as they seem to be used only once. -- Regards, Zash ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
On September 11, 2017 4:44:27 PM CDT, Evgeny Khramtsov wrote: >So, probably? Or are you absolutely sure? No, but this isn't designed to be a one size fits all solution to every problem under the sun, it's supposed to provide a simple, easy to implement solution for saying that you blocked someone because the message was spam. Would meeting it with the blocking command xep not fix your initial concerns without making it mite complicated? >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. XEP-0016 is deprecated so I am not interested in making this more complicated to support it. Again, let's keep it simple. It's hard to find a balance between "enough" features and "everything under the sun", but I think supporting alternative, deprecated blocking methods leans towards the latter. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
No not for me, in fact having one spam XEP on its own, and a second one with a report function in blocking command, makes implementation for clients more complicated. (not much although, we talking here about checking for one more feature) Roundtrips is not a good argument for me either, because how many people are you going to block a day? thats nothing in comparison with the traffic we are generating. 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. But go on. Philipp 2017-09-11 23:58 GMT+02:00 Evgeny Khramtsov : > 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 > ___ > ___ 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)
Hi, As this is about SPAM we should aim for something very simple that everyone will implement. I think the XEP should be standalone, not tied to anything else at first. So Server developers can implement it without having to implement anything else. 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 see no problem with that from the point of a client developer. Philipp 2017-09-11 23:44 GMT+02:00 Evgeny Khramtsov : > 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 > ___ > ___ 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)
Blocking Reason and Spam Reporting 2.0 could happily coexist. :-) On 11 Sep 2017 23:32, "Sam Whited" wrote: > On Mon, Sep 11, 2017, at 16:29, Evgeny Khramtsov wrote: > > 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. > > Maybe this should hav been called "blocking reason". The reason for a > block might not always be spam, but if it is a spam report you probably > always want it to result in a block. > > —Sam > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
On Mon, Sep 11, 2017, at 16:29, Evgeny Khramtsov wrote: > 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. Maybe this should hav been called "blocking reason". The reason for a block might not always be spam, but if it is a spam report you probably always want it to result in a block. —Sam ___ 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)
On Mon, Sep 11, 2017, at 16:08, Holger Weiß wrote: > Your assumption might be right or wrong. Using a separate query copes > with both cases. It also means the block and the spam report are no longer correlated and that there are more round trips with the server. Both of these don't seem desirable to me. As is, this XEP is very simple, I'd like to keep it that way. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
* Sam Whited [2017-09-11 15:32]: > I don't see why you'd want to report spam without also blocking the > sender personally. Your assumption might be right or wrong. Using a separate query copes with both cases. Holger ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
* Sam Whited [2017-09-11 15:54]: > On Mon, Sep 11, 2017, at 15:39, Evgeny Khramtsov wrote: > > 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. I think it's obvious that you're not responding to the actual question here, and I wonder why :-) If you do see a downside in using a separate query, I'd be interested as well. Holger ___ 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)
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. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
I'm not arguing that the XEP should define anything but the payload (and how entities do the initial reporting to their domain). Although there's no harm in blocking the sender of the spam that you reported, tying the two XEPs together implies that there are no other ways to prevent the spam after the report. To draw a parallel: when I mark an email as spam, I don't get a new inbound mail filter rule. I'm depending on my service provider to ensure that I, but perhaps also others, won't be bothered by the reported spam. I'd propose to modify this XEP a little to do only pretty basic reporting (to allow an end-user to send in a spam report) and have some recommendations on what implementations could do with such reports (blocking, sharing, what not), but leave the details of those actions to be described in XEPs. On 11 September 2017 at 22:32, Sam Whited wrote: > On Mon, Sep 11, 2017, at 15:29, Guus der Kinderen wrote: > > I'm not sure if the "reporting" bit should automatically go hand in hand > > with "blocking" specifically. There might be value in defining an entity > > that simply just receives spam reports. Obviously, end-users generally > > report spam because they want it to stop, but the goal of reporting could > > be broader. I'd not be opposed to a XEP that does just that: manage spam > > reports. The blocking bit is a logical extension to that, but there might > > be other extensions: things like analysis, and reports sharing with > > trusted > > other parties, etc. > > That's fair, and maybe you could reuse the same payload for that, but I > don't think this XEP should be expanded to cover anything else like > report sharing. It's just about sending the report to the server in the > first place. I don't see why you'd want to report spam without also > blocking the sender personally. > > —Sam > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
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)
On Mon, Sep 11, 2017, at 15:29, Guus der Kinderen wrote: > I'm not sure if the "reporting" bit should automatically go hand in hand > with "blocking" specifically. There might be value in defining an entity > that simply just receives spam reports. Obviously, end-users generally > report spam because they want it to stop, but the goal of reporting could > be broader. I'd not be opposed to a XEP that does just that: manage spam > reports. The blocking bit is a logical extension to that, but there might > be other extensions: things like analysis, and reports sharing with > trusted > other parties, etc. That's fair, and maybe you could reuse the same payload for that, but I don't think this XEP should be expanded to cover anything else like report sharing. It's just about sending the report to the server in the first place. I don't see why you'd want to report spam without also blocking the sender personally. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
I'm not sure if the "reporting" bit should automatically go hand in hand with "blocking" specifically. There might be value in defining an entity that simply just receives spam reports. Obviously, end-users generally report spam because they want it to stop, but the goal of reporting could be broader. I'd not be opposed to a XEP that does just that: manage spam reports. The blocking bit is a logical extension to that, but there might be other extensions: things like analysis, and reports sharing with trusted other parties, etc. On 11 September 2017 at 22:24, Sam Whited wrote: > On Mon, Sep 11, 2017, at 15:21, Guus der Kinderen wrote: > > The integration with block is an optional part of the XEP, isn't it? I'm > > reading it as: spam can be reported to any entity that advertises > > support, > > and could be inlined with Block if/when desired. > > Right now the only mechanism for reporting is the blocking command. > However, the payload was described in such a way > that it could be reusable if we wanted it to have its own special IQ > later. > > 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). > > —Sam > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
On Mon, Sep 11, 2017, at 15:21, Guus der Kinderen wrote: > The integration with block is an optional part of the XEP, isn't it? I'm > reading it as: spam can be reported to any entity that advertises > support, > and could be inlined with Block if/when desired. Right now the only mechanism for reporting is the blocking command. However, the payload was described in such a way that it could be reusable if we wanted it to have its own special IQ later. 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). —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
On Mon, Sep 11, 2017, at 14:56, Evgeny Khramtsov wrote: > 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. Thanks! After looking at it again, I do agree that it feels weird having this in a separate spec. However, I don't think it feels weird having it be a part of the blocking command (correlating the block and the reason for the block makes lots of sense in my mind). Maybe this should be merged into tXEP-0191 if that's still possible? Then everything is in one place. That being said, I also don't mind if it remains separate. If you arbitrarily split some concept of modules base don XEP, that's your choice, the XEPs shouldn't have to be formatted in such a way to make sure that your modules don't have interdependencies. Just put this functionality in whatever your blocking command extension is and be done with it. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
The integration with block is an optional part of the XEP, isn't it? I'm reading it as: spam can be reported to any entity that advertises support, and could be inlined with Block if/when desired. On 11 September 2017 at 21:56, Evgeny Khramtsov wrote: > 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 > ___ > ___ 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] DEFERRED: XEP-0377 (Spam Reporting)
On Mon, Sep 11, 2017, at 12:13, Jonas Wielicki wrote: > XEP-0377 (Spam Reporting) has been Deferred because of inactivity. Hi all. Spam reporting was just (correctly) deferred. Several servers have implemented it, but only a handful of operators and client developers, as far as I can tell so I wanted to see what the experience with it is so far: 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. Thanks, Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0378 (OTR Discovery)
XEP-0378 (OTR Discovery) has been Deferred because of inactivity. Abstract: This document provides a mechanism by which OTR encryption support can be discovered in XMPP, without relying on OTRs protocol agnostic discovery mechanism. URL: https://xmpp.org/extensions/xep-0378.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0377 (Spam Reporting)
XEP-0377 (Spam Reporting) has been Deferred because of inactivity. Abstract: This document specifies a mechanism by which users can report spam and other abuse to a server operator or other spam service. URL: https://xmpp.org/extensions/xep-0377.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0376 (Pubsub Account Management)
XEP-0376 (Pubsub Account Management) has been Deferred because of inactivity. Abstract: This specification describes a new model for handling remote pubsub services and a protocol for doing so. URL: https://xmpp.org/extensions/xep-0376.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0373 (OpenPGP for XMPP)
XEP-0373 (OpenPGP for XMPP) has been Deferred because of inactivity. Abstract: Specifies end-to-end encryption and authentication of data with the help of OpenPGP, announcement, discovery and retrieval of public keys and a mechanism to synchronize secret keys over multiple devices. URL: https://xmpp.org/extensions/xep-0373.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0371 (Jingle ICE Transport Method)
XEP-0371 (Jingle ICE Transport Method) has been Deferred because of inactivity. Abstract: This specification defines a Jingle transport method that results in sending media data using datagram associations via the User Datagram Protocol (UDP) or using end-to-end connections via the Transport Control Protocol (TCP). This transport method is negotiated via the Interactive Connectivity Establishment (ICE) methodology (which provides robust NAT traversal for media traffic) and also supports the ability to exchange candidates throughout the life of the session, consistent with so-called "Trickle ICE" (draft-ietf-ice-trickle). URL: https://xmpp.org/extensions/xep-0371.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0372 (References)
XEP-0372 (References) has been Deferred because of inactivity. Abstract: This document defines a method for one XMPP stanza to provide references to another entity, such as mentioning users, HTTP resources, or other XMPP resources. URL: https://xmpp.org/extensions/xep-0372.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0367 (Message Attaching)
XEP-0367 (Message Attaching) has been Deferred because of inactivity. Abstract: This specification defines a method for indicating that a message contains content which describes an earlier message in the conversation and should be grouped with the earlier message. URL: https://xmpp.org/extensions/xep-0367.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0361 (Zero Handshake Server to Server Protocol)
XEP-0361 (Zero Handshake Server to Server Protocol) has been Deferred because of inactivity. Abstract: This specification defines an approach for a pair of servers to eliminate initial handshakes and associated data transfer when using the XMPP S2S Protocol. This approach may only be used with a priori agreement and configuration of the two servers involved. This is of significant benefit in high latency environments. URL: https://xmpp.org/extensions/xep-0361.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0365 (Server to Server communication over STANAG 5066 ARQ)
XEP-0365 (Server to Server communication over STANAG 5066 ARQ) has been Deferred because of inactivity. Abstract: This specification defines operation over XMPP over the NATO STANAG 5066 data link service for point to point links (ARQ). This enables optimized XMPP performance over HF Radio (which STANAG 5066 was designed for) and over other data links using STANAG 5066. URL: https://xmpp.org/extensions/xep-0365.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0370 (Jingle HTTP Transport Method)
XEP-0370 (Jingle HTTP Transport Method) has been Deferred because of inactivity. Abstract: This specification defines two Jingle transport methods for establishing HTTP connections for either uploading or downloading data. URL: https://xmpp.org/extensions/xep-0370.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0360 (Nonzas (are not Stanzas))
XEP-0360 (Nonzas (are not Stanzas)) has been Deferred because of inactivity. Abstract: This specification defines the term "Nonza", describing every top level stream element that is not a Stanza. URL: https://xmpp.org/extensions/xep-0360.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0355 (Namespace Delegation)
XEP-0355 (Namespace Delegation) has been Deferred because of inactivity. Abstract: This specification provides a way for XMPP server to delegate treatments for a namespace to an other entity URL: https://xmpp.org/extensions/xep-0355.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0362 (Raft over XMPP)
XEP-0362 (Raft over XMPP) has been Deferred because of inactivity. Abstract: This specification provides a means for transporting messages from the Raft consensus algorithm over XMPP. URL: https://xmpp.org/extensions/xep-0362.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0356 (Privileged Entity)
XEP-0356 (Privileged Entity) has been Deferred because of inactivity. Abstract: This specification provides a way for XMPP entities to have a privileged access to some other entities data URL: https://xmpp.org/extensions/xep-0356.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0351 (Recipient Server Side Notifications Filtering)
XEP-0351 (Recipient Server Side Notifications Filtering) has been Deferred because of inactivity. Abstract: This specification defines a modern efficient way to deliver PubSub notifications. URL: https://xmpp.org/extensions/xep-0351.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0354 (Customizable Message Routing)
XEP-0354 (Customizable Message Routing) has been Deferred because of inactivity. Abstract: This specification specifies customizable behavior of RFC 6121 section 8.5.2.1.1 to allow various message routing algorithms (e.g., for load balancing). URL: https://xmpp.org/extensions/xep-0354.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0358 (Publishing Available Jingle Sessions)
XEP-0358 (Publishing Available Jingle Sessions) has been Deferred because of inactivity. Abstract: This specification defines an XMPP protocol extension that enables an XMPP entity to advertise the fact that it is willing accept a particular Jingle session request. The protocol is used mainly to inform other entities that a particular file is available for transfer via the Jingle File Transfer protocol defined in XEP-0234. URL: https://xmpp.org/extensions/xep-0358.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0353 (Jingle Message Initiation)
XEP-0353 (Jingle Message Initiation) has been Deferred because of inactivity. Abstract: This specification provides a way for the initiator of a Jingle session to propose sending an invitation in an XMPP message stanza, thus taking advantage of message delivery semantics instead of sending IQ stanzas to all of the responder's online resources or choosing a particular online resource. URL: https://xmpp.org/extensions/xep-0353.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0350 (Data Forms Geolocation Element)
XEP-0350 (Data Forms Geolocation Element) has been Deferred because of inactivity. Abstract: This specification defines an XMPP protocol extension for including geolocation data in XEP-0004 data forms. URL: https://xmpp.org/extensions/xep-0350.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0348 (Signing Forms)
XEP-0348 (Signing Forms) has been Deferred because of inactivity. Abstract: This specification describes a method whereby a client can sign a form using credentials not related to the current connection. URL: https://xmpp.org/extensions/xep-0348.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0347 (Internet of Things - Discovery)
XEP-0347 (Internet of Things - Discovery) has been Deferred because of inactivity. Abstract: This specification describes an architecture based on the XMPP protocol whereby Things can be installed and safely discovered by their owners and connected into networks of Things. URL: https://xmpp.org/extensions/xep-0347.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0345 (Form of Membership Applications)
XEP-0345 (Form of Membership Applications) has been Deferred because of inactivity. Abstract: This specification outlines the form and mandatory content of membership applications. URL: https://xmpp.org/extensions/xep-0345.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0349 (Rayo Clustering)
XEP-0349 (Rayo Clustering) has been Deferred because of inactivity. Abstract: This specification describes an extension to the Rayo protocol to support clustering of Rayo servers and their presentation as a unified service. URL: https://xmpp.org/extensions/xep-0349.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0342 (Rayo Fax)
XEP-0342 (Rayo Fax) has been Deferred because of inactivity. Abstract: This specification defines an extension to the Rayo protocol (XEP-0327) to provide provision for sending and receiving faxcimilies via a call under the control of a Rayo client. URL: https://xmpp.org/extensions/xep-0342.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0340 (COnferences with LIghtweight BRIdging (COLIBRI))
XEP-0340 (COnferences with LIghtweight BRIdging (COLIBRI)) has been Deferred because of inactivity. Abstract: This specification defines an XMPP extension that allows real-time communications clients to discover and interact with conference bridges that provide conference mixing or relaying capabilities. URL: https://xmpp.org/extensions/xep-0340.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0344 (Impact of TLS and DNSSEC on Dialback)
XEP-0344 (Impact of TLS and DNSSEC on Dialback) has been Deferred because of inactivity. Abstract: This specification provides documentation how Server Dialback is used together with Transport Layer Security, and discusses how the security considerations of Dialback are changed by the introduction of TLS and/or DNSSEC. URL: https://xmpp.org/extensions/xep-0344.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0346 (Form Discovery and Publishing)
XEP-0346 (Form Discovery and Publishing) has been Deferred because of inactivity. Abstract: This specification describes a series of conventions that allow the management of form templates and publishing of completed forms. URL: https://xmpp.org/extensions/xep-0346.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0338 (Jingle Grouping Framework)
XEP-0338 (Jingle Grouping Framework) has been Deferred because of inactivity. Abstract: This specification provides an XML mapping for translating the RFC 5888 SDP Grouping Framework to Jingle URL: https://xmpp.org/extensions/xep-0338.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0341 (Rayo CPA)
XEP-0341 (Rayo CPA) has been Deferred because of inactivity. Abstract: This specification defines an extension to the Rayo protocol (XEP-0327) to provide provision for performing Call Progress Analysis on a call under the control of a Rayo client. URL: https://xmpp.org/extensions/xep-0341.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0339 (Source-Specific Media Attributes in Jingle)
XEP-0339 (Source-Specific Media Attributes in Jingle) has been Deferred because of inactivity. Abstract: This specification provides an XML mapping for translating the RFC 5766 Source-Specific Media Attributes from SDP to Jingle URL: https://xmpp.org/extensions/xep-0339.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0343 (Signaling WebRTC datachannels in Jingle)
XEP-0343 (Signaling WebRTC datachannels in Jingle) has been Deferred because of inactivity. Abstract: This specification defines how to use the ICE-UDP Jingle transport method to send media data using WebRTC DataChannels, so technically uses DTLS/SCTP on top of the Interactive Connectivity Establishment (ICE) methodology, which provides robust NAT traversal for media traffic. URL: https://xmpp.org/extensions/xep-0343.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0327 (Rayo)
XEP-0327 (Rayo) has been Deferred because of inactivity. Abstract: This specification defines an XMPP protocol extension for the third- party control of telephone calls and other similar media sessions. The protocol includes support for session management/signaling, as well as advanced media resources such as speech recognizers, speech synthesizers and audio/video recorders. The protocol serves a different purpose from that of first-party protocols such as Jingle or SIP, and is compatible with those protocols. URL: https://xmpp.org/extensions/xep-0327.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0337 (Event Logging over XMPP)
XEP-0337 (Event Logging over XMPP) has been Deferred because of inactivity. Abstract: This specification provides a common framework for sending events to event logs over XMPP networks. URL: https://xmpp.org/extensions/xep-0337.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0329 (File Information Sharing)
XEP-0329 (File Information Sharing) has been Deferred because of inactivity. Abstract: This document specifies a simple extension to existing protocols that allows an entity to request information about files. URL: https://xmpp.org/extensions/xep-0329.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0333 (Chat Markers)
XEP-0333 (Chat Markers) has been Deferred because of inactivity. Abstract: This specification describes a solution of marking the last received, displayed and acknowledged message in a chat. URL: https://xmpp.org/extensions/xep-0333.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEFERRED: XEP-0332 (HTTP over XMPP transport)
XEP-0332 (HTTP over XMPP transport) has been Deferred because of inactivity. Abstract: This specification defines how XMPP can be used to transport HTTP communication over peer-to-peer networks. URL: https://xmpp.org/extensions/xep-0332.html If and when a new revision of this XEP is published, its status will be changed back to Experimental. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
