Subject: RE: [Simple] RE: IM delivery reports for conferencing

From: "Burger, Eric" <[email-masked]>
Date: Fri, 7 Apr 2006 09:14:36 -0400

Client cannot do aggregation, as it has no clue why it is getting
bombarded with dozens of IMDN's for the single message it sent.

That said, I agree, we should not do aggregations in the initial release
of IMDN, but leave it as an exercise for the reader (and future
standardization work) for how a B2BUA could do aggregation.

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Thursday, April 06, 2006 10:53 PM
To: Burger, Eric
Cc: [email-masked]
Subject: Re: [Simple] RE: IM delivery reports for conferencing

It seems like we are going around in circles on this one.

We spent a good bit of time discussing this in the design team  
meeting.  Aggregation creates a huge amount of complexity. You have  
to worry about how long an aggregator is willing to wait to get all  
the possible IMDNs. The amount of time it may take for an IMDN to  
come back is effectively unbounded. What does an aggregator do with  
IMDNs that come back days later? Are we going to require all  
exploders device to statefully aggregate IMDNs? That can create a lot  
of state.

Or, if we follow one of Sean's previous suggestions and allow  
exploders to send multiple batches (which I assume allows for batch  
sizes of 1), then UAC's have to deal with the possibility of  
receiving multiple IMDNs from a single message. That is, clients are  
no simpler to implement than they would be if we did not have  
aggregation at all. In fact, they are more complex because they have  
to deal with parsing the aggregated format.

IMHO, if we include aggregation as an intrinsic part of IMDN, we  
greatly reduce our chance of finishing IMDN in any relevant  
timeframe. My preference is to make aggregation support optional at  
the client. In a separate spec. That does not block completion of the  
rest of IMDN. SIP has perfectly good mechanisms for signaling such  
support.

Bottom line: We should start out with the simplest mechanism that can  
possibly work.

Ben.

On Mar 20, 2006, at 7:52 PM, Burger, Eric wrote:

> I would offer that it MUST be driven by the client - they are the only
> one that knows whether they care.  C.f. the use of notifications for
> MSRP conferencing.
>
> -----Original Message-----
> From: Sean Olson [mailto:[email-masked]]
> Sent: Monday, March 20, 2006 4:58 PM
> To: Hisham Khartabil
> Cc: Burger, Eric; [email-masked]
> Subject: RE: IM delivery reports for conferencing
>
> Well, my opinion obviously is that we do need this capability.  
> However,
> I don't believe the sender should really be in control of this  
> facet of
> delivery notifications. In fact if you build in aggregation support  
> now
> rather than later, than you don't even need to negotiate this. (I
> propose making receiving aggregated DN support at the sender  
> mandatory)
>
> -----Original Message-----
> From: Hisham Khartabil [mailto:[email-masked]]
> Sent: Monday, March 20, 2006 1:52 PM
> To: Sean Olson
> Cc: [email-masked]; [email-masked]
> Subject: Re: IM delivery reports for conferencing
>
>
> On Mar 20, 2006, at 10:41 PM, Sean Olson wrote:
>
>> The URI attribute only works if you structure the rest of the
>> information around it.... Are you suggesting aggregation by multipart
>> MIME or creating a new top-level XML element?
>
> I have suggested neither. I doesn't matter really although the latter
> makes more sense. The question is do we need such feature? and if  
> we do,
> to allow the sender of the IM to choose which mode or reporting s/he
> wanted (aggregated or one by one)? If the answer to the first question
> is yes, then I strongly believe that the answer to the second question
> is also yes.
>
> Hisham
>
>>
>> -----Original Message-----
>> From: Hisham Khartabil [mailto:[email-masked]]
>> Sent: Wednesday, March 15, 2006 1:49 PM
>> To: Sean Olson
>> Cc: [email-masked]; [email-masked]
>> Subject: Re: IM delivery reports for conferencing
>>
>>
>> On Mar 15, 2006, at 7:30 PM, Sean Olson wrote:
>>
>>>
>>> Looking at:
>>> http://tools.ietf.org/wg/simple/draft-khartabil-simple-im-receipts
>>> -00.tx
>>> t
>>> And: http://tools.ietf.org/wg/simple/draft-burger-simple-imdn-03.txt
>>>
>>> Neither seems to address the use case of an "exploder" or IM
>>> conferencing where a single IM may have multiple recipients. My
>>> suggestion is that the schema you choose for the notification allow
>>> multiple delivery notifications to be batched together with each
>>> entry
>>
>>> distringuished by the recipient URI.
>>
>> It does address it to an extent. That's what the "uri" attribute is
>> there for. If we want to allow aggregation of receipts before sending
>> the receipt to the IM sender, then we also need to start thinking
>> about what the sender wants and how to indicate it in the IM itself.
>>
>> Hisham
>>
>>>
>>> For example:
>>>
>>> For Draft-khartabil-simple-im-receipts-00
>>>
>>>          <status-receipt>
>>>             <message-id>34jk324j</message-id>
>>>             <recipient uri="[email-masked]">
>>>                  <type>read</type>
>>>                  <status>200</status>
>>>                  <note lang="en">The message has been read</note>
>>>             </recipient>
>>>             <recipient uri="[email-masked]">
>>>                  <type>error</type>
>>>                  <status>415</status>
>>>                  <note lang="en">The message could not be
>>> delivered</note>
>>>             </recipient>
>>>          </status-receipt>
>>>
>>> Or, for Draft-burger-simple-imdn-03
>>>
>>>         <imdn>
>>>             <original-message-id>
>>>                1542af3e8b@[email-masked]
>>>             </original-message-id>
>>>             <reporting-uas uri="im:[email-masked]">
>>>                <original-recipient-uri>
>>>                   im:[email-masked]
>>>                </original-recipient-uri>
>>>                <disposition>read</disposition>
>>>             </reporting-uas>
>>>             <reporting-uas uri="im:[email-masked]">
>>>                <original-recipient-uri>
>>>                   im:[email-masked]
>>>                </original-recipient-uri>
>>>                <disposition>read</disposition>
>>>             </reporting-uas>
>>>         </imdn>
>>>
>>> Sorry if this has been discussed before. Was there a reason this was
>>> omitted previously?
>>>
>>> Thanks,
>>> Sean
>>>
>>
>
> _______________________________________________
> 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: Fri, 7 Apr 2006 08:48:58 -0500

> bombarded with dozens of IMDN's for the single message it sent.

It does not have to know why. It just has to know it could happen.

> standardization work) for how a B2BUA could do aggregation.

Oh, well, I will quit arguing with you then :-)