Subject: Re: [Simple] IMDN issue #10: More than one IMDN for an IM

From: Aki Niemi <[email-masked]>
Date: Thu, 02 Feb 2006 12:51:41 +0200

ext Burger, Eric wrote:
> I'll buy the argument, if we said that every IM generates an IMDN.
> Given the scenarios Hisham and Aki have posted, the sender has no way of
> knowing whether or not there are intermediaries.  This is why every IM
> must request an IMDN, unless the sender does not care.

RFC3428 states that receipt of a 202 (as opposed to 200) tells the
sender that there is (possibly) an intermediary in the picture. It's a
different question as to how useful that indication is, but at least
there is one.

> This issue also says that SIP was the wrong choice for IM transport.
> We're hacking hacks on hacks to implement transport layer features.

I'm not sure I understand where you draw that conclusion. But as long as
we're making conclusions about transports, I think UDP was the wrong
choice for SIP IM. ;)

> Yes, it will work to use IMDN for what in the normal SIP world would be
> a final response.  Does this pass muster with the Internet architecture,
> however?

SIP MESSAGE is hop-by-hop in this case, same as with email. IM does
allow this concept of an IM inbox that is in the network, so there is
always a possibility that a message is not delivered to the agent that
ends up consuming it immediately after being received by this IM inbox.

Cheers,
Aki

> -----Original Message-----
> From: Hisham Khartabil [mailto:[email-masked]] 
> Sent: Tuesday, January 31, 2006 4:12 AM
> To: Burger, Eric
> Cc: Simple WG
> Subject: Re: [Simple] IMDN issue #10: More than one IMDN for an IM
> 
> I dont understand your point here. what ACK for the message? do you 
> mean 200 ok?
> 
> While 200 ok is transport level delivery, IMDN is user level delivery 
> notification. A GW, for example, can generate a 2xx response before it 
> has been guaranteed that the final recipient has actually received the 
> message.
> 
> Hisham
> 
> On Jan 30, 2006, at 9:35 PM, Burger, Eric wrote:
> 
>> REPORT method tells you the IM was received.
>> ACK of the MESSAGE tells you the IM was received.
>>
>> IMDN is for user-level read, not transport.  This is the distinction
>> between user-level (IMDN, MDN) and transport-level (MESSAGE, ACK, SMTP
>> DSN) reporting.
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf
>> Of Hisham Khartabil
>> Sent: Friday, January 27, 2006 10:19 AM
>> To: Simple WG
>> Subject: [Simple] IMDN issue #10: More than one IMDN for an IM
>>
>> The draft states:
>>
>> "The Reporting UAS MUST NOT send more than one final IMDN in response
>>     to an IMDN request.  That is, once an IMDN has been issued on 
>> behalf
>>     of a recipient, no further IMDNs may be issued on behalf of that
>>     recipient, even if another disposition is performed on the
> message.
>>     For example, if the user reads and then deletes the message, the 
>> UAS
>>     will send a single read notification.  The delete operation in
> this
>>     case will not generate an additional IMDN."
>>
>> I do not agree. I would like to know when the message is delivered,
>> then when the message is read and when whatever future state we come
> up
>> with for an IM happens.
>>
>> Regards,
>> Hisham
>>
>>
>>
>> _______________________________________________
>> 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