Subject: RE: [Simple] Issue 2: Sender keeps state

From: "Burger, Eric" <[email-masked]>
Date: Tue, 8 Nov 2005 07:24:43 -0500

The only reliable way is to have the message shipped around.  However,
that is a well-known SPAM attack in e-mail, and it would be microseconds
before that attack would occur in IM/IMDN if we left open that
opportunity.

If an instant message is around a line, the Subject (summary) is the
message itself...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Xiao Wang
Sent: Monday, November 07, 2005 9:26 PM
To: 'Hisham Khartabil'
Cc: [email-masked]
Subject: RE: [Simple] Issue 2: Sender keeps state

This is a way. But if user delete items from sent box ,
receiving MDNs  don't have matching any IMs.
Now, inbox and sent box in the mobile phone are not big enough,
So they are often cleaned up.

Xiao

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
Of
> Hisham Khartabil
> Sent: Tuesday, November 08, 2005 2:57 AM
> To: Burger, Eric
> Cc: [email-masked]
> Subject: Re: [Simple] Issue 2: Sender keeps state
> 
> I don't agree that state is needed at the client. SPAM will be solved
> elsewhere. And a UAS does not need to put the actual IM in the MDN.
> Often enough, the URI of the recipient of the IM is, imo, enough for
> the human user to know what this MDN is for. Having said that, we
> should not stop implementations from keeping state if they want to.
> 
> Also, think of having an inbox and and sent box (just like email or
sms
> in your mobile phone). In those cases, the client is, soft of, keeping
> state until the user deletes items from the sent box. Matching of MDNs
> and IMs in this case can be done using message-id-
> 
> Hisham
> 
> On Nov 7, 2005, at 4:24 PM, Burger, Eric wrote:
> 
> > In MDN, the message itself keeps state.  In the e-mail world, there
is
> > no requirement for the UAC to keep the state of messages sent.  When
> > the
> > UAS sends a MDN, it includes the message itself so the user can
figure
> > out what the report is about.
> >
> > This has turned into a major SPAM hole.  Folks send out SPAM
> > masquerading as a MDN.
> >
> > I'd like to close this hole, which is what the draft does.  However,
it
> > imposes the burden of the UAC keeping state of messages it sends.
My
> > logic is that this is a tiny price to pay to close the SPAM hole.
> >
> > OK with everyone?
> >
> > _______________________________________________
> > Simple mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/simple
> >
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple

_______________________________________________
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: Ben Campbell <[email-masked]>
Date: Tue, 8 Nov 2005 10:54:26 -0800

I think the sender should keep the state, for a couple of reasons:

1) IMs are by nature short lived. We are not talking about email  
lifetimes where the MDN could happen months later.
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.

---

From: Hisham Khartabil <[email-masked]>
Date: Tue, 8 Nov 2005 20:18:57 +0100

> lifetimes where the MDN could happen months later.

Keep in mind we are talking about read reports, not just delivery. Sure 
the IM is short lived, but that doesnt mean I have to read it 
immediately.

> 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.

Hisham

---

From: Ben Campbell <[email-masked]>
Date: Tue, 8 Nov 2005 14:18:31 -0800

On Nov 8, 2005, at 11:18 AM, Hisham Khartabil wrote:

> Keep in mind we are talking about read reports, not just delivery.  
> Sure the IM is short lived, but that doesnt mean I have to read it  
> immediately.
>

My point is that if I send you an IM and request a read-report, and  
don't get a report back in a fairly short period of time, I am going  
to give up. If we expect people to wait indefinitely, then I start to  
wonder why we don't just use email.

> 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.

I guess I support saying that the UAC should have the option of not  
keeping state, but it will not be able to provide much info to the  
user if it doesn't. But I don't want to require the UAS to include a  
lot of information in the IMDN to make life easier on a stateless UAC.

---

From: Hisham Khartabil <[email-masked]>
Date: Tue, 8 Nov 2005 23:28:33 +0100

On Nov 8, 2005, at 11:18 PM, Ben Campbell wrote:

>> 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.
>
> 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.

> lot of information in the IMDN to make life easier on a stateless UAC.

Agreed.

Hisham