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" <pkyzivat at cisco.com>
To: "Deepanshu Gautam" <deepanshu at huawei.com>
Cc: "Simple WG" <simple at ietf.org>
Sent: Tuesday, October 13, 2009 9:16 PM
Subject: Re: I-D Action:draft-gautam-simple-quick-answer-00.txt
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...
Deepanshu Gautam wrote:
Hi,
Thanks for your comments, some clarification are provided inline
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.
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.
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.
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.
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
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.
Differences would be:
You may not want to change/choose the ring tone everytime you get a
message
or call.
I might not what to change my quick answers every time I get a message or
call either.
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.
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.)
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.
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.
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
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.
Thanks,
Paul
----- Original Message ----- From: "Paul Kyzivat" <pkyzivat at cisco.com>
To: "Deepanshu Gautam" <deepanshu at huawei.com>
Cc: "Simple WG" <simple at ietf.org>
Sent: Monday, October 12, 2009 9:22 PM
Subject: Re: I-D Action:draft-gautam-simple-quick-answer-00.txt
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
Internet-Drafts at ietf.org 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
I-D-Announce at ietf.org
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