On Tue, Nov 1, 2016 at 8:02 AM, Florian Schmaus <f...@geekplace.eu> wrote: > That is what I'm thinking too. The question is: Shall we assume that > every entity which announces support for hash algorithm X, also supports > HMAC based on X? If yes, then we could simply add a <hmac/> element to > XEP-0300 and be done. Doesn't even require a namespace version bump.
My initial reaction is that having just an <hmac/> element is a good idea (because if you support 5 hash functions you almost certainly support using them in your HMAC implementation). However, it also strikes me that there may be situations where you support a hash like MD5 for use in some legacy situations, so you advertise it, but those legacy situations don't use HMAC and in the protocols where you do use HMACs you don't need the legacy stuff so you don't want to support MD5. I also can't think of a real example of this, so maybe if you support a broken legacy hash mechanism in one place you can just support it everywhere else (or, even better: don't). I'm leaning towards just <hmac/> for simplicities sake, but if anyone can think of a real-world example of the above situation it would probably change my mind. —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
