On Montag, 12. Februar 2018 00:41:54 CET Christian Schudt wrote: > - Generally I am unsure if using the "xml:lang" and „name" from the > identities is a good idea at all, because these two attributes should not > change the capabilities of an entity. Name and language is just for humans. > I.e. if a server sends german identities for one user and english > identities for the next user (depending on their client settings/stream > header), the server still has the same identities, which should result in > the same verification string, shouldn’t it?
First of all, I think previously, an entity answering a disco#info request always sent all translated identities, so that would not have been an issue. You’re touching on a more general thing though which I’d like to discuss. We could separate the hash into three hashes, one for identities, one for features and one for forms (or maybe two: identities and forms+features). This has the upside that human readable identifiers don’t interfere with protocol data (features/forms) in many cases (I think the identities are more rarely used in protocols, but I might be wrong). The obvious downside is that we need to transfer more data in the presence (twice or thrice the amount for ecaps2). I’d like to know what you people think of it. Since this is still Experimental, I’d be fine with bumping the namespace and getting this done. But I’m afraid that the bandwidth costs will outweigh the advantages. We have ~100 bytes for a 256 bit hashsum (including wrapper XML). We would end up with more than half a kilobyte (~0.6 kB) for ecaps2 if we split the hashes and assume that each entity uses two hash functions with 256 bits each (which I think is a reasonable assumption). If we have caps optimization, the impact would probably be neglectible, but I’m not sure if we can assume that. I’d like to get input from you folks on that. kind regards, Jonas
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________