Subject: Re: [Simple] I-D Action:draft-gautam-simple-quick-answer-00.txt

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Oct 2009 09:22:28 -0400

I just did a quick skim of this draft.
AFAICT, this draft is proposing a mechanism for configuring/provisioning 
UACs with some information, and for updating the information that is 
included in that provisioning.

I cannot think of any good reason why there should be a *unique* 
mechanism for this particular configuration information, in contrast to 
all the other information that a UA may need to be configured with.

For instance, the management of this information is conceptually no 
different than ring tone data that I might want to configure for my 
UA(s), or buddies I might want to have in my buddy list.

There is already a framework for getting configuration data into the UA, 
but less of one for updating that information. IMO it would make for 
sense to focus on that general problem, and on fitting this particular 
data into that framework.

	Thanks,
	Paul

The existing

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : Quick Answer for SIMPLE
> 	Author(s)       : D. Gautamn
> 	Filename        : draft-gautam-simple-quick-answer-00.txt
> 	Pages           : 10
> 	Date            : 2009-10-11
> 
> 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.  These short
> IM (here after referred as QA - Quick Answer) can be created, stored
> and used when needed.  This document defines a new QA content type
> and XML namespace that conveys QA between two entities.  The QAs are
> delivered to the instant messaging sender in the same manner as the
> instant messages themselves.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-gautam-simple-quick-answer-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Deepanshu Gautam <[email-masked]>
Date: Tue, 13 Oct 2009 16:44:20 +0800

Hi,

Thanks for your comments, some clarification are provided inline

> included in that provisioning.
This draft is not proposing a configuration/provisioning mechanism itself
instead it is proposing things (platform or base or protocol ) needed for
that kind of configuration. It does explains what kind of configuration is
needed but doesn't say how to do it.
The type of information (i.e Quick Answer) also plays a significant role in
the feasibility of the proposal. The draft is not intending for all the
information but for one specific information with particular characterstics.
Further, it is not saying anything
about updation, but for sure its a good thing to include.
>
> I cannot think of any good reason why there should be a *unique* mechanism
> for this particular configuration information, in contrast to all the
> other information that a UA may need to be configured with.
Because the solution proposed for this information involves MESSAGE carrying
something which is not a regular IM (firstly, the draft tries to make this
possible) and require some special behavior (secondly, the draft tries to
specify those behavior) from the involved entities such as registrar, UAC,
UAS. The question is whether we think that this solution is feasible for the
concept of Quick Answer or not.
> different than ring tone data that I might want to configure for my UA(s),
> or buddies I might want to have in my buddy list.
Differences would be:
You may not want to change/choose the ring tone everytime you get a message
or call.
You generally don't create a ring tone (some sort of user generated
content), you just get it from SP
You may not want to synchronize ring tones between your UA and server.
...
> but less of one for updating that information. IMO it would make for sense
> to focus on that general problem, and on fitting this particular data into
> that framework.
I think trying to fit this data in the avaliable configuration framework (in
other words, trying to make it possible on the top of that framework) will
involve much of overhead which may not be required/worth-taking for such a
simple concept. This can be simple done as stated in 1-2 (technical
solutions) pages in the draft. For instance, there is no need to define a
profile data, sending subsequent subscription request (enrolling) and
getting corresponding notification, retrieving content, ... for this.
I duly agree with you on the feasibility of the concept of updation here and
will work on that part. Adding updation concept to the whole avaliable
configuration  framework is, for sure, a right thing to do as well, but it
is not something being considered here at this point of time with this
draft.

----- Original Message ----- 
From: "Paul Kyzivat" <[email-masked]>
To: "Deepanshu Gautam" <[email-masked]>
Cc: "Simple WG" <[email-masked]>
Sent: Monday, October 12, 2009 9:22 PM
Subject: Re: I-D Action:draft-gautam-simple-quick-answer-00.txt

> I cannot think of any good reason why there should be a *unique* mechanism
> for this particular configuration information, in contrast to all the
> other information that a UA may need to be configured with.
>
> different than ring tone data that I might want to configure for my UA(s),
> or buddies I might want to have in my buddy list.
>
> but less of one for updating that information. IMO it would make for sense
> to focus on that general problem, and on fitting this particular data into
> that framework.
>
> Thanks,
> Paul
>
> The existing
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Oct 2009 09:16:09 -0400

In general it is easier, in the short term, to make a specific solution 
for a specific problem than it is to generalize the problem and solve 
that. But if you make lots of little focused mechanisms things overall 
get very complex and difficult to implement.

I personally find the problem itself not very interesting, and 
especially not compelling enough to design a specific mechanism for. If 
it were simply one more piece of configuration information that you were 
integrating into a general mechanism, then that wouldn't be an issue.

A bit more inlne...

> about updation, but for sure its a good thing to include.

As I read the draft, the "QA Holder" is a provisioning server for this 
information. The UA is "provisioned/configured" with quick answers by 
the QA holder, and the UA can update the QA Holder with new/revised 
quick answers.

So the QA Holder is a "micro" provisioning server, dedicated to this one 
kind of information.

>> mechanism

The use of MESSAGE is just a mechanism for achieving your end. It is in 
no way integral to the concept.

>> UA(s),

I might not what to change my quick answers every time I get a message 
or call either.

> You may not want to synchronize ring tones between your UA and server.

I might not, but then I might. E.g. I might hunt up and download my new 
favorite ring tone while using one phone, and then want that same ring 
tone on my other phones.

(Of course the SP would prefer that I pay for it again for each phone, 
but that's another story.)

>> sense
> simple concept.

You can say the same about almost everything.
The first use of sub/not was (I think) for message waiting.
Certainly there were other ways that the MWI info could have been hacked 
into sip. But it made more sense to have a generic mechanism.

There has been a lot of criticism of the configuration framework, 
including proposals to start over on it. Those have some merit. But I 
think there is little doubt that some sort of generic configuration 
mechanism is important. Building a separate mechanism for each piece of 
configuration information that comes along does not appeal to me.

	Thanks,
	Paul

> This can be simple done as stated in 1-2 (technical
> ----- Original Message ----- From: "Paul Kyzivat" <[email-masked]>
>> mechanism
>> UA(s),
>> sense

---

From: Deepanshu Gautam <[email-masked]>
Date: Wed, 14 Oct 2009 16:50:32 +0800

The issues with using config. framework for this would be:

1. The framework doesn't address the creation of profile data, which is the
integral part of this concept, in terms of QA Creation.
2. In case of sub/not: *subsequent* subscribe request are required to remain
subscribed for the requested content (which would be QA here). QA need to be
fetched eveytime a UA gets registered or UA Holder is updated, which will
happen pretty often, i guess. As i said before, why to define a profile
data, send subsequent subscription request (enrolling) and get corresponding
notification, retrieve content (all what in there in config. framework), if
it can be simplified to some extent as stated in the draft. MWI used sub/not
because that may be considered optimal for that. For this, sub/not is not
required at all, things (configuration/synchronization) can be initiated
simply on registration.

Anyway, i can think of the following to fit this in the general framework:
1. Depict QA Holder as PDS. And, extend the behavior of PDS as they are
defined for QA Holder. In this way there will be no seperate entity
proposed, instead the one in config. framework will be extended.
2. As the config. framework leaves the creation of profile data for further
standardization activities, the MESSAGE can be considered serving that
purpose.

Above two are just some initial thoughts, to make it work. Let me know
opinion on the above two points, if that seems to be a way forward.

I hope we can find a way out. This is a problem which needs to be solved (as
simply as it can) . There are real-world requirement for this. For instance,
OMA-IM has requirements for this function.

one more inline.........

----- Original Message ----- 
From: "Paul Kyzivat" <[email-masked]>
To: "Deepanshu Gautam" <[email-masked]>
Cc: "Simple WG" <[email-masked]>
Sent: Tuesday, October 13, 2009 9:16 PM
Subject: Re: I-D Action:draft-gautam-simple-quick-answer-00.txt

> that. But if you make lots of little focused mechanisms things overall get
> very complex and difficult to implement.
>
> I personally find the problem itself not very interesting, and especially
> not compelling enough to design a specific mechanism for. If it were
> simply one more piece of configuration information that you were
> information. The UA is "provisioned/configured" with quick answers by the
> QA holder, and the UA can update the QA Holder with new/revised quick
> answers.
>
> The use of MESSAGE is just a mechanism for achieving your end. It is in no
> way integral to the concept.
Its not about achieving ends, it is about what is correct and right to do. I
agree, there MAY be other ways but what we have on table, at this point of
time, is this.

Regards
Deepanshu
> I might not what to change my quick answers every time I get a message or
> call either.
>
> (Of course the SP would prefer that I pay for it again for each phone, but
> that's another story.)
>
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Oct 2009 12:51:08 -0400

I guess the first step is to find out if anyone else considers this a 
problem they would like to see solved.

	Thanks,
	Paul

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 14 Oct 2009 19:27:10 +0200

> problem they would like to see solved.

<joking-mode>
  Isn't the IETF purpose to deliver solutions nobody has required and also
  to provide half-done specifications (as SIMPLE/XCAP) so other
  specifications in top of them (as OMA's XDM) are needed to build an
  interoperable and feasible vendor solution?
</not-so-jokin-mode>

-- 
Iñaki Baz Castillo <[email-masked]>