On Donnerstag, 16. November 2017 22:11:50 CET Philipp Hörist wrote:
> 2017-11-16 21:40 GMT+01:00 Jonas Wielicki :
> > Doesn’t it make more sense to require that senders who mark messages as
> > markable MUST use at least N bits of entropy (where N is the number of
> > bits of
> > entropy in UUID4,
On 16 November 2017 at 19:39, Daniel Gultsch wrote:
> 2017-11-16 20:34 GMT+01:00 Dave Cridland :
>> On 16 November 2017 at 19:22, Daniel Gultsch wrote:
>>> * Add a sender attribute to and that MUST
>>> contain the full JID of the person who requested the marker in group
>>> chats.
>
> Assuming
2017-11-16 21:40 GMT+01:00 Jonas Wielicki :
>
> Doesn’t it make more sense to require that senders who mark messages as
> markable MUST use at least N bits of entropy (where N is the number of
> bits of
> entropy in UUID4, since people seem to like that) in the message IDs,
> stanza
> IDs and orig
On Donnerstag, 16. November 2017 20:22:58 CET Daniel Gultsch wrote:
> * Add a sender attribute to and that MUST
> contain the full JID of the person who requested the marker in group
> chats.
Doesn’t it make more sense to require that senders who mark messages as
markable MUST use at least N bi
* Note that if the markable message has an origin-id this id should be
used over the stanza id.
should -> MUST
everything else seems good to me.
philipp
2017-11-16 20:39 GMT+01:00 Daniel Gultsch :
> 2017-11-16 20:34 GMT+01:00 Dave Cridland :
> > On 16 November 2017 at 19:22, Daniel Gultsch wr
2017-11-16 20:34 GMT+01:00 Dave Cridland :
> On 16 November 2017 at 19:22, Daniel Gultsch wrote:
>> * Add a sender attribute to and that MUST
>> contain the full JID of the person who requested the marker in group
>> chats.
Assuming that stanza ids are unique per person (client) but not
necessa
On 16 November 2017 at 19:22, Daniel Gultsch wrote:
> * Add a sender attribute to and that MUST
> contain the full JID of the person who requested the marker in group
> chats.
This doesn't make sense to me, which is probably my fault - could you
expand on this?
Dave.
__
Hi,
I'm planning to make some changes to XEP-0333 tomorrow but before I do
I want to very quickly run this by you to see if anyone has very
strong objections towards any of the following changes.
* Get rid of
* Get rid of discovery
* Add a sender attribute to and that MUST
contain the full JID
Thu, 16 Nov 2017 11:50:55 +0300
Kozlov Konstantin wrote:
> It's a nice idea to recommend experimental XEP's.
I agree with your irony, but this is the case where formal rules don't
work as planned.
___
Standards mailing list
Info: https://mail.jabber.or
It's a nice idea to recommend experimental XEP's.16.11.2017, 11:45, "Evgeny Khramtsov" :Thu, 16 Nov 2017 11:42:58 +0300Kozlov Konstantin wrote: Bad thing is that developers of new clents don't know which XEP to implement. XEP-0136 (which is deprecated) or XEP-0313 (which is still
Thu, 16 Nov 2017 11:42:58 +0300
Kozlov Konstantin wrote:
> Bad thing is that developers of new clents don't know which XEP to
> implement. XEP-0136 (which is deprecated) or XEP-0313 (which is still
> experimental and may be deferred, retracted and so on).
MAM is recommended by the compliance sui
Bad thing is that developers of new clents don't know which XEP to implement.XEP-0136 (which is deprecated) or XEP-0313 (which is still experimental and may be deferred, retracted and so on).16.11.2017, 11:12, "Dave Cridland" :On 16 Nov 2017 7:43 am, "Kozlov Konstantin" wrote:Too
On 16 Nov 2017 7:43 am, "Kozlov Konstantin" wrote:
Too bad...
XEP-0313 is still experimental and XEP-0136 is deprecated already.
No, it's a good thing. While MAM isn't quite Draft yet, the council was
confident it will be very soon, and is clearly what we want new
implementations to be doing.
13 matches
Mail list logo