[Standards] XEP-0334 Message Processing Hints (Was: [Council] Council Meeting Minutes April 5th 2017)
georg at op-co.de
Thu Jul 13 14:59:05 UTC 2017
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
|| 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 ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the Standards