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

2. 4 August 2005draft-burger-simple-imdn-012 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

3. 4 August 2005draft-burger-simple-imdn-013 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

4. 4 August 2005draft-burger-simple-imdn-014 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

5. 4 August 2005draft-burger-simple-imdn-015 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

6. 4 August 2005draft-burger-simple-imdn-016 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

7. 4 August 2005draft-burger-simple-imdn-017 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

8. 4 August 2005draft-burger-simple-imdn-018 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

9. 4 August 2005draft-burger-simple-imdn-019 Open Issue 1a: Consolidated Reporting 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?

10. 4 August 2005draft-burger-simple-imdn-0110 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

11. 4 August 2005draft-burger-simple-imdn-0111 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

12. 4 August 2005draft-burger-simple-imdn-0112 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)

13. 4 August 2005draft-burger-simple-imdn-0113 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)

14. 4 August 2005draft-burger-simple-imdn-0114 Other Slides Not for Presentation, Unless Needed

15. 4 August 2005draft-burger-simple-imdn-0115 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

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