[Standards] Re: [jdev] XEP-0115: Entity Capabilities
hildjj at gmail.com
Fri Jun 29 14:17:50 UTC 2007
On Jun 29, 2007, at 3:40 AM, Dave Cridland wrote:
> On Thu Jun 28 23:12:25 2007, Joe Hildebrand wrote:
>> The current spec could absolutely be used for this. The hardest
>> part is spec'ing how to generate a string that has all of the
>> capabilities, so that you can run the hash. Canonical XML is
>> massive overkill, but, for example, if we just said:
>> - For all sorting, use the Unicode Collation Algorithm (http://
> Feh. UTF-8 encode then i;octet - much faster, just as stable, and a
> heck of a lot simpler to implement, especially given that
> namespaces will be us-ascii anyway (hence UTF-8). RFC4790 defines
> this. (i;basic uses TR10, but ISTR it's not yet ready).
+1. What's the standards-language way of saying that?
>> - Initialize an empty string E
>> - sort the identities by category, then type
>> - for each identity, append the category, then the type (if it
>> exists) to E (note: any information inside an identity will be
> I'd propose something mildly more structured here, really such that
> it's simpler to view by eye to ensure the formatting and ordering
> is correct. This has no security impact, it's just easier to
I'm not sure why readability is important here. It's never going on
>> For better security, we could use HMAC, and/or a different hash
>> function. One option would be that, if H is the result of the hash/
>> hmac function, then V, the version string, is formed by prepending
>> its algorithm and a $, something like:
> E = *(cat-line) *(feat-line)
> H = <hash/hmac of E>
> V = hash-func-name "$" H
> hash-func-name = hash-name / "HMAC-" hash-name
> hash-name = "MD5" / "SHA1" / "SHA-256"
> We mandate that HMAC-MD5 is used, but a future specification MAY
> change this requirement. MD5 does have the minor advantage of being
I think this is overkill. Finding a one-way collision in a hash
function seems like adequate protection against a DoS attack. The
simpler this is to check, and the less ways of messing it up, the
more likely it will be to get implemented. Let's just pick a single
algorithm and stick with it.
>> If the receiving client detects an inconsistency, it MUST NOT use
>> the information it received, and SHOULD show an error of some kind.
>> For backwards-compatibility, any version number that is not 32
>> octets long consisting only of [0-9a-f] MUST be treated as if it
>> does not implement MD5 checking.
> We've got slightly better error checking if we explicitly tag the
> data with the prefix defined by the V ABNF production above.
Fine. But let's just pick one prefix. Is there a urn:hash: URI scheme?
> We send these out, currently, with every presence update, correct?
> Is it worth looking at an alternate mechanism, or a generalized
> presence-delta? (After all, I'm pretty sure that this data won't
> change as often as my status).
There's a server optimization that keeps it from going out as often,
but I don't know that it's been implemented.
> I have to admit, I have an odd feeling that combining all
> extensions together might generate a better result, too, but that's
> nothing more than a gut feeling.
It probably depends upon how often extensions are turned on and off,
whether the server optimization is in effect, and the like. I
suppose there's nothing stopping the writer of an entity from doing
this, and never sending ext.
More information about the Standards