Subject: [Simple] IM delivery reports for conferencing

From: "Sean Olson" <[email-masked]>
Date: Wed, 15 Mar 2006 10:30:05 -0800

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.

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: Hisham Khartabil <[email-masked]>
Date: Wed, 15 Mar 2006 22:49:19 +0100

> 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

---

From: "Sean Olson" <[email-masked]>
Date: Mon, 20 Mar 2006 13:41:01 -0800

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? 

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

Hisham

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 20 Mar 2006 22:51:47 +0100

> 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

---

From: "Sean Olson" <[email-masked]>
Date: Mon, 20 Mar 2006 13:57:33 -0800

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

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

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