[Standards] XEP-0334 Message Processing Hints (Was: [Council] Council Meeting Minutes April 5th 2017)
daniel at gultsch.de
Thu Jul 13 15:52:55 UTC 2017
Maybe we are obsessing a bit too much about hints. Maybe we should
take a step back and think about what we need hints for in the first
place and if we can maybe replace hints with some more well defined
server side rules.
I'm primarily using hints to 'tag' OTR messages as no-store and
no-copy. Furthermore I'm using hints to tag OMEMO messages as <store/>
as they don't have a body.
Also hints operate under the assumption that the sender knows best how
the receiving server should handle this…
Fom my perspective hints could go away if MAM learns about OMEMO
messages (Or maybe all messages with an EME tag) and we stop sending
2017-07-13 16:59 GMT+02:00 Georg Lukas <georg at op-co.de>:
> I'll make another attempt to unstall the hints situation.
> * Sam Whited <sam at samwhited.com> [2017-04-19 16:54]:
>> On Wed, Apr 12, 2017 at 10:14 AM, Dave Cridland <dave at cridland.net> wrote:
>> - 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
> I'm strongly in favor of having a hints XEP, also because of
> discoverability. Why should I, as a client developer working on any
> random message-based feature (let's say OTR or CSNs), have to go through
> all the XEPs that might affect server-side message routing, just to
> collect the right combination of hints?
>> - 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
> The good thing about hints is that they are just hints, not normative.
> I see the merit in your argument, though, and I can imagine two ways
> a) where needed, support for a given hint can be advertised by an
> according <feature/> element. Really, we should get away from versioned
> protocols to feature-detection ;)
> b) the normative language for hints can be placed in the respective
> routing XEPs (Carbons, MAM), and _the_ hints XEP becomes an informative
> one that describes the principal ideas and refers to the normative XEPs.
> That way, we can still solve the discoverability problem.
> Option (b) would also give us an elegant way to have all hints within
> the same namespace, with the hints XEP being the normative place for
> this namespace.
> || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++
> || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ ||
> || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? ||
> ++ IRCnet OFTC OPN ||_________________________________________________||
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
More information about the Standards