Re: [Standards] Council Voting Summary 2019-08-06

[Dave Cridland]

On Wed, 11 Sep 2019 at 16:35, Marvin W  wrote:

> By specifically
> disallowing referencing of messages that reference other messages it
> obviously is not a general referencing.


I actually quite like this restriction - it means I can split IM traffic
into "Messages" and "Attachments". It also means it's unsuited to, say,
Slack-style threading (but then we have  if people actually want
to go that route).

But a smaller, more contained data model means that, in turn, I have the
ability to have an archive of messages, and for each message have the
reactions and other ancillary data that's needed.

That said, I'm not entirely convinced that message receipts, edits (and
retractions) need to either not apply to, or should be, fastenings, so
perhaps that simplifies the problem space sufficiently.

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

Re: [Standards] Council Voting Summary 2019-08-06

[Marvin W]

On 11.09.19 17:22, Jonas Schäfer wrote:
> I recall you stating in the past that Message Attaching would not be fit to 
> general referencing use-cases (such as Emoji Reactions), which is what 
> Fastening aims at.
I don't read Fastening at aiming a general references use-case, but more
a specific subset of it (small information/markup that is attached to a
single message but doesn't make sense on its own). By specifically
disallowing referencing of messages that reference other messages it
obviously is not a general referencing. It does fit to some degree for
the use cases of Reactions, Delivery Receipts and maybe message edits
(although this is debatable given it apparently needs the special
meaning of removing some unrelated previous Fastenings then).

As I understand Message Attaching, it creates a full-featured message
(that still can receive Delivery Receipts, Reactions or edits) that is
just visually attached to another one.

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

Re: [Standards] Council Voting Summary 2019-08-06

[Jonas Schäfer]

On Freitag, 6. September 2019 16:47:23 CEST Sam Whited wrote:
> On Fri, Sep 6, 2019, at 10:08, Kevin Smith wrote:
> > I’ve instead submitted a fastening protoXEP that Reactions can use to
> > allay my concerns. If that is published, I’m amenable to accepting
> > reactions as-is and immediately updating it to use fastening
> > (providing we agreed that me doing so was appropriate), or for the
> > authors to update pre-publish.
> 
> At a quick glance this seems broadly similar to XEP-0367: Message
> Attaching, would it be better to just add you as an author and you can
> add external payloads to that instead of having yet another XEP that
> does the same thing and muddies the waters when people are trying to
> figure out what they should use to actually implement a feature?

I recall you stating in the past that Message Attaching would not be fit to 
general referencing use-cases (such as Emoji Reactions), which is what 
Fastening aims at.

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Voting Summary 2019-08-06

[Sam Whited]

On Fri, Sep 6, 2019, at 10:08, Kevin Smith wrote:
> I’ve instead submitted a fastening protoXEP that Reactions can use to
> allay my concerns. If that is published, I’m amenable to accepting
> reactions as-is and immediately updating it to use fastening
> (providing we agreed that me doing so was appropriate), or for the
> authors to update pre-publish.

At a quick glance this seems broadly similar to XEP-0367: Message
Attaching, would it be better to just add you as an author and you can
add external payloads to that instead of having yet another XEP that
does the same thing and muddies the waters when people are trying to
figure out what they should use to actually implement a feature?

—Sam

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

Re: [Standards] Council Voting Summary 2019-08-06

[Kevin Smith]

On 29 Aug 2019, at 10:05, Dave Cridland  wrote:
> Can I persuade you to work on this on the road to Draft, rather than leaving 
> a ProtoXEP addressing a problem I think we all want to solve languishing in 
> limbo?

I’ve instead submitted a fastening protoXEP that Reactions can use to allay my 
concerns. If that is published, I’m amenable to accepting reactions as-is and 
immediately updating it to use fastening (providing we agreed that me doing so 
was appropriate), or for the authors to update pre-publish.

/K

> 
> Dave.
> 
> On Thu, 29 Aug 2019 at 09:22, Kevin Smith  > wrote:
> 
> 
> > On 29 Aug 2019, at 09:19, Daniel Gultsch  > > wrote:
> > 
> > Hi,
> > 
> > Am Mi., 7. Aug. 2019 um 16:18 Uhr schrieb Tedd Sterr  > >:
> > 
> >> VETOED (-1:0:+4)
> >> Proposed XMPP Extension: Message Reactions - 
> >> https://xmpp.org/extensions/inbox/reactions.html 
> >> 
> >> Dave: +1 (enthusiastic about the problem space, but expect this will need 
> >> a lot of changes on the way to Draft)
> >> Georg: +1 (it is good enough for Experimental)
> >> Jonas: +1 (details can be ironed out)
> >> Kev: -1 (we need a general way of referencing a previous message for 
> >> assorted things and to use that everywhere, while the reactions syntax is 
> >> not reusable)
> >> Link: +1 (issues can be ironed out before Draft)
> > 
> > 
> > just a quick 'imho' from my point of view here.
> > I get where this veto is coming from. We discussed the need to
> > collapse meta data around a message within the archive and I totally
> > agree that long term we need to solve this.
> > However I find it unfair to put the burden of figuring out a solution
> > to a very complex problem upon a single XEP (or its authors). 
> 
> Which is why I offered to the authors to fix this now so the XEP could be 
> accepted, as I had some spare cycles at the time, but that offer wasn’t taken 
> up. I very much want a reactions XEP published, and was willing to put the 
> time in to make it happen.
> 
> /K
> 
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards 
> 
> Unsubscribe: standards-unsubscr...@xmpp.org 
> 
> ___
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___

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

Re: [Standards] Council Voting Summary 2019-08-06

[Dave Cridland]

Kev,

Can I persuade you to work on this on the road to Draft, rather than
leaving a ProtoXEP addressing a problem I think we all want to solve
languishing in limbo?

Dave.

On Thu, 29 Aug 2019 at 09:22, Kevin Smith  wrote:

>
>
> > On 29 Aug 2019, at 09:19, Daniel Gultsch  wrote:
> >
> > Hi,
> >
> > Am Mi., 7. Aug. 2019 um 16:18 Uhr schrieb Tedd Sterr <
> teddst...@outlook.com>:
> >
> >> VETOED (-1:0:+4)
> >> Proposed XMPP Extension: Message Reactions -
> https://xmpp.org/extensions/inbox/reactions.html
> >> Dave: +1 (enthusiastic about the problem space, but expect this will
> need a lot of changes on the way to Draft)
> >> Georg: +1 (it is good enough for Experimental)
> >> Jonas: +1 (details can be ironed out)
> >> Kev: -1 (we need a general way of referencing a previous message for
> assorted things and to use that everywhere, while the reactions syntax is
> not reusable)
> >> Link: +1 (issues can be ironed out before Draft)
> >
> >
> > just a quick 'imho' from my point of view here.
> > I get where this veto is coming from. We discussed the need to
> > collapse meta data around a message within the archive and I totally
> > agree that long term we need to solve this.
> > However I find it unfair to put the burden of figuring out a solution
> > to a very complex problem upon a single XEP (or its authors).
>
> Which is why I offered to the authors to fix this now so the XEP could be
> accepted, as I had some spare cycles at the time, but that offer wasn’t
> taken up. I very much want a reactions XEP published, and was willing to
> put the time in to make it happen.
>
> /K
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Voting Summary 2019-08-06

[Kevin Smith]

> On 29 Aug 2019, at 09:19, Daniel Gultsch  wrote:
> 
> Hi,
> 
> Am Mi., 7. Aug. 2019 um 16:18 Uhr schrieb Tedd Sterr :
> 
>> VETOED (-1:0:+4)
>> Proposed XMPP Extension: Message Reactions - 
>> https://xmpp.org/extensions/inbox/reactions.html
>> Dave: +1 (enthusiastic about the problem space, but expect this will need a 
>> lot of changes on the way to Draft)
>> Georg: +1 (it is good enough for Experimental)
>> Jonas: +1 (details can be ironed out)
>> Kev: -1 (we need a general way of referencing a previous message for 
>> assorted things and to use that everywhere, while the reactions syntax is 
>> not reusable)
>> Link: +1 (issues can be ironed out before Draft)
> 
> 
> just a quick 'imho' from my point of view here.
> I get where this veto is coming from. We discussed the need to
> collapse meta data around a message within the archive and I totally
> agree that long term we need to solve this.
> However I find it unfair to put the burden of figuring out a solution
> to a very complex problem upon a single XEP (or its authors). 

Which is why I offered to the authors to fix this now so the XEP could be 
accepted, as I had some spare cycles at the time, but that offer wasn’t taken 
up. I very much want a reactions XEP published, and was willing to put the time 
in to make it happen.

/K

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

Re: [Standards] Council Voting Summary 2019-08-06

[Daniel Gultsch]

Hi,

Am Mi., 7. Aug. 2019 um 16:18 Uhr schrieb Tedd Sterr :

> VETOED (-1:0:+4)
> Proposed XMPP Extension: Message Reactions - 
> https://xmpp.org/extensions/inbox/reactions.html
> Dave: +1 (enthusiastic about the problem space, but expect this will need a 
> lot of changes on the way to Draft)
> Georg: +1 (it is good enough for Experimental)
> Jonas: +1 (details can be ironed out)
> Kev: -1 (we need a general way of referencing a previous message for assorted 
> things and to use that everywhere, while the reactions syntax is not reusable)
> Link: +1 (issues can be ironed out before Draft)


just a quick 'imho' from my point of view here.
I get where this veto is coming from. We discussed the need to
collapse meta data around a message within the archive and I totally
agree that long term we need to solve this.
However I find it unfair to put the burden of figuring out a solution
to a very complex problem upon a single XEP (or its authors). Vaguely
pointing to to Message ~References~ Attaching isn’t very helpful
either IMHO as it is not proven to me that this XEP will actually
solve the problem. Furthermore if we ever do collapsing we need to
deal with legacy anyway that is not using the generalized mechanism
(Display markers, delivery receipts, Corrections) adding one more to
that list doesn’t feel like a big deal to me.

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

[Standards] Council Voting Summary 2019-08-06

[Tedd Sterr]

2019-07-10 (expired 2019-07-24)
PASSED (-0:1:+4) PR #797 - XEP-0128: Remove 'unlikely' statement - 
https://github.com/xsf/xeps/pull/797
PASSED (-0:1:+4) PR #796 - XEP-0368: clarify what happens when a `.` target is 
published - https://github.com/xsf/xeps/pull/796


2019-07-17 (expired 2019-07-31)

PASSED (-0:2:+3)
Proposed XMPP Extension: Anonymous unique occupant identifiers for MUCs - 
https://xmpp.org/extensions/inbox/occupant-id.html
Dave: +0 (won't block this, but concerned we're introducing a new identifier 
form for endpoint entities, which feels pretty rough)
Georg: +1 (would rather see occupant IDs in the form of JIDs, maybe even passed 
in a 'jid' attribute in the XEP-0045 item tag)
Jonas: +1
Kev: -0 (concerned there's an assumption that it's desirable to effectively 
de-anonymise semi-anonymous MUCs, and a lack of security considerations)
Link: +1

VETOED (-1:0:+4)
Proposed XMPP Extension: Message Reactions - 
https://xmpp.org/extensions/inbox/reactions.html
Dave: +1 (enthusiastic about the problem space, but expect this will need a lot 
of changes on the way to Draft)
Georg: +1 (it is good enough for Experimental)
Jonas: +1 (details can be ironed out)
Kev: -1 (we need a general way of referencing a previous message for assorted 
things and to use that everywhere, while the reactions syntax is not reusable)
Link: +1 (issues can be ironed out before Draft)


2019-07-31 (expiring 2019-08-14)

VETOED (-5:0:+0)
PR #801 - XEP-0368: clarify fallback behavior on SRV failure - 
https://github.com/xsf/xeps/pull/801
Dave: -1 (don't think I like possibly anything about this)
Georg: -1 (agree with Jonas)
Jonas: -1 (inappropriate port choice; doesn't clarify, but changes behaviour; 
contradicts normal SRV working; logically incoherent regarding trust of DNS)
Kev: -1 (don't like it at all; in comparison, #796 seems logical)
Link: -1 (same reasons as Jonas)

PASSED (-0:0:+5)
PR #803 - Obsolete Compliance Suites 2018 - https://github.com/xsf/xeps/pull/803
Dave: +1
Georg: +1
Jonas: +1
Kev: +1
Link: +1

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