On 19 April 2017 at 15:52, Sam Whited <s...@samwhited.com> wrote: > On Wed, Apr 12, 2017 at 10:14 AM, Dave Cridland <d...@cridland.net> wrote: >> I'd be interested in Sam's counter-arguments, mind. > > - Discoverability: if <private/> or <no-copy/> 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?
I've no objection to a note in Carbons (say) that points to a/the hints XEP. > - 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? > I don't really mind where new hints are defined. I'd like them to end up in the same namespace, however. I'd welcome the philosophical argument about whether adding new hints to an existing hint namespace is countenanced by the church, though. > 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 > <no-archive/> 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). What about MUC web logs? > > —Sam _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
