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

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?

> -----Original Message-----
> From: Eric Burger 
> Sent: Friday, February 27, 2004 4:24 PM
> To: Jonathan Rosenberg; Chris Boulton
> Cc: [email-masked]
> Subject: RE: [Simple] RE: Advanced IM requirements
> 
> 
> 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 :-)
> 
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:[email-masked]]
> > Sent: Thursday, February 26, 2004 1:51 AM
> > To: Chris Boulton
> > Cc: [email-masked]; [email-masked]; Eric Burger
> > Subject: Re: [Simple] RE: Advanced IM requirements
> > 
> > 
> > 
> > 
> > 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.
> > 
> > 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
> > 
> > 
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 29 Feb 2004 21:17:50 -0500

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

Using SIP for the notification request isn't sufficient, because it only 
works for page mode IM. An entirely different mechanism would be 
required for session mode. But if the request is conveyed via CPIM then 
it can be the same for both forms of messaging.

Note that in the case of session mode messaging, the notification will 
likely not be returned in the same session. And notifications in general 
need not be returned using the same mode (page/session) as the original 
message.

That is actually an interesting issue - what mode should be used for 
returning the receipt. (If a lot of receipts need to be sent at once 
then a session may be justified. But if establishing a session 
necessitates alerting the end user then it might be a bad choice. This 
appears to be part of a larger subject - how and when a choice is made 
between page mode and session mode.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 29 Feb 2004 21:17:50 -0500

Paul