I think it would be tidier to move the Appendix (currently Section 14) to the end of the document.

---

Can I assume that a deliberate and careful decision has been made not to create IANA registries to manage the codepoint spaces defined in this document?

Please check the division of references into normative and informative. For example, I doubt that [XEP-0262] is a normative reference (because developers don't need to understand XEP-0262 in order to implement ZRTP).

#1) Sec 4.1.1: Should the should be SHOULD:

 Both
 parties should choose the highest version number that appear in both
 parties' list of a=zrtp-hash version numbers, and use that version
 for their Hello messages.

#2) Sec 4.4.1.2: Should the should be SHOULD:

If pvi is 1 or p-1, the user should be alerted of the
   attack and the protocol exchange MUST be terminated.

#3) Is the space really used:

clear_mac = MAC(mackeyi, "GoClear ")

#4) I support Tim's DISCUSSes.

(a) Section 3 could be interpreted as requiring a single Hello-HelloACK
exchange.  A few pages later, it becomes clear that both the initiator
and responder are required to generate a Hello and respond with a HelloACK.  I would suggest a few clraifying words in section 3.

(b) In section 3.1.1, I gather that the initiator needs to generate their
ephemeral key pair before sending the Commit, and the responder
generates their key pair before sending DHPart1.  It might be helpful
to add that information - it helps clarify issues regarding Commit
contention.  (see comment on 4.2)

(c) this is a nit, but 3.1.3, first sentence
s/and hence/with/ 
rationale: established SRTP media stream does not imply a ZRTP
session key in many contexts

(d) 4.2 last paragraph
As I understand it, if commit contention occurs, both parties will
generate ephemeral key pairs before genreating the commit.  The point of
this paragraph is that a new key pair does not need to be generated by
the entity that is selected to be responder by the contention resolution
process.  If that is correct, this bit could be a bit clearer.

However, this text states "should only be discarded if it does not match
the initiator's key size".  As I understood the algorithm negotiation
process, I do not believe this condition can ever occur with two
well-behaved systems.  Am I missing something?  Wouldn't this indicate
an attack?

(e) Section 7.2.1 establishes clear constraints on the algorithms and key
sizes. Section 7.2.2 implies that X.509 certificates are restricted to
EC P-256 and P-384 keys.  Is this intentional?  Other algorithms could
have issues with the 2044 octet limitation for the X509 signature block,
but it is certainly possible to support effective DSA and RSA key sizes
within that limitation.

Given that the vast maority of X.509 cetificates contain RSA keys,
limiting ZRTP to ECDSA would seem to be a major ipediment to using this
feature.