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

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

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

---

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

_______________________________________________
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

_______________________________________________
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: "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