Instant Message Delivery Notification (IMDN) for Presence and Instant Messaging (CPIM) Messages

1. Instant Message Delivery Notification (IMDN) for Presence and Instant Messaging (CPIM) Messages draft-burger-simple-imdn-01 Eric Burger draft-burger-simple-imdn-01

2. IMDN • Transport Notifications Handled by OK (p2p) and REPORT (MSRP) • “Return Receipt” • User Notifications Needed • Recipient UAS Received Message, But Did User Actually See/Hear/Feel Message? • “Read Receipt”, or other dispositions draft-burger-simple-imdn-01

3. Internet Mail Approach: Message Delivery Notification (MDN) • After Message “Delivered”, i.e., Available for Presentation to User • Not a Non-Repudiation Service • A Regular Message Body • Uses Message Transport and Delivery Mechanisms • User Readable • Machine Readable draft-burger-simple-imdn-01

4. Abstract Flow • Sender Marks Message for Reporting • Message Becomes Available to the Recipient • Possibly Expanded Through Recursive List Expansion • Recipient Disposes of the Message • Read, Delete, Other • Recipient UA Sends Message Disposition Notification to Sender draft-burger-simple-imdn-01

5. B2BUA • Often, Recipient is Not Human • Common B2BUA Situations for CPIM: • Gateway to “foreign” IM Network • List Expansion • User Interpretation of “Read Report” Might Not Match Protocol Interpretation • Gateway may “read” message to forward it • User expects report to relate to final destination draft-burger-simple-imdn-01

6. What Dispositions? • Asking for a Failed Delivery Report Does Not Make Sense • Delivery failure report only happens on “happy path”: UAS generates report. • Most likely to have no report for failure • UAS failure, UAS deciding to not send IMDN, network failure all look identical, and more likely than “success” being the absence of a failure message • Thus One and Only One Reporting Request draft-burger-simple-imdn-01

7. Harmony • IMDN and im-report Have Similar Flavor • From im-report • XML Data Format • “Absence of Header / Empty Value” Means Explicit Report Suppression • B2BUA Drives Reporting • From IMDN (High Level) • Reduce State Request to “Read” • List Expansion / Gateway Mechanism • User Privacy Considerations • Require Processing Allows UAS to Explicitly Reject Request • End-to-End Report Integrity draft-burger-simple-imdn-01

8. Open Issue 1: B2BUA Reporting • Proposal #1: Punt. Delivery is to B2BUA. IMDN indicates “processed” • Protocol Purity • Proposal #2: Always Assume User Wants Final Recipient Report • Matches Most User Expectations • Proposal #3: Allow User to Indicate Which They Want • Precisely Matches User Expectations • No Burden on UAS • Pretty Easy for UAC • IMDN Today Uses Proposal #3 draft-burger-simple-imdn-01

9. For List Expansion, User Wants Either A Single Report With All Deliveries Delivery Reports for Each Recipient IMDN Today Is Proposal #2 Leaning Towards #1 (im-report mechanism doesn’t work) Proposal #1: Per-Recipient Reporting Easy Implementation at UAS, B2BUA Flood Potential at UAC Security & Privacy Issues Proposal #2: B2BUA Consolidates Reports B2BUA Collects IMDNs from Recipients How Long to Wait for IMDNs? What About Late IMDNs? Open Issue 1a: Consolidated Reporting draft-burger-simple-imdn-01

10. Open Issue 2: Notification-To • Simplification for B2BUA State Storage • Endpoints Report Directly to Sender • Method Used by MDN • BUT: MDN is SPAM-Friendly • Would Require Sender Authentication and UAS Trust of B2BUA (transitive via sips?) • Or, Use im-reports Mechanism of B2BUA Relaying Responses • Requires Infinite State Storage at B2BUA • Proposal: Use im-reports Mechanism With Local Policy Timeout Plus “No More Reports Coming” Protocol Action draft-burger-simple-imdn-01

11. Open Issue 3: Human Reports • MDN is multipart/report • One part is human readable “what happened to your message” • Another part is machine readable error codes, etc. • Do we want something users can read? • Grandma does not understand XML or headers draft-burger-simple-imdn-01

12. Open Issue 4:Transport Encoding • XML Is Cool. Wow. • Headers Work. Boring. • Headers Easy to Extend and Parse. Wow. • XML Parser Validates Tags. Cool. • All CPIM Processors MUST Parse and Process Headers. Excellent. • Some CPIM-Transported Messages are In XML. Neat. • Headers Have Namespaces, Too (CPIM Model) • Proposal: Use Headers, not XML (IMDN-00) draft-burger-simple-imdn-01

13. Work to Do • Correct Errata • Need to do examples • Example is really schema • Security & Privacy From Notification-To Present • Forgot to specify report type (over deletion from IMDN-00) draft-burger-simple-imdn-01

14. Other Slides Not for Presentation, Unless Needed draft-burger-simple-imdn-01

15. Details: IMDN vs. im-report • Explanation (and use case) for globally unique Message-ID • Remove Failure Report Request: Only Meaningful Report Request is “read” • No confusion between REPORT and IMDN • Content-Disposition • IMDN’s Can Have Message-ID’s • Never get 485, so no similar mechanism; do have other states, though (processed, expanded, denied) • IMDN Provides Privacy Considerations • B2BUA Disposition States: adds “processed”, “expanded”, “denied” • End-to-End Integrity of Reports • Reports Get Nested, so S/MIME Can Work • NO MULTIPLE REPORTS FOR SINGLE TRANSACTION draft-burger-simple-imdn-01

16. List Expansion in im-report • Can’t work as specified • Recipient-uri needs to explicitly be end target URI • Some might be <read>, others might be something else • No possibility for end-to-end integrity; all from B2BUA draft-burger-simple-imdn-01