IMDN issue #9: related to issue #2 keeping state

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: simple-bouncesietf.org [mailto:simple-bouncesietf.org]
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
Simpleietf.org
https:/
/www1.ietf.org/mailman/listinfo/simple

_______________________________________________
Simple mailing list
Simpleietf.org
https:/
/www1.ietf.org/mailman/listinfo/simple

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

On Jan 30, 2006, at 9:37 PM, Burger, Eric wrote:

> 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: simple-bouncesietf.org
[mailto:simple-bouncesietf.org] 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
> Simpleietf.org
> https:/
/www1.ietf.org/mailman/listinfo/simple
>


_______________________________________________
Simple mailing list
Simpleietf.org
https:/
/www1.ietf.org/mailman/listinfo/simple