On 23 March 2017 at 01:40, Florian Schmaus wrote:
> On 22.03.2017 12:53, Steve Kille wrote:
>> I think that keeping Create and Join separate is the right thing.
>
> They can and should be separate, but I think there needs to be a third
> operation "join-and-maybe-create". Otherwise the protocol is
On 29 January 2017 at 04:26, XMPP Extensions Editor wrote:
> This message constitutes notice of a Last Call for comments on XEP-0368 (SRV
> records for XMPP over TLS).
>
> Abstract: This specification defines a procedure to look up
> xmpps-client/xmpps-server SRV records (for TLS connections) in
On 29 January 2017 at 04:25, XMPP Extensions Editor wrote:
> This message constitutes notice of a Last Call for comments on XEP-0333 (Chat
> Markers).
>
> Abstract: This specification describes a solution of marking the last
> received, displayed and acknowledged message in a chat.
>
> URL: http
On 25 January 2017 at 00:15, Georg Lukas wrote:
> Are there any real-world use cases (or implementations) that use bare
> JID or occupant JID in mediated invitations? If no, I would like to
> mandate in XEP-0045 that the full JID has to be used, thus allowing the
> invitee to verify the sender (se
On 30 October 2016 at 08:37, XMPP Extensions Editor wrote:
> This message constitutes notice of a Last Call for comments on XEP-0300 (Use
> of Cryptographic Hash Functions in XMPP).
>
> Abstract: This document provides recommendations for the use of cryptographic
> hash functions in XMPP protoco
On 7 September 2016 at 01:15, Steve Kille wrote:
> Daurnimator,
>
> Thanks for your comments.
>
>> -Original Message-
>> From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of
>> Daurnimator
>> Sent: 06 September 2016 09:00
>> To:
On 6 September 2016 at 00:59, XMPP Extensions Editor wrote:
> Version 0.3 of XEP-0369 (Mediated Information eXchange (MIX)) has been
> released.
>
> Abstract: This document defines Mediated Information eXchange (MIX), an XMPP
> protocol extension for the exchange of information among multiple us
On 24 June 2016 at 16:55, Kevin Smith wrote:
>
>> On 23 Jun 2016, at 23:35, Georg Lukas wrote:
>>
>> Hi,
>>
>> TL;DR: whenever a client (re)sends a join, the MUC service should return
>> everything a newly joining client needs to know.
>>
>> According to XEP-0045, an initial join presence needs t
On 24 June 2016 at 08:35, Georg Lukas wrote:
> Hi,
>
> TL;DR: whenever a client (re)sends a join, the MUC service should return
> everything a newly joining client needs to know.
>
> According to XEP-0045, an initial join presence needs to contain an 'x'
> element with 'http://jabber.org/protocol/
On 24 June 2016 at 02:17, Brian Cully wrote:
> OTOH, since it’s a mediated invitation, the MUC service already has
> state about pending invitations and room occupants.
It is not required for a room to store any information about pending
invitations.
_
On 22 October 2014 09:57, Tobias Markmann wrote:
> I think using a more secure hash function would be beneficial for reducing
> code. Secure wireless constrained applications are likely to already
> include a high security cryptographic hash function. Using this hash
> function would avoid the ne
On 20 June 2014 10:29, Peter Saint-Andre wrote:
> Nothing to panic about there. A few implementations exist, and I think the
> authors will be updating the spec soon.
>
>
> We are using MUC to handle posting comments and we need to do infinite
>> scrolling backward in the room archive. Nothing i
Hi List,
I'm a new subscriber, so I don't have the thread to reply to.
I recently re-wrote much of the MUC library used in prosody.
While doing so, I made a list of ambiguities and issues with the MUC
specification (XEP-0045)
Regards,
Daurnimator.
7.8.2 "The itself MUST t
13 matches
Mail list logo
