[Standards] Message Reactions vs XEP-0367 vs. XEP-0372

[Georg Lukas]

Hi Marvin,

* Marvin W  [2019-07-24 22:02]:
> > Referencing messages

I agree with all that you wrote about XEP-0372, and I suppose the only
reason it gets referenced so often in these discussion is because it's
inadequately titled "Message References".

> On the contrary, XEP-0367 does not suffer from any of these issues.

That's a great catch. I actually think that 0367 is a perfect match for
Reactions, even though I consider it to be too specific for the problem
of generic message association - it is not well-suited for:

 - Delivery Receipts
 - Last Message Correction (do you attach a correction to the original?)

I don't see the Business Rules of 0367 as a problem here - I'm pretty
sure they don't interfere with Reactions, and we could change them if
they do anyway.

> Another alternative that I'd like to propose is to not mix server
> processing information ([...]) with client and message information.

I think this is opening a can of worms, because as a sender, you end up
adding multiple elements with the same semantic meaning (this message
belongs to X). A malicious client could start gaming implementations by
adding different references to the different elements.

> I am happy to work any of these three possibilities into a XEP
> (modification) proposal, if there was consensus which is best.

I think that the issues inside of 0367 are outside of your scope and
should be solved by its authors/the Council, and that it would make very
much sense to use the 0367 attach-to element in Reactions.

> > Backward compatibility
> 
> That said, I support Florians suggestion to gather some implementation
> experience first and decide on a more specific business rule afterwards.

Yes, let's go on with that. Nothing I have read so far got me convinced,
but this is not a blocker for moving to Experimental.

> > Correcting reactions
> 
> There are two main reasons for me to not use XEP-0308. First (according
> to its specification) it only can be used for the last outgoing message.

You can well supersede that rule in your XEP by saying that LMC can be
applied for Reactions without any time / history constraints.

That said, I accept your arguments, and I'd be fully OK with LMC only
getting used for the backward compatibility part of Reactions.

> > Limitation to Emoji
> 
> I think the current specification is open enough to allow future
> extension of what a reaction is.

My issue is with TR51 being a living standard, which will inevitably
cause implementations to disagree on what is valid and what is not. If
you want a demonstration of the (arguably worst-case) effect of this,
try to join a large public MUC with a nickname of "🤖" (U+1F916 Robot
Face), and then send a message there.

This is why I had a hard time with this specific statement:

| Receiving entities MAY ignore  elements that do not comply
| with this specification.


> By having the reaction as a text and not as an attribute, future
> versions of the XEP could allow for other elements including XEP-0231
> images inside the  element.

But then you'd want to have a backward-compatible emoji text inside of
 anyway, to accommodate the first generation of Reactions
clients ;-)

> I hope that, despite the valid discussion points, we can advance with
> the standardization process of Reactions as fast as possible. At Dino,
> we prefer to not implement any non-standard behavior on the master 😉.

None of my points was blocking the acceptance of Reactions as an
Experimental standard, but you'll have a hard time convincing me on the
backward compatibility issue, if you want to get it into Draft fast.


Kind regards,


Georg


signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Voting Summary 2019-07-28

[Georg Lukas]

* Tedd Sterr  [2019-07-29 03:16]:
> Proposed XMPP Extension: Message Reactions - 
> https://xmpp.org/extensions/inbox/reactions.html
> Dave: [pending]
> Georg: +0 (for now; still undecided)
> Jonas: +1 (details can be ironed out)
> Kev: [pending]
> Link: +1 (issues can be ironed out before Draft)

I hereby change my vote to +1. It is good enough for Experimental.


Georg


signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Detecting an ended file transfer

[hrxi]

Hi,

for XEP-0234: Jingle File Transfer
(https://xmpp.org/extensions/xep-0234.html), how is one supposed to
detect the end of a file transfer?

I currently see two methods:

1) The transport method has a way of closing the stream. This exists for
IBB, via the `` element. It also exists for S5B, via closing the
TCP connection.

2) Counting the bytes until you receive as many bytes as promised by the
file offer. This works if the non-mandatory `` tag is present in
the file offer.

Could the XEP be amended to clarify how to do this? If 2) is the
supposed method, could the XEP be changed so that the `` tag is
mandatory for offering a file?

Conversations currently does 2). It closes the IBB but not the S5B which
is why this question even arose.

I posted a blog post on this matter and was asked to post it to this
mailing list.

Kind regards,
hrxi
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Voting Summary 2019-07-28

[Kozlov Konstantin]

The only thing about it which makes me feel bad is using Emoji.Using User Mood element instead sounds much better for me.29.07.2019, 15:32, "Georg Lukas" :* Tedd Sterr  [2019-07-29 03:16]: Proposed XMPP Extension: Message Reactions - https://xmpp.org/extensions/inbox/reactions.html Dave: [pending] Georg: +0 (for now; still undecided) Jonas: +1 (details can be ironed out) Kev: [pending] Link: +1 (issues can be ironed out before Draft)I hereby change my vote to +1. It is good enough for Experimental.Georg,___Standards mailing listInfo: https://mail.jabber.org/mailman/listinfo/standardsUnsubscribe: standards-unsubscr...@xmpp.org__
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Detecting an ended file transfer

[Lance Stout]

> 1) The transport method has a way of closing the stream. This exists for
> IBB, via the `` element. It also exists for S5B, via closing the
> TCP connection.

Potential race condition since signaling and media are flowing in different 
planes.

You can’t be sure that the ‘done sending’ signal arrives after the peer has 
finished
receiving all of the data. IBB can do it, because signaling and data _are_ 
flowing
in the same plane, since it is in-band.

> 2) Counting the bytes until you receive as many bytes as promised by the
> file offer. This works if the non-mandatory `` tag is present in
> the file offer.

That is the intended method, yes.

The size is listed as a SHOULD specifically to allow the case where the file 
being
sent is actually being generated on demand. In which case, the size wouldn’t
be known until the end. For any other case, the size would be known and would
be included.

> Could the XEP be amended to clarify how to do this? If 2) is the
> supposed method, could the XEP be changed so that the `` tag is
> mandatory for offering a file?

Mandating the size in the offer wouldn’t suffice, as covered above. What would 
be
an appropriate change would be to have the checksum update include the final
size information (especially if it wasn’t included in the offer). The schema 
already
allows it, the XEP just needs to mention it. I honestly thought it already did, 
but this
particular situation did get overlooked.

I would consider such an update safe enough to keep in the current namespace.


/Lance

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___