On Wed, Aug 19, 2009 at 3:47 PM, Jonathan Dickinson<[email protected]> wrote: > This may be a bit extreme but how about a V2 115? This would come up as a > feature with a new namespace (alongside the old one). If the old one would > be selected the server would transparently intercept it and send the > originating user a warning ("Your Jabber client is using old and flawed > technology which could present a security risk. Please update it or contact > the developers about XEP-115."); at such a point we could kill the standard > (not just deprecate it) the server could ignore the stanza (and never route > it). >
If we did decide to take such drastic action for deprecating the original spec then I vote for going the route of a new hash algorithm to minimise disruption, confusion, and effort on the part of lazy developers :) It also allows wise implementations to make an informed choice about whether to trust a hash or not. I think I'm in favour simply of using \0 as the new separator, it being disallowed in XML in general. And I'd like to clear up that if any existing implementations are using "<" as the separator with the current spec then they are the exception, since an XML parser in general would always pass data unescaped (ie. it would pass to the application "<" and not "<")... it is usually the parser's responsibility to handle XML escaping, so for applications to use escaped strings in hash calculation would require an extra XML-escaping step. That any mention of this step is missing from the XEP is the root cause of the problem. Simply using \0 protects developers from making the same mistake (and given the opportunity someone will), whether we fix the spec or not. Matthew
