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

From: "Burger, Eric" <[email-masked]>
Date: Mon, 20 Mar 2006 20:52:14 -0500

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

---

From: Dean Willis <[email-masked]>
Date: Thu, 6 Apr 2006 18:26:28 -0500

I'll further note that there are some bright young lads in OMA who  
want to use IMDN as a billing mechanism. If you send an IMDN, the  
sender gets billed for sending you the message, and if you don't, the  
billing system will presume the message was lost in transit and  
presumably not bill. This would appear to make IMDN both mandatory  
and something that couldn't be driven from a UA.

I maintain IMDN is a bad idea. It gives people bad ideas.

--
Dean

---

From: "Sean Olson" <[email-masked]>
Date: Thu, 6 Apr 2006 16:32:19 -0700

There are people who proposed billing based on the ACK as well .... Is
ACK a bad idea?

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Thursday, April 06, 2006 4:26 PM
To: Burger, Eric
Cc: Sean Olson; Hisham Khartabil; [email-masked]
Subject: Re: [Simple] RE: IM delivery reports for conferencing

I'll further note that there are some bright young lads in OMA who want
to use IMDN as a billing mechanism. If you send an IMDN, the sender gets
billed for sending you the message, and if you don't, the billing system
will presume the message was lost in transit and presumably not bill.
This would appear to make IMDN both mandatory and something that
couldn't be driven from a UA.

--
Dean

> 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 

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

---

From: Ben Campbell <[email-masked]>
Date: Thu, 6 Apr 2006 21:13:56 -0500

On Apr 6, 2006, at 6:26 PM, Dean Willis wrote:

> sender gets billed for sending you the message, and if you don't,  
> the billing system will presume the message was lost in transit and  

Babies and bathwater.

I suspect there are very few protocol mechanisms that no-one has  
tried to abuse. As long as we don't try to accept these "abuse cases"  
as requirements, we should be fine. In the case of your particular  
example, one of our working IMDN requirements is that the receiving  
endpoint must not send an IMDN unless its user approves. That makes  
it pretty useless for billing.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 6 Apr 2006 21:52:59 -0500

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.

---

From: "Sean Olson" <[email-masked]>
Date: Thu, 6 Apr 2006 22:32:12 -0700

Aggregation is not trivial, I would agree. In fact, I would argue that solving the trivial 2-party problem is not solving any problem at all. I see almost zero value in IMDN for simple 2-party conversations -- can you demonstrate otherwise? I'm willing to put some effort in to define how aggregation works. Do you think it is intractable to solve in 3-6 months?

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]]
Sent: Thu 4/6/2006 7:52 PM
To: Burger, Eric
Cc: Sean Olson; Hisham Khartabil; [email-masked]
Subject: Re: [Simple] RE: IM delivery reports for conferencing

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 7 Apr 2006 08:47:46 -0500

On Apr 7, 2006, at 12:32 AM, Sean Olson wrote:

> Aggregation is not trivial, I would agree. In fact, I would argue  
> that solving the trivial 2-party problem is not solving any problem  
> at all. I see almost zero value in IMDN for simple 2-party  
> conversations -- can you demonstrate otherwise? I'm willing to put  
> some effort in to define how aggregation works. Do you think it is  
> intractable to solve in 3-6 months?
>
>
I do have use cases for 2 party, the most compelling of which are  
store-and-forward intermediaries. But I am not arguing that we limit  
ourselves to the 2 party case.

What I don't want to solve right now (read: don't want to block the  
rest of IMDN on solving it) is IMDN aggregation at an intermediary. I  
am more than happy to say that the UAC must be prepared to receive  
multiple IMDNs for a single message. Then we can add intermediary  
aggregation in as an extension, to which a client would have to  
indicate support.

As far as "solving in 3-6 months", I offer up the example of how hard  
it was to agree on the REPORT mechanism in  MSRP. It is not that it  
is hard to come up with a solution that works so much as it is hard  
to come up with a solution that everyone agrees on. It is possible  
that I am just still traumatized over MSRP :-)

---

From: "Sean Olson" <[email-masked]>
Date: Fri, 7 Apr 2006 07:31:10 -0700

This works for me (not standardizing how the intermediary aggregates for
now) provided we can define the XML schema in such a way that it is
straightforward to extend it to the aggregation scenario.

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Friday, April 07, 2006 6:48 AM
To: Sean Olson
Cc: Burger, Eric; Hisham Khartabil; [email-masked]
Subject: Re: [Simple] RE: IM delivery reports for conferencing

On Apr 7, 2006, at 12:32 AM, Sean Olson wrote:

> Aggregation is not trivial, I would agree. In fact, I would argue that

> solving the trivial 2-party problem is not solving any problem at all.

> I see almost zero value in IMDN for simple 2-party conversations -- 
> can you demonstrate otherwise? I'm willing to put some effort in to 
> define how aggregation works. Do you think it is intractable to solve 
> in 3-6 months?
>
>

What I don't want to solve right now (read: don't want to block the rest
of IMDN on solving it) is IMDN aggregation at an intermediary. I am more
than happy to say that the UAC must be prepared to receive multiple
IMDNs for a single message. Then we can add intermediary aggregation in
as an extension, to which a client would have to indicate support.

As far as "solving in 3-6 months", I offer up the example of how hard it
was to agree on the REPORT mechanism in  MSRP. It is not that it is hard
to come up with a solution that works so much as it is hard to come up
with a solution that everyone agrees on. It is possible that I am just
still traumatized over MSRP :-)

---

From: Ben Campbell <[email-masked]>
Date: Fri, 7 Apr 2006 09:33:37 -0500

> straightforward to extend it to the aggregation scenario.

That seems reasonable to me.

>> that
> rest