Jacek Konieczny wrote: > On Tue, Jun 26, 2007 at 11:59:24PM -0700, Rachel Blackman wrote: >> But second, and more importantly, not one single person has offered a >> solution other than 'make every extension hardcoded' or 'just probe >> each contact, cache only per-JID,' which returns us to the original >> troublesome network-flooding behavior on logins. > > That is not true. Years ago I have proposed other solution:
Ah, I don't remember that. Do you have a pointer to the mailing list archive? > instead of > announcing client name version and caps clients should announce digest > (e.g. MD5 or SHA) SHA-256? ;-) > of normalized set of supported features. What does that mean exactly? > The list > would have to be obtained only once per feature set and it could be > verified. The traffic would not be much bigger than with current > solution and the 'cache taint' problem would be gone. And > implementations could be simpler (no need for capability registry -- > namespace registry is enough) and less error-prone Sounds good. > (when a new namespace > is added the digest would change 'automatically'. Currently developers > have to manually update version or capability string). > > I think the digest could be used with current specification too -- as > the only capability string, bound with all the supported namespaces. But > XEP-0115 is not optimized for such usage and says nothing about digest > verification. Because the authors don't remember your suggestion. :) Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml
smime.p7s
Description: S/MIME Cryptographic Signature
