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

RE: [Simple] Issue 2: Sender keeps state

To: "Hisham Khartabil" <hisham.khartabil at telio.no>, "Ben Campbell" <ben at estacado.net>
Subject: RE: [Simple] Issue 2: Sender keeps state
From: "Burger, Eric" <eburger at brooktrout.com>
Date: Tue, 8 Nov 2005 19:33:08 -0500
Cc: simple at ietf.org
List-archive: <http://www1.ietf.org/pipermail/simple>
List-help: <mailto:simple-request@ietf.org?subject=help>
List-id: SIP for Instant Messaging and Presence Leveraging Extensions <simple.ietf.org>
List-post: <mailto:simple@ietf.org>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=unsubscribe>
Sender: simple-bounces at ietf.org
Thread-index: AcXktC376q2+hl83T3WtPFYtXgi3lwAEO0AA
Thread-topic: [Simple] Issue 2: Sender keeps state

The UAC *ALWAYS* can decide how much state, and what state, to keep.
That is an implementation issue beyond the protocol.

-----Original Message-----
From: Hisham Khartabil [mailto:hisham.khartabil at telio.no] 
Sent: Tuesday, November 08, 2005 5:29 PM
To: Ben Campbell
Cc: simple at ietf.org; Burger, Eric
Subject: Re: [Simple] Issue 2: Sender keeps state


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

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

That's all I'm asking for.

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

Agreed.

Hisham

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

Prev by Date: RE: [Simple] Issue 1: End-to-End encryption
Next by Date: [Simple] Agenda tweaks
Previous by thread: Re: [Simple] Issue 2: Sender keeps state
Next by thread: [Simple] Issue 3: No date/time in IMDN
Index(es):
- Date
- Thread