Subject: [Simple] New IM-specific feature

From: Deepanshu Gautam <[email-masked]>
Date: Mon, 10 Aug 2009 11:21:39 +0800

Dear All,

I would like to propose a new IM-specific feature for SIMPLE, which i would call as "Quick Answer(QA)". Allow me to explain about it briefly.

In instant messaging system, it is useful to have some readily available IM (text, audio or video) which can be sent in case of the receiver is too busy to type/speak/record for a reply. User can create and store IM (QA) using a particular client device and can use them when required. Creating and then storing on a single device may not be very useful because user can log-in a particular IM system using different client devices at different point of time. In that case QA created using one client device will not be available to another client device.

I would like to propose a draft to solve this problem and perform the needed standardization, which will further make this IM-feature possible. Before moving forward I would like to get some initial comment from the group about this idea. You comments would be valuable.

Regards
Deepanshu Gautam

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Aug 2009 18:44:20 -0400

Inline...

Deepanshu Gautam wrote:
> Dear All,
>  
> I would like to propose a new IM-specific feature for SIMPLE, which i 
> would call as "Quick Answer(QA)". Allow me to explain about it briefly.
>  
> In instant messaging system, it is useful to have some readily available 
> IM (text, audio or video) which can be sent in case of the receiver is 
> too busy to type/speak/record for a reply. User can create and store IM 
> (QA) using a particular client device and can use them when required. 
> Creating and then storing on a single device may not be very useful 
> because user can log-in a particular IM system using different client 
> devices at different point of time. In that case QA created using one 
> client device will not be available to another client device.
>  
> I would like to propose a draft to solve this problem and perform the 
> needed standardization, which will further make this IM-feature 
> possible. Before moving forward I would like to get some initial comment 
> from the group about this idea. You comments would be valuable.

Where do you imagine this new state would be stored?
And who/what would use it?

Are you proposing a "database" that is shared by the various UAs for an
AOR, that they would each update and retrieve from?

Would the sending of the answer still depend on a UA receiving the
message? Or do you expect that the answer will be sent even if there is
no UA registered?

IMO this doesn't fit well with the simple model.

	Thanks,
	Paul

> Regards
> Deepanshu Gautam
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple

---

From: Ben Campbell <[email-masked]>
Date: Mon, 10 Aug 2009 22:26:47 -0500

(as individual)

I concur with Paul's opinion (and questions).

To expand a bit, while I have seen some IM systems with this function,  
its utility seems weak in a _presence_ and IM system. That is, the  
sort of information one might put into a QA is better communicated as  
part of presence state. IMO, this sort of thing is exactly what the  
presence distribution mechanism was designed for.

---

From: Deepanshu Gautam <[email-masked]>
Date: Tue, 11 Aug 2009 13:14:07 +0800

inline with [DG]
----- Original Message ----- 
From: "Paul Kyzivat" <[email-masked]>
To: "Deepanshu Gautam" <[email-masked]>
Cc: "Simple WG" <[email-masked]>
Sent: Tuesday, August 11, 2009 6:44 AM
Subject: Re: [Simple] New IM-specific feature

> And who/what would use it?
[DG] I don't see this as a new state (if you are referring to IM user state
like "ideal", "active" defined in 3994). Irrespective of state, the only
concerns here is that "an IM is received and user would like to select from
a list of messages (here QA) as reply to that IM". Problem to solve: how to 
create and make that list of messages avaliable on various UAs.
I foresee these QA to be stored both on server and UA.[/DG]
> AOR, that they would each update and retrieve from?
[DG]No, Actually i'm proposing protocol(s) to make that kind of database
avaliable[/DG]

> message? Or do you expect that the answer will be sent even if there is
[DG] According to me, till now, it depends on UA receiving the message. But,
it may be other way round too, if we have feasible usecase/requirement.[/DG]

---

From: Deepanshu Gautam <[email-masked]>
Date: Tue, 11 Aug 2009 17:27:45 +0800

I can foresee some disadvantage of using Presence for this as follows.
1. Adds more overhead as an explicit and periodic subscription is required 
(i.e Events and extension to presence).
2. Presence fits situation where IM sender (as watcher) gets information 
about IM recipient (as presentity), here the situation is reverse.
3. Will not allow user to choose from different option (QA) avaliable in 
real-time.
4. I may want to send some QA to those who are not my 'watchers' (because 
they don't care about my presence information) but v.important to me e.g HR 
delegate from a probable employer :-)
5. For page-mode delivery, subscribing to the right user agent and set of 
messages may not be easy.

We can consider these QA somewhat analogous to multimedia message-templates 
in current messaging(SMS, MMS, ...) system which is usefull and widely used. 
User can themselves create them for future use.

Regards
Deepanshu

----- Original Message ----- 
From: "Ben Campbell" <[email-masked]>
To: "Deepanshu Gautam" <[email-masked]>; "Simple WG" <[email-masked]>
Cc: "Paul Kyzivat" <[email-masked]>
Sent: Tuesday, August 11, 2009 11:26 AM
Subject: Re: [Simple] New IM-specific feature

> its utility seems weak in a _presence_ and IM system. That is, the  sort
> of information one might put into a QA is better communicated as  part of
> presence state. IMO, this sort of thing is exactly what the  presence
> distribution mechanism was designed for.
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Aug 2009 08:57:23 -0400

Deepanshu Gautam wrote:
> inline with [DG]
> ----- Original Message ----- From: "Paul Kyzivat" <[email-masked]>
> a list of messages (here QA) as reply to that IM". Problem to solve: how 
> to create and make that list of messages avaliable on various UAs.

Which server? The registrar?

IIUC you are then just proposing that the registrar provide storage for
attributes that the various UAs registering to an AOR would share?

That is a very slippery slope, since there are many pieces of
state/configuration that UAs might like to store or share.

> [DG]No, Actually i'm proposing protocol(s) to make that kind of database

This is especially ugly when it calls for specific protocol additions to
SIP to maintain each piece of such state that comes along.

This sounds much more like provisioning information, to be maintained by
a provisioning server and made available to the controlled devices.

> usecase/requirement.[/DG]

If you go that way, it becomes much more like a voicemail system.
(In this case, a "IM-mail" system.) Namely it is a UA of last resort for
responding to incoming requests if no other UA does. Its not really part
of a registrar, though it *might* be collocated with one.

This is not an unreasonable thing to do - its pretty common. But so far
there have been no proposals to standardize anything about this as part
of SIMPLE. (Nor have there been any to standardize voicemail systems.)

	Thanks,
	Paul

---

From: Deepanshu Gautam <[email-masked]>
Date: Wed, 12 Aug 2009 15:14:11 +0800

When i say "protocols" i only mean to define a new XML schema (to carry QA 
as instance of it) and a content-type (for labelling that QA), thats it. I 
don't see any thing ugly in that. It has been done for other two IM-specific 
feature already.

I can agree with you on bit of a relation between QA and what you call 
"IM-mail" and would like to consider it further. However, i can think of a 
prominent difference i.e "IM-mail" will not allow user to choose from the 
avaliable options in real time (i.e when it has received an IM)

About storage, i think that would not be on registrar. Can we consider 
storage of QA as implementation specific? We just provide a mechanism (XML 
schema/content-type) to deliver QA between two entities. How to store them 
will be implementation specific. Some IM application server (e.g OMA 
IM-XDMS) or provisioning server can do that. Will that make sense?

Regards
Deepanshu

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Aug 2009 09:49:19 -0400

Deepanshu Gautam wrote:
> When i say "protocols" i only mean to define a new XML schema (to carry 
> QA as instance of it) and a content-type (for labelling that QA), thats 
> it. I don't see any thing ugly in that. It has been done for other two 
> IM-specific feature already.

I hadn't realized you wanted to carry this info in a body part.

But then you would need to specify in which messages it is conveyed, and
what the semantics are of including it in those messages. What did you
have in mind? Were you thinking of using REGISTER and its response to
convey this? Or were you going to send this in a MESSAGE?

> "IM-mail" and would like to consider it further. However, i can think of 
> a prominent difference i.e "IM-mail" will not allow user to choose from 
> the avaliable options in real time (i.e when it has received an IM)
> 
> storage of QA as implementation specific? We just provide a mechanism 
> (XML schema/content-type) to deliver QA between two entities. How to 
> store them will be implementation specific. Some IM application server 
> (e.g OMA IM-XDMS) or provisioning server can do that. Will that make sense?

The problem is that you have to pass the data in some message, and have
some reason to believe it will be received by something that will
process it as you expect. That implies some level of standardization of
the behavior.

(The long history of trouble with INFO is testament to what happens if
you don't address such issues.)

If I am to send the info in REGISTER, then I am counting on some
behavior by the registrar to do something with it. Its even more
important if I expect the *response* to the REGISTER to give me such data!

I still think this sounds like a provisioning problem.

	Thanks,
	Paul

---

From: Deepanshu Gautam <[email-masked]>
Date: Fri, 14 Aug 2009 13:41:52 +0800

----- Original Message ----- 
From: "Paul Kyzivat" <[email-masked]>
To: "Deepanshu Gautam" <[email-masked]>
Cc: "Simple WG" <[email-masked]>
Sent: Wednesday, August 12, 2009 9:49 PM
Subject: Re: [Simple] New IM-specific feature

> convey this? Or were you going to send this in a MESSAGE?
[DG] The MESSAGE is what i have in my mind.
> important if I expect the *response* to the REGISTER to give me such data!
[DG] Let me go 1 step further in explanation
I would divide the whole work to be done in two steps.
1. QA creation - Here the QAs are created by UA
2. QA Usage - Here a QA is selected by UA from the avaliable list of UAs.
In step 1 UA will create QA and send to something (lets call it as QA 
Storer).
This QA storer will be implementation specific. We *will* standardize the
behaviour of this QA storer to *some extent* (leaving scope for addition).
It may be further implemented by other standard organization like OMA.
Step 2 will be straight forward: delivery of QA from QA Sender to QA
Receiver using XML schema in MESSAGE body.
Is this sounds feasible to you? Something which SIMPLE can do?