I originally reviewed version -06 of this document
(2008-02-8). Examining the diff, it does not appear to me that any of
my comments from my previous review. Looking back in my mail folder, I
don't see any reasponses from the authors telling me my review was
wrong, so I'm retransmitting it here.
-Ekr
$Id: draft-ietf-simple-imdn-06-rev.txt,v 1.1 2008/02/08 18:17:54 ekr Exp $
This document describes a mechanism for IM senders to request status
notifications for their IMs. The sender attaches a header specifying
the status conditions he wants to be notified of and intermediaries
and the receiving UA notify the sender (or someone else of his choice)
subject to policy constraints.
One thing I'm not clear on is how the recipient determines where to
send the IMDN. Are they supposed to read the "From" field? One thing
that I don't get is how the IMDN-Route header interacts here.
It looks to me like this gets stuffed in the "To" in the IMDN.
What happens if someone puts an IMDN-Record-Route that points
to an IMDN-ignorant UA?
Overall, this document seems pretty well written and clearly lays out
the security issues.
That said, I'm concerned about the bounce/reflection threats discussed
in S 14 (where the sender asks for notification to a third party
victim). I'm particularly concerned about the "note" field, since a
natural implementation seems to be to include an excerpt from the
message you're acknowledging. This draft identifies the threat but
doesn't specify any mechanism for ameliorating them. I think some
suggested mechanisms would be appoprirate here, or at least some
analysis of what the potential mechanisms were and why they would or
would not work.
Other comments: I would avoid the term "non-repudiation" if at all
possible in S 5.3 and later. It's just so overloaded now that it's
hard to know what it means.
S 6.5. A little more explanation of why IMDN-Record-Route is useful
would help.
S 7.1.1.1. Why does Message-ID need any randomness at all as opposed
to uniqueness? And if it needs randomness, why is 32 enough?
S 7.1.3. Note that you can pack the state into the messageid if
you're willing to make large message ids and hte stte is small.
S 11.1
An IMDN Payload is an XML document [6] that MUST be well formed and
MUST be valid according to schemas, including extension schemas,
available to the validater and applicable to the XML document. The
IMDN Payload MUST be based on XML 1.0 and MUST be encoded using
UTF-8.
Is this a requirement that the receiver validate the XML?
S 12.1.1. Why can't anonymous senders request notifications?
S 14.3. See above comemnts about nonrepudiation
-Ekr
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf