[Standards] 2017-04-19 XSF Council Minutes

[JC Brand]

2017-04-19 XSF Council Minutes
==

Present: Tobias, Link Mauve, SamWhited, daniel
Minute taker: jcbrand

1). Link Mauve's SHA-1 migration plan

Nothing new to report from Link Mauve. Tobias offered to help and Link Mauve
accepted, saying that he'll share his work/research done so far.

2). Date of next meeting is Wednesday same time (15:00 UCT).

3). Any other business?

Tobias mentions Ge0rg's MUC changes and the deprecation voted on some time ago
but which hasn't yet been applied and asks whether they are on the radar of
SamWhited, the editor.

SamWhited responds that there's no editor infrastructure currently and
therefore no way for him to publish anything.

Tobias mentions that the board should probably be informed about this.

Kev asks to be told what SamWhited can't do as editor.

SamWhited says that there is a custom mercurial repo required for the scripts to
work, since they don't work with the git repo and that he assumed tooling was
pending some docker work that needs to be done first.

Kev says that he'll install any packages that SamWhited needs.

Tobias will try to set up the mercurial magic repo today or tomorrow.

SamWhited thinks there are some packages missing still as well, he'll check and
advise.

Another AOB from Tobias is outstanding votes on ISR-SASL2 and Message
Processing hints. Tobias thinks ISR-SASL2 votes expire today.

Tobias mentions that there is an ongoing discussion on the mailing list.
Current options on the table are to either continue as the current XEP or let
it be split up into the respecive XEPs that use the hint.

No other business.

**Tobias  bangs the gavel


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

Re: [Standards] [Council] Council Meeting Minutes April 5th 2017

[Sam Whited]

On Wed, Apr 12, 2017 at 10:14 AM, Dave Cridland  wrote:
> I'd be interested in Sam's counter-arguments, mind.

- Discoverability: if  or  or whatever is only
used from carbons, why do I have to click through to a different long
XEP to find the one hint that I care about while I'm implementing
carbons?
- Editing: In future, how do we define new hints if this becomes
final? Add them to a final document? A registry? If a registry is
created, can it have normative language if new hints need it? A hints2
document?

In general, these are just simple enough, small enough, and necessary
enough that I think they should be defined in carbons or MAM or
wherever. I vaguely agree that it could be nice to re-use
 between XEPs, but I don't think it's an actual problem
except between MAM and Message Archiving (and as far as I'm concerned
we need to deprecate Message Arhciving and stop confusing people when
the community recommendation is MAM, so that's a no-issue for me).

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

Re: [Standards] [Council] Council Meeting Minutes April 5th 2017

[Sam Whited]

On Wed, Apr 19, 2017 at 9:29 AM, Tobias M  wrote:
> Having an own XEP for each hint feels a bit over the top.

I agree, let's not do this.

> Moving each hint to the XEP that uses it would lead to duplication of hints 
> or one XEP using
> a hint defined in an otherwise unrelated XEP.

Is there a real case where this is a problem? I agree that duplication
might not be nice, but if it's eg. duplication between MAM and Message
Archiving, then I think it's fine because we already have a huge
amount of duplication that I'm hopeful we can one day fix by
deprecating one of them. If it's duplication between two different
things that should coexist, then maybe that's an actual problem that
needs solving, but I don't think it's actually a problem right now.

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

Re: [Standards] Council Meeting Minutes April 5th 2017

[Tobias M]

> On 12. Apr 2017, at 13:43, Daniel Gultsch  wrote:
> 
> 4) Vote on advancing XEP-0334: Message Processing Hints
> Everyone to vote on list.
> Sam considers voting -1 because it includes functionality that should 
> probably exist as part of other XEPs.
> Daniel agrees that every XEP should define its own hints.
> Requires more mailing list discussion.

+1, ideally XEP-0334 would refer to the known XEPs that currently make use of 
the hint, as should the other XEPs the other way around. This isn’t an ideal 
solution but would be fine with me as it helps visibility on what hints exist 
and in what way they are used.

Having an own XEP for each hint feels a bit over the top. Moving each hint to 
the XEP that uses it would lead to duplication of hints or one XEP using a hint 
defined in an otherwise unrelated XEP.

Ultimately I do not care that much, only that we get to a solution and do not 
discuss this for much longer.

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

Re: [Standards] [Council] Council Meeting Minutes April 5th 2017

[Florian Schmaus]

On 19.04.2017 15:25, Tobias Markmann wrote:
> 
> On Wed, Apr 12, 2017 at 5:14 PM, Dave Cridland  > wrote:
> 
> So, Carbons is the only consumer of  - at least for now. But
>  is used by, at least, XEP-0313 and XEP-0136, as well as
> (in principle) MUC web logs, offline storage, and so on.
> 
> Moreover, hints work well for collecting a set of suggested handling
> behaviours under one namespace, such that servers can identify an
> unknown hint and potentially log its existence.
> 
> 
> How is the standardisation of Message Processing Hints to go on? There
> will likely be more hints in future. So will this XEP never get Final?

I'm not sure if there will be (much) more hints in the future. Even if
there will be more hints after XEP-0334 got final, I do not see any harm
in adding them to the XEP, mostly because they are just hints and are
usually used together with a "hint-consuming" XEP.

> I kind of like small XEPs that deal with one thing and do it well.

Me too, that's why I like the hints XEP and don't like the idea that
other XEPs should be required to re-invent it.

- Florian



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

Re: [Standards] [Council] Council Meeting Minutes April 5th 2017

[Tobias Markmann]

On Wed, Apr 12, 2017 at 5:14 PM, Dave Cridland  wrote:

> So, Carbons is the only consumer of  - at least for now. But
>  is used by, at least, XEP-0313 and XEP-0136, as well as
> (in principle) MUC web logs, offline storage, and so on.
>
> Moreover, hints work well for collecting a set of suggested handling
> behaviours under one namespace, such that servers can identify an
> unknown hint and potentially log its existence.
>

How is the standardisation of Message Processing Hints to go on? There will
likely be more hints in future. So will this XEP never get Final? Or should
each hint be its own XEP if its used by more than one XEP?

I kind of like small XEPs that deal with one thing and do it well.

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