> This message constitutes notice of a Last Call for comments on
> XEP-0388.
>
> Title: Extensible SASL Profile
> Abstract:
> This document describes a replacement for the SASL profile documented
> in RFC 6120 which allows for greater extensibility.
>
> URL:
I'm also fine with each roster request resetting the state. :) I
created/updated the PR [1].
Linus
[1]: https://github.com/xsf/xeps/pull/1187
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe:
Hello,
in MIX-PAM [1] a client needs to add an to enable additional the
MIX roster extension
in the roster result and later roster pushes. The XEP doesn't say anything
about what happens when
the user makes a second request without the element.
The intended behaviour is probably that the
Hello,
I just wanted to note that there's also XEP-0447: Stateless file sharing [1]
which has some
improvements over SIMS (like multiple files in one message and a little simpler
API (no need to
use character counting / the References XEP) and later attaching of additional
sources).
Not sure
On Tue, 1 Sep 2020 17:05:23 +0200
Paul Schaub wrote:
> Hi Linus,
>
> thank you for your feedback!
>
> Am 01.09.20 um 16:25 schrieb Linus Jahn:
> > 1. The XEP suggests that each encryption method uses a tag with
> > xmlns=''. However, since the element is not
On Tue, 1 Sep 2020 17:03:59 +0200
Philipp Hörist wrote:
> Am Di., 1. Sept. 2020 um 16:26 Uhr schrieb Linus Jahn :
>
> > Hello folks,
> >
> > I'm planning to implement Stanza Content Encryption [1] in QXmpp [2] and I
> > had
> > a more detailed look at
Hello folks,
I'm planning to implement Stanza Content Encryption [1] in QXmpp [2] and I had
a more detailed look at the XEP. Here are my open questions / suggestions:
1. The XEP suggests that each encryption method uses a tag with
xmlns=''. However, since the element is not defined
by SCE,
Hello,
I opened a pull request more than 1.5 years ago and received a +1 from stpeter,
but no further interaction. The pull request was not merged.
The pull request can be found here:
https://github.com/xsf/registrar/pull/30
Can I do something to speed up this? Is writing a mail here the
On Thu, 21 Nov 2019 11:51:11 +0100 Holger Weiß
wrote:
> * Daniel Gultsch [2019-11-20 21:49]:
> > Am Mi., 20. Nov. 2019 um 20:45 Uhr schrieb Linus Jahn
> > :
> > > Also the 'blocking command' way isn't so flexible. Ideally I
> > > would like to send one req
On Tue, 19 Nov 2019 09:51:00 + Daniel Gultsch wrote:
> Am Sa., 16. Nov. 2019 um 17:48 Uhr schrieb Linus Jahn :
>
> > I'm currently working on XEP-0405 / MIX-PAM. I'm replacing the roster
> > mechanism by a private PEP node. The basics are working now, but I'm
> >
Am Sat, 16 Nov 2019 18:45:12 +0100
schrieb Linus Jahn :
> Hello,
>
> I'm currently working on XEP-0405 / MIX-PAM. I'm replacing the roster
> mechanism by a private PEP node. The basics are working now, but I'm
> not sure what's the best way to make presence sharing w
Hello,
I'm currently working on XEP-0405 / MIX-PAM. I'm replacing the roster
mechanism by a private PEP node. The basics are working now, but I'm
not sure what's the best way to make presence sharing with the channel
configurable.
The roster mechanism allowed the client to disable presence
On Mon, 17 Jun 2019 16:20:53 +
Daniel Gultsch wrote:
> Hi,
>
> at the last summit we sort of came to the conclusion that we want to
> get rid of MIX roster entries and instead place 'joined channels' into
> a private PEP node or some other (non roster) place.
>
> The arguments in favor of
On Wed, 08 Aug 2018 10:39:52 -0500
Sam Whited wrote:
> On Mon, Aug 6, 2018, at 10:25, Tedd Sterr wrote:
> > 3b) Proposed XMPP Extension: File Sharing Notifications -
> > https://xmpp.org/extensions/inbox/fsn.html
> > …
> > Sam: [on-list] (agree with Kev, but not sure if it should go to
> >
On Wed, 18 Jul 2018 20:40:45 +0500
Ненахов Андрей wrote:
> I'd rather call it 'extended chat state notifications' or something
> like that. Recording audio is only distantly related to file sharing.
I can see your point, but I don't think that the name 'Extended Chat
State Notifications'
On Tue, 17 Jul 2018 15:36:06 +0200, Jonas Wielicki wrote:
> Yes. Not tying this to seems like a good idea for
> flexibility. My suggestion would be to put your new elements next to
> the existing XEP-0085 elements, not as children of them. E.g.:
>
>
>
>type='image'
>
Hello Matthew and Ненахов,
thank you for your answers.
On Mon, 16 Jul 2018 13:59:23, Matthew Wild wrote:
> Authoring a new XEP for this case would not be hard. Take a look at
> https://xmpp.org/about/standards-process.html for details about
> getting started.
Thanks, I'll do that.
On Mon, 16
,
Linus
--
Linus Jahn
High school student and open-source enthusiast
E-Mail:
Jabber/XMPP:
GnuPG fingerprint: 03C2 D10D C97E 5B0B EBB8 F3B4 4663 231A 91A1 E27B
Projects I contribute to:
- Kaidan - A user-friendly XMPP client for every device!
https://git.kaidan.im/kaidan/kaidan
- Halium
18 matches
Mail list logo
