Keith> RSA can complain "but that's *our* protocol", and IETF will
Keith> duly record that complaint, but that by itself won't stop
Keith> IETF from considering whether to use it.
....................
Keith> Call it whatever you like, but that's what RFC 2026 says.
Excuse me, but who cares what RFC 2036 says? I thought we weren't
discussing what RFC 2036 got to tell us?
Some people have been talking about in terms of use of RC2 being
a violation of IETF process. RFC 2026 defines that process, and
most of my contribution to this discussion has been an attempt to
clarify that process. People's beliefs about the process rules are
very relevant to this discussion, because those beliefs color the
thinking about the solution space.
If a working group decides not to use RC2, that's fine with me. But I
hate to see a group making such a decision based on a misunderstanding
of IETF process rules. If the group understands the process rules,
and still makes the same decision, I'm a lot more comfortable.
Everybody wants a standard that is free [to implement].
Only problem is, the intersection of "free to implement" and
"compatible with s/mime" is the null set.
So do people here really want to define Yet Another Email Security
Standard which can freely be implemented, even if it's incompatible
with anything else that's out there?
Keith