Instant Message Disposition Notification (IMDN)
draft-ietf-simple-imdn-10

Jon convinced me to make this a comment rather than a discuss position.  Partly because this fits in the model put forward by CPIM:

4. The decision to mix transitive routing information
(IMDN-Record-Route, IMDN-Route) into the IMDN content itself is bad
design, especially when that information is to be removed by
intermediaries. That makes any sort of content based signature
impossible, and such mechanisms are likely to become an important part
of the necessary reputation systems as the volume of IM spam increases
over time.

Section 5.3., paragraph 2:
>    In addition to text, some IMs may contain audio, video, and still
>    images.  Therefore, the state "read" includes playing the audio or
>    video file to the user.

  Does it indicate the start of playback, or when playback has
  concluded? (Probably the former, but it might be good to be explicit
  in the text.)


Section 5.3., paragraph 3:
>    Since there is no positive acknowledgement from the user, one cannot
>    determine _a priori_ the user actually read the IM.  Thus, one cannot
>    use the protocol described here as a non-repudiation service.

  That restriction - that getting a "read" IMDN doesn't actually mean
  that the recipient is guaranteed to have read the IM - seems important
  enough to describe more prominently, e.g., in the introduction. "Read"
  is maybe also a bit inaccurate, maybe "rendered" would be a better
  term, i.e., the IM has been rendered to the user, which is about as
  much as a program can guarantee it did. It's probably too late to make
  this wording change, but an explanation can still be added. (Nit: I
  don't understand what "a priori" is supposed to express in this
  sentence.)


Section 7.1.1.1., paragraph 1:
>    The Message-ID field is populated
>    with a value that is unique with at least 32 bits of randomness.

  Nit: It's not unique, it's _statistically_ unique.


Section 7.1.3., paragraph 2:
>    Once an IM Sender sends an IM containing an IMDN request, it MAY
>    preserve the IM context, principally the Message-ID, and other user-
>    identifiable information such as the IM subject or content, and date
>    and time it was sent.

  Isn't a MAY a bit weak? Requesting IMDNs when I'm not going to be able
  to correlate them to specific sent messages seems to be pretty
  pointless.


Section 12.1.1., paragraph 4:
>    An IM Recipient can ignore such request
>    if the IM Sender is anonymous.

  Nit: s/can/MAY/


Section 13., paragraph 1:
>    MSRP already provides a built-in mechanism to supply positive and
>    negative delivery reports.

  Reference to MSRP missing.


Section 14., paragraph 1:
>    IMDNs provide a fine-grained view of the activity of the IM Recipient
>    and thus deserves particularly careful confidentiality protection so
>    that only the intended recipient of the IMDN will receive the IMDN.
>    In most cases, the intended recipient of the IMDN is the IM Sender.

  When the IMDN recipient isn't the sender but instead the IMDN is
  addressed to multiple recipients, an amplification attack can be
  performed. Is this a new threat with IMDNs or is this already being
  discussed for the base IM transport?