[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Simple] I-D Action:draft-gautam-simple-quick-answer-00.txt
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.
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.
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.
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.
...
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. 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