the users that the service is back up and
that they could join again. Having a standard way to do this would be handy.
Cheers,
--
Mickaël Rémond
> On 19 Jun 2019, at 11:26, Daniel Gultsch wrote:
>
> Thank you Kim for explaining that. I wasn’t aware that Prosody was doing this.
>
> F
ed CSI, but as the XEP is deferred, I guess this is intended.
Maybe, for consistency then, we can remove iq-auth, as the XEP is obsolete.
I hope this helps,
--
Mickaël Rémond
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/sta
Hello Marcel,
> On 11 Jun 2019, at 14:59, Marcel Waldvogel
> wrote:
>
> On Tue, 2019-06-11 at 14:23 +0200, Mickaël Rémond wrote:
>> Hello Guus,
>>
>>> On 11 Jun 2019, at 14:00, Guus der Kinderen >> <mailto:guus.der.kinde...@gmail.com>>
ive.
I can easily live with "best practices" instead of "standards" and hardcode a
few values in my lib.
Cheers,
--
Mickaël Rémond
> On 11 Jun 2019, at 14:31, Guus der Kinderen
> wrote:
>
> I'd have to check, but I think we're sending a IQ Ping when the cl
,
--
Mickaël Rémond
> On 11 Jun 2019, at 14:19, Guus der Kinderen
> wrote:
>
> Yeah, I remember our then-CEO telling us that his phone "would not get warm
> anymore", after we changed the interval from 30 seconds to 2 minutes. That
> was over a decade ago thoug
G is an obvious choice, but any query will do). As the
> client is obliged to respond, if anything with an error, the server knows if
> the connection is, in fact, lost.
What would be the trigger for determining that the connection is lost and send
the ping? Is it whitespace keep-alive or
thing at the application level, then do something at the XMPP
> level, such as stream management.
The goal is to save bandwidth and CPU parsing time on both the client and the
server. When you have to handle a lot of clients, the whitespace keepalive
makes a huge diff
could be part of the stream management
negotiation)
What do you think ?
--
Mickaël Rémond
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
-one.net/xmpp-mobile-groupchat-introducing-muc-subscription/
ejabberd master already supports it.
I hope this will help us gather from the field feedback to help improve MIX.
Anyway, we are also ready to implement and propose feedback on the next MIX
iteration.
Cheers,
--
Mickaël Rémond
On Wed
>
We also wants to get things moving and to help get started we have just
added experimental MIX support to ejabberd:
https://github.com/processone/ejabberd/commit/b5121a346d5775bdac20aa6a52a96434073fb1b6
>From there, plan is to start testing with real clients to have real live
feedback to fo
chieve what you need by limiting presence broadcast to
"moderators". In specific implementations, that list of options could
presumably handle different restriction to presence broadcast (like self
for example).
Own user presence is still broadcasted to self in all cases to acknowledge
join.
I hop
roach is
> considered useful.
Yes, I think this would be useful. We have something similar to this but it
would be nice to be able to rely on something standard.
I am willing to review / help with implementation for the purpose of having
real life feedback.
Thanks !
--
Mickaël Rémond
ht
think it is worth it ?
--
Mickaël Rémond
http://www.process-one.net
, very intermittent connection.
I hope clearly specialising both XEP will make developers of both types
of apps happy.
--
Mickaël Rémond
http://www.process-one.net
needed]).
Actually, the first spec we published is already used for an Amazon S3
backend in production.
--
Mickaël Rémond
http://www.process-one.net
Hello Florian,
On 4 Aug 2015, at 22:45, Florian Schmaus wrote:
On 04.08.2015 19:35, Mickaël Rémond wrote:
I hope it makes sense to you :)
It really seems like a xep33 service needs to keep track of presence
sessions established via xep33 broadcasted presences, similar to what
servers
Hello Florian,
On 4 Aug 2015, at 22:45, Florian Schmaus wrote:
On 04.08.2015 19:35, Mickaël Rémond wrote:
I hope it makes sense to you :)
Yep. At first I was thinking that triggering the unavailable presence to
the xep33 service could become an issue. But after looking again at
xep33
Hello Florian,
On 4 Aug 2015, at 18:39, Florian Schmaus wrote:
On 03.08.2015 22:21, Mickaël Rémond wrote:
What happens next is unspecified, but I think it should be as follow:
Maybe I'm missing something, but why is that underspecified? The
server
of the user sending the presences
some change
improvements from me. I have lot of experience using XEP and writing
informal XMPP extensions, but this is my first attempt at patching
official XEPs.
Thanks !
--
Mickaël Rémond
http://www.process-one.net
On 31 Jul 2015, at 18:31, Daniel Gultsch wrote:
Yes I had the very same
need to practice my XEP writing style :)
--
Mickaël Rémond
http://www.process-one.net
Hello Sam,
On 31 Jul 2015, at 22:17, Sam Whited wrote:
On Fri, Jul 31, 2015 at 1:25 AM, Mickaël Rémond
mrem...@process-one.net wrote:
I don't see any mention of headers in your document, except for
Content-MD5, (though it does cover the case where you can request a
file's GET url from
type
Yes, that's what I reused muc#user.
--
Mickaël Rémond
http://www.process-one.net
this parameter should alternatively (even primarily) accept the
room/nick criteria.
How does it sounds ?
Do you see other way for solving original issue ?
Thanks !
--
Mickaël Rémond
http://www.process-one.net
are admin and can see JID now, you still can
investigate an abuse yesterday for example.
So, wouldn't the check being done at time of access to the archive be
reasonable enough ?
--
Mickaël Rémond
http://www.process-one.net
else missing ?
If you want I can try to propose a patch on HTTP file upload proto XEP based on
some of these ideas, but I would like to be sure this is helpful.
--
Mickaël Rémond
http://www.process-one.net
Hello,
As a follow up, as promised, here is what we have implemented and tested
with Amazon S3:
https://github.com/processone/ejabberd-saas-docs/blob/master/http-filetransfer/http-filetransfer.md
I hope you will find some ideas could be valuable for Daniel's proposal.
--
Mickaël Rémond
http
service. It seems a bit strange as I would expect to have a
single service to talk to for my MUC archives
- The filter / with behaviour would still need to be clarified. Does it
really make sense to return only messages send by a given user ?
Thanks !
--
Mickaël Rémond
http://www.process-one.net
clearer and
maybe we can pick a few ideas from there for the XEP.
I hope this helps,
--
Mickaël Rémond
http://www.process-one.net/
On Mon, Jul 27, 2015 at 9:37 AM, XMPP Extensions Editor
edi...@xmpp.org wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: HTTP
?
Should this only be implemented in component that need it (for example
MUC) ?
I think any clarification on the use case that the XEP covers would be
welcome.
Thanks !
--
Mickaël Rémond
http://www.process-one.net
On 14 Jul 2015, at 18:37, XMPP Extensions Editor wrote:
Version 0.1 of XEP
Hello,
I read the Unique and Stable Stanza I
On 14 Jul 2015, at 18:37, XMPP Extensions Editor wrote:
Version 0.1 of XEP-0359 (Unique and Stable Stanza IDs) has been released.
Abstract: This specification describes unique and stable IDs for stanzas.
time-sensitive.
I think it implies that they should not be pushed as well. Otherwise,
you may receive a push notification for a message you will never be able
to receive if you reconnect.
Am I wrong ?
Do you think it could be useful to clarify the push XEP on that point ?
Thanks !
--
Mickaël
Hello,
On 1 Jul 2015, at 11:42, Dave Cridland wrote:
On 1 July 2015 at 09:20, Mickaël Rémond mrem...@process-one.net
wrote:
I think it implies that they should not be pushed as well. Otherwise,
you
may receive a push notification for a message you will never be able
to
receive if you
in the same good way.
But my feeling is that we need that registry if we want to cover the
mobile case.
--
Mickaël Rémond
http://www.process-one.net/
type='set' id='x97'
disable-all xmlns='urn:xmpp:push:0' jid='push-5.client.example' /
/iq
What about having the ability to list all your nodes (= devices) + the
ability to delete a node as owner ?
That would allow you to manage them as a users.
I hope this helps,
--
Mickaël Rémond
http
Hello,
On 4 Mar 2015, christian...@rechenwerk.net wrote:
On Di, 2015-03-03 at 21:55 +0100, Mickaël Rémond wrote:
Here is a very common example: I would like to receive push on my
mobile, even if my desktop client is connected. In that situation,
the message will not use offline and may
sending. And as a user, I need to be able to manually
clean that list in some rare but important cases.
Does it make sense ?
--
Mickaël Rémond
http://www.process-one.net/
example on how they are used
created and deleted ?
- I could not see how that step is performed in the XEP: The App Client
sends the token to the App Server for later use.
Sorry for the very basic questions and thanks for your feedback.
--
Mickaël Rémond
http://www.process-one.net/
Hello,
On 3 Mar 2015, christian...@rechenwerk.net wrote:
On 03.03.2015 16:16, Mickaël Rémond wrote:
Hello,
On 3 Mar 2015,christian...@rechenwerk.net wrote:
Then the client app hands this information over to its xmpp server
using the enable-iq stanza so the xmpp server can publish push
be a plugin to
change XMPP behavior in multi-user chats ?
If you control the client, you can always send a message stanza containing an
extension that you client will understand.
I guess you do not need to change the MUC behaviour in that case.
--
Mickaël Rémond
http://www.process-one.net/
By harcoding the node in sm-id, who is immutable during the session
you cannot move the session to the node the user is resuming the
session. It will not work on second resume.
We need the full jid but it seems we are alone, so I see no point in
fighting for that.
--
Mickaël Rémond
http
Le 27 févr. 09 à 15:34, Dave Cridland a écrit :
No, I disagree, the sm-id is allocated by the server, the server can
put as much meaning into it as it wants. It's still opaque to the
client.
If the server's implementation means that it needs to have access to
the full jid, then it
Hello,
I was wondering if someone has already done some work on end to end
encryption to protect a stream from the relay ?
I feel this is important if we want public relay to become more useful
and more largely used.
Any thought ?
--
Mickaël Rémond
http://www.process-one.net/
Hello,
Le 19 nov. 07 à 23:20, Tomasz Sterna a écrit :
Dnia 19-11-2007, Pn o godzinie 22:27 +0100, Mickaël Rémond pisze:
Nodeprep adds forbidden characters to usual stringprep tables. Among
those characters we find / (47).
IIUC the only reason that slash '/' character is forbidden in a node
are appreciated.
Cheers :)
--
Mickaël Rémond
http://www.process-one.net/
;
| micalg=sha1;
| protocol=application/pkcs7-signature
It seems to me that it implies and requires CDATA to be part of XMPP.
You can check by yourself:
http://www.xmpp.org/rfcs/rfc3923.html
--
Mickaël Rémond
http://www.process-one.net/
Hello,
Le 31 juil. 07 à 13:58, Mridul a écrit :
Hi,
Not sure where the confusion was ... I always assumed that
support for
CDATA was a given since it is just another xml construct.
So am I. I have been surprise by the heated debate :)
--
Mickaël Rémond
http://www.process-one.net/
agree with that statement.
--
Mickaël Rémond
http://www.process-one.net/
47 matches
Mail list logo
