-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/18/09 6:15 AM, Joe Hildebrand wrote:
>
> On Jul 31, 2009, at 8:59 PM, Peter Saint-Andre wrote:
>>
>> I haven't yet had time (at least since the XMPP Summit last week) to
>> think more about this problem. We did a lot of work in the more recent
>> versions of XEP-0115 to maintain backward compatibility, and it would be
>> a shame to lose all that work now. But sometimes sunk costs are a fact
>> of life...
>
> Backward-compatibility is very important to me.
Me, too. We've already bend over backwards here once...
> There is a LOT of
> XEP-115 deployed out there. My preferences are:
>
> 1) characterize exactly the sorts of strings that lead to attack. Put
> wording in the XEP that allows detecting those attacks by disallowing
> certain combinations. I'm not sure if that's possible, but, for
> example, forbidding empty type attributes in identities might mitigate
> attacks 2 and 3.
That would be helpful, too.
> 2) add a new feature that sorts at the end, or a new extension that
> sorts at the front to signal the shift between features and extensions
Something like this?
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<value>!</value>
</field>
</x>
Yes, literally "!". Or something else that would pretty much always sort
first.
> 3) move extensions to deprecated, and have everyone who sends extensions
> be viewed with suspicion. This is a distant last for me, since there
> were valid compromises that went into the inclusion of extensions in the
> first place. The last thing I want is for clients to go back to sending
> iq:version to everyone on the roster every time they receive presence.
Agreed.
Peter
- --
Peter Saint-Andre
https://stpeter.im/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkqwEi4ACgkQNL8k5A2w/vzZgACfbxcscIit5ltMYfxxDuXBfR5x
HOYAnjurSu9VNjxWreY1blK6FjoY0EFJ
=fGBn
-----END PGP SIGNATURE-----
