Subject: [Simple] RE: Advanced IM requirements

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.

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: 24 February 2004 12:11
>To: Chris Boulton; [email-masked]; [email-masked]
>Subject: RE: Advanced IM requirements
>
>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.

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

>
>/Miguel
>
>
>
>> -----Original Message-----
>> 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.
>>
>>
>> >-----Original Message-----
>> >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,
>> >
>> >	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
>
>_______________________________________________
>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

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

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 24 Feb 2004 23:28:43 -0500

Trimming to simple...

> particular grid parameter - otherwise dispose of state (But I agree -

The usage of Require/Supported is orthogonal to whether you place a gruu 
in the Receipt-To header field. I agree with Miguel here that usage of 
Require is inappropriate in the 2xx response. Indeed, I think you need 
to be clear on the role of Supported vs. the Receipt-To header field. 
The former merely indicates that the extension is supported. The latter 
explicitly asks for notifications. The two are not the same.

I also agree with Paul's comment that a GRUU is probably not a good idea 
for inclusion in this header field, since the acknowledgement can come 
much later, and you don't want it to be tied to a specific instance.

Also, note that there was a previous ID submitted on IM delivery 
notifications:
http://www.watersprings.org/pub/id/draft-burger-simple-imdn-00.txt

That spec differed in a few ways:

1. it placed the URI for sending the delivery notification as a CPIM 
header, not a SIP header

2. It used the existing email delivery status notification.

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

-Jonathan R.

Chief Technology Officer                    Parsippany, NJ 07054-2711

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 24 Feb 2004 23:28:43 -0500

Trimming to simple...

-Jonathan R.