Re: [Standards] Council Agenda 2018-02-14

[Evgeny Khramtsov]

Thu, 15 Feb 2018 08:18:24 +0100
Daniel Gultsch  wrote:

> I want to put the current MAM preferences into the a disco features
> form on the account.

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

Re: [Standards] Council Agenda 2018-02-14

[Daniel Gultsch]

2018-02-15 7:49 GMT+01:00 Evgeny Khramtsov :
> Wed, 14 Feb 2018 10:01:31 -0600
> Sam Whited  wrote:
>
>> I'm sure we'll discuss this is the council meeting, but to my
>> knowledge this is the only part of the spec that anything implements
>> now (please correct me if there is significant adoption of the other
>> parts of the spec).
>
> Well, as Daniel noted, blindly purging all offline nodes is risky in a
> general case because you don't know if MAM is enabled in user's
> preferences.

I want to put the current MAM preferences into the a disco features
form on the account.
If Kev and MattJ are ok with that I would quickly annotate the XEP.

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

Re: [Standards] Council Agenda 2018-02-14

[Evgeny Khramtsov]

Wed, 14 Feb 2018 10:01:31 -0600
Sam Whited  wrote:

> I'm sure we'll discuss this is the council meeting, but to my
> knowledge this is the only part of the spec that anything implements
> now (please correct me if there is significant adoption of the other
> parts of the spec).

Well, as Daniel noted, blindly purging all offline nodes is risky in a
general case because you don't know if MAM is enabled in user's
preferences. As a work-around you can first request the number of
messages (before sending an initial presence), this, according to the
spec, will automatically disable offline messages flood. In a later
stage you can check if MAM is enabled and if it is, you purge, if it's
not, you retrieve offline messages via any mechanism described in
XEP-0013. Thus, other parts of specs can also be utilized. I know, this
is ugly, but at least doable. For sure, new mechanism is needed in this
situation (such as MAM interface to offline storage, dunno).
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Agenda 2018-02-14

[Sam Whited]

On Wed, Feb 14, 2018, at 06:44, Holger Weiß wrote:
> A MAM client might want to purge offline messages to avoid duplicates.

I'm sure we'll discuss this is the council meeting, but to my knowledge this is 
the only part of the spec that anything implements now (please correct me if 
there is significant adoption of the other parts of the spec).

This means we have a whole spec that looks like it's the recommended way to do 
history even though no one actually uses it just so that clients can use one 
small part of it to clear MUC history. Deprecating does not mean that clients 
will stop doing that, and may encourage us to find a better way to do this (if 
one is necessary).

FWIW, this also might be a good footnote in the compliance suites for next year 
if someone takes those up. It's worth mentioning that MAM doesn't provide a way 
to do this.

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

Re: [Standards] Council Agenda 2018-02-14

[Holger Weiß]

* Dave Cridland  [2018-02-14 08:54]:
> Perhaps I'm overly aware that I haven't much of an idea about XEP-0013's
> usage.

A MAM client might want to purge offline messages to avoid duplicates.

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

Re: [Standards] Council Agenda 2018-02-14

[Dave Cridland]

On 13 February 2018 at 18:55, Sam Whited  wrote:
> On Tue, Feb 13, 2018, at 11:28, Dave Cridland wrote:
>> Currently, anyone can ask the Council to vote, and the Council can
>> simply do so. That's not really very helpful, and in practise we do
>> try to solicit opinion from across the community.
>>
>> As such, I'm thinking of writing something for XEP-0001 that imposes a
>> last-call-like period for comments - Intent To Deprecate/Obsolete
>> perhaps - and imposing that on ourselves.
>
> Please don't. We already have too much process making it impossible for us to 
> get anything done in a reasonable time frame. I don't see what problem this 
> is solving so I don't see the need for more process to solve something that 
> hasn't (to my knowledge) caused any problems.

I do appreciate what you're saying, but:

* The majority of the delay is actually imposed by Council not voting
in time. That is avoidable delay.
* Council voting to deprecate seems like something we should ensure is
done with feedback from the community. The practical way we do this
for other cases is a note to the list with a bit of warning. I don't
think this is process for the sake of process.
* Council this session have completed votes on 20 items (with three
expiries, incidentally), and have a further 5 in progress. I don't see
evidence that we're not getting anything done.
* I don't know what process we have that is "too much". Please do
suggest bits we can get rid of.

This all said, we have three deprecations to vote on today - XEP-0071
I feel I know what the community feeling is, XEP-0137 is mopping-up
the remains of SI, and I'm not concerned about this. Perhaps I'm
overly aware that I haven't much of an idea about XEP-0013's usage.

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

Re: [Standards] Council Agenda 2018-02-14

[Kevin Smith]

On 13 Feb 2018, at 17:28, Dave Cridland  wrote:
> 
> On 13 February 2018 at 17:20, Evgeny Khramtsov  wrote:
>> Tue, 13 Feb 2018 17:04:36 +
>> Dave Cridland  wrote:
>> 
>>> 4) Deprecate XEP-0013 Flexible Offline Message Retrieval
>>> 
>>> https://xmpp.org/extensions/xep-0013.html
>> 
>> Just my 3 cents: this XEP is, from what I know, the only way to disable
>> offline messages on a client, so we need a similar mechanism if the XEP
>> is going to be deprecated.
> 
> Yes, good point.
> 
> On a more general note, the process around deprecation is pretty weak
> - it might be useful to formally gather feedback about deprecating a
> spec in the same way we gather it for advancement.
> 
> Currently, anyone can ask the Council to vote, and the Council can
> simply do so. That's not really very helpful, and in practise we do
> try to solicit opinion from across the community.
> 
> As such, I'm thinking of writing something for XEP-0001 that imposes a
> last-call-like period for comments - Intent To Deprecate/Obsolete
> perhaps - and imposing that on ourselves.

It’s not immediately clear to me that this is truly needed. The process as-is 
seems sufficiently tight (‘Council votes’) that it’s not causing issues right 
now, and I’m not sure that adding a mandatory almost-LC would address possible 
future problems (although I think Council getting a feeling of the land before 
voting is sensible).

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

Re: [Standards] Council Agenda 2018-02-14

[Peter Saint-Andre]

On 2/13/18 11:55 AM, Sam Whited wrote:
> On Tue, Feb 13, 2018, at 11:28, Dave Cridland wrote:
>> Currently, anyone can ask the Council to vote, and the Council can
>> simply do so. That's not really very helpful, and in practise we do
>> try to solicit opinion from across the community.
>>
>> As such, I'm thinking of writing something for XEP-0001 that imposes a
>> last-call-like period for comments - Intent To Deprecate/Obsolete
>> perhaps - and imposing that on ourselves.
> 
> Please don't. We already have too much process making it impossible for us to 
> get anything done in a reasonable time frame. I don't see what problem this 
> is solving so I don't see the need for more process to solve something that 
> hasn't (to my knowledge) caused any problems.

But Dave enjoys imposing process on himself!

Peter




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 Agenda 2018-02-14

[Sam Whited]

On Tue, Feb 13, 2018, at 11:28, Dave Cridland wrote:
> Currently, anyone can ask the Council to vote, and the Council can
> simply do so. That's not really very helpful, and in practise we do
> try to solicit opinion from across the community.
> 
> As such, I'm thinking of writing something for XEP-0001 that imposes a
> last-call-like period for comments - Intent To Deprecate/Obsolete
> perhaps - and imposing that on ourselves.

Please don't. We already have too much process making it impossible for us to 
get anything done in a reasonable time frame. I don't see what problem this is 
solving so I don't see the need for more process to solve something that hasn't 
(to my knowledge) caused any problems.

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

Re: [Standards] Council Agenda 2018-02-14

[Goffi]

Le mardi 13 février 2018, 18:28:02 CET Dave Cridland a écrit :

> As such, I'm thinking of writing something for XEP-0001 that imposes a
> last-call-like period for comments - Intent To Deprecate/Obsolete
> perhaps - and imposing that on ourselves.

That's a really good idea! 
 
> Dave.


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

Re: [Standards] Council Agenda 2018-02-14

[Dave Cridland]

On 13 February 2018 at 17:20, Evgeny Khramtsov  wrote:
> Tue, 13 Feb 2018 17:04:36 +
> Dave Cridland  wrote:
>
>> 4) Deprecate XEP-0013 Flexible Offline Message Retrieval
>>
>> https://xmpp.org/extensions/xep-0013.html
>
> Just my 3 cents: this XEP is, from what I know, the only way to disable
> offline messages on a client, so we need a similar mechanism if the XEP
> is going to be deprecated.

Yes, good point.

On a more general note, the process around deprecation is pretty weak
- it might be useful to formally gather feedback about deprecating a
spec in the same way we gather it for advancement.

Currently, anyone can ask the Council to vote, and the Council can
simply do so. That's not really very helpful, and in practise we do
try to solicit opinion from across the community.

As such, I'm thinking of writing something for XEP-0001 that imposes a
last-call-like period for comments - Intent To Deprecate/Obsolete
perhaps - and imposing that on ourselves.

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

Re: [Standards] Council Agenda 2018-02-14

[Evgeny Khramtsov]

Tue, 13 Feb 2018 17:04:36 +
Dave Cridland  wrote:

> 4) Deprecate XEP-0013 Flexible Offline Message Retrieval
> 
> https://xmpp.org/extensions/xep-0013.html

Just my 3 cents: this XEP is, from what I know, the only way to disable
offline messages on a client, so we need a similar mechanism if the XEP
is going to be deprecated.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___