Subject: [Simple] Advanced IM requirements

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 22 Feb 2004 01:16:45 -0500

Folks,

As I noted earlier, I resubmitted the advanced IM requirements draft. It 
specifies a bunch of advanced IM functions we havent yet tackled here. 
They are:

* delivery reports for IM
* is-typing indicator (Henning had an I-D on this that has expired)
* capabilities indications of maximum desired message sizes for IM
* page mode groups (under discussion in the context of exploders in sipping)
* invitations to non-real time sessions

The last of these is particularly interesting. One use case is "call 
alerts" in PTT. There, I send you a request to have a PTT chat. The 
request is not answered in real time. Rather, its stored by the 
recipient as if it were an IM, and can be answered at any time later. 
"Answering it" merely involves setting up a PTT call back to the caller. 
Its also possible to cancel the call alert at any time.

There are some interesting ways to accomplish this function. The one 
I've been thinking about is taking a SIP INVITE message, and sending it 
in the body of a MESSAGE request as a message/sip content. I'm sure 
there are other ways.

Are these topics for which there is still group interest in working on? 
I think all of them remain quite important.

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

---

From: "Chris Boulton" <[email-masked]>
Date: Mon, 23 Feb 2004 10:40:01 -0000

Hi Jonathan et al,

	I have an extremely early version (so be gentle) of a draft
aimed at supplying IM delivery reports.  It hasn't been formally
submitted yet but I have attached a copy - so would be grateful if the
list could take a look and see if it's worth progressing.  I will submit
to the archives in the next few days.  I will also put this on the
internet somewhere in case this attachment doesn't survive its journey
(Will send link later).

Best Regards,

Chris.

>-----Original Message-----
>From: Jonathan Rosenberg [mailto:[email-masked]]
>Sent: 22 February 2004 06:17
>To: Simple WG
>Subject: [Simple] Advanced IM requirements
>
>Folks,
>

This message has been scanned for viruses by MailControl - www.mailcontrol.com

---

From: "Chris Boulton" <[email-masked]>
Date: Mon, 23 Feb 2004 10:40:01 -0000

Hi Jonathan et al,

Best Regards,

Chris.

---

From: "Chris Boulton" <[email-masked]>
Date: Mon, 23 Feb 2004 17:00:57 -0000

As promised.

https://www.ubiquity.net/draft-boulton-sipping-message-receipt-00.txt

Chris.

>From: Chris Boulton
>Sent: 23 February 2004 10:40
>To: 'Jonathan Rosenberg'; Simple WG
>Cc: [email-masked]'
>Subject: RE: [Simple] Advanced IM requirements
>
>Hi Jonathan et al,
>
aimed at
>supplying IM delivery reports.  It hasn't been formally submitted yet
but I
>have attached a copy - so would be grateful if the list could take a
look
>and see if it's worth progressing.  I will submit to the archives in
the
>next few days.  I will also put this on the internet somewhere in case
this
>attachment doesn't survive its journey (Will send link later).
>
>Best Regards,
>
>Chris.
>
>

---

From: [email-masked]
Date: Tue, 24 Feb 2004 14:11:20 +0200

A comment on the usage of the Require header in the MESSAGE receipt draft.

As far as I know, the Require header is used to indicate the peer that the request should not be processed if the extension is not supported.

You apply the Require header to the response... which is a bit weird, because you tell me what should be the action of the UAC if it does not support the functionality.

You can argue that we have already used Require headers in SIP responses (e.g.., 100rel). But there it had a clear meaning: there is an action that has to be taken upon the reception of the response: to generate a PRACK. But in your draft, I didn't see an equivalence.

In my view, this mechanism should only be applicable to Support headers in requests. If the message is no delivered, then a DSN can be generated, because of the Support header tag in the request.

And that comes to my next question. Do you intend proxies to generate DSNs to non delivered messages? I guess this is the idea, but I didn't find a "Proxy behavior" section in the document.

/Miguel

> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> ext Chris Boulton
> Sent: 23 February, 2004 19:01
> To: Simple WG; sipping
> Subject: [Sipping] FW: [Simple] Advanced IM requirements
> 
> 
> 
> 
> As promised.
> 
> >>As I noted earlier, I resubmitted the advanced IM 
> requirements draft.
> It

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: [email-masked]
Date: Tue, 24 Feb 2004 14:11:20 +0200

/Miguel

---

From: "Chris Boulton" <[email-masked]>
Date: Tue, 24 Feb 2004 12:45:01 -0000

Miguel - thanks for taking the time to read this - I have included a
couple of comments in-line.

>From: [email-masked] [mailto:[email-masked]]
>Sent: 24 February 2004 12:11
>To: Chris Boulton; [email-masked]; [email-masked]
>Subject: RE: Advanced IM requirements
>
>As far as I know, the Require header is used to indicate the peer that
the
>request should not be processed if the extension is not supported.
>
>You apply the Require header to the response... which is a bit weird,
>because you tell me what should be the action of the UAC if it does not
>support the functionality.
>
>You can argue that we have already used Require headers in SIP
responses
>(e.g.., 100rel). But there it had a clear meaning: there is an action
that
>has to be taken upon the reception of the response: to generate a
PRACK.
>But in your draft, I didn't see an equivalence.
>
>In my view, this mechanism should only be applicable to Support headers
in
>requests. If the message is no delivered, then a DSN can be generated,
>because of the Support header tag in the request.

[Chris Boulton] Seems reasonable to me.  This is an early version and I
will note this as a point for my discussions in Korea.  My intention was
to encourage a stateless mechanism that allowed for state-full
processing if required when used with a GRUU.  In that if a UAC issued a
MESSAGE with a GRUU + grid parameter, it would need state for the grid
association on the incoming receipt(Even though this is discouraged).
So the intended action for the UAC was to remain state-full for that
particular grid parameter - otherwise dispose of state (But I agree -
not a SIP action).

>
>And that comes to my next question. Do you intend proxies to generate
DSNs
>to non delivered messages? I guess this is the idea, but I didn't find
a
>"Proxy behavior" section in the document.

[Chris Boulton] In this initial draft, the mechanism only applies to
successful MESSAGE requests (2xx class recpose).  It covered scenarios
where the message had arrived at a store-forward device OR delivered to
the handset but had not been read etc.  Again, I am interested in the
lists thoughts on this so please let me know.  I will also note this
down for discussion.

Chris.

>> >>I've been thinking about is taking a SIP INVITE message, and
sending
>> it

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 25 Feb 2004 16:09:37 -0000

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?

2. It used the existing email delivery status notification.

<<CJB>> A new XML schema was chosen as it allowed extensibility.  As mentioned before this is an early version of this 
work and the plan is to make it as generic as possible - This will be discussed in Korea.  That way implementors could use
it as a framework and extend if required.

These, I think, represent the main design choices for such an extension.

-Jonathan R.

This message has been scanned for viruses by MailControl - www.mailcontrol.com
¢š™^™¨¥Šx%ŠËRŠjez'~Šà†Ûi³ÿðÃ
bz×è®æj)fjåŠËb�ú?²)©•

---

From: "Eric Burger" <[email-masked]>
Date: Fri, 27 Feb 2004 16:24:21 -0500

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

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

---

From: "Eric Burger" <[email-masked]>
Date: Fri, 27 Feb 2004 16:24:21 -0500

---

From: [email-masked]
Date: Sun, 29 Feb 2004 15:16:22 +0200

Hi,

I agree that it should be enough if we do this for SIP MESSAGE only, not for CPIM in general.

Also I think this work should borrow as much as possible from the current e-mail mechanims, so we would not need to re-invent stuff that already works there.

Markus

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Aki Niemi
> Sent: 26 February, 2004 14:44
> To: ext Jonathan Rosenberg
> Cc: Chris Boulton; Garcia Miguel.An (Nokia-NRC/Helsinki);
> [email-masked]; Eric Burger
> ext Jonathan Rosenberg wrote:
> > 
> > 
> > 
> > Chris Boulton wrote:
> > 
> >> <<CJB>> Out of interest, what was the driving force for 
> this design 
> >> choice?
> > 
> > 
> 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.
> 
> Cheers,
> AKi
> 
> > Of course, Eric is the author of this and is better suited 
> to answer the 
> > question.
> > 
> > -Jonathan R.
>

---

From: [email-masked]
Date: Sun, 29 Feb 2004 15:16:22 +0200

Hi,

Markus

---

From: [email-masked]
Date: Sun, 29 Feb 2004 18:08:02 +0200

Hi,

See inline:

> ext Eric Burger
> Sent: 29 February, 2004 15:31
> To: Chris Boulton; Niemi Aki (Nokia-M/Espoo)
> Cc: [email-masked]
> 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?
> 
> > 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 :-)
> > 
> > > this design choice?

---

From: [email-masked]
Date: Sun, 29 Feb 2004 18:08:02 +0200

Hi,

Markus

---

From: "Eric Burger" <[email-masked]>
Date: Sun, 29 Feb 2004 21:23:59 -0500

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

Given that assertion, can we say IMDN's are page mode messages.

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Sunday, February 29, 2004 9:18 PM
> To: Eric Burger
> Cc: Chris Boulton; [email-masked]; [email-masked]
> Eric Burger wrote:
> 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: "Eric Burger" <[email-masked]>
Date: Sun, 29 Feb 2004 21:23:59 -0500