On 3/20/17 4:23 PM, Dave Cridland wrote:
> On 20 March 2017 at 22:04, Florian Schmaus wrote:
>> On 20.03.2017 22:32, Dave Cridland wrote:
>>> Loosely, this is OK, but, in order:
>>>
>>> 1) Section 6 must go. I don't believe that the XSF has the required
>>> expertise to
On Mon, Mar 20, 2017 at 12:50 PM, XMPP Extensions Editor
wrote:
> URL: https://xmpp.org/extensions/inbox/isr-sasl2.html
> Example 2. An xmlns:isr='urn:xmpp:isr:0' \ isr:mechanism='X-HT-SHA-256-ENDP'/>
I don't think that namespaced attributes are necessary; they add
Ah, but Kev noted to me that this is using namespaced attributes.
We have, traditionally, avoided these, on the basis that nobody (well,
almost nobody) understands them.
I don't think these are actually required here; a child element will
work just as well. Can we do that instead?
On 20 March
On 20 March 2017 at 22:04, Florian Schmaus wrote:
> On 20.03.2017 22:32, Dave Cridland wrote:
>> Loosely, this is OK, but, in order:
>>
>> 1) Section 6 must go. I don't believe that the XSF has the required
>> expertise to adequately review a SASL mechanism. I'm saying this
>>
On 20.03.2017 22:32, Dave Cridland wrote:
> Loosely, this is OK, but, in order:
>
> 1) Section 6 must go. I don't believe that the XSF has the required
> expertise to adequately review a SASL mechanism. I'm saying this
> without commenting on the mechanism described in Section 6. This needs
> to
On 3/20/17 3:32 PM, Dave Cridland wrote:
> Loosely, this is OK, but, in order:
>
> 1) Section 6 must go. I don't believe that the XSF has the required
> expertise to adequately review a SASL mechanism. I'm saying this
> without commenting on the mechanism described in Section 6. This needs
> to
On 20.03.2017 18:50, XMPP Extensions Editor wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Instant Stream Resumption
>
> Abstract: This specification introduces a mechanism for instant
> stream resumption, based on Stream Management (XEP-0198), allowing
>
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Instant Stream Resumption
Abstract: This specification introduces a mechanism for instant
stream resumption, based on Stream Management (XEP-0198), allowing
XMPP entities to instantaneously resume an XMPP stream.
URL:
Hi,
To only generate "sent" carbons when a message is sent to ourself, seems
like a easy solution that would make the self messaging use case a bit less
complex. I see no downsides to this.
To drop that one message that has to be issued according to 6121, seems ok.
Philipp
On 20/03/2017 16:22, Georg Lukas wrote:
> Hi,
>
> sometimes IM users want to talk to themselves, e.g. to send a URL from
> one device to another, or to take notes. In systems like Slack this is
> recognized and the self-message area is provided as a draft board.
>
> In modern XMPP
Hi,
sometimes IM users want to talk to themselves, e.g. to send a URL from
one device to another, or to take notes. In systems like Slack this is
recognized and the self-message area is provided as a draft board.
In modern XMPP (6121+Carbons/MAM), messages-to-self are always delivered
twice(*),
On Mon, Mar 20, 2017 at 3:02 AM, Marvin Gülker wrote:
> I looked into this problem a little more, and it appears that the
> Makefile only runs xelatex once.
Sorry about that; this was an oversight on my part. I've fixed it and
will merge the changes when CI passes
I found myself a few days ago writing a getOrCreateLeafNode() method for
Smack's PubSubManager [1] and noticed that Smack has a similar method
for MUC (createOrJoin(), [2]). Both methods are often required, e.g. you
need the PubSub one for OMEMO (or everything PEP). But both methods are
inherent
On Sat, Feb 25, 2017 at 09:42:10AM +0100, Marvin Gülker wrote:
> However, it appears there's a number of XEPs on xmpp.org/extensions
> whose PDF files have no Table of Contents, albeit the HTML versions
> have.
I looked into this problem a little more, and it appears that the
Makefile only runs
14 matches
Mail list logo