4 August 2005 draft-burger-simple-imdn-01 1

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 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

4 August 2005 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

4 August 2005 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

4 August 2005 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

4 August 2005 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

4 August 2005 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

4 August 2005 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

4 August 2005 draft-burger-simple-imdn-01 9

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?

4 August 2005 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

4 August 2005 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

4 August 2005 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)

4 August 2005 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)

4 August 2005 draft-burger-simple-imdn-01 14

Other Slides

Not for Presentation, Unless Needed

4 August 2005 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

4 August 2005 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