Transcript Instant Message Delivery Notification (IMDN) for Presence

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
(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
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
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
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
– 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
7
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
8
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)
4 August 2005
• 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?
draft-burger-simple-imdn-01
9
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
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
•
•
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
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 B2BUA
4 August 2005
draft-burger-simple-imdn-01
16