[Standards] XEP-0334 Message Processing Hints (Was: [Council] Council Meeting Minutes April 5th 2017)

Florian Schmaus flo at geekplace.eu
Thu Jul 13 15:20:14 UTC 2017


On 13.07.2017 16:59, Georg Lukas wrote:
> 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
>> carbons?
> 
> 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
>> document?
> 
> 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
> forward:
> 
> 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.

+1

- Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 642 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170713/bd38bdcc/attachment.sig>


More information about the Standards mailing list