Last Call: 'XMPP Core' to Proposed Standard

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

To the IESG,

I concur with Alexey's recent comments regarding XMPP's SASL
Profile.  I have a few addition concerns regarding this profile.
The scope of my review was, due to time constraints, was limited
to the profile.

I not sure why the documents says that SASL and TLS security
layers SHOULD NOT be enabled simultaneously (Section 6.2, rule 2),
but this recommendation is, I believe, flawed.  There are numerous use
cases where implementations SHOULD establish additional layers.
For example, establishing additional SASL layers may prevent
certain kinds of tunneling man-in-the-middle attacks.

The requirement that initiating receiving entity drop all knowledge
it learned before negotiating SASL layers (rule 5) is too broad.
This could be viewed as requiring the implement to forget knowledge
it gained previously in a secure manner (such as an externally
established lower level (IPSEC or TLS) identity information).
Likewise for rule 6.

For rule 8, a normative reference to the base64 encoding algorithm
should be provided.

I am also concerned by the use of the term "stream encryption"
in the document as this doesn't imply, in my eyes, "stream
integrity".   It's unclear to me which imperatives imply when
encryption, integrity, and/or in combination with other security
services which TLS provides.

Additionally, I would like to note that the document suffers
from a number of nits.  As I only did a casual scan, this
list is likely no where near complete.  I suggest that XMMP
WG members be asked to do a more careful review for nits.

	Acronym not spelled out in title: XMMP
	Citiation in abstract
	Used old citation style (numeric tags instead of mnemonic tags)
	Acronyms not spelled out on first use in Abstract: XML
	Table of contents too long
	Acronyms not spelled out on first use in body: XML, JID
	Confusing upper casing of words: COULD
	Odd use of 2119 keywords: "MAY optionally"