[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Simple] RE: Advanced IM requirements
Hi,
See inline:
> -----Original Message-----
> From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of
> ext Eric Burger
> Sent: 29 February, 2004 15:31
> To: Chris Boulton; Niemi Aki (Nokia-M/Espoo)
> Cc: simple@ietf.org
> Subject: RE: [Simple] RE: Advanced IM requirements
>
>
> 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?
>
I guess SUBSCRIBE/NOTIFY still has problems over a long time period, as it requires refreshing, and the recovery of subscription state may be hard after e.g. powerdown, which is a quite normal thing with wireless endpoints.
Also, the notifications themselves, if they can be sent over a long time period, should be possible to store, if their recipient is not on-line. This seems to make MESSAGE a more suitable carrier.
Markus
> 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: simple@ietf.org
> > 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:jdrosen@dynamicsoft.com]
> > > Sent: Thursday, February 26, 2004 1:51 AM
> > > To: Chris Boulton
> > > Cc: Miguel.An.Garcia@nokia.com; simple@ietf.org; 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
> > > jdrosen@dynamicsoft.com FAX: (973) 952-5050
> > > http://www.jdrosen.net PHONE: (973) 952-5000
> > > http://www.dynamicsoft.com
> > >
> > >
> >
> >
> > _______________________________________________
> > Simple mailing list
> > Simple@ietf.org
> > https://www1.ietf.org/mailman/listinfo/simple
> >
> >
>
>
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
>
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple