Hi, On Sat, Aug 27, 2011 at 9:07 AM, Waqas Hussain <[email protected]> wrote: > On Sat, Aug 27, 2011 at 4:52 AM, Matthew A. Miller >>> I'm still in favor of a clean new algorithm and XEP, which can also fix >>> many of the non-algorithmic issues with the XEP. >> >> I personally would like to explore the possibilities we might have to fix >> things with as small an impact as possible. >> > > So would I. But I'm mostly convinced that it wouldn't be possible. > Take the disco response of any of the popular clients, and I'm certain > I would be able to attack it despite all reasonable restrictions, > escaping and checks you could come up with which don't change the > algorithm in a major way.
Yes it looks to me that the most annoying issue with the caps algorithm is that it codes anything that could go in a service disco (identities, features, etc.) the same way (something<something<...). No structure difference. That sounds difficult to fix without breaking many of the existing hashes. Too bad the namespace does not follow the URN format, where we could simply update the version to change the hash definition. Anyway if there was to be a new XEP, I would say that it should be close to caps, so that implementation can very quickly/easily update, and also because, even though some things may indeed be improved, caps has still a nice design, in my opinion. And in particular, we should quickly and very clearly deprecate caps in favor to the new XEP (if we decide to do one). What hurts the more some features from becoming widespread or common to all implementation is the duplication of XEPs doing the same things without coming to any consensus nor making any real choices for years. Up to now, caps was very nice, because it filled an empty gap, but if we have to evolve the feature into a better XEP, let's do it well. Our standardization process really should take these duplication issues more into account. Jehan
