[Simple] Re: IM delivery reports for conferencing

[Hisham Khartabil <[e-mail]>]

I, for one, want such control. I would like to choose if I want one 
receipt per user whenever each individual reads the IM or I want to 
wait until all recipients have read the IM before I am notified.

Hisham

On Mar 21, 2006, at 3:55 PM, Sean Olson wrote:

> Caring about notifications is one thing .... Caring whether they are
> batched together or not is another. The second should be in the control
> of the server
>
> -----Original Message-----
> From: Burger, Eric [mailto:[e-mail]]
> Sent: Monday, March 20, 2006 5:52 PM
> To: Sean Olson; Hisham Khartabil
> Cc: [e-mail]
> Subject: RE: IM delivery reports for conferencing
>
> 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:[e-mail]]
> Sent: Monday, March 20, 2006 4:58 PM
> To: Hisham Khartabil
> Cc: Burger, Eric; [e-mail]
> 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:[e-mail]]
> Sent: Monday, March 20, 2006 1:52 PM
> To: Sean Olson
> Cc: [e-mail]; [e-mail]
> 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:[e-mail]]
>> Sent: Wednesday, March 15, 2006 1:49 PM
>> To: Sean Olson
>> Cc: [e-mail]; [e-mail]
>> 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="[e-mail]">
>>>                  <type>read</type>
>>>                  <status>200</status>
>>>                  <note lang="en">The message has been read</note>
>>>             </recipient>
>>>             <recipient uri="[e-mail]">
>>>                  <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@[e-mail]
>>>             </original-message-id>
>>>             <reporting-uas uri="im:[e-mail]">
>>>                <original-recipient-uri>
>>>                   im:[e-mail]
>>>                </original-recipient-uri>
>>>                <disposition>read</disposition>
>>>             </reporting-uas>
>>>             <reporting-uas uri="im:[e-mail]">
>>>                <original-recipient-uri>
>>>                   im:[e-mail]
>>>                </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
[e-mail]
https://www1.ietf.org/mailman/listinfo/simple