[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Simple] Issue 2: Sender keeps state


On Nov 8, 2005, at 7:20 PM, Ben Campbell wrote:

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.

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.

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.

Hisham


On Nov 8, 2005, at 4:24 AM, Burger, Eric wrote:

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: simple-bounces at ietf.org [mailto:simple-bounces at ietf.org] On Behalf
Of Xiao Wang
Sent: Monday, November 07, 2005 9:26 PM
To: 'Hisham Khartabil'
Cc: simple at ietf.org
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: simple-bounces at ietf.org [mailto:simple-bounces at ietf.org] On

Behalf
Of

Hisham Khartabil
Sent: Tuesday, November 08, 2005 2:57 AM
To: Burger, Eric
Cc: simple at ietf.org
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
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple



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



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

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




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