Subject: [xmpp] Fwd: Robert Sparks' Discuss on draft-ietf-xmpp-3921bis-19: (with DISCUSS and COMMENT)

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 19 Jan 2011 14:13:24 -0700

FYI. I'll reply to Robert's feedback later today or perhaps tomorrow.

-------- Original Message --------
Subject: Robert Sparks' Discuss on draft-ietf-xmpp-3921bis-19: (with
DISCUSS	and COMMENT)
Date: Wed, 19 Jan 2011 13:02:09 -0800
From: Robert Sparks <[email-masked]>
To: The IESG <[email-masked]>
CC: [email-masked], [email-masked]

Robert Sparks has entered the following ballot position for
draft-ietf-xmpp-3921bis-19: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

DISCUSS
In section 3.1.3 item 4, a server is required to keep a complete
presence stanza for an unbounded amount of time (potentially forever).
This looks like a vector for a state-exhaustion attack. The restriction
for keeping only one such stanza per sender helps, but a malicious
attacking server could send stanzas from an arbitrary number of
identites. I suggest providing implementation guidance on when it's ok
to drop information that's truly stale, and call out the potential for
this attack in the security considerations.

Section 5.2.4 calls out "for the purpose of providing alternate versions
of the same subject" when allowing multiple subjects to appear with
different xml:lang attributes. Section 5.2.3 does not have analogous
text constraining multiple bodies. Should it?

Section 5.3 - Was the intent to constrain the contents of a message
stanza to things intended to be rendered to a user? As written, this
section would allow <message/> to be used as part of the framing of an
arbitrary transport protocol.

Section 5.3 - The document should say what an implementation receiving a
child element in a namespace it doesn't understand should do with that
child.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

COMMENT

In section 2.3.3, is the intent that error conditions listed earlier in
the section take precedence over error conditions listed later in the
section? What's the appropriate response if a message qualifies for both
a <forbidden/> and a <bad-request/> as described in this section?

When would an element choose not to follow the SHOULD in 3.1.2 item 1,
and what are the consequences?

The end of section 4.3 has an implementation note containing normative
requirements. Can these be moved into the main prose?  This same
implementation note may be easy to misinterpret. I don't believe it is
meant to prevent an implementation from returning an error to a
malformed presence probe, but it could be read that way.

Section 5.2.5 does not prevent a thread from claiming it is its own
parent (should that be allowed?), or warn implementations about the
possibility of thread A indicating a parent of B, and thread B
indicating a parent of A (generalize this to any kind of cycle). I don't
think XEP-0201 calls this out either. Should it be mentioned as an
implementation consideration? (A naive implementation would very likely
crash or do something surprising with its UI.)

In section 8.5.2.1, I encourage adding text explaining why delivering to
all non-negative resources is SHOULD and not MUST. I understand from
out-of-band communication that local policy may determine that some
particular resource not receive the message, but the document does not
say this. As written, I can see implementations that adopt a policy of
delivering to the first non-negative resource and claim they've met the
requirement.