Instant Message Delivery Notification IMDN for Presence and

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

IMDN • Transport Notifications Handled by OK (p 2 p) 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 4 August 2005 draft-burger-simple-imdn-01 2

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 August 2005 draft-burger-simple-imdn-01 3

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

B 2 BUA • Often, Recipient is Not Human • Common B 2 BUA 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 4 August 2005 draft-burger-simple-imdn-01 5

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

Harmony • IMDN and im-report Have Similar Flavor • From im-report – XML Data Format – “Absence of Header / Empty Value” Means Explicit Report Suppression – B 2 BUA 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 4 August 2005 draft-burger-simple-imdn-01 7

Open Issue 1: B 2 BUA Reporting • Proposal #1: Punt. Delivery is to B 2 BUA. 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 4 August 2005 draft-burger-simple-imdn-01 8

Open Issue 1 a: 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) 4 August 2005 • Proposal #1: Per-Recipient Reporting – Easy Implementation at UAS, B 2 BUA – Flood Potential at UAC – Security & Privacy Issues • Proposal #2: B 2 BUA Consolidates Reports – B 2 BUA Collects IMDNs from Recipients – How Long to Wait for IMDNs? – What About Late IMDNs? draft-burger-simple-imdn-01 9

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

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

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

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

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

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 • • B 2 BUA 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 4 August 2005 draft-burger-simple-imdn-01 15

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 B 2 BUA 4 August 2005 draft-burger-simple-imdn-01 16