Subject: [Sipping] Quick thoughts on draft-ren-sipping-replace-instant-message-01

From: Eric Burger <[email-masked]>
Date: Thu, 26 Jul 2007 12:36:33 -0500

<lemonade-chair-hat ON>

We have looked over and over and over again in the e-mail community at a
Recall Message function.  Everyone asks for it, but no one uses it.

The problem is, Recall Message is, at best, a hint.

For example, in the Microsoft Exchange case, where the vendor has full
control of the server and client, 80% of the text in the referenced web site
is describing why Message Recall does not work.  As an aside, I like to see
what was so important or embarrassing that the sender thought they needed to
recall the message :-)

That is, Recall Message is, at worst, a highlighter for the recipient to
ensure she looks at the message!

As Paul pointed out, the expectations for the length of time a message is
stored before forwarding of an e-mail is much longer than for an Instant
Message.  Remember, most systems combine IM with presence, so the recipient
will statistically see the message way before the sender can recall it.

</lemonade-chair-hat>

I would offer there is microscopic technical value for this extension in the
real world.  However, I would also offer that ignorant marketing folks may
demand such an extension.  By ignorant here I mean they do not realize that
the feature is highly unlikely to work, thus resulting in lots of help desk
time ("Why didn't my message get deleted?") to legal liability ("I recalled
my resignation, but my boss still saw it, you need to pay me for losing my
job!").

I am thus ambivalent.  However, if this does go forward, I would STRONGLY
suggest that we get input from the messaging community.

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

_______________________________________________
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, 27 Jul 2007 02:14:57 +0800

Thanks for your input! Responses inline!

BR,
Linyi

-----Original Message-----
>From: Eric Burger [mailto:[email-masked]] 
>Sent: Friday, July 27, 2007 1:37 AM
>To: [email-masked]; sunqian 32328; [email-masked]
>Cc: [email-masked]'
>Subject: Quick thoughts on draft-ren-sipping-replace-instant-message-01

>Recall Message function.  Everyone asks for it, but no one uses it.
[Linyi] I saw two recall messages yesterday from 3GPP and OMA mailing list.
I guess I am too lucky in Chicago. 

>The problem is, Recall Message is, at best, a hint.
[Linyi] Sometimes it is, but not always. Consider the SMS replace/recall
case, it is not a hint. 

>what was so important or embarrassing that the sender thought they needed
to
[Linyi] I have already given some use cases for different needs on replace
and recall. Rarely use doesn't mean it is not important for people. If a guy
accidentally sent confidential company report to public mail list, I guess
the only think he wants to do is RECALL! I saw this happens last year in a
SDO. I guess that guy really wanted to use RECALL even he think that
function is useless forever.

>ensure she looks at the message!
[Linyi] Consider the replace use case "replace an important notice for a
meeting arrangement" I given before it is the intention to highlight
something. So there are different faces for replace and recall.

>will statistically see the message way before the sender can recall it.
[Linyi] It's no problem for them to see in some cases. Replace indication
could be forwarded to UAC for important notice. So replace/recall can happen
in UAS or UAC depends on the place where the message is.

>suggest that we get input from the messaging community.
[Linyi] Sure. There are already some work in messaging community considering
this as an interworking function for SMS,MMS,Email with SIP based Messaging
service.

---

From: Eric Burger <[email-masked]>
Date: Thu, 26 Jul 2007 13:44:35 -0500

> function is useless forever.

Precisely my point: Person recalls the confidential report.  I, working for
a competitor, deny the recall.  I have the report.

Or, I receive the report, forward it to my boss, I get the recall notice, I
don't care.

Or, since this is proposed as standard, I have a standard client NOT
delivered from SecurelyRecallsMessagesCo, but a client from
LetsMeDecideToKeepMessagesCo.

In all of the scenarios, the person issuing the recall on the confidential
company report is rather upset their message was not recalled.

SAME FOR SMS, by the way.

---

From: Linyi Tian <[email-masked]>
Date: Fri, 27 Jul 2007 02:58:14 +0800

Yes. Recall is some kind of BEST TRY for that manic and poor guy. However at
least he wants to try for small hope. From interworking perspective we need
it, too. Just like the life buoy on the plane or boat or 911 emergency call,
it is the hope, no guarantee it will save people's life always. Do you
agree?
How about replace? 

BR,
Linyi

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: Friday, July 27, 2007 2:45 AM
To: Linyi Tian; [email-masked]; 'sunqian 32328'
Cc: [email-masked]
Subject: Re: Quick thoughts on draft-ren-sipping-replace-instant-message-01

Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual or
entity named in this message. If you are not the intended recipient, and
have received this message in error, please immediately return this by email
and then delete it.

---

From: Adam Roach <[email-masked]>
Date: Thu, 26 Jul 2007 14:31:54 -0500

> a competitor, deny the recall.  I have the report.

Returning to the example: More likely, the confidential report arrives, 
I discard it as spam (who is this sending me an unsolicited, potentially 
virus-laden word document?), then get a recall notice and think "Wow. 
That must have been something important. Perhaps I should dig it out of 
my trash and see why someone wouldn't want me to see it..."

At least, that's been the only use _I've_ ever seen for the proprietary 
mail-recall extension mechanisms currently deployed.

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 26 Jul 2007 14:38:28 -0500

Roach, Adam would like to recall the message, "Re:
[Sipping] Re: Quick thoughts on
draft-ren-sipping-replace-instant-message-01"

---

From: DaQiRen 65275 <[email-masked]>
Date: Thu, 26 Jul 2007 15:44:41 -0400

[Da Qi] In the slides we told that it would be practical when the message is deffered and saved in the relay on network side. As of the case the IM has already been received in the user's instant box, it will depend on the user security profile and the user's decision. In that case, may possible options cite 
http://office.microsoft.com/en-us/outlook/HA010917601033.aspx

----- Original Message -----
From: Adam Roach <[email-masked]>
Date: Thursday, July 26, 2007 3:31 pm
Subject: Re: [Sipping] Re: Quick thoughts	on draft-ren-sipping-replace-instant-message-01

> >> SDO. I guess that guy really wanted to use RECALL even he think 
> that>> function is useless forever.
> >>     
> >

---

From: Adam Roach <[email-masked]>
Date: Thu, 26 Jul 2007 14:55:03 -0500

> http://office.microsoft.com/en-us/outlook/HA010917601033.aspx

Thank you! That's a *PERFECT* example of what's wrong with your 
proposal. Granted, if you are using Microsoft®-brand proprietary email 
protocol-based systems within a single domain, it works just fine. If 
you're using any other email system, even if you retract the message 
before I come back online, I'll still see your message, followed by a 
retraction that looks a whole heck of a lot like the one I just sent to 
the SIPPING list.

The Outlook message recall mechanism is the most powerful argument 
_against_ trying to specify a message recall mechanism in the IETF. It's 
*demonstrably* broken once messages leave a walled garden. And we don't 
do walled gardens here; we do the Internet here.

/a

---

From: Sean Olson <[email-masked]>
Date: Thu, 26 Jul 2007 13:11:07 -0700

Just to be clear, the issue is not whether you use a "standard" protocol or not. The issue is one of broad, cross-platform, industry adoption.  If the majority of IM implementations don't support recall, then this won't be a useful feature. I personally think IM recall is a horrible idea because it takes an already broken concept (e-mail recall) and makes it worse by trying to apply it to a real-time domain (IM) instead of an inherently store-and-forward architecture like e-mail.

You can't fix the inherent adoption issue just by standardizing a protocol. Nor can the protocol ensure compliance. Give up on this while you still have hairs to pull out ;-)

-----Original Message-----
From: Adam Roach [mailto:[email-masked]]
Sent: Thursday, July 26, 2007 12:55 PM
To: DaQiRen 65275
Cc: [email-masked]
Subject: Re: [Sipping] Re: Quick thoughts on draft-ren-sipping-replace-instant-message-01

proposal. Granted, if you are using Microsoft(r)-brand proprietary email

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jul 2007 16:36:13 -0400

I can see how this might be useful in a limited way - as a means of 
specifying message threading, so that the original message and the "Oh, 
I didn't mean that" are displayed together, rather than separated by 
lots of other messages.

	Paul

Adam Roach wrote:
>> [Da Qi] In the slides we told that it would be practical when the 
>> message is deffered and saved in the relay on network side. As of the 
>> case the IM has already been received in the user's instant box, it 
>> will depend on the user security profile and the user's decision. In 
>> that case, may possible options cite

---

From: DaQiRen 65275 <[email-masked]>
Date: Fri, 27 Jul 2007 01:33:21 -0400

Microsoft can do this just fine in there own domain is a proof for this technique work well. It is nothing about bullshit to talk about walled garden... Crossing domain belongs to the IM interworking issues (OMA CPM). 200 years ago you cannot send a regular international letter because of the country borders, that doesn't mean peoples cannot work on it at that time.

The work is to provide a replace/recall functionality to SIP MESSAGE. We don't see anything not meaningful in doing so....

----- Original Message -----
From: Adam Roach <[email-masked]>
Date: Thursday, July 26, 2007 3:55 pm
Subject: Re: [Sipping] Re: Quick thoughts	on draft-ren-sipping-replace-instant-message-01

> > [Da Qi] In the slides we told that it would be practical when 
> the message is deffered and saved in the relay on network side. As 
> of the case the IM has already been received in the user's instant 
> box, it will depend on the user security profile and the user's 
> decision. In that case, may possible options cite

---

From: "Linyi Tian" <[email-masked]>
Date: Fri, 27 Jul 2007 15:30:09 +0800

Thank you! Please don't use 'bad' implementation to complain standard work.
If you produce bad implementation to SIP, could you say that your product is
the great argument that SIP is useless?

Please keep in mind that this work is try to solve the interworking issue
identified by the other SDOs. Replace/Recall is introduced in several
existing services/standards, not by us. We know that this feature it not
necessary for you, but it does not mean it is not necessary for everybody.
Just like life buoy/emergency call case.

I understand the concern that SIPPING does not want to introduce a protocol
to do this. We still need to collect more evidence that this feature is
useful for some operators/service providers and try to avoid protocol change
to SIP. 

We will think about the use case Paul mentioned.

BR,
Linyi

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Friday, July 27, 2007 3:55 AM
To: DaQiRen 65275
Cc: [email-masked]
Subject: Re: [Sipping] Re: Quick thoughts
ondraft-ren-sipping-replace-instant-message-01

On 7/26/07 2:44 PM, DaQiRen 65275 wrote:
> [Da Qi] In the slides we told that it would be practical when the message
is deffered and saved in the relay on network side. As of the case the IM
has already been received in the user's instant box, it will depend on the
user security profile and the user's decision. In that case, may possible
options cite 

proposal. Granted, if you are using MicrosoftR-brand proprietary email 

/a

---

From: sunqian 32328 <[email-masked]>
Date: Fri, 27 Jul 2007 20:23:31 +0800

Hi, Sean and Adam 

Thanks for your thoughts.

The truth is that majority of IM implementations are "walled gardens". Very few companys have monopolized the IM industry, this is different from email products.

In addition, maybe replace/recall function can work better with IMDN(Instant Message Disposition Notification).

Best Regards,
Qian Sun

----- Original Message -----
From: Sean Olson <[email-masked]>
Date: Friday, July 27, 2007 4:11 am
Subject: RE: [Sipping] Re: Quick	thoughts	on draft-ren-sipping-replace-instant-message-01

> Just to be clear, the issue is not whether you use a "standard" 
> protocol or not. The issue is one of broad, cross-platform, 
> industry adoption.  If the majority of IM implementations don't 
> support recall, then this won't be a useful feature. I personally 
> think IM recall is a horrible idea because it takes an already 
> broken concept (e-mail recall) and makes it worse by trying to 
> apply it to a real-time domain (IM) instead of an inherently store-
> and-forward architecture like e-mail.
> 
> You can't fix the inherent adoption issue just by standardizing a 
> protocol. Nor can the protocol ensure compliance. Give up on this 
> while you still have hairs to pull out ;-)
> 
> 
> 
> proposal. Granted, if you are using Microsoft(r)-brand proprietary 
> emailprotocol-based systems within a single domain, it works just 
> fine. If
> *demonstrably* broken once messages leave a walled garden. And we 
> don'tdo walled gardens here; we do the Internet here.
> 
> /a
> 
>

---

From: [email-masked]
Date: Fri, 27 Jul 2007 23:45:25 -0400

I still have doubts about the *meaning* of a "recall" or "replace"
operation in IM.  While I can see the difficulty implementing of a
recall operation in e-mail, I can understand what the operation is
intended to do.  But in IM, I expect the message to be delivered to
the destination user in less than 1 second, which makes it very
difficult to recall the message before it is displayed to the
destination user.  (E.g., I expect that the 200 response to the
MESSAGE request means that the message has been displayed to the
user.)

In a sense, it seems to me that even if we define a *mechanism* for
recall, the realities of the usage scenario are such that it will
still be impossible to satisfy the stated requirement:

      REQ-1: It MUST be possible for a user to replace or recall a
      previous instant message with a new instant message.

I am wondering if the usage you are considering is one where messages
are stored or cached for some time before they are delivered.  This
seems to be the case in the examples you cite:  "The similar
requirement has been realized in many messaging services (e.g., Email,
SMS and MMS)." (none of which are IM systems).

Or perhaps you should describe the usage scenario as "page-mode
store-and-forward messaging systems".

If so, it would improve the discussion if you specified this.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 29 Jul 2007 22:11:19 -0400

Dale,

Based on prior messages in this thread I think the primary case they 
have in mind is when the message is stored somewhere before being 
delivered. At least one case is when there is a gateway to SMS. Also, I 
think the submitters are involved in IMS, so it could be an IMS 
store-forward IM server.

That makes the case much more like email.

Also, I can see how even if the earlier message was delivered in 
realtime, the UI could correlate the recall/replace and annotate the 
recalled/replaced message to indicate the situation. (However I would 
hope they would not just reach back into the message log and replace the 
message - changing history - without any traceability.

	Paul

---

From: Linyi Tian <[email-masked]>
Date: Mon, 30 Jul 2007 15:58:52 +0800

Dear Paul and Dale

You are right. Three points:
1. It is for interworking purpose. There should be a gateway between IM
system and Legacy Systems(sms, mms, email, etc.)
2. Recall is intended for page-mode store-forward IM (In OMA we call it
deffered IM).
3. Replace could be intended to both page-mode and real-time delivery. 
Paul is right that replace/recall could be a correlation for UI to annotate
the recalled/replaced message to indicate the situation.

I guess we need to update the 01 draft to avoid any confusion and continue
the discussion. Your suggestions are really helpful and we appreciate that. 

BR,
Linyi

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Monday, July 30, 2007 10:11 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sipping] Re: Quick thoughts

Dale,

	Paul

---

From: David R Oran <[email-masked]>
Date: Mon, 30 Jul 2007 16:34:49 -0400

On Jul 29, 2007, at 10:11 PM, Paul Kyzivat wrote:

> Dale,
>
> Based on prior messages in this thread I think the primary case  
> they have in mind is when the message is stored somewhere before  
> being delivered. At least one case is when there is a gateway to  
> SMS. Also, I think the submitters are involved in IMS, so it could  
> be an IMS store-forward IM server.
>
Darn, why settle for "recall message" when we could go for "recall  
missiles". :-)

> That makes the case much more like email.
I'm not sure that whether there is a store-and forward system  
underneath or not has much if any effect on the semantics. One could  
imagine a TCP operation that asks to not deliver a previously- 
transmitted segment just as easily. The sender has no control over  
whether a message he tossed into the delivery layer is still around  
or gone. Giving the UI layer an "oops" capability that has no clean  
delivery layer implementation is probably not in the sending user's  
interests anyway.

> realtime, the UI could correlate the recall/replace and annotate  
> the recalled/replaced message to indicate the situation. (However I  
> would hope they would not just reach back into the message log and  
> replace the message - changing history - without any traceability.
>
I agree with this, since you can't do it deterministically, or even  
tell deterministically whether it worked or not. And we haven't even  
started to talk about what the semantics would be if there were  
multiple recipients via an exploder.

I could envision one service that might be useful though and would in  
fact be realizable since it would work mostly at the UI layer.

Assuming the underlying service has a threading capability that  
works, and a robust way to identify messages uniquely over space and  
time with a message ID, I see no harm in allowing one message to  
refer to an earlier message as "obsoleted" by the message being sent.  
The receiving UI could do one of a number of things with this  
information:
- replace the rendered output of the earlier message, including a  
visual indication that an "obsoleted" message was sent earlier
- remove the earlier message or grey it out if the "obsoleting"  
message was empty
- mark the relationship in the threading order in some other,  
possibly clever way.

There is a subtle semantic difference between "obsoleting" a message  
and "recalling" or "replacing" a message. We can get most of we want  
IMO from something like that without the pitfalls of making the  
message history non-monotonic.

Note that if there are multiple recipients we still do not have  
either reliable partial or total order, but that would require much  
deeper surgery than any of what this thread discusses.

DaveO.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Jul 2007 17:14:53 -0400

David R Oran wrote:
>> delivered. At least one case is when there is a gateway to SMS. Also, 
>> I think the submitters are involved in IMS, so it could be an IMS 
>> store-forward IM server.
>>

Or perhaps "replace the missle filled with nukes with one filled with 
lollipops and cash". :-)

> I'm not sure that whether there is a store-and forward system underneath 
> or not has much if any effect on the semantics. One could imagine a TCP 
> operation that asks to not deliver a previously-transmitted segment just 
> as easily. The sender has no control over whether a message he tossed 
> into the delivery layer is still around or gone. Giving the UI layer an 
> "oops" capability that has no clean delivery layer implementation is 
> probably not in the sending user's interests anyway.
> 
>> hope they would not just reach back into the message log and replace 
>> the message - changing history - without any traceability.
>>
> I agree with this, since you can't do it deterministically, or even tell 
> deterministically whether it worked or not. And we haven't even started 
> to talk about what the semantics would be if there were multiple 
> recipients via an exploder.
> 
> Assuming the underlying service has a threading capability that works, 
> and a robust way to identify messages uniquely over space and time with 
> a message ID, I see no harm in allowing one message to refer to an 
> earlier message as "obsoleted" by the message being sent.

This is what I had in mind, but using their terminology.

I agree that this seems harmless and perhaps helpful in some cases.

> The receiving 
> UI could do one of a number of things with this information:
> - replace the rendered output of the earlier message, including a visual 
> indication that an "obsoleted" message was sent earlier

And hopefully access to the obsoleted message as well.
It will be available in some cases and times. In the interest of 
consistent treatment of all it should be equally available to all.

> - remove the earlier message or grey it out if the "obsoleting" message 
> was empty
> - mark the relationship in the threading order in some other, possibly 
> clever way.
> 
> There is a subtle semantic difference between "obsoleting" a message and 
> "recalling" or "replacing" a message. We can get most of we want IMO 
> from something like that without the pitfalls of making the message 
> history non-monotonic.
> 
> Note that if there are multiple recipients we still do not have either 
> reliable partial or total order, but that would require much deeper 
> surgery than any of what this thread discusses.
> 
> DaveO.
> 
>>     Paul
>>

---

From: Linyi Tian <[email-masked]>
Date: Tue, 31 Jul 2007 11:00:58 +0800

>>Or perhaps "replace the missle filled with nukes with one filled with 

[Linyi] I guess this feature may have already been considered by 'U.S. missile shield plans'. Otherwise it must be dangerous to the world if US issues missile by mistake without 'recall' control.

>>I agree that this seems harmless and perhaps helpful in some cases.

[Linyi] This is exactly what we intended for 'Replace' which you call it 'obsolete'. That's why during the meeting I said that we discussed the issues for 'Recall' but not discussed the potential usage of 'Replace/Obsolete'. We will add clarification to this feature in next version. If you guys can give us some suggestions that will be great and we appreciate that.

>>consistent treatment of all it should be equally available to all.

[Linyi] I also explained this before. This is why I said that obsoleted message is not hidden to recipient in Replace case. 

Thank you very much for helping us to explain the intention and continue the discussion!

BR,
Linyi