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 

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,

Attachment: signature.asc
Description: This is a digitally signed message part.

Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org

Reply via email to