Instant Message Disposition Notification (IMDN)
Note: This ballot was opened for revision 10 and is now closed.
(Jon Peterson) Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Ross Callon) No Objection
(Lisa Dusseault) No Objection
(Lars Eggert) No Objection
Comment (2008-05-08 for -** No value found for 'p.get_dochistory.rev' **)
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 18.104.22.168., 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?
(Pasi Eronen) (was Discuss) No Objection
(Russ Housley) No Objection
(Cullen Jennings) No Objection
(Chris Newman) (was Yes, Discuss) No Objection
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.