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

Re: [Simple] Issue 2: Sender keeps state


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


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.


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.

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.

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.




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



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