[Standards] [Council] 2016-07-20 Council Meeting

Tobias Markmann tmarkmann at googlemail.com
Fri Aug 5 16:26:27 UTC 2016


On Fri, Aug 5, 2016 at 6:01 PM, Holger Weiß <holger at zedat.fu-berlin.de>
wrote:

>
> I'd be interested in feedback on this.  Personally, I'd still prefer
> referring to MAM, as I think the client should to be fully aware of the
> implications of enabling that option, especially in private rooms.  If
> we ever come up with another archiving XEP that supports XEP-0045,
> chances are the archiving semantics and access rules will be different.
> And it should be no problem for clients supporting future XEPs to use
> new MUC configuration options if necessary.
>
> However, if others prefer "roomconfig_enablearchiving", I'll update my
> PR¹ accordingly.
>

I changed my mind, use roomconfig_enablemam or whatever.


>
> > So what's the way forward?  Shall I provide an updated PR against
> > XEP-0045, or against XEP-0313, or something else (e.g., others suggested
> > putting all XEP-0045 configuration options into a separate registrar's
> > list)?
>
> While I understand how moving the configuration options into a separate
> document might be nice, I'm probably not the right person to make this
> happen, and I'd be grateful if this idea wouldn't block the addition of
> an option to enable MUC MAM.  If people agree with such an option, can
> we just put it into XEP-0045 until someone moves things around?
>

Guess XEP-0045 is fine, it already has a pubsub specific config uption, so
why not MAM too.
Further things missing in this change though are:
- possibly adding a status code for this, there is one for public logging
after all ( 7.2.13 Room Logging ), but this is probably not a requirement
- a reference to this option in section 13.3 Privacy, it sounds worthy
enough to mention there

If that's done i'm +1 for the change.

Cheers,
Tobi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160805/c797a489/attachment.html>


More information about the Standards mailing list