XMPP Council - 2016-07-20

SamWhited: I will check https://github.com/xsf/xeps/pull/202

I have some PRECIS work to do anyway (need to review WG mail to see if we can push the revisions to Working Group Last Call)

Many thanks; I think there might be one or two more PRs from other people that could use your approval.

I'm sure :(

psa: I know you're busy, so if you don't have the time to go through them I may just bring them to the council for a decision in the next week or two if that's okay with you. Whatever makes things easiest for you; if you'd prefer to approve, I can wait too, no rush :)

SamWhited, Is the trello up to date, do you know?

Dave Cridland: I'm not sure

meeting today?

SamWhited, Actually, I'm pretty sure it isn't. But have there been any protoxeps over the past week or other things needing votes?

SamWhited: I will certainly look at the PRECIS issue, and I have some others (pubsub, XEP-0300, etc.) in browser tabs - will try to close them while traveling over the next few days

Tobias, I believe so.

psa: Many thanks!

Dave Cridland: PARS is still missing a vote from Lance, and I think there were some PRs that needed a vote, I'll track them down.

So far the PRs Sam mentioned are the main items for the agenda, I thought there was a new XEP proposal, but that seems to have been handled last week

https://github.com/xsf/xeps/pull/204

Does not appear to be on the Trello

https://github.com/xsf/xeps/pull/202 is, and psa (as the author) is looking at that one now, so I'm not sure if the Council would prefer to wait on him or not. Up to you.

Those are the only things I see worth bringing up this week

SamWhited, Thanks.

I could bring up deprecating privacy lists again if people just want more stuff to argue about :)

it is time

0) Roll call

Here.

The JID mention card can also be closed; Geoffi is aware that it was declined so no notification needs to be sent (although he never received feedback on the why, apparently)

oops, notating.

here

psa MattJ

here

1) Old Business: PARS

I'm +1 on PARS

so all have +1 that now

2) XEP-0060: be more consistent with reply ( https://github.com/xsf/xeps/pull/106 )

Here

updated trello regarding PARS

ta

I'm +1 for the pubsub change

+1

I will review on the plane today.

+1 on this. I think it should be safe.

3) XEP-0106: Update to use PRECIS and newer XMPP RFCs ( https://github.com/xsf/xeps/pull/202 )

will review it later today and post on list regarding 2)

ditto on 202

On (3), I'm going to wait until PSA reviews it and then pretend I have and have the same comments, in order to make out as if I understand Precis.

I'm +1 in principle for the changes, but I also want to actually review the details

i18n ftw

vote on list for 3) too...

Lance, Dave Cridland: I'm putting "tentative +1 pending psa's author review" for you in the minutes, is that correct?

correct for me

It's a good euphemism for me.

4) XEP-0045: Define option name for enabling/disabling MAM ( https://github.com/xsf/xeps/pull/204 )

I got lost as to why this is an update to '45.

Seems it could be an update to '313, really.

isn't that the same as the existing enablelogging option? it's just a different interface

I'm on-list for #3

Tobias, No, it's the difference between logging and exposing that logging over MAM.

and this

Dave Cridland, so? why does this need to be a specific option i wonder?

i could understand that you don't want a room to be logged...but that's the enablelogging option, not?

Yes, but iirc the desire was to be able to specifically enable MAM logging. Using the existing option might not enable MAM (only turn on HTTP logs instead) and the client doesn't know

Would someone ever want HTTP logs but no MAM?

if the user wants public logging i don't see a reason to enable logging only for HTTP but not for MAM or only MAM and not HTTP

other that implementation specific constraints or so

It seems to me that what the logging is (MAM, HTTP, etc.) is a matter of server policy and that the only option should be "enable/disable logging"

Otherwise you end up opening the door for a dozen different options for a dozen different logging implementations, and things just get confusing.

SamWhited, right...and that's the roomconfig_enablelogging option

or is this logging of PMs to the MUC's MAM?

Hmm, so Holger argued this: http://mail.jabber.org/pipermail/standards/2016-July/031197.html

(I missed this thread on the list)

but for member only rooms as a server i just wouln't provide HTTP logging, only MAM

still single option, but can reply on list regarding that

I agree with Tobias, I don't think this stops it from being a matter of policy, not a technical problem.

I take it we're all going to be on list for this one to catch up with that standards@ thread?

yes

5) Date of next

sbtsbc?

wfm

wfm

WFM

6) AOB?

I should be done traveling for awhile after this week, so I'll have a bit more time.

none here

Date of next set for 2016-07-27 15:00:00 UTC

seeing no AOB

thanks all

thank you

thanks!!

SamWhited, btw: do you have/want access to the trello so you can take care of the stuff in the "For Editor" column?

+1

Tobias: Yah, let me actually go sign up for a Trello, I'm always reluctant to do it, but we do need tooling and they don't appear to offers single sign in.

bbiab, I need to pack for yet another flight

SamWhited, they offer login via oauth, don'T they?

or via google, can't remember

Hmm, so they do. It requires more than just my email address for some reason :S oh well, permissions aren't that bad.

Tobias: sam@samwhited.com

did that work?

Tobias: Sure did, thanks.

great

i'll try to clean up the other columns a bit later today

One of these days I'll write a thing that sends an invite to this room in time for council

:)

MattJ, Tobias, SamWhited: Regarding the MUC MAM option, I really disagree this should be done with the existing "enablelogging" option. The difference is that the access rules are clearly defined for MUC MAM, and not at all for "enablelogging". So as a client I don't know what I'm doing when touching the existing option.

But I wasn't in this room before and am not sure whether this is an appropriate place to discuss things.

enablelogging says public logging in XEP-0045, not?

Right. And if your client implements "private" rooms on top of MUC, you clearly don't want that. But you may well want MAM.

I think Holger's argument is compelling.

You said this should be a matter of server policy. I totally disagree there. This should be clearly defined in the XEPs.

Did I? Did I give any more context than that?

Kev, not you..I and other councilers

Kev: Not you, sorry; I'm just type slowly :-)

(And incorrectly.)

Oh, sorry, I've not been watching MUCs this afternoon, just started now.

right...but if so i'd name it roomconfig_enableprivatelogging or somelike that....

But it's not necessarily private :-)

having private room logging is orthogonal to having support for MAM

Access works as specified in XEP-0313.

You could have both options (public logging from 45 and the new MAMlogging) working in tandem, on a private room.

if you want your public room logged....then set roomconfig_enablelogging

that should get you also MAM logs

if the server supports that

As a client, you pretty much want to know what toggling an option is going to do.

You don't want to toggle an option hoping it'll enable MAM, when it'll really enable HTTP access to logs.

Tobias: I think we need a separate MAM option for the reason I mentioned. And if we have that, I don't think another option should implicitly set the MAM option as well.

That is a compelling argument indeed; maybe MAM isn't really "logging" per say.

i don't see why we need it

So, I was planning at some point to add a multi-option setting for who would be given MAM access, like { owners, members, participants, anyone }

the XEP says "Enable Public Logging?" <--- it doesn't say HTTP logging

so you're totally fine to provide public MAM logs when that's checked

Yes, which isn't the argument.

what you want is an option that enables private logging

The question isn't "Could you enable MAM when that option is enabled", the answer to which is obviously "Yes"

and yes, that needs a new option...but that's orthogonal to MAM imo

The question is whether a client might reasonably want to be able to toggle MAM access on and off - the semantics of which don't match that option.

Tobias: No, I want an option that enables MAM. Access to the MAM archive depends on access to the MUC room, so it's not necessarily "private". It's just clearly defined (in 0313).

I don't dispute the option, FWIW, but I don't follow the argument that it should be in '45.

why do you want the option?

what will you say in the UI?

Holger: Why? As opposed to always supporting MAM but it being the exact same data as the history you get on join (ie limited to ~20 or so)

Dave Cridland: I don't care where it goes. There was no consensus and I just went by the majority :-)

I think Holger's right; I was thiking of logging and archiving as the same thing, but really they're not in this case. If "enablelogging" is actually "enable access to logs" that's different from "enable archive" (which is what the MAM one would be).

I think -45 as a place for MUC options is cleaner, FWIW, and ideally in blue.

Tobias: It will say "enable room archiving" or whatever?

Zash: I don't quite understand your point I'm afraid.

Holger: Why enable/disable the protocol instead of the feature?

Or control the size of the archive

Eg. it's not about "enable public logging, enable private logging" options, it's about "enable/disable public logs, enable/disable storing messages whether they're exposed publically or not"

Kev, Not entirely a bikeshed - the canonical list of possible '45 config options should be, I thought, in the registrar's list. Otherwise every spec that wants an option would have to put it in '45 (or '369), which seems awkward.

Oh, in that case I vaguely agree, actually.

In my mind if the option is about archiving it belongs in '45, if it's about MAM it belongs in MAM

I inferred you were wanting it in 313, which I think would be wrong.

SamWhited, that kind of makes sense :)

Zash: Do we have an option for that?

(and I agree with what I think Zash was saying, if it's going to be an option it should be about archiving, not MAM)

if only the enablelogging description wouldn't mention the word public :)

Tobias: Why not? It's nice to have a separate option for that.

Tobias: I mean your service may well offer both things.

yes

i just don't want redundant things

HTML logs (or whatever) for public rooms, MAM for private group chat or whatever else clients do with it.

we already have a setting to set a room private

Holger: I believe implementations have an option for how many items to keep in history, suppose you extend on that

we already have a setting to set a room private/member-only

Tobias: You might want public logs for private rooms, no? :-)

no

Tobias: I don't think this is redundant, I think these are independent options.

that doesn't make sense

Tobias: Yes, it does.

Kev, not what Holger most recently said

public logs for private rooms?

Yes, it does.

then it's not that private, is it?

Access to the room, as in -45, is private.

Members-only, or whatever.

You might not want a million people joining the room and trying to voice an opinion, but you might want the discussion to be public. Eg. a special XSF Super-important Council-only Decision room could be private and only council members would be allowed in, but the logs and that decision would be a matter of public record.

ah..right

that use case makes sense

Zash: So to enable MAM, the client sets the number to 999999? I'm probably still not getting the idea.

so yeah...so the existing 'roomconfig_enablelogging' and a new 'roomconfig_enablearchiving' sounds sensbile and should be what Holger wants, right?

Dave Cridland: So you're suggesting 45 references the registry, and therefore the options are in -45 by reference, but 45 doesn't need an update in order to add new ones, right? That sounds 'right' to me.

Kev, That sounds like what I thought happened now. If it doesn't, we should fix it.

Yes, I believe that's right.

But it's not what obviously happens.

If your server supports MUC+MAM, does it not make sense to use the same data for both <history/> and MAM?

It certainly could make sense. I don't think it necessarily does.

Hm, you could even go and just re-use some other settings, like the one for persistence

How is the question whether the same data is used related?

I forgot half of what I was thinking before I finished writing. :(

Holger: I don't think enabling MAM itself is needed. Configuration for how long / how many messages persist, and who has access to them would be nice tho

Zash: The "how many messages" thing seems unrelated to me. Do you want that for user archives as well?

Zash: 0313 specifies access rules which I think conver the common use cases. Not sure we need more complex things standardized, but if we do, this also seems like a separate feature to me.

holger: Yes (if allowed by local policy). Per-user limits in time or number would be nice I think.

Maybe. Not sure I want to implement that :-)

Right, but there's some flexibility in that language, so maybe you want some configuration for it

> MAY further limit access based on other criteria as part of the deployment policy

The use case I have in mind is a client offering a simple UI for private group chat. That's covered by the MUC support in 313, there's currently just no way for that client to enable that. The problem with reusing existing options is that the client can't be sure about the result.

Replace all settings with a single (private, public) switch.

Thanks to Conversations, that's what people believe now anyways

Would cover my use case but lack the flexibility to cover other use cases.

What's so wrong about adding a simple option to enable MUC MAM, like we already have for 1:1 MAM?

Enable persistent archiving/logging?

I wonder, there's a setting for persistence already

But you may well want have a persistent room configuration but no archiving, no?

Maybe, but does it need to be a standardized option?

I'd actually want persistent room with archiving but limit access to older messages to members only

I think a new standard option to enable MUC MAM would solve a common use case in a straightforward way. I'm not sure I can add any more valuable input and will leave the decision to you guys.