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

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.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Feb 2004 14:07:54 -0500

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

Chris - just a couple of comments:

1) I don't see any particular reason to link this draft to GRUUs. The 
way receipts work, they may not be delivered until long after the 
message is sent. Anything that forces the receipt to be delivered to the 
same UA instance that sent the message is likely to cause problems. The 
response may well need to be captured by a recording device that 
wouldn't share a GRUU with the sending device. So I suspect that 
normally Receipt-To should mention the AOR of the sender. Of course the 
sender is still free to use a GRUU if desired, but it certainly isn't 
required.

2) I have some doubts about the need and value of the message-receipt 
option tag. Even if I sent you a message with Require: message-receipt, 
you are still free to not send me a receipt. (In the case of receipts 
with email I generally refuse to send them to parties unknown to me.) As 
a result, the option tag adds little or nothing. It should be sufficient 
to simply use the Receipt-To header without any option tag, and hope the 
recipient is willing and able to send a response.

	Paul