Subject: [Sipping] Re: I-D ACTION:draft-ren-sipping-replace-instant-message-00.txt

From: Paul Kyzivat <[email-masked]>
Date: Thu, 28 Jun 2007 16:22:59 -0400

This seems to just introduce a requirement for a capability, since the 
sections containing a solution are empty.

I'd like to explore the requirement itself further.

What is the expected action on the part of the recipient when it 
receives such a request?

- if the replaced message has not yet been displayed, do you
   want it *not* to be displayed?

- if the replaced message has already been displayed, do you
   want it to be removed from the display?

- if the replaced message has been logged, do you want it expunged
   from the log?

- clearly this will be a voluntary action on the part of the
   recipient. Do you expect that it will be in the best interest
   of the recipient to do the replacement as requested?

In practice I'm not convinced that the sender and the receiver have the 
same interest here, and so I don't really believe that there will be 
implementations that do anything helpful to the sender. Something that 
is more likely to be successful is to simply send another message that 
apologizes for the earlier message.

Also, this draft only addresses IM via MESSAGE. What about MSRP?

	Paul

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
> 	Title		: Replace Instant Message in the Session Initiation Protocol (SIP)
> 	Author(s)	: D. Ren, et al.
> 	Filename	: draft-ren-sipping-replace-instant-message-00.txt
> 	Pages		: 15
> 	Date		: 2007-6-28
> 	
>    This document specifies a mechanism that allows a SIP User Agent
>    Client (UAC) to replace or recall a previously sent instant message.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ren-sipping-replace-instant-message-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in the body of 
> the message. 
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then 
> "get draft-ren-sipping-replace-instant-message-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ren-sipping-replace-instant-message-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Linyi Tian <[email-masked]>
Date: Fri, 29 Jun 2007 15:26:34 +0800

Dear Paul

Thank you for your comments. My responses inline!

Best Regards,
Linyi

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, June 29, 2007 4:23 AM
To: [email-masked]
Cc: sipping
Subject: [Sipping] Re: I-DACTION:draft-ren-sipping-replace-instant-message-00.txt

What is the expected action on the part of the recipient when it 
receives such a request?
[linyi] It's up to recipient to decide how to make the final decision. Normally recipient may set some local policy or preference for replace/recall request.  

- if the replaced message has not yet been displayed, do you
   want it *not* to be displayed?
【linyi】Do you mean "read"? In some cases senders do not want replaced message to be read. For example the sender sent a wrong message. In this case the sender really wants the message to be removed on recipient side. In some other cases sender may accept the replaced message to be read. For example Alice sends a message to Bob to ask him to come to her office to discuss something. After that she changes her mind that she will go to Bob's office instead and sends another message to replace the previous one. In this case Bob may be allowed to read both messages. Do we need to distinguish two cases and deal with them differently?

- if the replaced message has already been displayed, do you
   want it to be removed from the display?
[linyi] No matter read/displayed or not, this depends on the local policy or preference on recipient side. This draft doesn't intend to standardize the action on the part of the recipient. But we can give some recommendation, e.g., in above example, if the new message and the old message are both unread in the Bob's message box, when the old message is displayed first, Bob's client can prompt this old message has been replaced with the new message, this can prevent Bob from going to Alice's office immediately when he only see the old message. On the other hand, when a new message is being displayed after the old message has been read, the client may also prompt this new message has replaced/recalled the old message, and displays the new message and the old message on the same screen.

- if the replaced message has been logged, do you want it expunged
   from the log?
[linyi] I guess this is not related to this draft. Generally replace/recall happens to two messages sent in short time.  

- clearly this will be a voluntary action on the part of the
   recipient. Do you expect that it will be in the best interest
   of the recipient to do the replacement as requested?
[linyi] It could be possible to replace old/wrong message to avoid boring recipient. 
In addition, the recipient or sender may be application service, MESSAGE has very broad use.

[linyi] One motivation for this draft is for interworking with some other message services, such as email, sms and mms. They have already supported recall/replace mechanism. OMA and 3GPP have already raised some requirements for interworking between EMAIL/SMS/MMS and SIP MESSAGE.

Also, this draft only addresses IM via MESSAGE. What about MSRP?
[linyi] Not at this moment. Do you have any idea on this?

	Paul

---

From: Qian Sun <[email-masked]>
Date: Fri, 29 Jun 2007 16:38:48 +0800

Hello, Paul

Maybe your some questions could be answered by this web page:
http://office.microsoft.com/en-us/outlook/HA010917601033.aspx?pid=CH062556091033

Cheers,
Qian

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, June 29, 2007 4:23 AM
To: [email-masked]
Cc: sipping
Subject: [Sipping] Re: I-DACTION:draft-ren-sipping-replace-instant-message-00.txt

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 29 Jun 2007 09:41:25 -0400

Thanks. The reference is of course about email processing. I see the key 
difference is that email is store-forward. There is typically a lag 
between when the message is sent and when it is read. This is sometimes 
true for IM, but the likelihood of a message not having been read before 
the recall attempt is much less.

It also assumes that the recipient desires to cooperate with the sender. 
In that regard it is similar to the receipt notifications. Those have 
very spotty success. I've noticed even on these mailing lists that mail 
from some enterprises always carries such a request - apparently it is 
policy for them. But my policy is to require manual confirmation before 
sending a receipt, and I very rarely do - only to people I know and trust.

I expect similar things for message recall. I have occasionally received 
a message saying that somebody would like to recall a message. That was 
perhaps the rendition of the Outlook request you have referenced, when 
rendered by a non-Outlook mail reader. When I get those requests they 
never prevent me from seeing the original message. AFAIK my current mail 
reader has no support for that feature, but if it did I would probably 
turn it off.

So I guess the utility of the feature depends on the policies of the 
users, and also that there be some store/forward delay. For me, this 
isn't worth the bother, but if there is a community of people who think 
it is useful and can get the work done then that is fine.

	Thanks,
	Paul

---

From: tianlinyi 34932 <[email-masked]>
Date: Fri, 29 Jun 2007 22:34:14 +0800

Dear Paul

You are right. Email is always store-forward. That't why we limited the scope to address the page mode MESSAGE scenario. 

This draft intends to address at least two requirement for different use cases:
1. Replace: It does not depend on whether the message has been read. The old message can always be allowed to read if not forbidden by policy.
Use Case: Alice sent a MESSAGE to Bob about the meeting schedule while Bob is not in the office. Later the room is changed, Alice sends a new MESSAGE to bob to replace previous message. When Bob comes back he may first read old messages first. Then the client may display a notification that this message is replaced. 

2. Recall: I guess even in recall case that receipient may still be able to view the old message depends on the implementation. Just like REFER mechanism it should be a recommendation for recipient to remove the old message. Sure it based on receipient's cooperation. 

Considering the interworking between {email, sms, mms} and MESSAGE we may need to introduce similar mechanism. For example Alice send sms to Bob and at Bob side it was converted as MESSAGE. If Alice send a sms to replace/recall previous sms, there should also have a similar MESSAGE request to Bob. 

Best Regards,
Linyi

------------------------------------------

> > http://office.microsoft.com/en-
> us/outlook/HA010917601033.aspx?pid=CH062556091033> 
> > Cheers,
> > Qian
> > 
> >>    Client (UAC) to replace or recall a previously sent instant 
> message.>>
> >>
> >> 	a MIME-compliant mail reader.  Different MIME-compliant mail 
> readers>> 	exhibit different behavior, especially when dealing with