[Simple] RE: IM delivery reports for conferencing
"Burger, Eric" <EBurger@cantata.com> Tue, 21 March 2006 16:37 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjri-0004yg-8E; Tue, 21 Mar 2006 11:37:50 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjrh-0004yb-6o for simple@ietf.org; Tue, 21 Mar 2006 11:37:49 -0500
Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLjrg-0006lE-QC for simple@ietf.org; Tue, 21 Mar 2006 11:37:49 -0500
X-IronPort-AV: i="4.03,115,1141621200"; d="scan'208"; a="30355233:sNHT83050556"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 21 Mar 2006 11:37:46 -0500
Message-ID: <330A23D8336C0346B5C1A5BB19666647027B0830@ATLANTIS.Brooktrout.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: IM delivery reports for conferencing
Thread-Index: AcZMaIwp+tCU0MRNToSgG8JDGluh4wAAHCFAAAhAqLAAG1hkEAADi+GA
From: "Burger, Eric" <EBurger@cantata.com>
To: Sean Olson <Sean.Olson@microsoft.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d
Cc: simple@ietf.org
Subject: [Simple] RE: IM delivery reports for conferencing
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions <simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=subscribe>
Errors-To: simple-bounces@ietf.org
I could argue that it is both: the sender might want individual reports; the server, under any circumstance, would rather not batch. Batching would be (should be?) an enhanced, extra cost service, as it imposes a bunch of processing and storage requirements on the server. -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com] Sent: Tuesday, March 21, 2006 9:55 AM To: Burger, Eric; Hisham Khartabil Cc: simple@ietf.org Subject: RE: IM delivery reports for conferencing 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:EBurger@cantata.com] Sent: Monday, March 20, 2006 5:52 PM To: Sean Olson; Hisham Khartabil Cc: simple@ietf.org 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:Sean.Olson@microsoft.com] Sent: Monday, March 20, 2006 4:58 PM To: Hisham Khartabil Cc: Burger, Eric; simple@ietf.org 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:hisham.khartabil@telio.no] Sent: Monday, March 20, 2006 1:52 PM To: Sean Olson Cc: eburger@brooktrout.com; simple@ietf.org 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:hisham.khartabil@telio.no] > Sent: Wednesday, March 15, 2006 1:49 PM > To: Sean Olson > Cc: eburger@brooktrout.com; simple@ietf.org > 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="bob@example.com"> >> <type>read</type> >> <status>200</status> >> <note lang="en">The message has been read</note> >> </recipient> >> <recipient uri="alice@example.com"> >> <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@eburger@example.com >> </original-message-id> >> <reporting-uas uri="im:hisham.khartabil@example.net"> >> <original-recipient-uri> >> im:hisham.khartabil@example.net >> </original-recipient-uri> >> <disposition>read</disposition> >> </reporting-uas> >> <reporting-uas uri="im:eric.burger@example.net"> >> <original-recipient-uri> >> im:eric.burger@example.net >> </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 Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple
- [Simple] IM delivery reports for conferencing Sean Olson
- [Simple] RE: IM delivery reports for conferencing Burger, Eric
- [Simple] Re: IM delivery reports for conferencing Hisham Khartabil
- [Simple] RE: IM delivery reports for conferencing Sean Olson
- [Simple] RE: IM delivery reports for conferencing Sean Olson
- [Simple] Re: IM delivery reports for conferencing Hisham Khartabil
- [Simple] RE: IM delivery reports for conferencing Sean Olson
- [Simple] Re: IM delivery reports for conferencing Hisham Khartabil
- [Simple] RE: IM delivery reports for conferencing Sean Olson
- [Simple] RE: IM delivery reports for conferencing Burger, Eric
- [Simple] RE: IM delivery reports for conferencing Burger, Eric
- [Simple] RE: IM delivery reports for conferencing Sean Olson
- [Simple] RE: IM delivery reports for conferencing Burger, Eric
- [Simple] SIMPLE IETF 65 presentations available o… Markus.Isomaki
- [Simple] srtp negotiation on SIP (sdp message) 이종필
- Re: [Simple] srtp negotiation on SIP (sdp message) Jonathan Rosenberg
- Re: [Simple] srtp negotiation on SIP (sdp message) Adam Roach
- [Simple] RE: IM delivery reports for conferencing Burger, Eric
- Re: [Simple] srtp negotiation on SIP (sdp message) Spencer Dawkins
- Re: [Simple] RE: IM delivery reports for conferen… Dean Willis
- RE: [Simple] RE: IM delivery reports for conferen… Sean Olson
- Re: [Simple] RE: IM delivery reports for conferen… Ben Campbell
- Re: [Simple] RE: IM delivery reports for conferen… Ben Campbell
- RE: [Simple] RE: IM delivery reports for conferen… Sean Olson
- RE: [Simple] RE: IM delivery reports for conferen… Burger, Eric
- Re: [Simple] RE: IM delivery reports for conferen… Ben Campbell
- Re: [Simple] RE: IM delivery reports for conferen… Ben Campbell
- RE: [Simple] RE: IM delivery reports for conferen… Sean Olson
- Re: [Simple] RE: IM delivery reports for conferen… Ben Campbell
- Re: [Simple] RE: IM delivery reports for conferen… Dean Willis