Hello,
On 31 Jul 2015, at 18:34, Daniel Gultsch wrote:
2015-07-31 18:31 GMT+02:00 Daniel Gultsch dan...@gultsch.de:
As for namespaces I would probably reuse XEP-0033: Advanced stanza
addressing http://xmpp.org/extensions/xep-0033.html
oh ok forget about this part. It doesn't have a from
Hello,
While iterating on our MAM for MUC server-side implementation, we
reached an issue on the following part of the XEP.
1. from in MUC archive:
When sending out the archives to a requesting client, the 'to' of the
forwarded stanza MUST be empty, and the 'from' MUST be the occupant JID
Hi,
2015-07-31 17:49 GMT+02:00 Mickaël Rémond mrem...@process-one.net:
We thus think that we need in some way include the room nick in the
message and only include the real JID if you have the right to access it,
to preserve the anonymous behaviour of the room. XEP-0045 says: However,
the
Hello,
On 31 Jul 2015, at 18:31, Daniel Gultsch wrote:
So, I think it may be interesting and more flexible to state that the
from
attribute will contain the room/nick JID and to add a special tag for
real
JID. For consistency, we can reuse the same approach we have for
presence
on
On Fri, Jul 31, 2015 at 1:25 AM, Mickaël Rémond mrem...@process-one.net wrote:
I think what we had implemented covers all this:
https://github.com/processone/ejabberd-saas-docs/blob/master/http-filetransfer/http-filetransfer.md
Here is what you have in mind ?
Anything else missing ?
I don't
Hello Sam,
Le 30 Jul 2015 à 20:21, Sam Whited s...@samwhited.com a écrit :
My position is that we should adopt HTTP File Upload with the
provision that it add support for specifying headers that the client
should send back, and possibly an IQ to fetch the GET URL later to
support file
Hello Goffi,
XEP-0027 has serious security concerns, especially regarding reply
attacks and key verification (you can read those in the Security
considerations paragraph of the XEP). It's true that a real
replacement hasn't been drafted yet (there are some drafts, but
nothing really definitive or
G'day,
I have a few questions about OpenPGP. XEP-0027 has been obsoleted by
council on 26/03/2014, but I can't see no explanation.
OpenPGP is not the best for instant messaging (and OTR is the de facto
standard), but still it's interesting for normal messages (e.g. with an
SMTP gateway),
On 31/07/2015 10:27, Daniele Ricci wrote:
Hello Goffi,
XEP-0027 has serious security concerns, especially regarding reply
attacks and key verification (you can read those in the Security
considerations paragraph of the XEP). It's true that a real
replacement hasn't been drafted yet (there are
Just wanted to notify that the link for the Git mirror is outdated:
http://xmpp.org/about-xmpp/xsf/xsf-source-control/
I think you've migrated to GitHub, right?
--
Daniele
10 matches
Mail list logo