Subject: RE: [Simple] IMDN issue #9: related to issue #2 keeping state

From: "Burger, Eric" <[email-masked]>
Date: Mon, 30 Jan 2006 15:37:30 -0500

The idea is to nip the well-known spam method of generating MDN (IMDN in
our case) as a means to push unwanted information to the human user.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hisham Khartabil
Sent: Friday, January 27, 2006 10:19 AM
To: Simple WG
Subject: [Simple] IMDN issue #9: related to issue #2 keeping state

The draft says:

"It is RECOMMENDED that a Requesting UAC not notify the user if the
    Requesting UAC receives an IMDN that does not correlate to a message
    the Requesting UAC sent."

This is not correct anymore since we agreed that, in Eric's words, "The 
UAC *ALWAYS* can decide how much state, and what state, to keep. That 
is an implementation issue beyond the protocol."

Therefore, we cannot recommend that a UAC not notify the user if there 
is a IMDN it cannot correlate with an IM. Humans are better judges and 
can correlate an IMDN with an IM, even after machine removes state. 
Remember this is for page-mode messaging as well, not just session 
mode.

I believe this also applies to B2BUAs where the draft says:

"If the B2BUA receives an IMDN that does not match an existing
    Message-ID, the B2BUA MUST discard the IMDN."

Regards,
Hisham

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Hisham Khartabil <[email-masked]>
Date: Tue, 31 Jan 2006 09:44:50 +0100

This draft is not the place to try to eliminate SPIM, imo. I have 
presented a scenario earlier where not notifying the user is not 
feasible. I'll paste a portion of that discussion below, but please 
refer to the thread on issue 2 for a complete picture.

>>> 2) I think most applications are going to be impacted worse by the 
>>> bandwidth issue of sending the whole message back in the IMDN than 
>>> they would be by keeping state for short periods. This is also an 
>>> issue when using SIP MESSAGE, due to the low size limits in RFC3428.
>>
>> How does your phone work today with SMS? It does not need any 
>> correlation information between the receipt reports and the messages 
>> in the sent box. Your email client is the same, if there is a match 
>> of the message-id, great. If there is not, the delivery report is 
>> stand alone and it leaves it for the human user to correlate the MDN 
>> and the message.
>
> My SMS client doesn't do receipt requests. But my old phone did. On 
> that one, I just got back something saying that message to X was 
> delivered. I I had more than one messages to X, I could not tell which 
> one. Certainly, it can do that without  keeping state.

That's all I'm asking for.

Hisham