On Wed, Dec 11, 2019 at 3:52 AM, Tedd Sterr
wrote:
Dave notes this is unchanged since being rejected by the previous
Council, and wants to avoid setting a precedent where an XEP is
re-submitted unchanged until one Council eventually accepts it.
Just my few cents: I'm with Dave here. If it has
On Mon, Nov 25, 2019 at 5:25 PM, Dave Cridland
wrote:
We put arbitrary namespaced data inside messages and other stanzas
all the time to no ill effect. Why is putting it inside PEP data
items so different?
Because I like the approach used when designing ASN.1 schemas (see for
example RFC 528
On Mon, Nov 25, 2019 at 5:17 PM, Dave Cridland
wrote:
If you're saying we shouldn't have arbitrary namespaced data in such
places, I disagree.
Yes, I see that we disagree. Dead end like always.
___
Standards mailing list
Info: https://mail.jabber.or
On Mon, Nov 25, 2019 at 4:47 PM, Philipp Hörist
wrote:
From a programming perspective I would argue that storing one element
away is much less work than searching for all unknown child elements.
+1. I also disagree with what Jonas and Dave said: we should not abuse
extensibility by putting an
Oops, sorry, wrong thread. I was mentioning XEP-0402 (Bookmarks 2) of
course.
On Wed, Nov 6, 2019 at 8:53 AM, Evgeny wrote:
...
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr
On Wed, Oct 23, 2019 at 9:41 PM, Paul Schaub
wrote:
1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?
2. Does the specification solve the problem stated in the
introduction
and requirements?
The purpose of the XEP is unclear. The
On Tue, Oct 15, 2019 at 9:27 PM, Marvin W wrote:
IMO XEPs should never mandate anything on UI.
Mandating - no. But you can find lots of SHOULDs in different RFCs, for
example when talking about errors displaying in user agents. Seems like
it's becoming a common practice...
On Thu, Oct 10, 2019 at 11:20 AM, JC Brand wrote:
Now you're saying "limitation", previously you said "restriction".
I use those words interchangeably in this context.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standar
On Thu, Oct 10, 2019 at 10:59 AM, JC Brand wrote:
Well, to come back to Georg's point of not deprecating BOSH until we
have a
solution, it seems that XEP-0397 would need to be included in the
compliance
suite, at least for this particular use-case (maintaining anonymous
logins
over websocket)
On Thu, Oct 10, 2019 at 10:52 AM, JC Brand wrote:
You're arguing against a point nobody made.
Nobody advocated using BOSH to bypass restrictions in XEP-0198.
The issue Georg mentioned isn't due to anything in XEP-0198.
The issue is with the SASL anonymous login mechanism not allowing you
to
r
On Wed, Oct 9, 2019 at 6:07 PM, Evgeny wrote:
supporting both XEP-0198 and BOSH makes no sense at all
I would also add that implementing both XEP-0198 and BOSH in the server
is not a trivial task at all. I would say both are very complex to
implement correctly and have tons of caveats. So
On Wed, Oct 9, 2019 at 10:20 PM, Evgeny wrote:
I still doubt this is anyhow more secure than session resumption in
XEP-0198 (which btw requires real re-authentication).
Let me explain: using BOSH to bypass restriction of XEP-0198 (namely,
SASL re-authentication) doesn't justify usage of
On Wed, Oct 9, 2019 at 10:11 PM, JC Brand wrote:
"Restoring" a session means simply making a new request within the
timeout
period. Whether the browser tab has been reloaded in the meantime is
irrelevant.
I still doubt this is anyhow more secure than session resumption in
XEP-0198 (which btw
On Wed, Oct 9, 2019 at 6:27 PM, Evgeny wrote:
According to such logic this "problem" should be resolved for plain
TCP c2s as well. Unless it's not solved we should not kill BOSH.
Ah, and another question is raising: why actually BOSH allows you to
restore the ses
On Wed, Oct 9, 2019 at 6:24 PM, Georg Lukas wrote:
Until this problem is solved, I'd rather not kill BOSH.
According to such logic this "problem" should be resolved for plain TCP
c2s as well. Unless it's not solved we should not kill BOSH.
___
Sta
On Wed, Oct 9, 2019 at 5:56 PM, Jonas Schäfer
wrote:
- Should we really require both BOSH and WebSockets for the Web Suite
for
clients? Maybe it makes more sense to require it both for Servers,
but only
one of them for clients, possibly even phasing out BOSH. (Disclaimer:
I’m not
a Web person
On Thu, Jun 6, 2019 at 12:45 PM, Daniel Gultsch
wrote:
I never liked the behaviour of some clients that would simply show
error messages without any context whatsoever in the chat window.
I prefer clients that track actual messages and mark individual
messages as failed.
That's a typical pitfa
On Mon, Apr 29, 2019 at 6:05 PM, Daniel Gultsch
wrote:
how about sending the upnp as a fallback using transport-replace, with
a new transport (new id) of type s5b:1?
Guys, how about switching to TURN instead? Maybe it's time already? ICE
is not something new anymore. You will really benefit f
On Wed, Apr 10, 2019 at 1:43 PM, Melvin Keskin wrote:
But end-to-end encryption is about sending encrypted messages from one
secure endpoint to another secure endpoint. It is not about securing
the endpoints themselves. If an endpoint is compromised, no end-to-end
encryption can help.
Encrypti
On Sat, Apr 6, 2019 at 5:59 PM, Jonas Schäfer
wrote:
I agree with Florian fully. This is rather non-idiomatic to implement
on the
client side, due to how XMPP works otherwise. The flow suggested by
Florian is
more idiomatic and implementable with less brain-hurt.
I don’t see any advantage (on
On Sat, Apr 6, 2019 at 12:59 PM, Jonas Schäfer
wrote:
I integrated more feedback and after lots of folks shouting "SHIP IT"
at me
and it haunting me in my dreams (not really), I decided to give it a
shot.
Is it possible to render full author's name in the version history?
___
On Wed, Apr 3, 2019 at 6:02 PM, Melvin Keskin wrote:
I appreciate that you think of UX aspects but ATT should not degrade
UX
when another way of authentication is implemented alongside it. For
ATT
no user interaction is needed and it can always be used. It is not
necessary to deactivate it. It
On Wed, Apr 3, 2019 at 5:52 PM, Melvin Keskin wrote:
Every way has its advantages and its disadvantages.
Everything is relative, I see.
That was the reason for creating ATT. I
wanted the users to benefit from automating the whole process of key
authentication now and not some day in the futu
On Wed, Apr 3, 2019 at 5:06 PM, Melvin Keskin wrote:
ATT does not depend on EAX. It just tackles the challenge of key
authentication when using end-to-end encryption with multiple devices
having different keys.
I already replied: if we produce both XEPs, we'll end up with some
devices with ma
On Wed, Apr 3, 2019 at 4:54 PM, Melvin Keskin wrote:
Hello Evgeny,
thanks for your comments.
Hi, Melvin!
This is especially doubtful,
since it's speculated that the topology of a social graph has power-
law
distribution [1] and thus only a few people will benefit from the
&
On Mon, Apr 1, 2019 at 9:40 PM, Florian Schmaus
wrote:
I am a little bit worried that this will take a few detours to
implement
cleanly and elegant in clients and client libraries. Especially since
this pattern never occurred before.
Instead I suggest the following control flow, which should b
On Mon, Apr 1, 2019 at 12:40 PM, Daniel Gultsch
wrote:
MLS is simply not
available right now. Also we have successfully pushed OMEMO into a
fairly high number of clients; it would be unfair to users and
developers alike to just drop it. That doesn’t mean we can’t
simultaneously explore other opt
On Mon, Apr 1, 2019 at 11:13 AM, Paul Schaub
wrote:
There was a ton of
interesting discussions around OMEMO and other stuff, as well as some
productive coding (and Mate!).
Not to bash the ProtoXEP itself, but why the community constantly
discussing OMEMO (and sometimes PGP), when there is ong
On Mon, Apr 1, 2019 at 12:03 PM, Tedd Sterr
wrote:
somewhat working MIX implementation!
Apr 1 :/
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
On Fri, Mar 29, 2019 at 5:08 PM, Dave Cridland
wrote:
In Winfried's case, he attended the 2016 FOSDEM key signing event
where someone turned up with a specimen passport, and all but 20
people signed his key anyway since they naturally assumed that nobody
would be doing that. Winfried was
On Fri, Mar 29, 2019 at 4:57 PM, Dave Cridland
wrote:
That's interesting, because my understanding was that the result of
ATT was that if I manually verify one of your keys, I could then
transitively trust all of your keys - I didn't read this as being
that I might trust any third party
On Fri, Mar 29, 2019 at 4:07 PM, Evgeny wrote:
1) The "trusted" graph is not connected (i.e. you cannot reach any
vertex from any other vertex), thus, in the worst case the complexity
of verification will remain the same. This is especially doubtful,
since it's speculated that
On Thu, Mar 28, 2019 at 8:23 PM, Dave Cridland
wrote:
Overall, my view is that this specification is very unclear and
impossible to implement as written.
I don't understand how this will work in practice indeed.
1) The "trusted" graph is not connected (i.e. you cannot reach any
vertex from an
On Thu, Mar 28, 2019 at 12:41 PM, Philipp Hörist
wrote:
I saw no arguments against 0394 and its approach, as i see it
perfectly fits Andrews usecases.
I dont see that there is a need to enclose each markup element into
reference elements just for the sake of consistency. This would lead
to som
On Wed, Mar 27, 2019 at 11:17 PM, carlo von lynX
wrote:
XMPP will be nearly completely dead in coming years
as it has always refused to change the fundament of its
inflexibility
Hey, dude, how is your psyced going? Oh, it's dead. Okay.
___
Standards
Hey, Georg, Dave.
I think I have addressed all your concerns in my new local copy [1]
[1] http://upload.zinid.ru/xep-eax-cir.html
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xm
On Fri, Mar 22, 2019 at 2:18 PM, Dave Cridland
wrote:
You can just have a note somewhere that says "All examples, and much
the the terminology, assumes that a CA is hosted on a XMPP server
entity addressed by a domain-style Jid; this is not a requirement of
the protocol, and a CA MAY be a
On Fri, Mar 22, 2019 at 11:29 AM, Georg Lukas wrote:
* Tedd Sterr [2019-03-17 21:53]:
Proposed XMPP Extension: E2E Authentication in XMPP: Certificate
Issuance and Revocation -
https://xmpp.org/extensions/inbox/eax-cir.html
+1
Thank you very much for the thorough review.
- A CA doe
On Tue, Mar 12, 2019 at 11:08 PM, Jonas Schäfer
wrote:
This specification defines an XMPP protocol extension for sending DNS
queries and getting DNS responses over XML streams. Each DNS query-
response pair is mapped into an IQ exchange.
Is this supposed to be an April 1st joke?
_
On Tue, Mar 12, 2019 at 8:35 PM, Daniele Ricci
wrote:
Did I lose the email by Wiktor? Or did he replied to you only?
https://mail.jabber.org/pipermail/standards/2019-March/035859.html
___
Standards mailing list
Info: https://mail.jabber.org/mailman/
On Tue, Mar 12, 2019 at 8:17 PM, Evgeny wrote:
Yeah, my protoXEP allows for instant certificate issuance without
challenges [1]
Oops, forgot the link:
http://upload.zinid.ru/xep-eax-cir.html#cert-issuance
___
Standards mailing list
Info: https
On Tue, Mar 12, 2019 at 2:33 PM, Wiktor Kwapisiewicz
wrote:
Issuing this certificates can also be automated, just like certbot
does for Let's Encrypt. This would work in backwards compatible way,
so for everyone that don't want to opt-in to this scheme a regular
captcha would be shown. But for
Hi, standard people!
So I'm going to propose my third (and last) protoXEP [1] in EAX series
[2][3][4].
Since the editor is kinda busy these weeks, I'd like the Council to add
it to the upcoming agenda, since it's empty anyway :)
I see here and there some confusion on WTF I'm actually doing, so
On Mon, Mar 4, 2019 at 7:42 AM, Ненахов Андрей
wrote:
I think that the whole idea of making compliance suites as a xep is
flawed and creates unnecessary bureaucracy for bureaucracy sake.
It could have been just a page on xmpp.org website, listing XEPs that
council currently consideres part of
On Thu, Feb 14, 2019 at 2:20 PM, Wiktor Kwapisiewicz
wrote:
SASL EXTERNAL has some practical issues, like client certs being sent
in cleartext [1] and the fact that for example Android requires lock
screen to be on to add client certs to the store not to mention
problems in browsers (browsers
On Fri, Feb 8, 2019 at 9:23 AM, Marcel Waldvogel
wrote:
I just became aware that XEP-0412/RFC 6120 mandate SCRAM-SHA-1-PLUS.
The way I understand it, the required TLS Channel Binding for the
SASL -PLUS schemes is not possible from browser-based clients, as
there is no way to get at the require
On Tue, Feb 5, 2019 at 7:58 PM, Dave Cridland wrote:
Meetings are normally held every Wednesday at 1600 UTC in the
xmpp:coun...@muc.xmpp.org?join chatroom.
s2s with the server doesn't work for me.
___
Standards mailing list
Info: https://mail.jabb
On Fri, Jan 25, 2019 at 1:45 PM, Dave Cridland
wrote:
I'm hearing "no", here - which is fine - but I do have a design for
enforced password changes and password resets, too. The former is
built around SASL2 (XEP-0388) and was actually one of the original
design goals. Password resets we built
On Fri, Jan 25, 2019 at 12:39 AM, Jonas Schäfer
wrote:
My understanding is that Dave talks about Mandatory To Implement,
which is
something different than Mandatory To Deploy / Mandatory To Offer (at
least
that’s what I get from reading the relevant section in RFC 6120).
I think this is fals
On Thu, Jan 24, 2019 at 9:15 PM, Dave Cridland
wrote:
XMPP-Grid (that draft) essentially says both servers and clients MUST
implement EXTERNAL, SCRAM-SHA1, SCRAM-SHA1-PLUS, SCRAM-SHA-256, and
SCRAM-SHA-256-PLUS.
Is there any interest in updating our MTI?
How can we require SHA-256 when we d
On Thu, Jan 24, 2019 at 6:46 PM, Jonas Schäfer
wrote:
For stuff like TURN/STUN/... I would suggest to investigate the
possibility of
tokens for user authentication (which cannot be used to log into the
XMPP
service). I think I’ve seen such an implementation of a
STUN/TURN/XMPP setup
in the pa
On Thu, Jan 24, 2019 at 6:39 PM, Florian Schmaus
wrote:
I am not sure if the XSF is the right venue
Well, some people cite RFC 6120, as I understand, section 13.8.1,
which requires, among others, to support SCRAM-SHA1-PLUS. So
XSF responsibility cannot be completely ruled out.
___
On Thu, Jan 24, 2019 at 6:37 PM, Philipp Hörist
wrote:
You get the password in plain at the point when the user creates the
account. Then you save it in 1 and 256.
In this case what prevents an operator to store plain password
as well? And we force him to do so, when he also runs
STUN/TURN/SIP
On Thu, Jan 24, 2019 at 6:05 PM, Sam Whited wrote:
Depending on the TLS
library you use, it may also not give you the TLS first message unless
you're not doing renegotiation, in which case you're also safe.
There is another problem with TLS offload, because to my
knowledge "proxy protocol" (su
On Thu, Jan 24, 2019 at 6:05 PM, Sam Whited wrote:
To my knowledge, we don't have a good solution for this.
Okay. In this situation the only solution for me is not
implementing anything except SHA1 to avoid interop problems.
___
Standards mailing li
On Thu, Jan 24, 2019 at 6:11 PM, Florian Schmaus
wrote:
Then you can't authenticate unless the server also stores the
authentication data for SCRAM-SHA1. I guess that is your point. What
is
wrong with the server storing the required data to authenticate
clients
with eg. SCRAM-SHA1 or SCRAM-SHA
Hi there.
Can someone please clarify how to maintain ineroperablity of
SCRAM-SHA1 vs SCRAM-SHA256 vs SCRAM-SHA-WHATEVER, e.g.
when some clients support SCRAM-SHA1 only, but the password
was created in SCRAM-SHA256 format. I know it's still
possible to authenticate via PLAIN, however:
1) Using PL
On Sat, Jan 19, 2019 at 11:44 PM, Kim Alvefur wrote:
I would like to see XEP-0292: vCard4 Over XMPP advanced. Since
popularity and deployment of XEP-0084 appears to be on the rise, much
thanks to XEP-0398, now seems like a good time to dust it off and
finish
it.
Given that "modern" clients d
On Fri, Jan 18, 2019 at 12:19 PM, Dave Cridland
wrote:
is that those same people will expect to be able to have their
specifications rubber-stamped through the process.
I fail to see how this is even possible within the XSF process.
If the spec is bad it will get -1 from the Council.
But I, ho
On Thu, Jan 17, 2019 at 8:41 PM, Ненахов Андрей
wrote:
Yes, so far this process has led XMPP to a great success, with jabber
being used as a primary communication protocol by a significant
portion of internet users.
You will be now told that this is irrelevant and basically
everything XSF does
On Thu, Jan 17, 2019 at 1:05 PM, Dave Cridland
wrote:
we do not require it until Final - not even Draft has an absolute
requirement.
I thought transitioning to Draft requires Call For Implementors,
but whatever. Again this raises a question about how sane all
those XEP statuses nowadays. I kno
On Sun, Jan 13, 2019 at 2:40 PM, Goffi wrote:
Future XEPs may extend this, but in case where it's too complicated,
implementation has always the choice to not implement it, or to have
different features with different backends.
I really don't see how this will work in practice.
1) a client is
On Sun, Jan 13, 2019 at 2:16 PM, Goffi wrote:
For Pubsub services based on SQL or NoSQL databases, it should not be
too hard to implement as ordering is most of time a part of API.
Note however, that some NoSQL databases only support a single index
in the query, DynamoDB is such an example. Yo
On Sun, Jan 13, 2019 at 2:16 PM, Goffi wrote:
a XEP for XPATH like syntax
And the server will process this XPATH query?
Not sure if you're serious...
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: st
On Mon, Jan 7, 2019 at 8:28 PM, Goffi wrote:
Are you talking about the fact that "date of modification" (as
defined in the protoXEP) could be out of sync between clusters?
No, from the discussion I thought you want to have something like
incremental
unique "order" attribute in the node.
And
On Mon, Jan 7, 2019 at 10:44 AM, Goffi wrote:
Is there any implementation in the wild which would have issue with
node order?
Sure, any clustered database will have issues with
such naive approach: after partitioning during merge
you'll end up with duplicated orders, like 2 items
with order=4.
On Sat, Jan 5, 2019 at 8:02 PM, Ненахов Андрей
wrote:
That was a joke. Of course, decent developers these days should use
json for tasks like these.
LMAO
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe
On Sat, Jan 5, 2019 at 6:35 PM, j.r wrote:
Why do you think this? I think that wouldn't that much complicated...
Because replication in distributed systems is an absurdly
complex topic by itself and this complexity will inevitably
lead to implementation bugs which is even harder to debug
than
On Wed, Jan 2, 2019 at 7:49 PM, Dave Cridland wrote:
Out of curiosity, do we know if the cryptographic properties involved
in sending a known set of plaintext about like that stack up?
I wonder how everyone is fixated on crypto part while the hardest
part is messages replication itself: in the
Just for the record,
this is not implemented in ejabberd, because this won't work
in clustered environment and locally you need some atomic operations
(if you support SMP) which sucks. At least from what I remember.
Not worth the effort, IMO.
___
Stan
On Fri, Nov 30, 2018 at 10:10 AM, Ненахов Андрей
wrote:
in our group chat protocol we did the following
So we now have muc light, muc sub, xabber muc, original muc and mix.
Who is next?
___
Standards mailing list
Info: https://mail.jabber.org/mailma
On Tue, Nov 20, 2018 at 6:43 PM, Florian Schmaus
wrote:
On 20.11.18 15:54, Georg Lukas wrote:
* Tedd Sterr [2018-11-15 20:41]:
8) PR #716 - XEP-0030: Clarify 'disco#info' feature in
'disco#info' responses - https://github.com/xsf/xeps/pull/716
-1, but we should add the Note about exa
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 tra
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
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, e
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
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
m
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 go
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
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 lang
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 th
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
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?
___
Standard
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,
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.
___
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 use
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
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.o
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] u
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 th
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 wi
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 S
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
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
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 alre
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
Unsubscr
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 no
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 t
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, poten
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
1 - 100 of 359 matches
Mail list logo
