Skip to main content

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

Yes

(Jon Peterson)

No Objection

(Cullen Jennings)
(Dan Romascanu)
(David Ward)
(Jari Arkko)
(Lisa Dusseault)
(Magnus Westerlund)
(Pasi Eronen)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Tim Polk)

Note: This ballot was opened for revision 10 and is now closed.

Jon Peterson Former IESG member
Yes
Yes () Unknown

                            
Chris Newman Former IESG member
(was Yes, Discuss) No Objection
No Objection (2008-07-31) Unknown
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.
Cullen Jennings Former IESG member
No Objection
No Objection () Unknown

                            
Dan Romascanu Former IESG member
No Objection
No Objection () Unknown

                            
David Ward Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection () Unknown

                            
Lars Eggert Former IESG member
No Objection
No Objection (2008-05-08) Unknown
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?
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Magnus Westerlund Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Pasi Eronen Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Tim Polk Former IESG member
(was No Record, Discuss) No Objection
No Objection () Unknown