Subject: RE: [Simple] RE: Advanced IM requirements

From: "Eric Burger" <[email-masked]>
Date: Mon, 1 Mar 2004 17:10:16 -0500

The first example is where the message sender is in a session and wants a notification on a particular message.  In that case, one could argue that the notification is still a one-shot message, and does not need a session.

I could see that someone could request confirmation on every message they send.  In that case, an optimization would be to have the notifications streamed.  That said, I think that use case really would drive a different protocol (Reliable IM?).

The second example is where the message sender sends a message to an exploder or conference bridge.  The first thing we should consider is whether the notification comes from the exploder/bridge or from the endpoints themselves.  In the SIP world, it does make a difference if we are talking exploder vs. bridge.  In the exploder case, the notifications come from the endpoints themselves.  Stream mode for the responses does not necessarily help.

In the bridge case, the endpoint only has a dialog with the bridge.  Thus, the bridge is where the notification has to come from.  The bridge could act as a state agent, optimizing network usage either by aggregating responses or opening a session for notifications.

Am I off-base in thinking the transport mode (stream v. one-shot) is independent of the notification?

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, March 01, 2004 1:44 AM
> To: Eric Burger
> Cc: [email-masked]
> Subject: Re: [Simple] RE: Advanced IM requirements
> 
> 
> 
> 
> Eric Burger wrote:
> > I agree.  Again, this highlights why IMDN is at the CPIM, 
> and not SIP, level.
> > 
> > Further, what is the use case for MDN in session mode?  
> Would anyone EVER use it?  I doubt it: if you are in a 
> session, presumably you are interactive, which means you have 
> OOB methods for knowing the message wasn't read (e.g., no 
> response from the other person).
> 
> I agree it doesn't seem like something that normally would be 
> used. But 
> there may be some cases. I may want explicit confirmation that a 
> particular message has not only been delivered, but read. (This might 
> require the UAS to demand some explicit confirmation from the 
> end user 
> before sending the confirmation.)
> 
> Another case is with an IM conference. If I send a message to 
> the mixer, 
> requesting confirmation, ideally that would be an end-to-all-ends 
> confirmation. The mixer would have to request and receive 
> confirmation 
> from all recipients before confirming to sender.
> 
> > Given that assertion, can we say IMDN's are page mode messages.
> 
> Based on above, I say NO.
> 
> 	Paul
> 
> 
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: "Eric Burger" <[email-masked]>
Date: Tue, 2 Mar 2004 00:49:53 -0500

You didn't misinterpret me; I was just a bit daft :-)

My assertion was that if you are in a session, you are probably being interactive.  There is no reason to prohibit the notification, but I still doubt it will ever be used.

> Sent: Tuesday, March 02, 2004 12:21 AM
[snip]
> > Am I off-base in thinking the transport mode (stream v. 
> one-shot) is independent of the notification?
> 
> The reason I posted this message was that in a prior message 
> you seemed 
> to be suggesting that delivery notification might not be required for 
> session mode messages.
> 
> I too think that the mode (page/session) used for delivery 
> notifications 
> is independent of the mode used for the message being confirmed.
> 
> 	Paul
[snip]

---

From: "Eric Burger" <[email-masked]>
Date: Tue, 2 Mar 2004 00:49:53 -0500

[snip]
[snip]

---

From: "Chris Boulton" <[email-masked]>
Date: Mon, 1 Mar 2004 07:00:36 -0000

-----Original Message----- 
	From: Paul Kyzivat [mailto:[email-masked]] 
	Sent: Mon 01/03/2004 06:44 
	To: Eric Burger 
	Cc: [email-masked] 
	Subject: Re: [Simple] RE: Advanced IM requirements

	Eric Burger wrote:
	> I agree.  Again, this highlights why IMDN is at the CPIM, and not SIP, level.
	>
	> Further, what is the use case for MDN in session mode?  Would anyone EVER use it?  I doubt it: if you are in a session, presumably you are interactive, which means you have OOB methods for knowing the message wasn't read (e.g., no response from the other person).
	
	I agree it doesn't seem like something that normally would be used. But
	there may be some cases. I may want explicit confirmation that a
	particular message has not only been delivered, but read. (This might
	require the UAS to demand some explicit confirmation from the end user
	before sending the confirmation.)

	<<CJB>> This is ceratainly the reason I allowed for more than one receipt per transaction.  The notion of delievery + read receipts is something that is quite beneficial + copies current SMS. 

	Another case is with an IM conference. If I send a message to the mixer,
	requesting confirmation, ideally that would be an end-to-all-ends
	confirmation. The mixer would have to request and receive confirmation
	from all recipients before confirming to sender.

	<<CJB>> Sorry Paul, I'm with Eric and still just don't see when this would be used.
	
	        Paul

	_______________________________________________
	Simple mailing list
	[email-masked]
	https://www1.ietf.org/mailman/listinfo/simple <https://www1.ietf.org/mailman/listinfo/simple> 

This message has been scanned for viruses by MailControl - www.mailcontrol.com
J)��隊X��X��(��W�z��m��?�0�'�~���f��f��X��)ߣ�"��^

---

From: "Chris Boulton" <[email-masked]>
Date: Mon, 1 Mar 2004 07:00:36 -0000

-----Original Message----- 
	From: Paul Kyzivat [mailto:[email-masked]] 
	Sent: Mon 01/03/2004 06:44 
	To: Eric Burger 
	Cc: [email-masked] 
	Subject: Re: [Simple] RE: Advanced IM requirements

	

	
	        Paul

---

From: "Eric Burger" <[email-masked]>
Date: Tue, 2 Mar 2004 22:54:15 -0500

Common scenario:
You send me an IM.  My device receives the message, forwards it to me, I read it.  Is my device going to send you two messages, a provisional MDN saying I got the message and a final MDN saying I read the message?  Doesn't SIP tell you if my device got the message?

Likely Scenario:
You send me an IM.  My device receives the message, creates a provisional MDN, because my device is online.  The MDN says the relay has received the message, but has not delivered it.

Unfortunately, I've turned off my device, because I am going to Korea for a week.

Are you suggesting the IM relay should open a session mode connection and leave it up for a week until I get back?

> From: Chris Boulton [mailto:[email-masked]]
> Sent: Monday, March 01, 2004 2:01 AM
> To: Paul Kyzivat; Eric Burger
> Cc: [email-masked]
> Subject: RE: [Simple] RE: Advanced IM requirements
> 
> 
>  
> 
> 	> Further, what is the use case for MDN in session 
> mode?  Would anyone EVER use it?  I doubt it: if you are in a 
> 	<<CJB>> This is ceratainly the reason I allowed for 
> more than one receipt per transaction.  The notion of 
> delievery + read receipts is something that is quite 
> beneficial + copies current SMS. 
> 
> 	
> 	
> <https://www1.ietf.org/mailman/listinfo/simple> 
> 	
> 
> 
> 
J)隊XX(Wzm?0'~ffX)ߣ"^
���^����x%��R�jez'�~����i����
bz���j)fj��b��?�)��

---

From: [email-masked]
Date: Wed, 3 Mar 2004 07:54:43 +0200

In case there is a store and forward server. You will get a 202. Once the recipient actually receives the message, you will get the first notification indicating recipient receiving message.

In peer-to-peer case, you are right.

/Hisham

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Eric Burger
> Sent: 03.March.2004 05:54
> To: Chris Boulton
> Cc: [email-masked]
> You send me an IM.  My device receives the message, forwards 
> it to me, I read it.  Is my device going to send you two 
> messages, a provisional MDN saying I got the message and a 
> final MDN saying I read the message?  Doesn't SIP tell you if 
> my device got the message?
> 
> 
> Likely Scenario:
> You send me an IM.  My device receives the message, creates a 
> provisional MDN, because my device is online.  The MDN says 
> the relay has received the message, but has not delivered it.
> 
> Are you suggesting the IM relay should open a session mode 
> connection and leave it up for a week until I get back?
> 
> 
> 
> 
> J)隊XX(Wzm?> 0'~ffX)ߣ"^
> Jz~

---

From: [email-masked]
Date: Wed, 3 Mar 2004 07:54:43 +0200

/Hisham

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 3 Mar 2004 07:07:16 -0000

Common scenario:

<<CJB>> SIP tells you that the transaction has completed - not that it has been delivered to your device.  Say I send you a message - your mobile handset is turned off - so my local storage retrieval service returns a 2xx - this doesn't mean that the message has been delivered + read.
 
You are also assuming that a user reads a message as soon as it is received. 

Likely Scenario:

J)隊XX(Wzm? 0'~ffX)ߣ"^

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 3 Mar 2004 07:07:16 -0000

Common scenario:

Likely Scenario:

J)隊XX(Wzm? 0'~ffX)ߣ"^

---

From: Ben Campbell <[email-masked]>
Date: Fri, 27 Feb 2004 16:02:07 -0600

Ben Campbell wrote:
> Aki Niemi wrote:
> 
>>
>> ext Jonathan Rosenberg wrote:
>>
>>>
>>>
>>>
>>> Chris Boulton wrote:
>>>
>>>> 1. it placed the URI for sending the delivery notification as a CPIM
>>>> header, not a SIP header
>>>>
>>>> <<CJB>> Out of interest, what was the driving force for this design 
>>>> choice?
>>>
>>>
>>>
>>>
>>> I believe the document talks a bit about this. It would make the 
>>> mechanism applicable to any system that uses cpim, which would 
>>> include IM sessions and in theory any other IMPP compliant IM 
>>> protocol, though since XMPP is not using it there are practically 
>>> none others.
>>
>>
>>
>> Perhaps that's a good sign that we should up a notch the place where 
>> MDNs are defined. In other words perhaps we should define the MDNs for 
>> SIP MESSAGE instead of message/cpim.
>>
>> This would enable us to request/receive delivery reports without 
>> having to wrap content in message/cpim.
> 
> 
> And it would make it harder to request delivery reports across gateways. 
> Are CPIM routers all that expensive?

Uhm, I meant CPIM wrappers. Not routers. I am willing to believe that 
CPIM routers may be expensive.

> 
>>
>> Cheers,
>> AKi
>>
>>> Of course, Eric is the author of this and is better suited to answer 
>>> the question.
>>>
>>> -Jonathan R.
>>
>>
>>

---

From: "Eric Burger" <[email-masked]>
Date: Sun, 29 Feb 2004 08:30:37 -0500

The differences between the drafts goes much farther than e-mail format versus XML format.  That said, other than "XML is cool", is there a reason for using XML instead of reusing the Message Disposition Notification's e-mail-oriented syntax?

First and foremost, the sipping-message-receipt draft does not specify the reporting period.  simple-imdn explicitly states that the recipient will send one and only one notification.  This simplifies state management at the sender.  It also eliminates an avenue for a denial-of-service attack, whereby the sender gets flooded with notifications as the message is received, processed, read, and deleted.

If there is a requirement for following the entire lifetime of a message, SUBSCRIBE/NOTIFY is a much better technology than either sipping-message-receipt or simple-imdn.  That said, I cannot imagine a use case that requires such notification.  Am I missing something?

Paul's comments hold: GRUU is not likely to be a good idea for notifications.  In fact, the reason that e-mail notifications and simple-imdn notifications can go to a different URI than the message sender is that the notification processor is often an automaton.  The user does not want to see the notifications -- they just want to see the blinky light turn off or the grey icon turn solid.

Moreover, the UAC instance could be long gone by the time the message has a disposition.  If you were in an interactive conversation, you wouldn't need notification in the first place...

Is there a reason for the notification request and protocol machinery to be a SIP, and not CPIM, construction?  Is this a generic notification protocol for SIP?  If so, are there use cases outside of CPIM?  This also is an issue for the report MIME type.  It is OK if it is a generic SIP tool.  However, I would call it something other than application/receipt-info+xml if it is only for IM.  I would call it what it is, something like application/simple-notification+xml.

One place where the issue of notification being a SIP vs. CPIM construct is message correlation.  The sipping-message-receipt draft goes to great lengths (e.g., invoking GRUU and GRID) to identify a message.  However, there already is a MsgID parameter in CPIM.  Users have no concept of GRUU or GRID, but they do have concepts (or at least the user interface can make sensible indicators) of message ID.  Likewise, the use of Call-ID for <message-id> doesn't make sense.

The normative UAS behavior is, IMHO, not correct for a message that requires disposition notification.  If the UAC requires a message disposition report, and the UAS refuses to give one, the message should be rejected.  In the e-mail world, this is how we train UAC's to not ask.

On the processing of the Receipt-To header, the sipping-message-receipt draft suggests that "Receipt-To" SHOULD NOT be in a notification.  This really, really, really has to be MUST NOT.  Under what circumstance is it OK for a notification to ask for a notification?  While we're at it, the UAC needs a "MUST disregard Receipt-To in a notification".

Concerning the <final-destination> element: It is useful to expose the route choices for error reports.  However, for notification reports is it a good idea to expose the UAS' actual Request-URI?

simple-imdn explicitly did not include the <deleted> state.  What does that mean for an Instant Message?

> From: Eric Burger 
> Sent: Friday, February 27, 2004 4:24 PM
> To: Jonathan Rosenberg; Chris Boulton
> Cc: [email-masked]
> The IMDN proposal (draft-burger-simple-imdn-00.txt) reuses 
> all of the protocol machinery, parsers, and deployment 
> experience of the MDN machinery from the messaging world.
> 
> Do note that almost half of the IMDN draft deals directly or 
> indirectly with security issues.  The message-receipt draft 
> will need to be expanded greatly to address the IESG issues 
> that are sure to arise that the messaging folks have hashed 
> through in the past.
> 
> I'll take a closer look at the message-receipt draft over the 
> weekend (isn't that what long plane flights are for?).  
> Expect more on Monday, Korea Time :-)
> 
> > From: Jonathan Rosenberg [mailto:[email-masked]]
> > Sent: Thursday, February 26, 2004 1:51 AM
> > To: Chris Boulton
> > Cc: [email-masked]; [email-masked]; Eric Burger
> > > <<CJB>> Out of interest, what was the driving force for 
> > this design choice?
> > 
> > mechanism applicable to any system that uses cpim, which 
> > would include 
> > IM sessions and in theory any other IMPP compliant IM 
> > protocol, though 
> > since XMPP is not using it there are practically none others.
> > 
> > Of course, Eric is the author of this and is better suited to 
> > answer the 
> > question.
> > 
> > -Jonathan R.
> > -- 
> > Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> > Chief Technology Officer                    Parsippany, NJ 
> 07054-2711
> > dynamicsoft
> > [email-masked]                     FAX:   (973) 952-5050
> > http://www.jdrosen.net                      PHONE: (973) 952-5000
> > http://www.dynamicsoft.com
> > 
> > 
> 
>