[Standards] Entity Capabilities 2.0
jonas at wielicki.name
Mon Feb 12 08:10:47 UTC 2018
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards