1. July 2007 (IETF 69)IETF - SIPPING1 Replace Instant Message in SIP draft-ren-sipping-replace-instant-message-00 Da Qi Ren Qian Sun Linyi Tian IETF 69, Chicago

2. July 2007 (IETF 69)IETF - SIPPING2 Requirements A message sender wants to replace an instant message previously sent by itself in the case that the previous message has mistake or needs content update. A message sender wants to recall an instant message previously sent by itself in the case that the previous message is no more useful e.g. the wrong destination.

3. July 2007 (IETF 69)IETF - SIPPING3 Applicability A Instant Message (IM) can be deferred and stored somewhere in the network. –Many young people prefer to use IM, even when their buddies are offline, they still send IM to buddies. –To this kind of deferred IM, similar with Email, it is practical to recall or replace when the IM is stored in the relay. The message receiver UAC cannot received the IM instantly for some reasons such as: –Cell phone powered off or out of the service region. –PC user physically off line. –People in different time-zones are not online at same time.

4. July 2007 (IETF 69)IETF - SIPPING4 Question: Can we simply send another message? – A message recipient may not like to be confused or disturbed by a inutile message even though there is another correct one follow it come after. – He/she wants to simply see a correct or updated one.

5. July 2007 (IETF 69)IETF - SIPPING5 Alice Alice sent Bob a MESSAGE to let him know about a meeting time and place. Shortly after the meeting was rescheduled with a new place and a different time. Alice sent a new MESSAGE to replace the previous one. Example Bob Bob was offline when Alice sent him the first MESSAGE and the replaced MESSAGE. When he come back online he directly read the new MESSAGE. Or if Bob may first read old message, the client may prompt that this old message has been replaced. Bob will not go to the wrong place at a wrong time.

6. July 2007 (IETF 69)IETF - SIPPING6 Usages SIP MESSAGE is more powerful than instant message. In some cases, the sender or recipient may be application services, and these services need replace/recall features. For example: –In SIP VoIP softphone: when a softphone powers on, it may receive some messages orders, old and new, to order it to update software. (or anti-virus code update) –It would be preferable for this softphone to execute the latest SIP MESSAGE order rather than run each MESSAGE order one by one, especially in the case that update info of the previous message is covered by the new message.

7. July 2007 (IETF 69)IETF - SIPPING7 Interworking Consideration In 3GPP and OMA, interworking between existing messaging services has been considered. One of the functionality is relaying and translation of messaging options between the peer messaging services. Replace/recall feature has been supported by SMS, MMS and Email, for interworking purpose, IM needs to be equipped this feature. Converged IP Messaging OMA is developing SIP-based CPM (Converged IP Messaging), current existing different type of messages are tend to be unified into CPM Message. Common features, such as replace/recall and notification of delivery, will be supported by CPM.

8. July 2007 (IETF 69)IETF - SIPPING8 Reference I: SMS 3GPP Technical realization of the Short Message Service (SMS) –TS 23.040 V6.7.0 (2006-03) Defined in MS capabilities –7.1 The MS, when equipped for SMS, should be capable of: notifying the SC when a short message is intended to replace a short message the MS has previously submitted to the same destination address. –9.2.3.9 TP-Protocol-Identifier (TP-PID): Replace Short Message Type code –9.2.3.19 TP-Command-Type (TP-CT) : 00000010Delete previously submitted Short Message

9. July 2007 (IETF 69)IETF - SIPPING9 Reference II : MMS The 3rd Generation Partnership Project (3GPP) –3GPP TS 22.140 V6.7.0 (2005-03) Replacing MM –The MMS shall be able to support a request by a VASP to replace a previously sent MM from the VASP with a second newer MM. Cancellation of MM –The MMS shall be able to support a request by a VASP to delete a MM that had previously been sent from the VASP but not yet delivered to the terminal.

10. July 2007 (IETF 69)IETF - SIPPING10 Reference III: Email It is well known for the replace/recall features in Email, e.g. MS Outlook/Exchange. RFC4021: –2.1.46. Header Field: Supersedes Description: Reference message to be replaced Status: standards-track

11. July 2007 (IETF 69)IETF - SIPPING11 Open Issues Open issue 1: A possible solution to the replace/recall requirements: –Which header field could be possibly effort the function to carry the replace/recall information in SIP MESSAGE? –Or carried in CPIM body? Open issue 2: A precise identification method to locate the previous SIP instant message is one of the key issues. –As we know, the counterpart mechanism in email is Message- ID, then what is the one for MESSAGE?

12. July 2007 (IETF 69)IETF - SIPPING12 Thank You!